I poked around and found another possible solution uploaded as
SLICE-Issue-12970-16-steps-to-get-through-halt-BenComan.2. However this
based on my microscope view of tracing in from a #halt in the <Step Over>
button. This is the first time I've looked at this and I don't grasp the
the high level architecture. Can someone help polish it?
The essential modification is the added line marked "--->" below, plus
there is a scattering of <debuggerCompleteToSender> pragmas spread through
methods of Halt and Object. I chose to use a pragma since I wanted to
cover a broader range of methods than just #halt (e.g. like
Halt>>signalerContext)
and there seemed no common convention between methods in Halt and Object.
Hopefully the pragma provides flexibility for later expansion - but I'm not
sure about the pragma name I chose.
Process>>complete: aContext
"Run self until aContext is popped or an unhandled error is raised. Return
self's new top context, unless an unhandled error was raised then return
the signaler context (rather than open a debugger)."
| ctxt pair error |
ctxt := suspendedContext.
suspendedContext := nil. "disable this process while running its stack in
active process below"
pair := Processor activeProcess
evaluate: [ctxt runUntilErrorOrReturnFrom: aContext]
onBehalfOf: self.
suspendedContext := pair first.
error := pair second.
"--->" error class = Halt ifTrue: [ aContext methodNode pragmaNamed:
#debuggerCompleteToSender ifPresent: [ ^ self completeTo: aContext sender ]
].
error ifNotNil: [^ error signalerContext].
^ suspendedContext
Here is my test script to compare before and after the slice. Debug it
from Playground then <Step Over> each line.
a := 1.
Halt now.
b := 2.
Halt enableHaltOnce.
Halt once.
c := 3.
self halt.
d := 4.
Halt enableHaltOnce.
self haltOnce.
self inform: (a + b + c + d) printString.
Now if you execute the above script normally, and <Proceed> at each
breakpoint, you will find the the #haltOnce leaves you in the wrong
position, on level too deep. The can be fixed by adding "or: [ (context
method selector = #haltOnce) ]" to Halt>>signalerContext, but then what
about the other breakpoint statements like Object>>haltIf:. I wonder
if Halt>>signalerContext
might leverage the pragmas I added.
The slice is tested to work with nested halts per the following example.
Execute "BenPlay new outer" and it will stop at the first #halt, then the
second #halt can be stepped over, but stepping over #inner breaks at the
#halt inside #inner.
BenPlay>>outer
| a b c | a := 1. self halt. b := 2. self halt. self inner. c := 3.
self inform: (a + b + c ) printString.
BenPlay>>inner
| a b |
a := 10.
self halt.
b := 20.
self inform: (a + b) printString.
cheers -ben
On Tue, Jan 27, 2015 at 11:14 PM, Ben Coman <[email protected]> wrote:
> Just notice, I have another solution under development.
>
> On Tue, Jan 27, 2015 at 9:55 PM, Ben Coman <[email protected]> wrote:
>
>> @Sean, In what way will it make halts more annoying? As far as I can
>> tell, it eliminates FIVE mouse-clicks from #halt, and #haltOnce behaviour
>> is unchanged.
>>
>> Now ideally the debugger should not step into the halt at all when you
>> <Step Over> - but this change eliminates FIVE mouse-clicks from #halt,
>> making #halt behave the same as #haltOnce. I can live with that. Lets
>> do the simple thing first (the ticket has been open 11 months), and leave
>> the potentially harder thing to make it right later on - unless of course
>> this creates other problems.
>>
>> On Mon, Jan 26, 2015 at 5:25 PM, Nicolai Hess <[email protected]> wrote:
>>
>>>
>>>
>>> 2015-01-25 0:22 GMT+01:00 Sean P. DeNigris <[email protected]>:
>>>
>>>> Ben Coman wrote
>>>> > Anyone see a problem with removing
>>>> > that last condition?
>>>>
>>>> Off the top of my head... Yes that doesn't seem like a good idea. You
>>>> don't
>>>> want to find yourself inside Halt. You want to be in your code.
>>>
>>>
>>> But isn't it already like that in case of #haltOnce ?
>>>
>>>
>>>
>>>
>>>> Although the
>>>> change makes this weird exceptional-sounding case better, it looks like
>>>> a
>>>> hack that will make halts more annoying in general. The question is why
>>>> you
>>>> end up deeply buried in the internals of Halt and how to prevent that in
>>>> this odd case.
>>>>
>>>>
>>>>
>>>> -----
>>>> Cheers,
>>>> Sean
>>>> --
>>>> View this message in context:
>>>> http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX-tp4801405p4801457.html
>>>> Sent from the Pharo Smalltalk Developers mailing list archive at
>>>> Nabble.com.
>>>>
>>>>
>>>
>>
>
