MVC debugging

>  On 9/8/2010 1:54 AM, Andreas Raab wrote:
> > On 9/7/2010 7:57 PM, David T. Lewis wrote:
> >> I can't reproduce this. Are you able to get a debugger to open under
> >> MVC at this point?
> >
> > Yes. I would have posted this earlier but I had an unexpected dinner and don't feel quite capable of doing this now
> > (hick!).
> >
> >> Specifically, I changed Debugger class>>openOn:context:label:contents:fullView:
> >> to call #searchForActiveControllerNoTerminate, where #searchForActiveControllerNoTerminate
> >> is a copy of #searchForActiveController with the #terminateActive removed.
> >> I'm not seeing any difference in behavior, so I must be missing a step
> >> in the recipe.
> >
> > All right, I'm attaching the changes I have so far unreviewed. With these changes I've been able to debug just fine
> > except from the case of handling a user interrupt which doesn't quite work yet. If you want to try this out, give it a
> > shot, if not, I'll try to make headway tomorrow night. Right now I need some sleep :-)
> >
> > Cheers,
> >   - Andreas
> >
> >
> >
>
> I also did a little debugging, and I now think that the two main issues are:
> 1 the code to open the debugger is inside WorldState addDeferredUiMessage: [], even for MVC, which will probably never
> get executed
> 2 MVCTooBuilder was supposed to openNoTerminate (not open, which terminates the previous UI process) when called from
> the debugger code

