[debugger] too many $sources

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 456058 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Dec 23, 2014 04:43 EDT | | Modified | Jun 01, 2015 13:32 EDT | | Reporter | Ed Willink |

Description

Stepping the following to see why indexOf malfuctions is a good exercise for debugger useability -=> poor.

let s = Sequence{0.0,0.0,0.0} in s->collect(r | r + Sequence{1.0,2.0,3.0}->at(s->indexOf(r)))

Amomngst other problems there can be three $source's and no "s" in indexOf.

[eclipse-ocl-bot]

By Ed Willink on Dec 23, 2014 07:45

(In reply to Ed Willink from comment #0)

to see why indexOf malfuctions

indexOf was actually correct, but the variables and context were insufficiently clear to persuade the viewer that the behavior was correct.

[eclipse-ocl-bot]

By Ed Willink on Jun 01, 2015 04:31

(In reply to Ed Willink from comment #0)

Amomngst other problems there can be three $source's

Now $ownedSource.

The problem is that each the source/argument expression of each pending node is in the EvaluationEnvironment and given a synthetic $ownedSource variable name.

The multiple values are useful but not if they are confusing.

? show only the nearest values\ ? provide a better unambiguous synthetic name\ ? create a nested stack entry for each OCLExpression or perhaps just CallExp

Now that the Outline is an AS tree, perhaps making hovertext and menu entries work in the outline may be a solution.

[eclipse-ocl-bot]

By Ed Willink on Jun 01, 2015 06:32

(In reply to Ed Willink from comment #2)

The multiple values are useful but not if they are confusing.

The code is also confused. Since the variables come from a Map, they are in unpredictable order. When the user selects one, the first matching name is displayed in the toString(). Very confusing.\

? show only the nearest values

Simplest solution for now. Show only synthetic variables that are the immediate child of the $pc variable.

This simplifies the displayed variables so that they are now credible.

(In reply to Ed Willink from comment #0)

Amomngst other problems ... no "s" in indexOf.

This is only half true. Nested stack entries are created and "s" is visible from higher up the stack. Perhaps all non-occluded true variables on the stack should be shown up to and including the scoping ExpressionInOCL. (Bug 468940)

However the stack entries have very unhelpful display text, (Bug 468949)

ocl::OclVoid::oclDebuggerExpression() - debug_9jj7EAgwEeWxruOoAbAmZw.ocl line: 3

and when pushed entries are selected the displayed variables show a difficult to correlate $pc, possibly the $ownedSource of the CallExp rather than the CallExp itself.

It appears that OperationCallExp creates a nested stack but IteratorExp does not. (Bug 468949)

[eclipse-ocl-bot]

By Ed Willink on Jun 01, 2015 13:32

? show only the nearest values

Simplest solution for now. Show only synthetic variables that are the immediate child of the $pc variable.

This simplifies the displayed variables so that they are now credible.

commit 7bd0ebb3e87381b41dd550d297f5d614eb4da9d0

pushed to master for RC3

(In reply to Ed Willink from comment #0)

Stepping the following to see why indexOf malfuctions is a good exercise for debugger useability -=> poor.

I think this at least brings the useability to adequate.

(In reply to Ed Willink from comment #1)

indexOf was actually correct, but the variables and context were insufficiently clear to persuade the viewer that the behavior was correct.

since displayed values are now credible.

Bug 468940, Bug 468949 deal with side issues.