Hi Christoph,

thanks for your explanation; my head's spinning :D I was aware about the Debugger hiding the top of the stack, it's a nice feature :)

Just one more question: if you close the debugger the pluggable list menu closes - is this expected or not? The debugger runs unwinds and closes it as a result; and I don't understand whether it's an unwanted side effect or whether closing the dialog is an expected behavior when closing the debugger.

I just wanted to share the observation... no opinion about the fixes, the debugger is still out of my reach :)

Thanks,

best, ~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2022-01-16T01:23:46+01:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi Jaromir,

as always, very nice observation! :) Yeah, I was already aware that stepping too early from this debugger before answering the dialog would lead to some weird behavior, but then I forgot about it again when I introduced this menu item a few years ago. Thanks for the reminder!

After taking a look in it, it's actually a pretty nice story that is going on here: If you press "debug invocation" and then immediately press any of the stepping buttons, then the new debugger will send the process which is displaying the dialog window a #complete: message with the displayed "suspended" context, which is not really the top context of this process (that would be MorphicDebugger class>>openOn:context:label:contents:fullView: - the debugger is often cutting away a few contexts from the top of the sender stack to keep it manageable for the user - to reproduce this, just open a halo on the "debug invocation" menu and debug its action invocation (debugging the debugger is so much fun!)) but rather, the debugger is pointing to the context that initially sent a message to the UIManager (in the bug report from below, this would be UndefinedObject>>DoIt). End of parentheses forest, during this stepping operation, the control is given back to the debuggee process vi!

a the #runUntilErrorOrReturnFrom: trick until it reaches the invocation context (#DoIt) again. So far so good, but in this case, it's actually taking a lot of time until this invocation context is reached again, because the dialog window will run in a large loop and do one world subcycle after each other until the dialog has been closed (see DialogWindow>>#offerDialogMenu). This means that everything you can see after pressing the stepping button for the first time is actually still happening INSIDE the stepping button, executed by the genuine process which was also responsible for showing up the debugger, so it is literally debugging itself, #runUntilErrorOrReturnFrom: has not yet returned. So if you pressed the stepping button for a second time, things would explode because the active process's suspendedContext is nil, thus the nil MNU for #findContextSuchThat:.

To cut a long story short, stepping from a "debug invocation" debugger before you answered the dialog is a bad thing and should not be done. But at the same time, I experienced the same confusion like you in the past as well, so I think it would be helpful to place a simple self inform: 'You must answer the dialog window before continuing stepping' translated. right after the debugger invocation in DialogWindow>>#debugInvocation (a request to debug an active process will only return in the moment where this process is advanced). You can still stray off the desired path by resisting this call, but at least you will be warned now and know how to debug the dialog invocation properly.

I think this would be a good mitigation. If there is no objection from you or anyone else, I will patch this in a few days. Thank you for sweetening my evening with this interesting observation! :-)

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2022-01-15T23:55:47+01:00, mail at jaromir.net wrote:

...

Hi Christoph,

I did steps 1 and 2 only and tried to step the debugger and was confused what happened next:

• if you do step over twice the debugger gets "MessageNotUnderstood: UndefinedObject>>findContextSuchThat:" which is weird
• however, if you do step through instead of step over, you even get an infinite loop, luckily recoverable via Alt+., which is even weirder...
• and using step into instead of step over ends up with a similar MNU too.

So maybe the pluggable dialog bug in your scenario has even deeper roots, I don't know... I don't understand why the MNU error above; I wouldn't expect that... it sounds like the debugger is searching for a context on the wrong stack...

best,

