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@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.h...
*=============== 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: SimulationSideEffectWarningdo: [:ex |ex isControlPrimitive ifTrue: [ex unsuppress].ex primitive = 87 "primitiveResume" ifTrue:[| process |process := ex theReceiver.(Project uiManagerchooseOptionFromLabeledValues: (OrderedDictionary newat: 'Continue and resume (default)' translatedput: [ex resume];
at: 'Debug the new process' translated put:[process debug. ex skipPrimitive];
yourself)title: ('The process you are debugging is startingor 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>>effectiveProcesswhen debugging this warning, because the warning while the simulator was evaluating on behalf of the interrupted process."
(originalProcessevaluate: [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@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.squeakfo...
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.h...
=============== 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%3E
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:
- In the Debugger: [ self doSomething ] "--> next send" fork.
nextStatement.
- Press the Through button.
- 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!