On Fri, Jan 30, 2015 at 2:54 PM, Sean P. DeNigris <[email protected]> wrote:
> Ben Coman wrote > > @Sean, In what way will it make halts more annoying? > > Clearly seems to make things better in your use case, but IIRC the purpose > of that test is that you don't want to open the debugger within the halting > system. And indeed, when you remove it, you end up in #halt. But where you > want to be is in UndefinedObject>>DoIt. So, it seems like a hack that, > while > better in this case, may have implications in other cases. The solution > we're looking for is: "debuggers-opened-due-to-halts always open on the > first context totally outside the halt machinery" and we're not quite there > yet. > Nobody responded to my suggestion of inlining the code for haltOnce so that the Halt signal happens in haltOnce itself, just as it does inside halt. This may make the system respond to haltOnce the same as it does to halt. i.e. the debugger can look to the sender of the signalling context. As it is now, the sender of the signalling context of a haltOnce is halt, not the sender of haltOnce as desired. Let me reiterate, I expect haltOnce "Halt unless we have already done it once." (Smalltalk at: #HaltOnce ifAbsent: [false]) ifTrue: [Smalltalk at: #HaltOnce put: false. Halt signal] will behave similarly to halt Halt signal and stop the debugger where desired. If the decomposition into haltOnceEnabled & clearHaltOnce is desired it can still be written haltOnce "Halt unless we have already done it once." self haltOnceEnabled ifTrue: [self clearHaltOnce. Halt signal] but keeping Halt signal in haltOnce instead of invoking through halt is key. > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX-tp4801405p4802841.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- best, Eliot
