Hi
Comments inline.
Regards
Ed Willink
On 15/10/2015 15:16, Christopher
Gerking wrote:
Hi
How
should the debugging work? I mean, for an incomplete trace
record, ‘resolve’ will always return null because there is
no result. Thus, the behavior can’t be distinguished from
the situation where the mapping hasn’t been executed and
there is no trace record at all.
Debugging is an implementation problem. You are free to store
proprietary information in an extended trace record to support an
implementation.
Isn't the executed mapping field null/non-null?
The
bigger problem is that storing an incomplete trace record in
case of an assertion failure could prevent a successful
re-execution of a mapping. If we store the trace record at
the beginning of init, then it must be clearly specified
that a re-execution is only prevented if the trace record
includes a result object. In contrast, if there is only an
incomplete trace record without a result, then a full
re-execution must still be possible.
Conversely. If a.f(b) encountered an assertion failure, a
re-execution of a.f(b) is supposed to use the same results. So it
too should be an assertion failure. Maybe the trace record needs an
exception field.
Eclipse
QVTo does in fact prohibit re-assignments to the result
variable after the init section. The init section is the
only place where the result can be initialized/set.
Afterwards it is stored in the trace, before the population
section starts. No re-assignment after init. I think this
should apply to out parameters as well. Therefore I consider
the a := … assignment in your example below as invalid.
mapping m(out a : String)...
init{
result := ...
}
...
end {
a := result.name;
}
}
result is special so I can see that its reassignment is prohibited.
We can move result-field initialization to end of init.
But currently there is no prohibition of out/inout parameter
assignment and they are boring. They must be end of termination if
we are tracing mappings.
However, if we re-clarify as tracing mapping initializations,
everything freezes at the end of init. We could also halve the trace
record overhead by prohibiting object mutation, or at least input
mutation during the init.
Regards
Christopher
Hi Christopher
Replying to you first since you are an hour ahead. But please
keep an eye out for my imminent reply to Adolfo; there are
some important clarifications.
An early trace record serves two purposes.
a) it is available to inhibit re-execution within the init
section.
b) it is available to inhibit / trace / debug following an
assertion failure
But this is exactly as you write, it exists for a failure in
the init, so surely it is created at the start of init? You
confuse me.
From my limited knowledge this must happen before "result := "
When you write that "in Eclipse QVTo, a mapping can't
re-assign", I am confused. As an OMG specification author I am
not that concerned about bugs in a particular implementation.
If however you mean that QVTo provides no syntax to permit
such a re-assignment, then that is relevant.
The scanario I am considering is:
mapping m(out a : String)...
init{
result := ...
}
...
end {
a := result.name;
}
}
a must be traced on exit.
Regards
Ed Willink
On 14/10/2015 16:05, Christopher Gerking
wrote:
Hi
Trace
record at the start of init: How helpful are they? Without
the results, a trace record doesn’t yield much. If there
is an assertion failure inside the init section, the
incomplete trace record already exists (without the
result). Since there is a trace record, the mapping won’t
re-execute for the same input. Resolve will return null.
Are these effects desired?
Trace
record results initialization: in Eclipse QVTo, a mapping
can’t re-assign the result after the init section, only
mutate it. Therefore the result can be stored in the trace
right after its instantiation. It might still change, but
not re-assigned. So why waiting until after the end
section?
Regards
Christopher
Hi
I am awaiting comments (today) if the following
clarifications/changes are to be revised:
The trace record is created at the start of the init
section.
The trace record result fields are initialized at the end of
the termination section.
All late resolution property writes occur after all affected
properties have been read.
I've added two strong sentences to Trace Record.
A _trace record_ is created by every mapping execution.
If execution fails the _out\-parameters_ and
_result\-parameters_ are _null_.
A _trace record_ is created or re-used by every mapping
invocation. If no mapping is executed, the
_executed\-mapping_, _out\-parameters_ and
_result\-parameters_ are _null_.
---
Default for access/extends is still undecided.
As an Eclipse QVTo committer, I lean towards no breakage and
so extends
As OMG QVT chair, I lean towards common sense and so access
If SmartQVT is/was extends as default then my dilemma goes
away.
---
The following discussions are deferred:
Nested transformation trace data remains unspecified.
http://solitaire.omg.org/browse/QVT13-124 raised.
Suggestion is that it is accessble via Status and additional
optional first resolve() Status argument.
Regards
Ed Willink
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4447/10818 - Release
Date: 10/14/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4447/10823 - Release
Date: 10/15/15
|