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