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 <btc@openinworld.com> wrote:
Just notice, I have another solution under development.

On Tue, Jan 27, 2015 at 9:55 PM, Ben Coman <btc@openinworld.com> 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 <nicolaihess@web.de> wrote:


2015-01-25 0:22 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
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.