search

eclipse-gemoc / gemoc-studio-modeldebugging

gemoc-studio-modeldebugging
Eclipse Public License 1.0
6 stars 15 forks source link

Clarify stack content in Debug view #91

Open dvojtise opened 5 years ago

dvojtise commented 5 years ago

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:

image

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)

ebousse commented 5 years ago

1/ True that in a classical debugger, the stack only shows context frames, and not instructions nor the "next" instruction about to be executed. The problem in our case is the genericity: we have very little way to know whether something should be considered as "context" or as "instructions". Relying on containments will definitely not work in the general case, as one could imagine a language where the context of a given execution step is not specified in the container element.

And about the distinction context/instruction, that is for sure a good question but again a hard one. At runtime, GEMOC cannot know whether a step will have children steps, and if it does then it definitely cannot be considered as an "instruction". If we were to rely on a small static analysis of the dependencies among execution rules (which we actually already implemented in the trace metamodel generator), then we could distinguish big steps from small steps, and make sure to not put small steps at the top of the stack.

2/ If I remember correctly, the "Global context" is a hack made by @d-leroy to deal with limitations of the eclipse debug integration layer. It was the only way to reliably display all runtime data, I think. But it is not supposed to represent a real stack frame, and is not really tied to the "main" rule (even less if the latter is not a step rule). The best would be a way to get rid of this global context altogether, but that may be tricky.

3/ To be a little more precise: each element of the stack is simply a step that started but did not finish yet. Therefore the topmost element is not really supposed to represent the "future" instruction, but is there to preemptively prepare the stack in case such instruction is in fact a big step, and therefore a "context" (if I use the same vocabulary as above). Yet it is true that it leads to something we would not see in a classical debugger.

dvojtise commented 5 years ago

1/ true that is doesn't work in the general case. However, I was thinking that a simple default rule would help in many situations. such as: for a given frame/step, if it is a big step, then it should update its instruction to the small step context; especially if this object is contained. If not contained or if there is no known small step, let's stick to the current behaviour. Ie. context==instruction . Then, if context and instructions ad different, this is is up to the label image provider to have the most concise way to present it (using a number in the containment or clearly indicating the instruction name) (note: I'm not sure that the containment rule is required, we could probably simply say that the context EObject of a child frame is the instruction EObject of the parent frame)

2/ Actually, I've started a branch https://github.com/eclipse/gemoc-studio-modeldebugging/tree/improve-variable-view that implements the notion of "self" and duplicate RTD on all frames (for #87 and #88) (you can actually see it in the image above) so the need for this special frame is not anymore about showing the RTD. However, we still need one root frame that corresponds to the launched engine: in case of a sequential engine this can be mapped to the main method that has been started (so it would be fair to show the name of this main method in the frame as it is done in other frames), in case of the concurrent engine, this corresponds to the main loop of the engine.

3/ Mhh, for the topmost element, it should at least be displayed differently in order to show that something had happened or not. (in order to be able to interpret the content of the variable view) this leads again to this notion of instruction: on the topmost element it is on a kind of "preparation instruction" ( "0" if an ordering is possible ?) whereas in other frames, the instruction is on the child frame context. (using a position if it an ordering is possible otherwise just the reference to it) The idea to show it as a "future" was interesting in order to allow integration of concepts such as injected events from the behavioural interface or alternative solutions from the concurrent solver.