On Fri, Jun 24, 2016 at 9:54 PM, Alexandre Bergel <[email protected]>
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
