> Would we need to protect this against accidentally stepping into system
> processes?
Good question. First, the proposal always asks the user before opening a second debugger, which should reduce the chance of accidentally stepping. Second, currently only primitiveResume is monitored. Sempahores/critical sections are NOT covered at the moment because I believe this would fire up too often. I'm not aware of any place where a system process (by which I assure you mean high-level processes such as idle or timing) are manually resumed by normal processes. Were you having any concrete examples in mind?
Best,
Christoph
---
Sent from Squeak Inbox Talk
On 2024-03-03T12:36:30-08:00, vanessa@codefrau.net wrote:
> Seems like a very useful feature to me.
>
> Would we need to protect this against accidentally stepping into system
> processes?
>
> Vanessa
>
> On Sun, Mar 3, 2024 at 11:24 <christoph.thiede(a)student.hpi.uni-potsdam.de>
> wrote:
>
> > Hi all,
> >
> > bumping this again. :-) I'm attaching an updated changeset after I have
> > merged SimulationSideEffectWarning into the trunk today. What do you think:
> > Do we want these dialogs in the trunk or not? We could also hide them
> > behind an (opt-out?) preference. Are you dealing with any systems that
> > involve so much multiprocessing that these dialogs would become irritating?
> >
> > 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
> > 3/3/2024 20:18 (changed)*
> > handleLabelUpdatesIn: aBlock whenExecuting: aContext
> > "Send the selected message in the accessed method, and regain control
> > after the invoked method returns."
> > +
> > + | originalProcess |
> > + originalProcess := Processor activeProcess.
> >
> > ^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
> > + chooseOptionFromLabeledValues: (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 resume "fallback"].
> > + ex resume:
> > + "Avoid infinite recursion in Process>>effectiveProcess
> > when debugging this warning, because the warning while the simulator was
> > evaluating on behalf of the interrupted process."
> > + (originalProcess
> > + evaluate: [ex defaultAction]
> > + onBehalfOf: nil)]
> >
> > ---
> > *Sent from **Squeak Inbox Talk
> > <https://github.com/hpi-swa-lab/squeak-inbox-talk>*
> >
> > On 2023-11-11T20:00:29+01:00, christoph.thiede(a)student.hpi.uni-potsdam.de
> > wrote:
> >
> > > Hi all,
> > >
> > > I'd like to bump these two proposals - SimulationSideEffectWarning [1]
> > and "debug through forks". The former is basically a refactoring/refinition
> > of existing warnings for certain primitives in the simulator and adds a
> > hook for ignoring certain primitives, which I already discussed with
> > Marcel. The latter, which depends on the former, is more experimental, but
> > I would be curious how you receive such a feature and whether it makes
> > debugging with multilpe processes more insightful or just more cumbersome.
> > >
> > > Can I merge SimulationSideEffectWarning? What about the other? :-)
> > >
> > > Best,
> > > Christoph
> > >
> > > [1]
> > https://lists.squeakfoundation.org/archives/list/squeak-dev(a)lists.squeakfoundation.org/message/L2FSLGLNQUXDCTA27WBOFZTOYWXHUQGR/
> > >
> > > ---
> > > Sent from Squeak Inbox Talk
> > >
> > > On 2022-02-06T20:06:11+00:00, christoph.thiede(a)
> > student.hpi.uni-potsdam.de wrote:
> > >
> > > > 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(a)lists.squeakfoundation.org> im
> > Auftrag von Thiede, Christoph
> > > > Gesendet: Sonntag, 6. Februar 2022 21:02:17
> > > > An: squeak-dev(a)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(a)
> > 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!
> > > > > >
> > > > > >
> > > > >
> >