On Fri, Jan 30, 2015 at 2:54 PM, Sean P. DeNigris <sean@clipperadams.com> 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