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: 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
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 Talkhttps://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:
- 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!