>
> With these two addressed, I get the debugger as well (but also not from the user interrupt) - these are as hacks only (I
> named the openNoTerminate methods in the ToolBuilders 'open1'), but I post them as part of the conversation.
> I am not sure if these changes are identical to Andreas', but I also have to go to bed now :)
>
> Florin
>
>
>
> 'From Squeak4.1 of 17 April 2010 [latest update: #9957] on 8 September 2010 at 2:34:52 am'!
>
> !Debugger methodsFor: 'initialize' stamp: 'fm 9/8/2010 01:42'!
> openFullNoSuspendLabel: aString
>     "Create and schedule a full debugger with the given label. Do not terminate the current active process."
>
>     | oldContextStackIndex |
>     oldContextStackIndex := contextStackIndex.
>     self expandStack. "Sets contextStackIndex to zero."
>     ToolBuilder open1: self label: aString.
>     self toggleContextStackIndex: oldContextStackIndex.! !
>
> !Debugger methodsFor: 'initialize' stamp: 'fm 9/8/2010 01:39'!
> openNotifierContents: msgString label: label
>     "Create and schedule a notifier view with the given label and message. A notifier view shows just the message or the
> first several lines of the stack, with a menu that allows the user to open a full debugger if so desired."
>     "NOTE: When this method returns, a new process has been scheduled to run the windows, and thus this notifier, but
> the previous active porcess has not been suspended.  The sender will do this."
>     | msg builder spec |
>     Sensor flushKeyboard.
>     savedCursor := Sensor currentCursor.
>     Sensor currentCursor: Cursor normal.
>     (label beginsWith: 'Space is low')
>         ifTrue: [msg := self lowSpaceChoices, (msgString ifNil: [''])]
>         ifFalse: [msg := msgString].
>     builder := ToolBuilder default.
>     spec := self buildNotifierWith: builder label: label message: msg.
>     self expandStack.
>     builder open1: spec.
>     errorWasInUIProcess := Project spawnNewProcessIfThisIsUI: interruptedProcess.
> ! !
>
>
> !Debugger class methodsFor: 'opening' stamp: 'fm 9/8/2010 02:02'!
> openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
>     "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender
> stack and provides a menu that lets the user open a full debugger."
>
>     | controller errorWasInUIProcess debugger |
>     Smalltalk isMorphic
>         ifTrue: [errorWasInUIProcess := Project spawnNewProcessIfThisIsUI: process]
>         ifFalse: [controller := ScheduledControllers activeControllerProcess == process
>                 ifTrue: [ScheduledControllers activeController].
>                 debugger := self new process: process controller: controller context: context.
>                 bool
>                         ifTrue: [debugger openFullNoSuspendLabel: title]
>                         ifFalse: [debugger openNotifierContents: contentsStringOrNil label: title]].
>     WorldState addDeferredUIMessage: [
>         [
>             debugger := self new process: process controller: controller context: context.
>             Smalltalk isMorphic
>                 ifTrue: ["schedule debugger in deferred UI message to address redraw
>                         problems after opening a debugger e.g. from the testrunner."
>                     "WorldState addDeferredUIMessage: "
>                     bool
>                         ifTrue: [debugger openFullNoSuspendLabel: title]
>                         ifFalse: [debugger openNotifierContents: contentsStringOrNil label: title]]
>                 ifFalse: ["deferred UI message would require special controller in MVC"
>                     bool
>                         ifTrue: [debugger openFullNoSuspendLabel: title]
>                         ifFalse: [debugger openNotifierContents: contentsStringOrNil label: title]].
>             debugger errorWasInUIProcess: errorWasInUIProcess.
>             Preferences logDebuggerStackToFile ifTrue: [
>                 Smalltalk logError: title inContext: context to: 'SqueakDebug.log'].
>             Smalltalk isMorphic
>                 ifFalse: [ScheduledControllers searchForActiveController "needed since openNoTerminate (see debugger
> #open...) does not set up activeControllerProcess if activeProcess (this fork) is not the current
> activeControllerProcess (see #scheduled:from:)"].
>         ] on: Error do: [:ex |
>             self primitiveError:
>                 'Orginal error: ',
>                 title asString, '.
>     Debugger error: ',
>                 ([ex description] on: Error do: ['a ', ex class printString]), ':'
>         ]
>     ].
>     process suspend.
> ! !
>
>
> !MVCToolBuilder methodsFor: 'opening' stamp: 'fm 9/8/2010 01:39'!
> open1: anObject
>     "Build and open the object. Answer the widget opened."
>     | window |
>     window := self build: anObject.
>     window controller openNoTerminate.
>     ^window! !
>
> !MVCToolBuilder methodsFor: 'opening' stamp: 'fm 9/8/2010 01:41'!
> open1: anObject label: aString
>     "Build an open the object, labeling it appropriately.  Answer the widget opened."
>     | window |
>     window := self build: anObject.
>     window label: aString.
>     window controller openNoTerminate.
>     ^window! !
>
> !MVCToolBuilder methodsFor: 'opening' stamp: 'fm 9/8/2010 01:22'!
> open: anObject
>     "Build and open the object. Answer the widget opened."
>     | window |
>     window := self build: anObject.
>     window controller open.
>     ^window! !
>
> !MVCToolBuilder methodsFor: 'opening' stamp: 'fm 9/8/2010 01:23'!
> open: anObject label: aString
>     "Build an open the object, labeling it appropriately.  Answer the widget opened."
>     | window |
>     window := self build: anObject.
>     window label: aString.
>     window controller open.
>     ^window! !
>
>
> !MorphicToolBuilder methodsFor: 'opening' stamp: 'fm 9/8/2010 01:39'!
> open1: anObject
>     "Build and open the object. Answer the widget opened."
>     | morph |
>     anObject isMorph
>         ifTrue:[morph := anObject]
>         ifFalse:[morph := self build: anObject].
>     (morph isKindOf: MenuMorph)
>         ifTrue:[morph popUpInWorld: World].
>     (morph isKindOf: SystemWindow)
>         ifTrue:[morph openInWorldExtent: morph extent]
>         ifFalse:[morph openInWorld].
>     ^morph! !
>
> !MorphicToolBuilder methodsFor: 'opening' stamp: 'fm 9/8/2010 01:41'!
> open1: anObject label: aString
>     "Build an open the object, labeling it appropriately.  Answer the widget opened."
>     | window |
>     window := self open: anObject.
>     window setLabel: aString.
>     ^window! !
>
>
> !ToolBuilder class methodsFor: 'accessing' stamp: 'fm 9/8/2010 02:28'!
> default: aToolBuilder
>     "Set a new default tool builder"
>     aToolBuilder isNil ifTrue: [Processor activeProcess debug].
>     Default := aToolBuilder.! !
>
> !ToolBuilder class methodsFor: 'instance creation' stamp: 'fm 9/8/2010 02:10'!
> open1: aClass label: aString
>     ^self default open1: aClass label: aString! !
>
>

> On Wed, Sep 08, 2010 at 02:49:21AM -0400, Florin Mateoc wrote:
>>  On 9/8/2010 1:54 AM, Andreas Raab wrote:
>>> On 9/7/2010 7:57 PM, David T. Lewis wrote:
>>>> I can't reproduce this. Are you able to get a debugger to open under
>>>> MVC at this point?
>>> Yes. I would have posted this earlier but I had an unexpected dinner and don't feel quite capable of doing this now
>>> (hick!).
>>>
>>>> Specifically, I changed Debugger class>>openOn:context:label:contents:fullView:
>>>> to call #searchForActiveControllerNoTerminate, where #searchForActiveControllerNoTerminate
>>>> is a copy of #searchForActiveController with the #terminateActive removed.
>>>> I'm not seeing any difference in behavior, so I must be missing a step
>>>> in the recipe.
>>> All right, I'm attaching the changes I have so far unreviewed. With these changes I've been able to debug just fine
>>> except from the case of handling a user interrupt which doesn't quite work yet. If you want to try this out, give it a
>>> shot, if not, I'll try to make headway tomorrow night. Right now I need some sleep :-)
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>>
>>>
>> I also did a little debugging, and I now think that the two main issues are:
>> 1 the code to open the debugger is inside WorldState addDeferredUiMessage: [], even for MVC, which will probably never
>> get executed
>> 2 MVCTooBuilder was supposed to openNoTerminate (not open, which terminates the previous UI process) when called from
>> the debugger code
>
> With regards to #2 (MVCToolBuilder should use #openNoTerminate), aha! You have
> added the #open1:label: methods that call #openNoTerminate in the case of MVC.
> The #openNoTerminate method has been in the image since at least 1997, but it's
> unreferenced in Squeak now. In Squeak 3.8 and earlier it was called by several
> methods, including Debugger>>openFullNoSuspendLabel:.
>
> This does seem to be something that went missing due to some incomplete MVC
> ToolBuilder implementation (no surprise, but I think you are the first person
> to correctly spot it).
>
> The #open1:label: methods in your change set implement the calls to #openNoTerminate,
> although I think it might be cleaner to add ToolBuilder>>open:label:terminateActive:
> as this avoids the need to provide Morphic or other ToolBuilder implementations.
> I put an implementation of this for review in the inbox (ToolBuilder-Kernel-dtl.37
> and ToolBuilder-MVC-dtl.21).
>
> Andreas, when you get a chance can you have a look at these in the inbox and say
> if they should be included in ToolBuilder? Thanks.
>
> Dave
>
>

> With regards to #2 (MVCToolBuilder should use #openNoTerminate), aha! You have
> added the #open1:label: methods that call #openNoTerminate in the case of MVC.
> The #openNoTerminate method has been in the image since at least 1997, but it's
> unreferenced in Squeak now. In Squeak 3.8 and earlier it was called by several
> methods, including Debugger>>openFullNoSuspendLabel:.
>
> This does seem to be something that went missing due to some incomplete MVC
> ToolBuilder implementation (no surprise, but I think you are the first person
> to correctly spot it).
>
> The #open1:label: methods in your change set implement the calls to #openNoTerminate,
> although I think it might be cleaner to add ToolBuilder>>open:label:terminateActive:
> as this avoids the need to provide Morphic or other ToolBuilder implementations.
> I put an implementation of this for review in the inbox (ToolBuilder-Kernel-dtl.37
> and ToolBuilder-MVC-dtl.21).
>
> Andreas, when you get a chance can you have a look at these in the inbox and say
> if they should be included in ToolBuilder? Thanks.

> On 9/9/2010 6:11 PM, David T. Lewis wrote:
>> With regards to #2 (MVCToolBuilder should use #openNoTerminate), aha! You have
>> added the #open1:label: methods that call #openNoTerminate in the case of MVC.
>> The #openNoTerminate method has been in the image since at least 1997, but it's
>> unreferenced in Squeak now. In Squeak 3.8 and earlier it was called by several
>> methods, including Debugger>>openFullNoSuspendLabel:.
>>
>> This does seem to be something that went missing due to some incomplete MVC
>> ToolBuilder implementation (no surprise, but I think you are the first person
>> to correctly spot it).
>>
>> The #open1:label: methods in your change set implement the calls to #openNoTerminate,
>> although I think it might be cleaner to add ToolBuilder>>open:label:terminateActive:
>> as this avoids the need to provide Morphic or other ToolBuilder implementations.
>> I put an implementation of this for review in the inbox (ToolBuilder-Kernel-dtl.37
>> and ToolBuilder-MVC-dtl.21).
>>
>> Andreas, when you get a chance can you have a look at these in the inbox and say
>> if they should be included in ToolBuilder? Thanks.
>
> Sure. One thing I'm not sure about is this terminateActive: thingie. I don't like to expose a concept that is only
> applicable to MVC via the ToolBuilder APIs. So I'm wondering - poking in MVC it appears that the only difference
> between those xxxNoTerminate and the other variants are simply a call to Processor terminateActive. If that's the
> case, I think we should push these calls to the senders instead of exposing them via ToolBuilder. Any reason that
> wouldn't work?
>
> Cheers,
>   - Andreas
>
>

>   On 9/10/2010 1:55 AM, Andreas Raab wrote:
>> Sure. One thing I'm not sure about is this terminateActive: thingie. I don't like to expose a concept that is only
>> applicable to MVC via the ToolBuilder APIs. So I'm wondering - poking in MVC it appears that the only difference
>> between those xxxNoTerminate and the other variants are simply a call to Processor terminateActive. If that's the
>> case, I think we should push these calls to the senders instead of exposing them via ToolBuilder. Any reason that
>> wouldn't work?
>
> Yes. The common case is open (the one that needs terminating the active process), not openNoTerminate, which is limited
> to the debugger. This means that you would push those calls in a lot of places, plus they would need to be guarded by
> unseemly checks if you are in morphic or not

>  On 9/9/2010 9:11 PM, David T. Lewis wrote:
> > On Wed, Sep 08, 2010 at 02:49:21AM -0400, Florin Mateoc wrote:
> >>  On 9/8/2010 1:54 AM, Andreas Raab wrote:
> >>> On 9/7/2010 7:57 PM, David T. Lewis wrote:
> >>>> I can't reproduce this. Are you able to get a debugger to open under
> >>>> MVC at this point?
> >>> Yes. I would have posted this earlier but I had an unexpected dinner and don't feel quite capable of doing this now
> >>> (hick!).
> >>>
> >>>> Specifically, I changed Debugger class>>openOn:context:label:contents:fullView:
> >>>> to call #searchForActiveControllerNoTerminate, where #searchForActiveControllerNoTerminate
> >>>> is a copy of #searchForActiveController with the #terminateActive removed.
> >>>> I'm not seeing any difference in behavior, so I must be missing a step
> >>>> in the recipe.
> >>> All right, I'm attaching the changes I have so far unreviewed. With these changes I've been able to debug just fine
> >>> except from the case of handling a user interrupt which doesn't quite work yet. If you want to try this out, give it a
> >>> shot, if not, I'll try to make headway tomorrow night. Right now I need some sleep :-)
> >>>
> >>> Cheers,
> >>>   - Andreas
> >>>
> >>>
> >>>
> >> I also did a little debugging, and I now think that the two main issues are:
> >> 1 the code to open the debugger is inside WorldState addDeferredUiMessage: [], even for MVC, which will probably never
> >> get executed
> >> 2 MVCTooBuilder was supposed to openNoTerminate (not open, which terminates the previous UI process) when called from
> >> the debugger code
> >
> > With regards to #2 (MVCToolBuilder should use #openNoTerminate), aha! You have
> > added the #open1:label: methods that call #openNoTerminate in the case of MVC.
> > The #openNoTerminate method has been in the image since at least 1997, but it's
> > unreferenced in Squeak now. In Squeak 3.8 and earlier it was called by several
> > methods, including Debugger>>openFullNoSuspendLabel:.
> >
> > This does seem to be something that went missing due to some incomplete MVC
> > ToolBuilder implementation (no surprise, but I think you are the first person
> > to correctly spot it).
> >
> > The #open1:label: methods in your change set implement the calls to #openNoTerminate,
> > although I think it might be cleaner to add ToolBuilder>>open:label:terminateActive:
> > as this avoids the need to provide Morphic or other ToolBuilder implementations.
> > I put an implementation of this for review in the inbox (ToolBuilder-Kernel-dtl.37
> > and ToolBuilder-MVC-dtl.21).
> >
> > Andreas, when you get a chance can you have a look at these in the inbox and say
> > if they should be included in ToolBuilder? Thanks.
> >
> > Dave
> >
> >
>
> I think that your changes are pretty non-controversial, certainly open1... is not a good selector :)
>
> But I would have hoped that the community would play a little with these changes before they get cleaned up and
> integrated (Hopefully that's what Andreas is doing ;) )
> There are many possible scenarios (multiple projects, morphic and mvc combinations, switching back and forth (with the
> debugger up) - I did get some walkback when switching back to morphic but did not investigate - , hitting errors during
> debugging, debugging with no windows (screen only) versus with windows, exceptions from ui and from non-ui).

> On 9/9/2010 6:11 PM, David T. Lewis wrote:
> >With regards to #2 (MVCToolBuilder should use #openNoTerminate), aha! You
> >have
> >added the #open1:label: methods that call #openNoTerminate in the case of
> >MVC.
> >The #openNoTerminate method has been in the image since at least 1997, but
> >it's
> >unreferenced in Squeak now. In Squeak 3.8 and earlier it was called by
> >several
> >methods, including Debugger>>openFullNoSuspendLabel:.
> >
> >This does seem to be something that went missing due to some incomplete MVC
> >ToolBuilder implementation (no surprise, but I think you are the first
> >person
> >to correctly spot it).
> >
> >The #open1:label: methods in your change set implement the calls to
> >#openNoTerminate,
> >although I think it might be cleaner to add
> >ToolBuilder>>open:label:terminateActive:
> >as this avoids the need to provide Morphic or other ToolBuilder
> >implementations.
> >I put an implementation of this for review in the inbox
> >(ToolBuilder-Kernel-dtl.37
> >and ToolBuilder-MVC-dtl.21).
> >
> >Andreas, when you get a chance can you have a look at these in the inbox
> >and say
> >if they should be included in ToolBuilder? Thanks.
>
> Sure. One thing I'm not sure about is this terminateActive: thingie. I
> don't like to expose a concept that is only applicable to MVC via the
> ToolBuilder APIs. So I'm wondering - poking in MVC it appears that the
> only difference between those xxxNoTerminate and the other variants are
> simply a call to Processor terminateActive. If that's the case, I think
> we should push these calls to the senders instead of exposing them via
> ToolBuilder. Any reason that wouldn't work?

> On 9/9/2010 11:34 PM, Florin Mateoc wrote:
>>   On 9/10/2010 1:55 AM, Andreas Raab wrote:
>>> Sure. One thing I'm not sure about is this terminateActive: thingie. I don't like to expose a concept that is only
>>> applicable to MVC via the ToolBuilder APIs. So I'm wondering - poking in MVC it appears that the only difference
>>> between those xxxNoTerminate and the other variants are simply a call to Processor terminateActive. If that's the
>>> case, I think we should push these calls to the senders instead of exposing them via ToolBuilder. Any reason that
>>> wouldn't work?
>>
>> Yes. The common case is open (the one that needs terminating the active process), not openNoTerminate, which is limited
>> to the debugger. This means that you would push those calls in a lot of places, plus they would need to be guarded by
>> unseemly checks if you are in morphic or not
>
> Thanks for the info. Could we maybe turn this around along the lines of, say:
>
>     [ScheduledControllers scheduleActive: aController] fork.
>
> i.e., forking in the case where terminating the controller isn't desirable?
>
> BTW, (showing my lack of MVC knowledge) I'm not sure I understand the issue to begin with. Why is it that for
> "regular" views it's okay to terminate the active process, but not for the debugger? We don't seem to be having such
> issues with Morphic, but we *do* call Project>>spawnNewProcessIfThisUI: etc. Could we possibly utilize this hook to
> fork a proper controller process in MVC? I'm obviously missing something big time here, so bear with me and my stoopid
> questions :-)
>
> Cheers,
>   - Amndreas
>
>

>  On 9/10/2010 3:22 AM, Andreas Raab wrote:
>> On 9/9/2010 11:34 PM, Florin Mateoc wrote:
>>>   On 9/10/2010 1:55 AM, Andreas Raab wrote:
>>>> Sure. One thing I'm not sure about is this terminateActive: thingie. I don't like to expose a concept that is only
>>>> applicable to MVC via the ToolBuilder APIs. So I'm wondering - poking in MVC it appears that the only difference
>>>> between those xxxNoTerminate and the other variants are simply a call to Processor terminateActive. If that's the
>>>> case, I think we should push these calls to the senders instead of exposing them via ToolBuilder. Any reason that
>>>> wouldn't work?
>>> Yes. The common case is open (the one that needs terminating the active process), not openNoTerminate, which is limited
>>> to the debugger. This means that you would push those calls in a lot of places, plus they would need to be guarded by
>>> unseemly checks if you are in morphic or not
>> Thanks for the info. Could we maybe turn this around along the lines of, say:
>>
>>     [ScheduledControllers scheduleActive: aController] fork.
>>
>> i.e., forking in the case where terminating the controller isn't desirable?
>>
>> BTW, (showing my lack of MVC knowledge) I'm not sure I understand the issue to begin with. Why is it that for
>> "regular" views it's okay to terminate the active process, but not for the debugger? We don't seem to be having such
>> issues with Morphic, but we *do* call Project>>spawnNewProcessIfThisUI: etc. Could we possibly utilize this hook to
>> fork a proper controller process in MVC? I'm obviously missing something big time here, so bear with me and my stoopid
>> questions :-)
>>
>> Cheers,
>>   - Amndreas
>>
>>
> What we want to make sure (in the general case) is not so much that we kill the active process but the
> activeControllerProcess. We want to make sure that one and only one controller (or screen) loop (ui process) runs at all
> times. The debugger is different in the sense that it only wants to suspend activeControllerProcess in cases when
> activeControllerProcess is the debugged process. It does want to terminate it otherwise (then the debugger behaves as a
> "normal" ui controller). There are probably many different ways to achieve this. E.g. a lot of these scheduling methods
> in VW are guarded with a "activeControllerProcess notNil and: [activeControllerProcess == Processor activeProcess]". The
> same check is constantly done in the controller loop. Squeak doesn't have these checks, so it works with a lot of
> assumptions about which methods are called when.
>
> Florin

