On Fri, 21 Sep 2018 at 01:51, Tim Mackinnon <tim@testit.works> wrote:
I never knew it did that - but it makes sense. Presumably pressing resume then activated them again right?
yes. Though IIUC its not so much that they were deactivated, but more like the system goes... I hit a halt, hey I'm already halted, so no-op. cheers -ben
Tim
Sent from my iPhone
On 20 Sep 2018, at 08:42, Ben Coman <btc@openinworld.com> wrote:
I'll often put several breakpoints in code like this... ``` debug := true. "Somewhere else in application code..." debug ifTrue: [ self halt ]. 1 + 1. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 2 + 2. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 3 + 3. "Representing some longer bit of application code" ``` While stepping <Over> code after hitting the first halt, I am used to subsequent halts being silently stepped over. I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip and also build 60541 started from PharoLauncher.
However build 71231 and build 60542 do not silently step over a #halt. Each produces slightly different results (pics attached). <P01-Double-Halt-Pharo7.png> <P02-Double-Halt-Pharo60542.png>
I've logged an issue...
https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-h...
cheers -ben