[squeak-dev] Debugger Through slow

Eliot Miranda eliot.miranda at gmail.com
Tue Jan 7 01:20:13 UTC 2020


Hi Christoph,

On Mon, Jan 6, 2020 at 2:30 PM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Eliot, thanks for your message! :-)
>

you're most welcome.

> > 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.
>
>
> Yes, that is exactly what I proposed in
> http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5109109.html.
> The VM appears not to like this, but if we could ensure the lifespan of
> such a DebuggedContext is restricted to debugging time, this should be fine.
>
Yes, I can imagine that adpoptInstance: doesn't divorce/make single
contexts, so I may have some work to do.

> The only advantage I could imagine at the moment would be that such a
> subclass would make it even harder to find errors in the "non-debugging"
> machinery.
>
> Btw, if you could take a look at the changeset I proposed there, it would
> be great!
>

 I'll look at the change set asap (busy for the next few days).

Apart from this, according to my original question of this thread, I would
> actually expect "Through" not to search for blocks only, but for any
> context activations. What about you?
>

What is achieved by searching for context activations?

>
> (However, from theory, we would only need to override #
> doPrimitive:method:receiver:args:.)
>

That doesn't make sen=ce to me.  The basic idea behind speeding up
"through" is to use the same machinery as "step", which is based on
per4form: rather than simulation.  Within the execution of a perform:...
doPrimitive:method:receiver:args: is not used; instead value[:value*]
messages are sent to blocks.  So the way we intercept these is by morphing
blocks whose home is the context we're debugging into TBB's.  Does that
make sense?
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
> *Gesendet:* Montag, 6. Januar 2020 22:53:32
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] Debugger Through slow
>
> 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
>
>

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


More information about the Squeak-dev mailing list