>   On 9/10/2010 9:16 AM, Florin Mateoc wrote:
>> The debugger is different in the sense that, while it does take over as the activeController upon its open, it only wants to suspend the previously running activeControllerProcess in those cases when
>> the previously running activeControllerProcess is the process under debug
> Sorry about all these self-replies. I just wanted to make one more edit before I run to work, because I think it is
> important documentation:
>
>
> What we want to make sure, in the general case, is not so much that we kill the active process but the currently running
> activeControllerProcess, and allow the newly created controller loop to become the new activeControllerProcess. We want
> to make sure that one and only one controller (or screen) loop (ui process) runs at all times (except very briefly
> during transitions from one ui process to the other).
>
> The debugger is different in the sense that, while it does take over as the activeController upon its open, in those
> cases when the currently running activeControllerProcess is the process under debug, it only wants to suspend it.
> It does want to terminate the currently running activeControllerProcess otherwise (then the debugger behaves like any
> other "normal" ui controller).
>
> There are probably many different ways to achieve this. E.g. a lot of these scheduling methods in VW are guarded with a
> "activeControllerProcess notNil and: [activeControllerProcess == Processor activeProcess]". The same check is constantly
> done in the controller loop. Squeak doesn't have these checks, so it works with a lot of assumptions about which methods
> are called from which processes
>
>
> Florin
>
>

