A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full | debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug). uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title]. "Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ]. "Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock. processToDebug suspend. "Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel Am 16.12.2019 11:53:21 schrieb commits@source.squeak.org commits@source.squeak.org: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full
| debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).
uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].
"Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ].
"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock.
processToDebug suspend.
"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
Hi Marcel!
2.: As mentioned in the past, I would generally like to get rid of the separate Debugger subclasses (keep dimension of inheritance free for real features instead of implementation issues).
All the #openOn:context:label:contents:fullView: implementations share some duplication:
[cid:9e5cc07a-790d-434d-ac5f-6f8c33fbc150]
[cid:f85fdc00-a30a-4c55-8b40-6255d5176a9a]
I think it could be good to revise the method composition here. Ideally, we could have a separate method that only performs the opening itself, and we could wrap it into #setErrorRecursionFlagDuring: by the superclass.
And maybe outsource some UI specific things to the current UIManager ...
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 14:32:05 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel
Am 16.12.2019 11:53:21 schrieb commits@source.squeak.org commits@source.squeak.org:
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full
| debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).
uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].
"Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ].
"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock.
processToDebug suspend.
"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
Hi Christoph.
I would generally like to get rid of the separate Debugger subclasses.
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
I think it could be good to revise the method composition here.
Make sure that all DebuggerTests pass. Add new ones. I still need to document more thoughts on this because I think the reasons for the current architecture are not clear enough to other developers. We can talk about this, if you want to brainstorm on the topic. Keeping the image responsive is really tricky. In the past, the Emergency Evaluator (before 4.6) popped up way too often. We are in a better state now, I think. But there is still more to do.
And maybe outsource some UI specific things to the current UIManager ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Best, Marcel
Am 16.12.2019 15:01:16 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel!
2.: As mentioned in the past, I would generally like to get rid of the separate Debugger subclasses (keep dimension of inheritance free for real features instead of implementation issues). All the #openOn:context:label:contents:fullView: implementations share some duplication:
I think it could be good to revise the method composition here. Ideally, we could have a separate method that only performs the opening itself, and we could wrap it into #setErrorRecursionFlagDuring: by the superclass. And maybe outsource some UI specific things to the current UIManager ...
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 14:32:05 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel Am 16.12.2019 11:53:21 schrieb commits@source.squeak.org commits@source.squeak.org: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full
| debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).
uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].
"Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ].
"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock.
processToDebug suspend.
"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
Hi Marcel, thanks for your reply!
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
That sounds great! In face of "baby steps," maybe we should document this progress in the class comments? Minimizing the risks that someone relies on the existence of these classes ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Good to know: Project, not UIManager. Makes sense :) I will keep it mind - currently, I'm still working on the Inspectors, but this might be a potential project after Christmas :-)
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 19:30:34 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
Hi Christoph.
I would generally like to get rid of the separate Debugger subclasses.
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
I think it could be good to revise the method composition here.
Make sure that all DebuggerTests pass. Add new ones. I still need to document more thoughts on this because I think the reasons for the current architecture are not clear enough to other developers. We can talk about this, if you want to brainstorm on the topic. Keeping the image responsive is really tricky. In the past, the Emergency Evaluator (before 4.6) popped up way too often. We are in a better state now, I think. But there is still more to do.
And maybe outsource some UI specific things to the current UIManager ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Best, Marcel
Am 16.12.2019 15:01:16 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel!
2.: As mentioned in the past, I would generally like to get rid of the separate Debugger subclasses (keep dimension of inheritance free for real features instead of implementation issues).
All the #openOn:context:label:contents:fullView: implementations share some duplication:
[cid:9e5cc07a-790d-434d-ac5f-6f8c33fbc150]
[cid:f85fdc00-a30a-4c55-8b40-6255d5176a9a]
I think it could be good to revise the method composition here. Ideally, we could have a separate method that only performs the opening itself, and we could wrap it into #setErrorRecursionFlagDuring: by the superclass.
And maybe outsource some UI specific things to the current UIManager ...
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 14:32:05 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel
Am 16.12.2019 11:53:21 schrieb commits@source.squeak.org commits@source.squeak.org:
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full
| debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).
uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].
"Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ].
"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock.
processToDebug suspend.
"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
I just documented my intentions and plans in Tools-mt.925.
Best, Marcel Am 16.12.2019 19:39:07 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, thanks for your reply!
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
That sounds great! In face of "baby steps," maybe we should document this progress in the class comments? Minimizing the risks that someone relies on the existence of these classes ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Good to know: Project, not UIManager. Makes sense :) I will keep it mind - currently, I'm still working on the Inspectors, but this might be a potential project after Christmas :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 19:30:34 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz Hi Christoph.
I would generally like to get rid of the separate Debugger subclasses.
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
I think it could be good to revise the method composition here.
Make sure that all DebuggerTests pass. Add new ones. I still need to document more thoughts on this because I think the reasons for the current architecture are not clear enough to other developers. We can talk about this, if you want to brainstorm on the topic. Keeping the image responsive is really tricky. In the past, the Emergency Evaluator (before 4.6) popped up way too often. We are in a better state now, I think. But there is still more to do.
And maybe outsource some UI specific things to the current UIManager ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Best, Marcel
Am 16.12.2019 15:01:16 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel!
2.: As mentioned in the past, I would generally like to get rid of the separate Debugger subclasses (keep dimension of inheritance free for real features instead of implementation issues). All the #openOn:context:label:contents:fullView: implementations share some duplication:
I think it could be good to revise the method composition here. Ideally, we could have a separate method that only performs the opening itself, and we could wrap it into #setErrorRecursionFlagDuring: by the superclass. And maybe outsource some UI specific things to the current UIManager ...
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 14:32:05 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel Am 16.12.2019 11:53:21 schrieb commits@source.squeak.org commits@source.squeak.org: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full
| debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).
uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].
"Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ].
"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock.
processToDebug suspend.
"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
Great, thanks!
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 17. Dezember 2019 12:22:16 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
I just documented my intentions and plans in Tools-mt.925.
Best, Marcel
Am 16.12.2019 19:39:07 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, thanks for your reply!
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
That sounds great! In face of "baby steps," maybe we should document this progress in the class comments? Minimizing the risks that someone relies on the existence of these classes ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Good to know: Project, not UIManager. Makes sense :) I will keep it mind - currently, I'm still working on the Inspectors, but this might be a potential project after Christmas :-)
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 19:30:34 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
Hi Christoph.
I would generally like to get rid of the separate Debugger subclasses.
Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.
I think it could be good to revise the method composition here.
Make sure that all DebuggerTests pass. Add new ones. I still need to document more thoughts on this because I think the reasons for the current architecture are not clear enough to other developers. We can talk about this, if you want to brainstorm on the topic. Keeping the image responsive is really tricky. In the past, the Emergency Evaluator (before 4.6) popped up way too often. We are in a better state now, I think. But there is still more to do.
And maybe outsource some UI specific things to the current UIManager ...
Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)
Best, Marcel
Am 16.12.2019 15:01:16 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel!
2.: As mentioned in the past, I would generally like to get rid of the separate Debugger subclasses (keep dimension of inheritance free for real features instead of implementation issues).
All the #openOn:context:label:contents:fullView: implementations share some duplication:
[cid:9e5cc07a-790d-434d-ac5f-6f8c33fbc150]
[cid:f85fdc00-a30a-4c55-8b40-6255d5176a9a]
I think it could be good to revise the method composition here. Ideally, we could have a separate method that only performs the opening itself, and we could wrap it into #setErrorRecursionFlagDuring: by the superclass.
And maybe outsource some UI specific things to the current UIManager ...
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 16. Dezember 2019 14:32:05 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel
Am 16.12.2019 11:53:21 schrieb commits@source.squeak.org commits@source.squeak.org:
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1610.mcz
==================== Summary ====================
Name: Morphic-ct.1610 Author: ct Time: 16 December 2019, 11:52:56.435097 am UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad Ancestors: Morphic-mt.1608
Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.
To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.
=============== Diff against Morphic-mt.1608 ===============
Item was changed: ----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') ----- openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full
| debugger uiBlock | debugger := self new process: processToDebug context: context; errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).
uiBlock := [ full ifTrue: [debugger openFullNoSuspendLabel: title] ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].
"Try drawing the debugger tool at least once to avoid freeze." debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"]. ].
"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code." (Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess]) + ifTrue: [Project current addDeferredUIMessage: [ + Processor activeProcess setErrorRecursionFlagDuring: uiBlock]] - ifTrue: [Project current addDeferredUIMessage: uiBlock] ifFalse: uiBlock.
processToDebug suspend.
"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value." ^ debugger!
Am Mo., 16. Dez. 2019 um 14:32 Uhr schrieb Marcel Taeumel < marcel.taeumel@hpi.de>:
Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
- Generator step-over
Generator on: [:g | g yield: #foo].
- Error in a debugger's build-with method.
Best, Marcel
FYI today there are still some cases that spawn endless debuggers.
It had it twice today, but unfortunately can't give you exacts steps for reproduction. 1. Debug a test case, step over some long operation, interrupt with Cmd+. to because of impatience, step so far in the second debugger that control could theoretically return to the first one. Then there was some Context on the top of the stack that did not seem to belong there, with a return handler... Well I had a manual ping-pong situation between the two debuggers. After pressing the wrong button it resulted in an endless stream of new debuggers about not being able to return. 2. Press Into at the wrong place during a return handler (ensure:). Endless debuggers about aboutToReturn:through: (I saw that somewhere). The stack trace shows back-and-forth between Message>>sentTo: and UndefinedObject doesNotUnderStand: #findContextSuchThat: -- see attachment.
Maybe I should finally start to remember taking screenshots. Both cases seemed to be related to stack unwinding or ensure: actions though.
Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
Merry Christmas everyone. Kind regards, Jakob
Hi Jakob,
yes, these observations are very well known to me ... :)
Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
FYI, you can also press Ctrl + 5 to open the "Do" menu and then type "De" + Enter to perform "Utilities closeAllDebuggers". Or modify Marcel's changeset from May (cmd-dot-dialog.cs) and add the command there :)
However, we should sharpen our error detection while opening a debugger. This would make it so much easier to debug such problems ...
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Montag, 23. Dezember 2019 17:55:38 An: The general-purpose Squeak developers list Betreff: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Am Mo., 16. Dez. 2019 um 14:32 Uhr schrieb Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de>: Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel
FYI today there are still some cases that spawn endless debuggers.
It had it twice today, but unfortunately can't give you exacts steps for reproduction. 1. Debug a test case, step over some long operation, interrupt with Cmd+. to because of impatience, step so far in the second debugger that control could theoretically return to the first one. Then there was some Context on the top of the stack that did not seem to belong there, with a return handler... Well I had a manual ping-pong situation between the two debuggers. After pressing the wrong button it resulted in an endless stream of new debuggers about not being able to return. 2. Press Into at the wrong place during a return handler (ensure:). Endless debuggers about aboutToReturn:through: (I saw that somewhere). The stack trace shows back-and-forth between Message>>sentTo: and UndefinedObject doesNotUnderStand: #findContextSuchThat: -- see attachment.
Maybe I should finally start to remember taking screenshots. Both cases seemed to be related to stack unwinding or ensure: actions though.
Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
Merry Christmas everyone. Kind regards, Jakob
Encountered it again today. This time while stepping over something it ran into a self break, but instead of interrupting, the image froze until I pressed Cmd+. Now I get countless debuggers on the self break frame plus many more countless debuggers on Context>>cannotReturn:to: with a BlockCannotReturn exception.
It only hang for about 10 seconds and is still spawning debuggers after half an hour... I don't know whether this will ever come to an end.
--- The full stack --- [] in DosFileDirectory(FileDirectory)>>deleteFileNamed:ifAbsent: StandardFileStream class>>retryWithGC:until:forFileNamed: DosFileDirectory(FileDirectory)>>deleteFileNamed:ifAbsent: SmalltalkImage>>logError:inContext:to: SmalltalkImage>>logSqueakError:inContext: [] in Debugger class>>openOn:context:label:contents:fullView: BlockClosure>>on:do: Debugger class>>openOn:context:label:contents:fullView: ECToolSet class(StandardToolSet class)>>debugProcess:context:label:contents:fullView: ToolSet class>>debugProcess:context:label:contents:fullView: Process>>debug:title:full:contents: Process>>debug:title:full: Process>>debug:title: ECToolSet class(StandardToolSet class)>>handleError: ToolSet class>>handleError: UnhandledError>>defaultAction UndefinedObject>>handleSignal: UnhandledError(Exception)>>signal UnhandledError class>>signalForException: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BlockCannotReturn(Error)>>defaultAction BlockCannotReturn>>defaultAction UndefinedObject>>handleSignal: BlockCannotReturn(Exception)>>signal Context>>cannotReturn:to: Context>>cannotReturn: [] in BlockClosure>>newProcess
Am Mo., 23. Dez. 2019 um 20:05 Uhr schrieb Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de>:
Hi Jakob,
yes, these observations are very well known to me ... :)
Is there a way to stop this if it happens? I have "Open tools attached
to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
FYI, you can also press Ctrl + 5 to open the "Do" menu and then type "De"
- Enter to perform "Utilities closeAllDebuggers".
Or modify Marcel's changeset from May (cmd-dot-dialog.cs) and add the command there :)
However, we should sharpen our error detection while opening a debugger. This would make it so much easier to debug such problems ...
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de *Gesendet:* Montag, 23. Dezember 2019 17:55:38 *An:* The general-purpose Squeak developers list *Betreff:* [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Am Mo., 16. Dez. 2019 um 14:32 Uhr schrieb Marcel Taeumel < marcel.taeumel@hpi.de>:
Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
- Generator step-over
Generator on: [:g | g yield: #foo].
- Error in a debugger's build-with method.
Best, Marcel
FYI today there are still some cases that spawn endless debuggers.
It had it twice today, but unfortunately can't give you exacts steps for reproduction.
- Debug a test case, step over some long operation, interrupt with Cmd+.
to because of impatience, step so far in the second debugger that control could theoretically return to the first one. Then there was some Context on the top of the stack that did not seem to belong there, with a return handler... Well I had a manual ping-pong situation between the two debuggers. After pressing the wrong button it resulted in an endless stream of new debuggers about not being able to return. 2. Press Into at the wrong place during a return handler (ensure:). Endless debuggers about aboutToReturn:through: (I saw that somewhere). The stack trace shows back-and-forth between Message>>sentTo: and UndefinedObject doesNotUnderStand: #findContextSuchThat: -- see attachment.
Maybe I should finally start to remember taking screenshots. Both cases seemed to be related to stack unwinding or ensure: actions though.
Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
Merry Christmas everyone. Kind regards, Jakob
I don't know whether this will ever come to an end.
I'm almost sure it won't. This must be kind of a recursive error.
Afaik each debugger does a few hidden steps before appearing to the user (to hide the implementation details of UnhandledError; if the debugger opens, you will land at the outerContext or so), and I think somewhere on this way, an invalid context (with a nil sender) is passed ... But I could not investigate it yet.
If you would like to do so, you could experiment with inserting an #inform: in #handleError: and then open the ProcessBrowser before the next debugger appears.
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Montag, 30. Dezember 2019 14:07:53 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Encountered it again today. This time while stepping over something it ran into a self break, but instead of interrupting, the image froze until I pressed Cmd+. Now I get countless debuggers on the self break frame plus many more countless debuggers on Context>>cannotReturn:to: with a BlockCannotReturn exception.
It only hang for about 10 seconds and is still spawning debuggers after half an hour... I don't know whether this will ever come to an end.
--- The full stack --- [] in DosFileDirectory(FileDirectory)>>deleteFileNamed:ifAbsent: StandardFileStream class>>retryWithGC:until:forFileNamed: DosFileDirectory(FileDirectory)>>deleteFileNamed:ifAbsent: SmalltalkImage>>logError:inContext:to: SmalltalkImage>>logSqueakError:inContext: [] in Debugger class>>openOn:context:label:contents:fullView: BlockClosure>>on:do: Debugger class>>openOn:context:label:contents:fullView: ECToolSet class(StandardToolSet class)>>debugProcess:context:label:contents:fullView: ToolSet class>>debugProcess:context:label:contents:fullView: Process>>debug:title:full:contents: Process>>debug:title:full: Process>>debug:title: ECToolSet class(StandardToolSet class)>>handleError: ToolSet class>>handleError: UnhandledError>>defaultAction UndefinedObject>>handleSignal: UnhandledError(Exception)>>signal UnhandledError class>>signalForException: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BlockCannotReturn(Error)>>defaultAction BlockCannotReturn>>defaultAction UndefinedObject>>handleSignal: BlockCannotReturn(Exception)>>signal Context>>cannotReturn:to: Context>>cannotReturn: [] in BlockClosure>>newProcess
Am Mo., 23. Dez. 2019 um 20:05 Uhr schrieb Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:
Hi Jakob,
yes, these observations are very well known to me ... :)
Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
FYI, you can also press Ctrl + 5 to open the "Do" menu and then type "De" + Enter to perform "Utilities closeAllDebuggers". Or modify Marcel's changeset from May (cmd-dot-dialog.cs) and add the command there :)
However, we should sharpen our error detection while opening a debugger. This would make it so much easier to debug such problems ...
Best, Christoph
________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob@resfarm.demailto:forums.jakob@resfarm.de> Gesendet: Montag, 23. Dezember 2019 17:55:38 An: The general-purpose Squeak developers list Betreff: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Am Mo., 16. Dez. 2019 um 14:32 Uhr schrieb Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de>: Hi Christoph,
hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:
1. Generator step-over Generator on: [:g | g yield: #foo].
2. Error in a debugger's build-with method.
Best, Marcel
FYI today there are still some cases that spawn endless debuggers.
It had it twice today, but unfortunately can't give you exacts steps for reproduction. 1. Debug a test case, step over some long operation, interrupt with Cmd+. to because of impatience, step so far in the second debugger that control could theoretically return to the first one. Then there was some Context on the top of the stack that did not seem to belong there, with a return handler... Well I had a manual ping-pong situation between the two debuggers. After pressing the wrong button it resulted in an endless stream of new debuggers about not being able to return. 2. Press Into at the wrong place during a return handler (ensure:). Endless debuggers about aboutToReturn:through: (I saw that somewhere). The stack trace shows back-and-forth between Message>>sentTo: and UndefinedObject doesNotUnderStand: #findContextSuchThat: -- see attachment.
Maybe I should finally start to remember taking screenshots. Both cases seemed to be related to stack unwinding or ensure: actions though.
Is there a way to stop this if it happens? I have "Open tools attached to hand" activated so I cannot click on Do > Utilities closeAllDebuggers...
Merry Christmas everyone. Kind regards, Jakob
Am Mo., 30. Dez. 2019 um 14:20 Uhr schrieb Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de>:
If you would like to do so, you could experiment with inserting an #inform: in #handleError: and then open the ProcessBrowser before the next debugger appears.
A funny kind of breakpoint ;-)
For best experience, combine it with "debug dialog invocation".
And just another trick how to "debug without debugger":
thisContext veryDeepCopy explore.
:-)
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Montag, 30. Dezember 2019 14:24 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Am Mo., 30. Dez. 2019 um 14:20 Uhr schrieb Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:
If you would like to do so, you could experiment with inserting an #inform: in #handleError: and then open the ProcessBrowser before the next debugger appears.
A funny kind of breakpoint ;-)
On Dec 30, 2019, at 8:30 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
For best experience, combine it with "debug dialog invocation".
And just another trick how to "debug without debugger":
thisContext veryDeepCopy explore.
:-)
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Montag, 30. Dezember 2019 14:24 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Am Mo., 30. Dez. 2019 um 14:20 Uhr schrieb Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de: If you would like to do so, you could experiment with inserting an #inform: in #handleError: and then open the ProcessBrowser before the next debugger appears.
A funny kind of breakpoint ;-)
Actually this is a good idea. I find I can at least open the window menu and “choose close all like this” to close some debuggers even if I can’t get back control. So what you could do is provide a button on a debugger to save a deep copy to the file system, eg as an image segment, and then abandon the image, restart and load the context chain from the serialization for analysis.
Interesting approach :)
I find I can at least open the window menu and “choose close all like this” to close some debuggers even if I can’t get back control.
Um, this seems to depend on the kind of violation. If the debugged context cannot be unwound, you cannot even use Utilities closeAllDebuggers.
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Montag, 30. Dezember 2019 17:56:33 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
On Dec 30, 2019, at 8:30 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
For best experience, combine it with "debug dialog invocation".
And just another trick how to "debug without debugger":
thisContext veryDeepCopy explore.
:-)
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Montag, 30. Dezember 2019 14:24 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)
Am Mo., 30. Dez. 2019 um 14:20 Uhr schrieb Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:
If you would like to do so, you could experiment with inserting an #inform: in #handleError: and then open the ProcessBrowser before the next debugger appears.
A funny kind of breakpoint ;-)
Actually this is a good idea. I find I can at least open the window menu and “choose close all like this” to close some debuggers even if I can’t get back control. So what you could do is provide a button on a debugger to save a deep copy to the file system, eg as an image segment, and then abandon the image, restart and load the context chain from the serialization for analysis.
squeak-dev@lists.squeakfoundation.org
-
commits＠source.squeak.org -
Eliot Miranda -
Jakob Reschke -
Marcel Taeumel -
Thiede, Christoph