eclipse-gemoc / eclipse-gemoc/gemoc-studio-modeldebugging
[Trace] Investigate possibility to trace runtime data not contained in a model
- Dominant language
- Java
- Stars
- 6
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Description
**Motivation:**
Currently, we have [IMutableFieldExtractor](https://github.com/eclipse/gemoc-studio-modeldebugging/blob/master/framework/execution_framework/plugins/org.eclipse.gemoc.executionframework.debugger/src/org/eclipse/gemoc/executionframework/debugger/IMutableFieldExtractor.java#L17) that allows finding the runtime data.
this interface is used in two places:
- 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](https://github.com/eclipse/gemoc-studio-modeldebugging/blob/master/framework/execution_framework/plugins/org.eclipse.gemoc.executionframework.debugger/src/org/eclipse/gemoc/executionframework/debugger/DefaultDynamicPartAccessor.java)) 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](https://github.com/eclipse/gemoc-studio-modeldebugging/blob/master/framework/execution_framework/plugins/org.eclipse.gemoc.executionframework.debugger/src/org/eclipse/gemoc/executionframework/debugger/IntrospectiveMutableFieldExtractor.xtend)) 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](https://github.com/eclipse/gemoc-studio-modeldebugging/blob/master/framework/framework_commons/plugins/org.eclipse.gemoc.xdsmlframework.api/src/org/eclipse/gemoc/xdsmlframework/api/engine_addon/modelchangelistener/BatchModelChangeListener.xtend))?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with IMutableFieldExtractor, DefaultDynamicPartAccessor.java, and IntrospectiveMutableFieldExtractor.xtend, then inspect GenericTraceConstructor.addState(List) and BatchModelChangeListener. Compare how the Variable view and trace manager obtain runtime data; done means non-EMF runtime data can be captured and used by trace timelines and backward navigation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100