> Hi Florin -
>
> Thanks for all the info. Reading through it, it sounds to me that the real "specialty" here is opening a debugger.
> Which seems quite reasonable to me because debuggers have special needs. So maybe we should add a specific open method
> to ToolBuilder that is specifically used for opening debuggers? I.e., something like:
>
> ToolBuilder>>openDebugger: aSpec
>     "Build and open a debugger from the given spec.
>     Answer the widget opened. Subclasses can override this
>     method if opening a debugger has specific requirements
>     different from opening other widgets."
>
>     ^self open: aSpec
>
> And then MVCToolBuilder can implement the appropriate open method. This would make the interface more intentional,
> i.e.,describing what are we trying to do (open a debugger), instead of describing how we do it (not terminating the
> MVC scheduler process).
>
> What do you think?
>
> Cheers,
>   - Andreas
>
>
>
> On 9/10/2010 6:37 AM, Florin Mateoc wrote:
>>   On 9/10/2010 9:16 AM, Florin Mateoc wrote:
>>> The debugger is different in the sense that, while it does take over as the activeController upon its open, it only
>>> wants to suspend the previously running activeControllerProcess in those cases when
>>> the previously running activeControllerProcess is the process under debug
>> Sorry about all these self-replies. I just wanted to make one more edit before I run to work, because I think it is
>> important documentation:
>>
>>
>> What we want to make sure, in the general case, is not so much that we kill the active process but the currently running
>> activeControllerProcess, and allow the newly created controller loop to become the new activeControllerProcess. We want
>> to make sure that one and only one controller (or screen) loop (ui process) runs at all times (except very briefly
>> during transitions from one ui process to the other).
>>
>> The debugger is different in the sense that, while it does take over as the activeController upon its open, in those
>> cases when the currently running activeControllerProcess is the process under debug, it only wants to suspend it.
>> It does want to terminate the currently running activeControllerProcess otherwise (then the debugger behaves like any
>> other "normal" ui controller).
>>
>> There are probably many different ways to achieve this. E.g. a lot of these scheduling methods in VW are guarded with a
>> "activeControllerProcess notNil and: [activeControllerProcess == Processor activeProcess]". The same check is constantly
>> done in the controller loop. Squeak doesn't have these checks, so it works with a lot of assumptions about which methods
>> are called from which processes
>>
>>
>> Florin
>>
>>
>
>
>