^[^    Jaromir

Sent from Squeak Inbox Talk

On 2022-01-15T21:19:52+00:00, commits at source.squeak.org wrote:

> A new version of ToolBuilder-Morphic was added to project The Inbox:
> http://source.squeak.org/inbox/ToolBuilder-Morphic-ct.286.mcz
> 
> ==================== Summary ====================
> 
> Name: ToolBuilder-Morphic-ct.286
> Author: ct
> Time: 15 January 2022, 10:19:51.009373 pm
> UUID: 3c0068e7-ce8e-5f45-8782-34c92bc6ab5f
> Ancestors: ToolBuilder-Morphic-ct.285
> 
> Fixes a nil MNU when interrupting a pluggable dialog.
> 
> Steps to reproduce (before):
> ����1. Do it:
> ��������Project uiManager chooseFrom: ((1 to: 10) collect: #asWords).
> ����2. Interrupt/Debug invocation
> ����3. Close/cancel the dialog
> ����4. Abandon the debugger
> 
> During the unwinding logic, the dialog window would attempt to close itself a second time, neglecting the fact that the model had already been released.
> 
> Inbox because only 90% sure that this is the right fix. :-)
> 
> =============== Diff against ToolBuilder-Morphic-ct.285 ===============
> 
> Item was changed:
>   ----- Method: PluggableDialogWindow>>delete (in category 'submorphs - add/remove') -----
>   delete
>   
> + ����self model ifNil: [^ super delete].
>   ����self model okToClose ifFalse: [^ self].
>   ����
>   ����self closeDialogSelector ifNotNil: [:sel | self model perform: sel].
>   ����
>   ����self model
>   ��������windowIsClosing;
>   ��������release.
>   ����self model: nil.
>   ����
>   ����super delete.!
> 
>

Hi Jaromir,

please see Tools-ct.1109 for an alternative solution. My original proposal with the #inform: would only cover the most basic interaction sequences, this patch is more holistic. Maybe you could check whether I used the right selectors for testing the process state (#isTerminated and #isSuspended)? :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2022-01-16T19:16:40+01:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi Jaromir,

...

if you close the debugger the pluggable list menu closes - is this expected or not?

I would say this behavior make sense. You are debugging the process which has requested the dialog, and if you terminate this process, there is no client any longer which would be interested in processing the dialog answer. It would only confuse users if they answer the dialog then and nothing happens. :-)

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2022-01-16T10:21:41+01:00, mail at jaromir.net wrote:

...

Hi Christoph,

thanks for your explanation; my head's spinning :D I was aware about the Debugger hiding the top of the stack, it's a nice feature :)

Just one more question: if you close the debugger the pluggable list menu closes - is this expected or not? The debugger runs unwinds and closes it as a result; and I don't understand whether it's an unwanted side effect or whether closing the dialog is an expected behavior when closing the debugger.

I just wanted to share the observation... no opinion about the fixes, the debugger is still out of my reach :)

Thanks,

best,

^[^    Jaromir

Sent from Squeak Inbox Talk

On 2022-01-16T01:23:46+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi Jaromir,
> 
> as always, very nice observation! :) Yeah, I was already aware that stepping too early from this debugger before answering the dialog would lead to some weird behavior, but then I forgot about it again when I introduced this menu item a few years ago. Thanks for the reminder!
> 
> After taking a look in it, it's actually a pretty nice story that is going on here: If you press "debug invocation" and then immediately press any of the stepping buttons, then the new debugger will send the process which is displaying the dialog window a #complete: message with the displayed "suspended" context, which is not really the top context of this process (that would be MorphicDebugger class>>openOn:context:label:contents:fullView: - the debugger is often cutting away a few contexts from the top of the sender stack to keep it manageable for the user - to reproduce this, just open a halo on the "debug invocation" menu and debug its action invocation (debugging the debugger is so much fun!)) but rather, the debugger is pointing to the context that initially sent a message to the UIManager (in the bug report from below, this would be UndefinedObject>>DoIt). End of parentheses forest, during this stepping operation, the control is given back to the debuggee process vi!
 a the #runUntilErrorOrReturnFrom: trick until it reaches the invocation context (#DoIt) again. So far so good, but in this case, it's actually taking a lot of time until this invocation context is reached again, because the dialog window will run in a large loop and do one world subcycle after each other until the dialog has been closed (see DialogWindow>>#offerDialogMenu). This means that everything you can see after pressing the stepping button for the first time is actually still happening INSIDE the stepping button, executed by the genuine process which was also responsible for showing up the debugger, so it is literally debugging itself, #runUntilErrorOrReturnFrom: has not yet returned. So if you pressed the stepping button for a second time, things would explode because the active process's suspendedContext is nil, thus the nil MNU for #findContextSuchThat:.
