You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I find blocks a source of confusion. I see the complete method but not always all of the calls traced. That is as they are "hidden" in blocks. I can see them when having unfolded the trace of the block, but (at least) my brain expects them to be there already and then I wonder where they are.
As it would be incorrect to lift the block content up you could always directly unfold blocks. They would be correctly shown in the debugger and the content would be visible (this would map better to to mental model of exploring the method and its calls as you can see the calls in the code but not in the trace)
The text was updated successfully, but these errors were encountered:
Could you maybe give a short example? Do I understand you correctly that in this example:
... you would rather prefer the default tree expansion would be this?
Or even that?
It might be tricky to decide on a default representation that is neither too short nor too overwhelming for a large method with dozens of sends.
In general, the representation and navigation of contexts in the trace tree are quite basic at the moment and follow Squeak's execution model very strictly. I already had hoped to experiment with some more elaborate representation (maybe using Sandblocks) to make the tree easier to grasp, but I have no concrete concepts and plans for this right now. So if you have any further ideas or suggestions, please keep them coming! :-)
I find blocks a source of confusion. I see the complete method but not always all of the calls traced. That is as they are "hidden" in blocks. I can see them when having unfolded the trace of the block, but (at least) my brain expects them to be there already and then I wonder where they are.
As it would be incorrect to lift the block content up you could always directly unfold blocks. They would be correctly shown in the debugger and the content would be visible (this would map better to to mental model of exploring the method and its calls as you can see the calls in the code but not in the trace)
The text was updated successfully, but these errors were encountered: