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 <siguctua@gmail.com> wrote:
On 9 December 2016 at 01:39, phil@highoctane.be <phil@highoctane.be> 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.