>
> I think that your changes are pretty non-controversial, certainly open1... is not a good selector :)
>
> But I would have hoped that the community would play a little with these changes before they get cleaned up and
> integrated (Hopefully that's what Andreas is doing ;) )
> There are many possible scenarios (multiple projects, morphic and mvc combinations, switching back and forth (with the
> debugger up) - I did get some walkback when switching back to morphic but did not investigate - , hitting errors during
> debugging, debugging with no windows (screen only) versus with windows, exceptions from ui and from non-ui).
> Well, we still have some work to do to get ControlManager>>interruptName:preemptedProcess:
> working right. Background is at http://bugs.squeak.org/view.php?id=1041
> but the basic idea is that all four of the following should be interruptable:
>
>    "[true] whileTrue"
>    "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
>    "Smalltalk createStackOverflow"
>    "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
>
> I spent some time trying to get this working last night, but have not yet
> come up with a solution. The basic idea is if the low space interrupt watcher
> process has called #interruptName:preemptedProcess: passing it theInterruptedProcess,
> then we want the debugger to open on theInterruptedProcess rather than on
> activeControllerProcess. This is a bit tricky to debug for obvious reasons ;)
>
> Dave
>

> On 9/10/2010 6:26 PM, Florin Mateoc wrote:
>> What!? You don't like my meaning-conveying open1 ? :)
>
> He, he :-)
>
>> Seriously now, I don't have a strong opinion either way, but I do have a slight reservation. The 'debugger' part of the
>> name is more the 'what for' than the 'what' of what we are doing. There could be other clients that want to use the same
>> thing: in VW there is SyntaxError, which is not quite a debugger. Furthermore, from the point of view of an MVC
>> developer there is already a known protocol 'open', which the toolBuilder implements, as well as a protocol
>> openNoTerminate. Now granted, for the Morphic developer this is not as intuitive.
>
> Well, we could do openNoTerminate but I find it just a little opaque. But I'm good with either one; your's and David's
> call, just let me know which way you prefer.
>
> Cheers,
>   - Andreas
>
>

