[ModelDebugging] BREAK_ON_LOGICAL_STEP and BREAK_ON_MSE_OCCURRENCE can be renamed and moved to concurrent case

[ebousse]

Currently, a GEMOC breakpoint (org.gemoc.executionframework.engine.ui.debug.breakpoint.GemocBreakpoint) on a model element can be declared to:

• pause when an MSE occurrence starts that targets that element (BREAK_ON_MSE_OCCURRENCE)
• pause when a logical step starts, if it contains an MSE occurrence targeting that element (BREAK_ON_LOGICAL_STEP)

This is legacy, due to how breakpoints were designed for the purely concurrent former GEMOC Studio. In fact, these booleans are nowadays only used in concurrent mode (although they are not working properly, since checks are not done correctly, partly related to #42).

I would suggest to at least remove these booleans from the common generic GemocBreakpoint class, since they are irrelevant in the sequential case.

In addition, BREAK_ON_LOGICAL_STEP can probably be renamed BREAK_ON_PARALLEL_STEP.

[dvojtise]

I agree to rename BREAK_ON_LOGICAL_STEP into BREAK_ON_PARALLEL_STEP, this seems to be an equivalent in the new trace metamodel.

about the other point, this is a little bit more tricky because the idea was to be able to have (in concurrent mode) a stack view with some depth, LogicalStep then MSE, so the user would be able to step into a logical (parallel) step in order to run its content one by one. (I think this is currently broken)
Actually, it would be better if a parallel step could display in the stack its content (like java does for threads) then the question for a given break point on a model element involved in a parallel step is :

should it break on the parallel step, on the actual mse or both.

Another point : I think the GemocBreakpoint should be renamed something like GemocModelElementBreakpoint.
because, it currently implement code for breakpoint added on top of the user model element.

I recommand this renaming for enabling new development (low priority anyway) I would suggest adding new kind of breakpoints : such as

• a breakpoint on an MSE (ie. a couple model element + a given action/operation) : this is different from the BREAK_ON_MSE_OCCURRENCE of the current breakpoint which breaks on any action involving the given model element (this is not concurrent specific, because we can compute the possible MSEs for sequential mode too) actually in the stimuli manager of [Concurrent] Breakpoint on MSE cannot work for multiple reasons (see details)  #42 we should use this breakpoint implementation instead of the GemocModelElementBreakpoint
• a breakpoint when there is a Choice (this is concurrent specific) ie. allow to do step-by-step using the debug interface instead of a dedicated Decider. (This would also allow to step on solver decider decision for example and manually override the solver choice)

[combemale]

-- Benoit Combemale http://combemale.fr

On 28 Apr 2017, at 12:15, Didier Vojtisek ***@***.***> wrote: I agree to rename BREAK_ON_LOGICAL_STEP into BREAK_ON_PARALLEL_STEP, this seems to be an equivalent in the new trace metamodel.

This should be discussed in more details. The step itself is not parallel, and the use of logical has a long history behind. Who can take in charge the organization of a Skype meeting on the topic?

about the other point, this is a little bit more tricky because the idea was to be able to have (in concurrent mode) a stack view with some depth, LogicalStep then MSE, so the user would be able to step into a logical (parallel) step in order to run its content one by one.

This doesn't make sense to execute them one by one, by definition!

(I think this is currently broken) Actually, it would be better if a parallel step could display in the stack its content (like java does for threads) then the question for a given break point on a model element involved in a parallel step is : should it break on the parallel step, on the actual mse or both. Another point : I think the GemocBreakpoint should be renamed something like GemocModelElementBreakpoint. because, it currently implement code for breakpoint added on top of the user model element.

Yes

I recommand this renaming for enabling new development (low priority anyway) I would suggest adding new kind of breakpoints : such as a breakpoint on an MSE (ie. a couple model element + a given action/operation) : this is different from the BREAK_ON_MSE_OCCURRENCE of the current breakpoint which breaks on any action involving the given model element (this is not concurrent specific, because we can compute the possible MSEs for sequential mode too) actually in the stimuli manager of #42 we should use this breakpoint implementation instead of the GemocModelElementBreakpoint a breakpoint when there is a Choice (this is concurrent specific) ie. allow to do step-by-step using the debug interface instead of a dedicated Decider. (This would also allow to step on solver decider decision for example and manually override the solver choice)

And when a temporal property is violated

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dvojtise]

This doesn't make sense to execute them one by one, by definition!

Mhmm I would prefer to say that you cannot proceed to the next LogicalStep unless you have fully executed all its MSE. If we mimic java thread + join, the user is able to debug each thread separately, only the join will be enforced.
In addition, I think it still makes sense for the language designer in order to debug MSEs that are not implemented correctly and have side effect on each other because the engine internal execution order may hide issues.
(for the skype meeting we also probably need @jdeantoni ?)

[ebousse]

After today's call to discuss many debugging-related points, we decided to delete these two flags as they are not used or meaningful anymore.

On the longer term, we can probably consider adding new types of breakpoints to pause on different kinds of elements (object, step, pair <object,step>, etc).