Hi Christopher
QVTo is much more advanced than QVTc and QVTr in terms of its actual
useability.
e.g. QVTc/r have no Transformation/Model/Status classes. So far
Eclipse QVTd adds Transformation/Model.
OMG QVTc/QVTr clearly need something similar, so at some point I
anticipate sharing them.
----
Similarly, at a suitable level of abstraction, the TraceXXX classes
should be shared between all QVT languages. Exactly as specified in
principle, but almost certainly nothing like as realized in
practice.
Currently the various resolve operations have an ability to perform
a variety of canned queries as demonstrated by my OCL-like
equivalent. But they cannot do more. e.g examine the input parameter
for a particular traced mapping invocation. Opening up the internal
trace data with useable TraceRecord classes could allow users to
formulate their own queries. And do 'printf' debugging.
----
A write back of trace data after a transform() completes could be
done, but since extents will sometimes be cloned, particularly for
parallel execution on the cloud, the write back may be hard to use.
If multiple very similar executions are performed, e.g.
try-10-iterations, try-11-iterations, ... the access to the
write-back will need qualification with the transformation identity.
Not supported by resolve() for a DataType, but viable with an
arbitrary query.
But if the Status has a traceData field, the 'writeBack' is
available without any writing back cost and without creating
ambiguities. No extra syntax is needed, although it might be nice to
be able to re-use canned resolve() capabilities; but I cannot see
how to all the transformation identity to the current syntax. Ah!
Maybe just an optional first Status argument.
Probably invocation of resolve(status,...) will be responsible for
translating object identities backwards and forwards across clones
so that the user does not know the details.
Regards
Ed Willink
On 13/10/2015 15:47, Christopher
Gerking wrote:
Hi
How
helpful are classes such as TraceData or TraceRecord, if
they are not in the scope of the resolve operations? I vote
for a write-back, that is when the execution of transform()
finishes, the accessed trace gets included by the accessing
trace. In this way, the nested execution becomes subject to
resolve operations.
Regards
Christopher
Hi
On 12/10/2015 15:39, Ed Willink wrote:
“This
including any mappings executed by accessed or
extended transformations or libraries”.
I
basically agree. But what does this mean for resolving
from within an accessed transformation? Is the trace
data from the accessing transformation available? So
is there an immediate write-through? That’s dangerous,
because if one transformation accesses two other
transformations (which share some mapping operations),
the second transformation might fall over trace
records created by the first one.
Alternatively,
an accessed transformation could start with an empty
trace data. At the end of the nested execution, there
would be a write-back to the trace of the accessing
transformation. I consider this as the most generally
compatible solution.
Overall,
the initial trace data should depend on whether the
accessed transformation reuses the model extents from
the accessing transformation. But I think this would
imply too many hybrid forms and twilight areas for a
clean specification.
Maybe I don't understand accessed
transformations. I thought they were a variant of extended
transformations with different name visibility rules. In
both cases there is just one 'TransformationCallExp' and so
only one trace data. I see no actual
'TransformationCallExp'to enable one transformation to
invoke another.
I just found
Transformation::transform()/parallelTransform()
Clearly a parallelTransform() cannot share its trace data. So
IMHO, each distinct transformation invocation is 100%
independent, requiring clear rules on sharing 'mutable' out
extents passed as immutable in extents.
Bug. Status should provide access to the invoked
transformation's trace data... TraceData, TraceRecord should
be reified as visible classes (immutable by QVTo code). ? a
new issue for QVT 1.4.
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/10811 - Release
Date: 10/13/15
|
