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