You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
by the Variable view of the debugger (showing all RTD when paused)
by the trace manager in order to store the RTD in trace step and use it in the omniscient debugger (backward navigation) and in the timelines.
The default implementation (DefaultDynamicPartAccessor) reads RTD from the EMF model (based on the @aspect annotation). This implementation works correctly both in the variable view and the trace manager
A second implementation (IntrospectiveMutableFieldExtractor) is able to read RTD directly from java (K3 aspects). (Ie. not requiring Melange to have an EMF implementation of the data).
This works correctly for the Variable view but doesn't work for the trace manager (ie. timeline)
Desired behavior:
Be able to have a better interface to read/write mutable fields so they can be used in all GEMOC use cases.
which is populated by registering a listener of EMF notification events.
Using notification of model change is nice because this allows incremental work and avoid to analyse the RTD in order to decide if the state has changed or not and to consider only a subset of the RTD. However, in the case of non EMF RTD, there is no such notification and detailed analysis of the change.
Possible solution ?
Maybe find a way to ask the IDynamicPartAccessor for its changes in addition to those provided by EMF notification (and the BatchModelChangeListener)?
The text was updated successfully, but these errors were encountered:
contributes to
#155 by
adding a CompositeDynamicPartAccessor that allows to combine several
IDynamicPartAccessor/IMutableFieldExtractor so they can provide an
unified vision of the RTD to both the Variable view (ie.debugger) and
the timeline (ie. generic trace manager)
Signed-off-by: Didier Vojtisek <didier.vojtisek@inria.fr>
dvojtise
added a commit
to eclipse-gemoc/gemoc-studio-execution-java
that referenced
this issue
Mar 13, 2020
contributes to
eclipse-gemoc/gemoc-studio-modeldebugging#155 by
adding a CompositeDynamicPartAccessor that allows to combine several
IDynamicPartAccessor/IMutableFieldExtractor so they can provide an
unified vision of the RTD to both the Variable view (ie.debugger) and
the timeline (ie. generic trace manager)
Signed-off-by: Didier Vojtisek <didier.vojtisek@inria.fr>
however, the final goal of offering the trace directly for K3 aspect (not using melange) is not reached due to the discussion above (ie. model change notification)
Motivation:
Currently, we have IMutableFieldExtractor that allows finding the runtime data.
this interface is used in two places:
The default implementation (DefaultDynamicPartAccessor) reads RTD from the EMF model (based on the
@aspect
annotation). This implementation works correctly both in the variable view and the trace managerA second implementation (IntrospectiveMutableFieldExtractor) is able to read RTD directly from java (K3 aspects). (Ie. not requiring Melange to have an EMF implementation of the data).
This works correctly for the Variable view but doesn't work for the trace manager (ie. timeline)
Desired behavior:
Be able to have a better interface to read/write mutable fields so they can be used in all GEMOC use cases.
Preliminary analysis
apparently, the generic trace addon is able to monitor only emf model changes via the addState(List modelChanges)
https://github.com/eclipse/gemoc-studio-modeldebugging/blob/9e3cf1afaade4b4f70e000156e98d335af3538b4/trace/generator/plugins/org.eclipse.gemoc.trace.gemoc/src/org/eclipse/gemoc/trace/gemoc/traceaddon/GenericTraceConstructor.java#L352
which is populated by registering a listener of EMF notification events.
Using notification of model change is nice because this allows incremental work and avoid to analyse the RTD in order to decide if the state has changed or not and to consider only a subset of the RTD. However, in the case of non EMF RTD, there is no such notification and detailed analysis of the change.
Possible solution ?
Maybe find a way to ask the IDynamicPartAccessor for its changes in addition to those provided by EMF notification (and the BatchModelChangeListener)?
The text was updated successfully, but these errors were encountered: