Smalltalk › Pharo › Pharo Smalltalk Developers

debuggerCompleteToSender (was Re: Having comments for pragma?)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Ben Coman

debuggerCompleteToSender (was Re: Having comments for pragma?)

On Fri, Jun 24, 2016 at 9:54 PM, Alexandre Bergel <[hidden email]> wrote:

Hi!

A pragma may be very obscure. For example, I do:
Pragma allInstances anyOne
=> <debuggerCompleteToSender>

If I want to know more about this <debuggerCompleteToSender> is actually quite challenging.
I see many methods having that pragma, but not idea what it is for.
I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.

Sorry I don't know enough of Pragma architecture to form an opinion on your question, but I can give you some background on debuggerCompleteToSender. There are two cases where the debugger interacts with a halt statement.

The first is when a halt is first encountered in running code. This could be "Halt now" or "self halt" which respectively invoke...

Halt>>now

self signal.

Object>>halt

Halt now.

Now you don't want the debugger to open in those methods, but the method that sent the message. The problem with the implementation prior to

<debuggerCompleteToSender> was that while it was okay for signalerContext to be search the context chain for a Halt object so the debugger could open in the sender of #now, that meant the debugger would open inside "self halt" since it sends #now. So there was an #or: to look for #halt being sent, and an #or: for #haltOnce beign sent, and the dozen other senders of Halt>>now were ignored, or otherwise you'd need a dozen #or: conditions.

The second case is when you are stepping through code you come across another "self haltOnce" and previously when you <Step Over> the debugger would end up several methods "in" and it would take eight or so <Steps> to get back out to the method containing the "self halt". (and this really annoyed me enough to fix it).

So DebuggSession>>stepOver: calls Process>>completeStep: which calls Process>>complete: Again (vaguely I remember) it originally only searched up the context chain for senders of #halt and the dozen others halt methods were ignored and so they failed to set the debugger to the correct location.

From from #complete: the call "self completeTo: aContext sender" moves up the context chain, and completeTo: recurses back to complete. This recursion only happens while the error class is Halt and while the context methods have the pragma, otherwise it falls through to return suspendedContext as it unwinds.

So having written all that to remind myself, the short answer of the net effect is that a first method with <debuggerCompleteToSender> can call another method with <debuggerCompleteToSender> which can call another <debuggerCompleteToSender> methods etc to any depth, until eventually Halt>>now is called to signal the exception, then all calls get unwound up to the first method with <debuggerCompleteToSender>, and the debugger lands in its sender.

I was not completely happy with the pragma's name, but I was really at a loss what to name it, and so... since I was fixing the debugger, and was all happening in the "completion" machinery, and it unwound to the sender... *shrugs*

Now, where to add all that as a comment?

HTH, cheers -ben