Smalltalk › Squeak › Squeak - Dev

The Inbox: Morphic-ct.1610.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

commits-2

The Inbox: Morphic-ct.1610.mcz

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!

marcel.taeumel

Re: 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 [hidden email] <[hidden email]>:
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!

Christoph Thiede

Re: The Inbox: Morphic-ct.1610.mcz

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 <[hidden email]> 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 [hidden email] <[hidden email]>:

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!

Carpe Squeak!

marcel.taeumel

Re: 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 <[hidden email]>:

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 <[hidden email]> 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 [hidden email] <[hidden email]>:

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!

Christoph Thiede

Re: The Inbox: Morphic-ct.1610.mcz

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 <[hidden email]> 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.

> I think it could be good to revise the method composition here.

> And maybe outsource some UI specific things to the current UIManager ...

Best,

Marcel

Am 16.12.2019 15:01:16 schrieb Thiede, Christoph <[hidden email]>:

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 <[hidden email]> 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 [hidden email] <[hidden email]>:

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!

Carpe Squeak!

marcel.taeumel

Re: 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 [hidden email] <[hidden email]>:

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!

Christoph Thiede

Re: The Inbox: Morphic-ct.1610.mcz

Great, thanks!

Von: Squeak-dev <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 [hidden email] <[hidden email]>:

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!

Carpe Squeak!

Jakob Reschke

Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

In reply to this post by marcel.taeumel

Am Mo., 16. Dez. 2019 um 14:32 Uhr schrieb Marcel Taeumel <[hidden email]>:

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

SqueakDebug.log (10K) Download Attachment

Christoph Thiede

Re: Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

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 <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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 <[hidden email]>:

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.

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

Carpe Squeak!

Jakob Reschke

Re: 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 <[hidden email]>:

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 <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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 <[hidden email]>:

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

SqueakDebug.log (14K) Download Attachment

Christoph Thiede

Re: Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

> 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 <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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)

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.

Am Mo., 23. Dez. 2019 um 20:05 Uhr schrieb Thiede, Christoph <[hidden email]>:

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 <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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 <[hidden email]>:

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

Carpe Squeak!

Jakob Reschke

Re: Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

Am Mo., 30. Dez. 2019 um 14:20 Uhr schrieb Thiede, Christoph <[hidden email]>:

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 ;-)

Christoph Thiede

Re: Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

For best experience, combine it with "debug dialog invocation".

And just another trick how to "debug without debugger":

thisContext veryDeepCopy explore.

:-)

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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 <[hidden email]>:

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 ;-)

Carpe Squeak!

Eliot Miranda-2

Re: Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

On Dec 30, 2019, at 8:30 AM, Thiede, Christoph <[hidden email]> 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 <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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 <[hidden email]>:

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.

Christoph Thiede

Re: Endless debuggers (was: The Inbox: Morphic-ct.1610.mcz)

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 <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
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 <[hidden email]>:

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 ;-)

Carpe Squeak!