> 
> To cut a long story short, stepping from a "debug invocation" debugger before you answered the dialog is a bad thing and should not be done. But at the same time, I experienced the same confusion like you in the past as well, so I think it would be helpful to place a simple
> ????self inform: 'You must answer the dialog window before continuing stepping' translated.
> right after the debugger invocation in DialogWindow>>#debugInvocation (a request to debug an active process will only return in the moment where this process is advanced). You can still stray off the desired path by resisting this call, but at least you will be warned now and know how to debug the dialog invocation properly.
> 
> I think this would be a good mitigation. If there is no objection from you or anyone else, I will patch this in a few days. Thank you for sweetening my evening with this interesting observation! :-)
> 
> Best,
> Christoph
> 
> ---
> Sent from Squeak Inbox Talk
> 
> On 2022-01-15T23:55:47+01:00, mail at jaromir.net wrote:
> 
> > Hi Christoph,
> > 
> > I did steps 1 and 2 only and tried to step the debugger and was confused what happened next:
> > 
> > - if you do step over twice the debugger gets "MessageNotUnderstood: UndefinedObject>>findContextSuchThat:" which is weird
> > - however, if you do step through instead of step over, you even get an infinite loop, luckily recoverable via Alt+., which is even weirder...
> > - and using step into instead of step over ends up with a similar MNU too.
> > 
> > So maybe the pluggable dialog bug in your scenario has even deeper roots, I don't know... I don't understand why the MNU error above; I wouldn't expect that... it sounds like the debugger is searching for a context on the wrong stack...
> > 
> > best,
> > ~~~
> > ^[^    Jaromir
> > 
> > Sent from Squeak Inbox Talk
> > 
> > On 2022-01-15T21:19:52+00:00, commits at source.squeak.org wrote:
> > 
> > > A new version of ToolBuilder-Morphic was added to project The Inbox:
> > > http://source.squeak.org/inbox/ToolBuilder-Morphic-ct.286.mcz
> > > 
> > > ==================== Summary ====================
> > > 
> > > Name: ToolBuilder-Morphic-ct.286
> > > Author: ct
> > > Time: 15 January 2022, 10:19:51.009373 pm
> > > UUID: 3c0068e7-ce8e-5f45-8782-34c92bc6ab5f
> > > Ancestors: ToolBuilder-Morphic-ct.285
> > > 
> > > Fixes a nil MNU when interrupting a pluggable dialog.
> > > 
> > > Steps to reproduce (before):
> > > ????1. Do it:
> > > ????????Project uiManager chooseFrom: ((1 to: 10) collect: #asWords).
> > > ????2. Interrupt/Debug invocation
> > > ????3. Close/cancel the dialog
> > > ????4. Abandon the debugger
> > > 
> > > During the unwinding logic, the dialog window would attempt to close itself a second time, neglecting the fact that the model had already been released.
> > > 
> > > Inbox because only 90% sure that this is the right fix. :-)
> > > 
> > > =============== Diff against ToolBuilder-Morphic-ct.285 ===============
> > > 
> > > Item was changed:
> > >   ----- Method: PluggableDialogWindow>>delete (in category 'submorphs - add/remove') -----
> > >   delete
> > >   
> > > + ????self model ifNil: [^ super delete].
> > >   ????self model okToClose ifFalse: [^ self].
> > >   ????
> > >   ????self closeDialogSelector ifNotNil: [:sel | self model perform: sel].
> > >   ????
> > >   ????self model
> > >   ????????windowIsClosing;
> > >   ????????release.
> > >   ????self model: nil.
> > >   ????
> > >   ????super delete.!
> > > 
> > >
> > 
> > 
> 

Hi Jaromir,

merged Tools-ct.1109 and treated ToolBuilder-Morphic-ct.286. Could you please check again if you find any other inconveniences regarding 'debug dialog invocation'? :-)

I have kept both #isSuspended and #isTerminated to document both edge cases explicitly. Thanks for your feedback!

Unfortunately in case of step through the button greys out but the image somehow ends up in a loop anyway...

When you step through while the dialog is still open, the presentation + world cycles of the dialog will continue inside the debugger, which is just extremely slow. Not an infinite loop. :-) Be patient and accept/cancel the dialog, and some time later, the debugger will be responsive again. :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2022-01-16T22:17:18+01:00, mail@jaromir.net wrote:

Hi Christoph,

