and this works simply by knowing that primitive 19 always fails (this is guaranteed by VM itself). so when you run code naturally - the primitive fails, and so it runs the body of method.
but when same method attempted to activate(simulate) via debugger - it doesn't runs a method body and doing something else, what exactly - look at debugger code, because i don't remember :). On 9 December 2016 at 02:00, Igor Stasenko <[email protected]> wrote: > > On 9 December 2016 at 01:39, [email protected] <[email protected]> > wrote: > >> Nice to now understand how this debugger thing behaves. >> >> I have some issues when debugging tests GTDebugger in Pharo5 when there >> is a self halt in the test method. For some reason the step through looks >> like out of what with the actual thing to step through. >> >> How does that work? >> > > well, IIRC, when you stepping through, the debugger running a simulation > and detects that you trying to interrupt it > and since it is not a good idea to interrupt the debugger itself , else > you will need to open yet another debugger window, > showing where the simulation/exception handling was interrupted.. and so > you enter an endless recursive loop, > and as result won't be able to debug anything :) > > And this 'simulation guard' is serving to prohibit further processing in > such cases, or in certain cases, it simply ignores > it and pretends that it is done, suppressing actual code behavior, which > would be triggered, if it wouldn't run simulated by debugger. > > >> Phil >> >> > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
