eclipse-gemoc / eclipse-gemoc/gemoc-studio-modeldebugging
Clarify stack content in Debug view
- Dominant language
- Java
- Stars
- 6
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Description
In conjunction with #87 and #88, the Debug view and its stack can be improved and clarified.
1/ clarify context / instruction
More specifically, there is currently a mix of the notion: *context* and *instruction* that are defined in IDSLDebugger.pushStackFrame (https://github.com/eclipse/gemoc-studio-modeldebugging/blob/9062e18c4ffbac8e93f0717966e3a176e121a060/simulationmodelanimation/plugins/org.eclipse.gemoc.dsl.debug.ide/src/org/eclipse/gemoc/dsl/debug/ide/IDSLDebugger.java#L344)
Current we alway put the same EOject in both. However, if we look to classic java debugger, we can see that there is a distinction: the context is (for example) the procedure and the instruction, the "line" in the procedure.
Applied similarly to a GEMOC language such as Logo, we currently have:

As this is a sequential language we can take the opportunity to use the containment information of the model elements to infer a more precise *instruction*. Thus selecting the Block as in the picture, would actually indicate: `[Block] fr§.inria.sed.logo.BlockImpl@5476c6 -> run() {2}` where the {2} indicates that we are on the second instructions of the block. As the instruction is more precise, the selected element in the editor (graphical or textual) would be the selected instruction. (`right 90` in this example)
This kind of display would help to correctly deal with the *data changed* information (in yellow in the Variable view).
2/ clarify "global context"
The Global context could also be improved in order to behave in the same way as other stack elements: display the name of the method being run (in the example `main()`) and a possible current instruction ({3} as the third instruction of the logo program -> `repeat 4` in the example)
3/ clarify "future instruction" stack frame
Last, the stack frame `[Right] fr.inria.sed.logo.impl.RigthImpl@7cbd11ad -> run()` is actually a representation of the future instruction but does not have a context yet. Compared to java debugger, this frame does not exist in java debugger.
However, while representing the future is quite interesting (especially when thinking to concurrent engines), the fact that it is represented in the same way as the other stack frames is misleading. I suggest finding a way to display it differently (icon overlay and/or italic font). Once correctly identified we can imagine extensions such as popup or dropdown giving the possibility to show alternative future (injected events from the behavioural interface or alternative solutions from the concurrent solver)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with IDSLDebugger.pushStackFrame in simulationmodelanimation/plugins/org.eclipse.gemoc.dsl.debug.ide/src/org/eclipse/gemoc/dsl/debug/ide/IDSLDebugger.java and inspect how the Debug view renders stack frames. Compare the current context/instruction handling with the classic Java debugger. Done means clearer method and instruction positions, an improved global context, and a visibly distinct future-instruction frame.
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
- Mostly clear
- Newbie friendliness
- 25/100