about the condition in interruptedProcessIsReady

^ interruptedProcess notNil         and: [interruptedProcess isSuspended "do not debug the active process"]         and: [interruptedProcess isTerminated not]

If the process 'is suspended' it automatically means it 'is not terminated' so the second part of the conditon seems redundant. I'm not sure how 'isBlocked' would fit in because I'm really not able to follow the fix, sorry :)

However, regarding the behavior, it's nice to grey out the buttons! Unfortunately in case of step through the button greys out but the image somehow ends up in a loop anyway... No idea why though.

best,

^[^    Jaromir

Sent from Squeak Inbox Talk

On 2022-01-16T20:06:18+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi Jaromir,
> 
> please see Tools-ct.1109 for an alternative solution. My original proposal with the #inform: would only cover the most basic interaction sequences, this patch is more holistic. Maybe you could check whether I used the right selectors for testing the process state (#isTerminated and #isSuspended)? :-)
> 
> Best,
> Christoph
> 
> ---
> Sent from Squeak Inbox Talk
> 
> On 2022-01-16T19:16:40+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> 
> > Hi Jaromir,
> > 
> > > if you close the debugger the pluggable list menu closes - is this expected or not?
> > 
> > I would say this behavior make sense. You are debugging the process which has requested the dialog, and if you terminate this process, there is no client any longer which would be interested in processing the dialog answer. It would only confuse users if they answer the dialog then and nothing happens. :-)
> > 
> > Best,
> > Christoph
> > 
> > ---
> > Sent from Squeak Inbox Talk
> > 
> > On 2022-01-16T10:21:41+01:00, mail at jaromir.net wrote:
> > 
> > > Hi Christoph,
> > > 
> > > thanks for your explanation; my head's spinning :D I was aware about the Debugger hiding the top of the stack, it's a nice feature :)
> > > 
> > > Just one more question: if you close the debugger the pluggable list menu closes - is this expected or not? The debugger runs unwinds and closes it as a result; and I don't understand whether it's an unwanted side effect or whether closing the dialog is an expected behavior when closing the debugger.
> > > 
> > > I just wanted to share the observation... no opinion about the fixes, the debugger is still out of my reach :)
> > > 
> > > Thanks,
> > > 
> > > best,
> > > ~~~
> > > ^[^    Jaromir
> > > 
> > > Sent from Squeak Inbox Talk
> > > 
> > > On 2022-01-16T01:23:46+01:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> > > 
> > > > Hi Jaromir,
> > > > 
> > > > as always, very nice observation! :) Yeah, I was already aware that stepping too early from this debugger before answering the dialog would lead to some weird behavior, but then I forgot about it again when I introduced this menu item a few years ago. Thanks for the reminder!
> > > > 
> > > > After taking a look in it, it's actually a pretty nice story that is going on here: If you press "debug invocation" and then immediately press any of the stepping buttons, then the new debugger will send the process which is displaying the dialog window a #complete: message with the displayed "suspended" context, which is not really the top context of this process (that would be MorphicDebugger class>>openOn:context:label:contents:fullView: - the debugger is often cutting away a few contexts from the top of the sender stack to keep it manageable for the user - to reproduce this, just open a halo on the "debug invocation" menu and debug its action invocation (debugging the debugger is so much fun!)) but rather, the debugger is pointing to the context that initially sent a message to the UIManager (in the bug report from below, this would be UndefinedObject>>DoIt). End of parentheses forest, during this stepping operation, the control is given back to the debuggee proc!
 ess vi!
