On 08/29/2018 01:50 PM, Didier Vojtisek
wrote:
I agree that this scenario would a nice feature to support because
this is smart for simple language suchs as FSM family languages
however:
1/ I would be interrested to see how to create Sirius animation
layer for language similar to Activity diagram (TTC15 - https://github.com/gemoc/activitydiagram).
IE. that requires additional metaclasses as support for the
representation. For example, in activity diagram it adds the class
"Token";
2/ note that currently not only the trace save/restore of the
multibranch timeline rely on on this RTD definition via the
"aspect" annotation in the ecore file; other feature also depends
on it :
- the variable view will not be feed correctly too (without
annotation, it is empty)
- the multidimentional timeline will not have any dimension
- with the java engine, the step back will work but will have
no visible effect on data, only the callstack will change
=> the api/service approach should be more than just a helper
for sirius, it should provide an adaptater that provide a
"traceable"/"storable" model of the RTD and its
declaration; both using a generic/standard format so every implied
component could read/write it.
I totally agree... But this is important if we do not want to "blur"
the metamodel with RTD data...
The
ecore part with annotation is doing that role in current version
...
I'm not aware of any concrete code/implementation going that
direction yet (from Fabien and/or Erwan)...
Didier
Le 28/08/2018 à 17:40, Julien
DeAntoni a écrit :
I actually implemented an Helper to
retrieve the RTD for animation in Sirius (see the models
tutorial updated a minute ago, that works in pure K3/dsl file)
I think we should neither add the RTD in the ecore manually or
use melange for this purpose and the API is the good solution
(an Helper may be sufficient)
I'll work on it as soon as I can
j
On 08/28/2018 12:08 PM, Benoit Combemale wrote:
Hi
1/ I don't think we can support Runtime Data (RTD)
defined only in K3 aspect.
even the pure K3 (sequential) has its RTD in the ecore
(in order to be able to display them in sirius and in
the variable view (in the K3FSM, the current state
reference is in the ecore file)
Actually, when using Melange, Melange is used to
produce a dsl and an ecore that has the RTD
If not using Melange, the RTD must
Not conceptually, but in the current state of the
studio. Note that in the context of ALE and .dsl, Fabien
is working on other solutions.
be added
manually as if it was produced by Melange. This must
include the annotation named "aspect" that is used to
drive the variable view and the trace storage.
BTW, this annotation name: "aspect" is a legacy and
has probably a wrong name since this is not the fact
that is comes from an aspect (ie. produced thanks to
Melange) that is important but the fact that it
represents runtime data /dynamic information not
matter Melange was used or not to produce it.
We should have a discussion about a better name for it
and open an issue about it
2/ reminder (if needed), the possibility to set back
the full state works only for the concurrent engine
which doesn't rely on the java stack and thus is
really able to reset its full state. The sequential
java engine relies on the java stack, when going
backward we reset the model state but not the java
stack state, so we cannot really run-again it we
simply reset the model state, when reaching the last
really executed step, the engine continue normally
Didier
Le 28/08/2018 à 10:07,
Julien DeAntoni a écrit :
Hi,
the multibranch timeline is able to store/restore
states of the model to explore different futures.
It was working ok when used with melange or when the
RTD are directly defined in the ecore file since it
was based on EMFcompare.
Now, we are using pure K3 and the DSL file so that
the timeline save/restore mechanism is broken. Is
there already a piece of code that save/restore the
RTD defined in the K3 aspects ?
thanks
j
--
Didier Vojtisek
SED Rennes - DiverSE Team
Univ Rennes, Inria, CNRS, IRISA
Campus de beaulieu
35042 Rennes
02 99 84 75 07
_______________________________________________
gemoc-dev mailing list
gemoc-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gemoc-dev
_______________________________________________
gemoc-dev mailing list
gemoc-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gemoc-dev
--
Julien Deantoni
Associate Professor
I3S Lab - UMR 7271 -KAIROS
INRIA Sophia Antipolis Méditerranée
2004 rte des Lucioles (Lagrange L-041)
BP93, F-06902 Sophia Antipolis Cedex, France
tel: +334 92 38 77 66
http://www.i3s.unice.fr/~deantoni/
Don’t take life too seriously! Nobody gets out alive anyway.(Dawn Gluskin)
_______________________________________________
gemoc-dev mailing list
gemoc-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gemoc-dev
--
Didier Vojtisek
SED Rennes - DiverSE Team
Univ Rennes, Inria, CNRS, IRISA
Campus de beaulieu
35042 Rennes
02 99 84 75 07
_______________________________________________
gemoc-dev mailing list
gemoc-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gemoc-dev
--
Julien Deantoni
Associate Professor
I3S Lab - UMR 7271 -KAIROS
INRIA Sophia Antipolis Méditerranée
2004 rte des Lucioles (Lagrange L-041)
BP93, F-06902 Sophia Antipolis Cedex, France
tel: +334 92 38 77 66
http://www.i3s.unice.fr/~deantoni/
Don’t take life too seriously! Nobody gets out alive anyway.(Dawn Gluskin)
|