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 <siemenbaa...@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-mo > oc.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 >
