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.
Do you see any drawbacks or huge implementation challenges or blockers? Or would it be "only" a matter of somebody finding the time and will to implement such a feature?
Kind regards, Jakob
Hi Jakob,
That would be an awsome feature :) At the moment I insert self halt at the beginning of the forked process which works but is sort of a nuisance… Unfortunately I know very little about debugger’s implementation so far but I love the idea! (especially for a beginner, figuring out how to debug a forked process is a nightmare – well, at least for me it was) Thanks, jaromir
From: Jakob Reschkemailto:jakres+squeak@gmail.com Sent: Saturday, January 22, 2022 11:47 To: squeak-dev@lists.squeakfoundation.orgmailto:squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Debugging through #fork
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.
Do you see any drawbacks or huge implementation challenges or blockers? Or would it be "only" a matter of somebody finding the time and will to implement such a feature?
Kind regards, Jakob
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!
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@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!
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
On 2022-02-06T19:44:24+01:00, christoph.thiede@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!
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@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Sonntag, 6. Februar 2022 21:02:17 An: squeak-dev@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@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!
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@lists.squeakfoun...
--- Sent from Squeak Inbox Talk
On 2022-02-06T20:06:11+00:00, christoph.thiede@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: SimulationSideEffectWarningdo: [:ex |ex isControlPrimitive ifTrue: [ex unsuppress].ex primitive = 87 "primitiveResume" ifTrue:[| process |process := ex theReceiver.(Project uiManagerchooseFromLabeledValues: (OrderedDictionary newat: '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 asTextallBold;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!
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!
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!
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.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 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.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:
> > 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!
On Tue, Mar 5, 2024 at 12:18 christoph.thiede@student.hpi.uni-potsdam.de wrote:
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?
No. I didn’t realize it’s just primitiveResume. That should be safe.
Vanessa
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
christoph.thiede＠student.hpi.uni-potsdam.de -
Jakob Reschke -
Jaromir Matas -
Thiede, Christoph
-
Vanessa Freudenberg