>  On 9/10/2010 7:48 AM, David T. Lewis wrote:
>> I think that your changes are pretty non-controversial, certainly open1... is not a good selector :)
>>
>> But I would have hoped that the community would play a little with these changes before they get cleaned up and
>> integrated (Hopefully that's what Andreas is doing ;) )
>> There are many possible scenarios (multiple projects, morphic and mvc combinations, switching back and forth (with the
>> debugger up) - I did get some walkback when switching back to morphic but did not investigate - , hitting errors during
>> debugging, debugging with no windows (screen only) versus with windows, exceptions from ui and from non-ui).
>> Well, we still have some work to do to get ControlManager>>interruptName:preemptedProcess:
>> working right. Background is at http://bugs.squeak.org/view.php?id=1041
>> but the basic idea is that all four of the following should be interruptable:
>>
>>    "[true] whileTrue"
>>    "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
>>    "Smalltalk createStackOverflow"
>>    "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
>>
>> I spent some time trying to get this working last night, but have not yet
>> come up with a solution. The basic idea is if the low space interrupt watcher
>> process has called #interruptName:preemptedProcess: passing it theInterruptedProcess,
>> then we want the debugger to open on theInterruptedProcess rather than on
>> activeControllerProcess. This is a bit tricky to debug for obvious reasons ;)
>>
>> Dave
>>
> Of course that if we pass the preempted process, we have to honor that request.
> But I am not sure if I understand correctly. If I have a runaway non-ui process, I don't think that the user interrupt
> should try to find it and interrupt it. I think user interrupt is and should be dedicated to the ui process. Now once
> you open a debugger, you can have a list of currently running processes from which you can select and debug.
>
> Florin
>
>

