pharo-spec
Fastening debugger stack navigation
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
Thanks adrian What is the 'debugger inspector selection remembrance mechanism'? Because it looks like a nice feature.
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
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.
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.
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.