Fastening debugger stack navigation

[adri09070]

Fixes #584
The whole discussion is in this issue.

To fasten the navigation of the debugger stack, I removed the debugger inspector selection remembrance mechanism because it :

• makes the debugger inspector too long to update. Removing it speeds up makes the process twice faster
• is not accurate
• is not much useful, in the end ?

Furthermore, I modified the way the #receiverNodes are built for an StDebuggerContext object. It used to collect allInspectorNodes and then reject the self node, like this:

receiverNodes

	^ self context receiver allInspectorNodes reject: [ :node | 
		  node label = 'self' ]

while #allInspectorNodes actually adds a self node to the nodes returned by #inspectorNodes:

allInspectorNodes
	"Answer a list of attributes as nodes"

	^ { StInspectorSelfNode hostObject: self }, 
		self inspectorNodes

So to spare an unncessary filter, I changed #receiverNodes to this equivalent method:

receiverNodes

	^ self context receiver inspectorNodes

If you have some examples of programs to debug for which the stack navigation was slow, I'm eager to know

[adri09070]

Unrelated error: pharo-project/pharo#15953

[Ducasse]

Thanks adrian What is the 'debugger inspector selection remembrance mechanism'? Because it looks like a nice feature.

[adri09070]

Thanks adrian What is the 'debugger inspector selection remembrance mechanism'? Because it looks like a nice feature.

If you select a variable in the debugger inspector, then if you select another context in the context stack and then select again the previous context in the contexts stack, the debugger inspector automatically selects again the variable that was selected before you switched contexts

[Ducasse]

Thanks for the explanation. I was wondering this is slow.

[estebanlm]

uhm... the problem with this is that it cancels the effect "flow" that we have now with the inspector, making it harder to navigate in some situations.

[Ducasse]

So what is the decision on this issue.
I moved it to the Pharo13 branch.

[Ducasse]

So what is the decision for this issue?

[StevenCostiou]

In the current state, and specifically because we have not yet been able to exactly locate the source of the latency (it seems to come from spec but it could be how we use it):

• either we gain speed, but we lose the selection of inspectors if we change context in the stack (this PR)
• or we keep the selection (if I change context and come back, my previous selection in the inspector is maintained) but it remains slow

Today we can only propose these two options.
For more, it will have to wait september.

[StevenCostiou]

For more precision, the scenario is:

• you open a debugger which starts at context [C], you start digging in the inspector (so you have selected a variable in the inspector and we call it [A])
• you change context
• you go back to [C], [A] is automatically selected in the inspector because it was the last selection

It is this reselection of [A] that provokes a visible latency in the debugger.
This latency is not present in gtk.

[Ducasse]

Tx for investigating