On Sat, Jan 31, 2015 at 11:50 PM, Sean P. DeNigris <s...@clipperadams.com> wrote:
> Ben Coman wrote > > This is all in SLICE-Issue-12970-16-steps-to-get-through-halt-BenComan.4. > > Great, I'll take another look. Did you consider Elliot's suggestion? > > > Sorry I didn't. At first glance I didn't fathom the "inlining" concept and I already had a sniff that this other solution having potential to solve all woes, so I didn't stop to dig into it. Reviewing it again now, I understand the "inlining", but trying it as given (in a fresh image) fails to bring up a debugger at all, for the following... a := 1. Halt enableHaltOnce. self haltOnce. b := 2. I think the following gives the same intent... haltOnce "Halt unless we have already done it once." Halt isHaltOnceEnabled ifTrue: [Halt disableHaltOnce. Halt signal] but the debugger opens on the "Halt signal". This is due to Halt>>signalerContext's special handling ONLY of #halt, which is the essence of the different behaviour between #halt and #haltOnce. Changing "Halt signal" to "self halt" has no effect, with the debugger opening on the same line. As well, I think it would only solve the behaviour for the initial opening of the debugger, but not subsequent encounters of a halt while stepping - which was the problem I was attacking. Indeed, solving that #haltOnce problem was an afterthought - the one line change from the .2 slice to the .3 slice Now for your critical review, in particular consider the pragma name "<debuggerCompleteToSender>". I'm not sure its the best. Also, did I miss tagging any halt-like methods ? cheers -ben
