You can take an expression and "debug it" using over and through + run to here, inspecting things all over.

You can also use Halt>>if: #selector��

Halt if: is really useful:

if: condition
<debuggerCompleteToSender>
"This is the typical message to use for inserting breakpoints during��
debugging.
The argument can be one of the following:
- a block: if the Block has one arg, the calling object is bound to that.
- an expression
�� - a selector: Halt if found in the call chain"

condition isSymbol ifTrue: [ ^ self haltIfCallChainContains: condition ].
condition isBlock ifTrue: [ ^ self haltIfBlockWithCallingObject: condition].
condition ifTrue: [self signal].

That helped me :-)

Phil

On Thu, Jan 5, 2017 at 8:24 PM, Siemen Baader <siemenbaader@gmail.com> wrote:
Hi All,

I may be missing the obvious, but what are good strategies to understand the structure of existing code? Specifically, I'm trying to understand more of PharoJS to solve my own problems and eventually also to contribute back - but this is a general question.

There is this one MOOC exercise:��http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exercises-Pillar/Pillar-Questions.pdf that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

While writing this it occured to me that I can use the debugger to follow a call stack by putting a breakpoint in the top level method, then stepping down using the debugger. There is also a MOOC lecture on that that I will look at again, ��http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W5/C019-W2S-VideosDebugger1-UsingTheDebugger-V2-HD_720p_4Mbs.m4v.

Any tips? I think I don't see the forest for the trees here I'm afraid :)

thanks,
Siemen