Hi Christoph,

On Wed, Sep 11, 2019 at 4:55 AM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi all,
>
>
> take the following snippet, debug-it and press "Through":
>
> SqueakMessageCategoriesHelp asHelpTopic.
>
>
> For me, it makes the debugger hang really long time, as apparently the
> whole code execution is simulated, searching for the current context
> (#stepToHome:). "Over", in contrast, is faster by far, calling
> #completeStep: instead.
>
> Can we speed up "Through" in any way? As the button is explained as "Step
> into a block", we could call #completeStep: internally if the selected
> message does not contain a block argument, for example.
>

The way we did it in VisualWorks is to create subclasses of the various
BlockClosure classes (in our case of BlockClosure and FullBlockClosure)
that override the value[:value*] messages to call back into the debugger,
and use adoptInstance: to convert the blocks created in the current
activation into these "breaking" blocks.

The first problem is identifying the set of blocks that need to be morphed
into "through" breaking blocks (TBBs for the purposes of this email).
One way would be to simply use [Full]BlockClosure>>allInstances, selecting
those whose home is the home context, but that could suck in large images.
Another way would be to somehow intercept block creation while
stepping.sending and, say, maintain a dictionary in the debugger from home
context to blocks whose home is that context.
IIRC, the VW implementation scanned the outgoing arguments at point of send
(from a "through"), looking for blocks.  This is simple but misses cases
where blocks are stored in variables, etc.

The second problem is when to do the morphing.  It should be done during
the "through" processing, and undone on the "through" terminating, either
by breaking or by finishing the "through" send.  It c an then be reapplied
on every "through".

The final problem is what to do in the overridden value[:value*] methods.
These should call some common helper that contacts the debugger.  The
debugger can then morph the block back into a normal block and step into
its activation.

N.B.
It comes to mind that a similar trick might be usable to fix the
swapSender:/runIUntilErrorOrReturmFrom: misinteraction.  One could change
the class of the current context into one that overrides all sender setting
methods (in particular swapSender:).  That could be a cool solution.  And
tackling the two issues together (speeding up "through", and fixing
stepping over/into Generators) might lead you to come up with a nice
mini-framework for intercepting crucial execution transitions in the
debugger.  Clearly a better solution to fork than killing simulation with
primitive 19  is to open another debugger, or offer to open a new debugger,
on the new process.  But one can see issues here.  There might be a
rationale for a debugger with training wheels for learners exploring the
system, and a "oh my god, it's covered in hair!" full featured debugger for
us seasoned old hacks.

HTH

> Best,
>
> Christoph
>
HNY

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200106/ef9faca8/attachment.html>