> > >  a the #runUntilErrorOrReturnFrom: trick until it reaches the invocation context (#DoIt) again. So far so good, but in this case, it's actually taking a lot of time until this invocation context is reached again, because the dialog window will run in a large loop and do one world subcycle after each other until the dialog has been closed (see DialogWindow>>#offerDialogMenu). This means that everything you can see after pressing the stepping button for the first time is actually still happening INSIDE the stepping button, executed by the genuine process which was also responsible for showing up the debugger, so it is literally debugging itself, #runUntilErrorOrReturnFrom: has not yet returned. So if you pressed the stepping button for a second time, things would explode because the active process's suspendedContext is nil, thus the nil MNU for #findContextSuchThat:.
> > > > 
> > > > To cut a long story short, stepping from a "debug invocation" debugger before you answered the dialog is a bad thing and should not be done. But at the same time, I experienced the same confusion like you in the past as well, so I think it would be helpful to place a simple
> > > > ????self inform: 'You must answer the dialog window before continuing stepping' translated.
> > > > right after the debugger invocation in DialogWindow>>#debugInvocation (a request to debug an active process will only return in the moment where this process is advanced). You can still stray off the desired path by resisting this call, but at least you will be warned now and know how to debug the dialog invocation properly.
> > > > 
> > > > I think this would be a good mitigation. If there is no objection from you or anyone else, I will patch this in a few days. Thank you for sweetening my evening with this interesting observation! :-)
> > > > 
> > > > Best,
> > > > Christoph
> > > > 
> > > > ---
> > > > Sent from Squeak Inbox Talk
> > > > 
> > > > On 2022-01-15T23:55:47+01:00, mail at jaromir.net wrote:
> > > > 
> > > > > Hi Christoph,
> > > > > 
> > > > > I did steps 1 and 2 only and tried to step the debugger and was confused what happened next:
> > > > > 
> > > > > - if you do step over twice the debugger gets "MessageNotUnderstood: UndefinedObject>>findContextSuchThat:" which is weird
> > > > > - however, if you do step through instead of step over, you even get an infinite loop, luckily recoverable via Alt+., which is even weirder...
> > > > > - and using step into instead of step over ends up with a similar MNU too.
> > > > > 
> > > > > So maybe the pluggable dialog bug in your scenario has even deeper roots, I don't know... I don't understand why the MNU error above; I wouldn't expect that... it sounds like the debugger is searching for a context on the wrong stack...
> > > > > 
> > > > > best,
> > > > > ~~~
> > > > > ^[^    Jaromir
> > > > > 
> > > > > Sent from Squeak Inbox Talk
> > > > > 
> > > > > On 2022-01-15T21:19:52+00:00, commits at source.squeak.org wrote:
> > > > > 
> > > > > > A new version of ToolBuilder-Morphic was added to project The Inbox:
> > > > > > http://source.squeak.org/inbox/ToolBuilder-Morphic-ct.286.mcz
> > > > > > 
> > > > > > ==================== Summary ====================
> > > > > > 
> > > > > > Name: ToolBuilder-Morphic-ct.286
> > > > > > Author: ct
> > > > > > Time: 15 January 2022, 10:19:51.009373 pm
> > > > > > UUID: 3c0068e7-ce8e-5f45-8782-34c92bc6ab5f
> > > > > > Ancestors: ToolBuilder-Morphic-ct.285
> > > > > > 
> > > > > > Fixes a nil MNU when interrupting a pluggable dialog.
> > > > > > 
> > > > > > Steps to reproduce (before):
> > > > > > ????1. Do it:
> > > > > > ????????Project uiManager chooseFrom: ((1 to: 10) collect: #asWords).
> > > > > > ????2. Interrupt/Debug invocation
> > > > > > ????3. Close/cancel the dialog
> > > > > > ????4. Abandon the debugger
> > > > > > 
> > > > > > During the unwinding logic, the dialog window would attempt to close itself a second time, neglecting the fact that the model had already been released.
> > > > > > 
> > > > > > Inbox because only 90% sure that this is the right fix. :-)
> > > > > > 
> > > > > > =============== Diff against ToolBuilder-Morphic-ct.285 ===============
> > > > > > 
> > > > > > Item was changed:
> > > > > >   ----- Method: PluggableDialogWindow>>delete (in category 'submorphs - add/remove') -----
> > > > > >   delete
> > > > > >   
> > > > > > + ????self model ifNil: [^ super delete].
> > > > > >   ????self model okToClose ifFalse: [^ self].
> > > > > >   ????
> > > > > >   ????self closeDialogSelector ifNotNil: [:sel | self model perform: sel].
> > > > > >   ????
> > > > > >   ????self model
> > > > > >   ????????windowIsClosing;
> > > > > >   ????????release.
> > > > > >   ????self model: nil.
> > > > > >   ????
> > > > > >   ????super delete.!
> > > > > > 
> > > > > >
> > > > > 
> > > > > 
> > > >