Hi
Why must the re-execution fail again? A mapping behavior can depend on “global” variables or any other context. Therefore the behavior might change from failure
to success between two mapping executions.
I don’t see a difference between ‘result’ and ‘out’. An ‘out’ param should only be assigned in the init section, not later. Of course both can still be mutated
during population (maybe end as well), so the trace record mutates as well. The only problem I see is when the trace record refers to a copy instead of the original result. But why should that be the case? For mutable datatypes? Why?
IMHO an inout param shouldn’t be assigned at all. It can only mutate.
My visitor-like QVTo cloning transformations do often re-enter a mapping from their own population section. See
http://ceur-ws.org/Vol-1285/paper06.pdf for the very same idea. The reason are loops inside models, where the most simple loop is a plain opposite reference. These transformations rely on the presence of
the result in the trace right after init, because they must reuse the real result instead of null. Otherwise a model won’t be cloned correctly using that approach.
Kind regards
Christopher
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
_______________________________________________
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/10827 - Release Date: 10/15/15
