And because two pictures say more than two-thousand words ...


[cid:199fca0b-9899-401f-bc76-4e481cc26545]


If you choose the first option, everything will behave as usual. If you choose the second option, a second debugger will open:


[cid:eafe9018-ab85-4001-be49-dbe183539cc4]


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Thiede, Christoph
Gesendet: Sonntag, 6. Februar 2022 21:02:17
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] Debugging through #fork

Hi all,

please see the attached changeset which implements "debugging through fork" based on SimulationSideEffect. Please load SimulationSideEffectWarning.5.cs before loading the attached changeset.

Hope you like it! Still, I did not withdraw my caveats from my previous message, so maybe we should test this change for some more time. I would recommend merging this patch after the release (but SimulationSideEffect) before the release. Looking forward to your opinions. :-)

Best,
Christoph

=============== Summary ===============

Change Set:        debugFork
Date:            6 February 2022
Author:            Christoph Thiede

This changeset allows to debug forked/resumed processes. When users steps through/into a send that will resume another process, they are presented a small dialog to either resume the process or debug it.

See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218552.html

=============== Diff ===============

Debugger>>handleLabelUpdatesIn:whenExecuting: {context stack menu} · ct 2/6/2022 20:40 (changed)
handleLabelUpdatesIn: aBlock whenExecuting: aContext
    "Send the selected message in the accessed method, and regain control
    after the invoked method returns."

    ^aBlock
        on: Notification
        do: [:ex|
            (ex tag isArray
             and: [ex tag size = 2
             and: [(ex tag first == aContext or: [ex tag first hasSender: aContext])]])
                ifTrue:
                    [self labelString: ex tag second description.
                     ex resume]
                ifFalse:
-                     [ex pass]]
+                     [ex pass]]
+         on: SimulationSideEffectWarning
+         do: [:ex |
+             ex isControlPrimitive ifTrue: [ex unsuppress].
+             ex primitive = 87 "primitiveResume" ifTrue:
+                 [| process |
+                 process := ex theReceiver.
+                 (Project uiManager
+                     chooseFromLabeledValues: (OrderedDictionary new
+                         at: 'Continue and resume (default)' translated put: [ex resume];
+                         at: 'Debug the new process' translated put: [process debug. ex skipPrimitive];
+                         yourself)
+                     title: ('The process you are debugging is starting or resuming another process:\\    {1}\\Would you like to debug the new process?' withCRs translated asText format: {process printString asText
+                         allBold;
+                         addAttribute: (TextInspectIt on: process);
+                         yourself})) value].
+             ex pass]


---
Sent from Squeak Inbox Talk<https://github.com/hpi-swa-lab/squeak-inbox-talk>

On 2022-02-06T19:44:24+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi all,
>
> I would be cautious with adding such a feature since it would be likely to overflow you with redundant debuggers when you are stepping "through" some very complex operation. Still, I see your need for such a feature and thank this might be a nice extra feature, maybe as an opt-in or when combined with some clever heuristics.
>
> On the implementation side, detecting the resumption of a process during simulating is pretty easy. See SimulationSideEffectWarning [1] which prepares the simulator for reacting to these events conveniently from the debugger. Maybe I should revise and merge this one soon. :-)
>
> Best,
> Christoph
>
> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215469.html
>
> ---
> Sent from Squeak Inbox Talk
>
> On 2022-01-22T19:48:24-06:00, asqueaker at gmail.com wrote:
>
> > > Dear Squeakers,
> > >
> > > I was just asking myself, why we cannot debug process forking like this:
> > >
> > > 0. In the Debugger: [ self doSomething ] "--> next send" fork. nextStatement.
> > > 1. Press the Through button.
> > > 2. The debugger stops at the next step after the send of #fork: [ self
> > > doSomething ] fork. "-->" nextStatement.
> > > 3. A second full debugger opens on the new (and now suspended)
> > > process: [ self "-->" doSomething ] fork. nextStatement.
> >
> > I would love that!
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220206/f367d25e/attachment.html>
>
>
["debugFork.1.cs"]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220206/46aa46bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 41628 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220206/46aa46bf/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 24369 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220206/46aa46bf/attachment-0003.png>