>  On 9/10/2010 11:08 PM, Andreas Raab wrote:
> > On 9/10/2010 6:26 PM, Florin Mateoc wrote:
> >> What!? You don't like my meaning-conveying open1 ? :)
> >
> > He, he :-)
> >
> >> Seriously now, I don't have a strong opinion either way, but I do have a slight reservation. The 'debugger' part of the
> >> name is more the 'what for' than the 'what' of what we are doing. There could be other clients that want to use the same
> >> thing: in VW there is SyntaxError, which is not quite a debugger. Furthermore, from the point of view of an MVC
> >> developer there is already a known protocol 'open', which the toolBuilder implements, as well as a protocol
> >> openNoTerminate. Now granted, for the Morphic developer this is not as intuitive.
> >
> > Well, we could do openNoTerminate but I find it just a little opaque. But I'm good with either one; your's and David's
> > call, just let me know which way you prefer.
> >
> > Cheers,
> >   - Andreas
> >
> >
>
> As I said, I also don't have a strong opinion, so it's up to Dave

>  On 9/10/2010 9:33 PM, Florin Mateoc wrote:
> >  On 9/10/2010 7:48 AM, David T. Lewis wrote:
> >> I think that your changes are pretty non-controversial, certainly open1... is not a good selector :)
> >>
> >> But I would have hoped that the community would play a little with these changes before they get cleaned up and
> >> integrated (Hopefully that's what Andreas is doing ;) )
> >> There are many possible scenarios (multiple projects, morphic and mvc combinations, switching back and forth (with the
> >> debugger up) - I did get some walkback when switching back to morphic but did not investigate - , hitting errors during
> >> debugging, debugging with no windows (screen only) versus with windows, exceptions from ui and from non-ui).
> >> Well, we still have some work to do to get ControlManager>>interruptName:preemptedProcess:
> >> working right. Background is at http://bugs.squeak.org/view.php?id=1041
> >> but the basic idea is that all four of the following should be interruptable:
> >>
> >>    "[true] whileTrue"
> >>    "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
> >>    "Smalltalk createStackOverflow"
> >>    "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
> >>
> >> I spent some time trying to get this working last night, but have not yet
> >> come up with a solution. The basic idea is if the low space interrupt watcher
> >> process has called #interruptName:preemptedProcess: passing it theInterruptedProcess,
> >> then we want the debugger to open on theInterruptedProcess rather than on
> >> activeControllerProcess. This is a bit tricky to debug for obvious reasons ;)
> >>
> >> Dave
> >>
> > Of course that if we pass the preempted process, we have to honor that request.
> > But I am not sure if I understand correctly. If I have a runaway non-ui process, I don't think that the user interrupt
> > should try to find it and interrupt it. I think user interrupt is and should be dedicated to the ui process. Now once
> > you open a debugger, you can have a list of currently running processes from which you can select and debug.
> >
> > Florin
> >
> >
>
> Ok, with the current changeset you can interrupt "[true] whileTrue" or "Smalltalk createStackOverflow", and if you let
> "Smalltalk createStackOverflow" run, it will trigger the low space watcher and you can then recover.
>
> For interrupting processes running at higher priority I think the appropriate solution is not the debugger but an
> emergency evaluator running at an even higher priority