MVC debugging

> Hi -
>
> I'm interested in getting MVC into a reasonably usable shape to be able
> to play with unloading parts (or the entirety) of Morphic. However, it
> seems that the debugger is badly broken which leaves one hanging as soon
> as something goes wrong.
>
> Does anyone know when the MVC debugger has last worked in the recorded
> history of mankind? :-) Or even better what needs to be fixed to get it
> working again?
>
> Cheers,
>   - Andreas

> On 9/6/2010 6:29 PM, David T. Lewis wrote:
>> I think that the debugger (which is the critical thing), as well as a few
>> other UI things, are simply missing some necessary ToolBuilder support.
>> It's a bit tricky to figure this out because one cannot open a debugger
>> to figure out what's wrong, but my guess is that if we can get the debugger
>> working again that the rest of the broken UI elements would be fixable.
>
> Well, let's see. I am able to run this:
>
>     [Processor activeProcess debug] on: Error do:[:ex| ex return].
>
> which means we're not fully hosed. The next attempt:
>
> [Processor activeProcess debug] on: Error do:[:ex|
>     ex signalerContext longStack inspect.
>     ex return].
>
> yields the following stack:
>
>     UndefinedObject(Object)>>mustBeBooleanIn:
>     UndefinedObject(Object)>>mustBeBoolean
>     Debugger class>>ifPreferredInterruptUIProcessIfBlocked:
>     Debugger class>>openOn:context:label:contents:fullView:
>
> indicating that it's not anything ToolBuilder related. Commenting out the call to
> ifPreferredInterruptUIProcessIfBlocked: (what an awful name) makes the system go entirely idle and Cmd-Period causes
> the VM to exist since it has no runnable process.
>
> That leads me to believe that we're getting all the way through Debugger class openOn:context:label:contents:fullView:
> to the end where it says "process suspend" and no new MVC process is being spawned.
>
> And that's about where my MVC knowledge ends these days. Any ideas how to spawn the proper MVC scheduler process? It's
> probably some equvilant to #spawnNewProcessIfThisIsUI: in Morphic but I don't know the magic incantation.
>
> Cheers,
>   - Andreas
>
>

> On 9/6/2010 9:34 PM, Florin Mateoc wrote:
>>   On 9/6/2010 9:56 PM, Andreas Raab wrote:
>>> That leads me to believe that we're getting all the way through Debugger class openOn:context:label:contents:fullView:
>>> to the end where it says "process suspend" and no new MVC process is being spawned.
>>>
>>> And that's about where my MVC knowledge ends these days. Any ideas how to spawn the proper MVC scheduler process? It's
>>> probably some equvilant to #spawnNewProcessIfThisIsUI: in Morphic but I don't know the magic incantation.
>>>
>> It should be ScheduledControllers searchForActiveController, but I suspect ScheduledControllers is nil (it should be an
>> instance of ControlManager)
>
> This doesn't sound right to me. ScheduledControllers isn't nil (it's "a ControlManager") since I'm running this code
> from MVC, but #searchForActiveController ends with "Processor terminateActive" which seems decidedly wrong for a
> situation where we want to *debug* the process, not terminate it.
>
> However, if I instead use ScheduledControllers>>spawnNewProcess (which looks vaguely correct in such that it's indeed
> the equivalent of #spawnNewProcessIfThisIsUI:) the result is no lockup, but no debugger is showing up either :-(
>
> Cheers,
>   - Andreas
>
>

>   On 9/7/2010 12:48 AM, Andreas Raab wrote:
>> On 9/6/2010 9:34 PM, Florin Mateoc wrote:
>>>    On 9/6/2010 9:56 PM, Andreas Raab wrote:
>>>> That leads me to believe that we're getting all the way through Debugger class openOn:context:label:contents:fullView:
>>>> to the end where it says "process suspend" and no new MVC process is being spawned.
>>>>
>>>> And that's about where my MVC knowledge ends these days. Any ideas how to spawn the proper MVC scheduler process? It's
>>>> probably some equvilant to #spawnNewProcessIfThisIsUI: in Morphic but I don't know the magic incantation.
>>>>
>>> It should be ScheduledControllers searchForActiveController, but I suspect ScheduledControllers is nil (it should be an
>>> instance of ControlManager)
>>
>> This doesn't sound right to me. ScheduledControllers isn't nil (it's "a ControlManager") since I'm running this code
>> from MVC, but #searchForActiveController ends with "Processor terminateActive" which seems decidedly wrong for a
>> situation where we want to *debug* the process, not terminate it.
>>
>> However, if I instead use ScheduledControllers>>spawnNewProcess (which looks vaguely correct in such that it's indeed
>> the equivalent of #spawnNewProcessIfThisIsUI:) the result is no lockup, but no debugger is showing up either :-(
>>
>> Cheers,
>>    - Andreas
>>
>>
> It does end with terminateActive, but before that it calls activeController: , which spawns a new process (or it should,
> it is a primitive)

> On 9/6/2010 9:59 PM, Florin Mateoc wrote:
>>   On 9/7/2010 12:48 AM, Andreas Raab wrote:
>>> On 9/6/2010 9:34 PM, Florin Mateoc wrote:
>>>>    On 9/6/2010 9:56 PM, Andreas Raab wrote:
>>>>> That leads me to believe that we're getting all the way through Debugger class
>>>>> openOn:context:label:contents:fullView:
>>>>> to the end where it says "process suspend" and no new MVC process is being spawned.
>>>>>
>>>>> And that's about where my MVC knowledge ends these days. Any ideas how to spawn the proper MVC scheduler process?
>>>>> It's
>>>>> probably some equvilant to #spawnNewProcessIfThisIsUI: in Morphic but I don't know the magic incantation.
>>>>>
>>>> It should be ScheduledControllers searchForActiveController, but I suspect ScheduledControllers is nil (it should
>>>> be an
>>>> instance of ControlManager)
>>>
>>> This doesn't sound right to me. ScheduledControllers isn't nil (it's "a ControlManager") since I'm running this code
>>> from MVC, but #searchForActiveController ends with "Processor terminateActive" which seems decidedly wrong for a
>>> situation where we want to *debug* the process, not terminate it.
>>>
>>> However, if I instead use ScheduledControllers>>spawnNewProcess (which looks vaguely correct in such that it's indeed
>>> the equivalent of #spawnNewProcessIfThisIsUI:) the result is no lockup, but no debugger is showing up either :-(
>>>
>>> Cheers,
>>>    - Andreas
>>>
>>>
>> It does end with terminateActive, but before that it calls activeController: , which spawns a new process (or it should,
>> it is a primitive)
>
> Yes, but if the old one is the process we want to debug, there is no point in terminating it, is there? After all it's
> the process that hit an error - we want to look at it, inspect it, step through it; not terminate it.
>
> Cheers,
>   - Andreas
>
>

> On 9/6/2010 10:36 PM, Florin Mateoc wrote:
>>   On 9/7/2010 1:03 AM, Andreas Raab wrote:
>>> Yes, but if the old one is the process we want to debug, there is no
>>> point in terminating it, is there? After all it's
>>> the process that hit an error - we want to look at it, inspect it, step
>>> through it; not terminate it.
>>>
>>
>> Well, it looks like the method was written with the assumption that
>> 'process' is not the active process. Anyway, I
>> looked in VW and it uses a very similar method to
>> searchForActiveController (launchBaseProcess), the only difference
>> being that it does not call terminate.
>
> A-ha! That's it! I added a method #searchForActiveControllerNoTerminate
> that simply does not terminate the active process and it works.
>
> Woohoo! Thank you so much!
>
> Cheers,
>    - Andreas
>
>

> On 9/6/2010 10:36 PM, Florin Mateoc wrote:
> >  On 9/7/2010 1:03 AM, Andreas Raab wrote:
> >>Yes, but if the old one is the process we want to debug, there is no
> >>point in terminating it, is there? After all it's
> >>the process that hit an error - we want to look at it, inspect it, step
> >>through it; not terminate it.
> >>
> >
> >Well, it looks like the method was written with the assumption that
> >'process' is not the active process. Anyway, I
> >looked in VW and it uses a very similar method to
> >searchForActiveController (launchBaseProcess), the only difference
> >being that it does not call terminate.
>
> A-ha! That's it! I added a method #searchForActiveControllerNoTerminate
> that simply does not terminate the active process and it works.

>  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 9/8/2010 6:46 AM, David T. Lewis wrote:
> > Florin, Andreas,
> >
> > Great thanks for this progress! I do get a debugger window now (yay!).
> > I'm just heading out the door for the day but look forward to playing
> > with this later.
> >
> > Dave
> >
>
> I made a little more progress:
>
> there is a bug in MVCToolBuilder class>>isActiveBuilder, which only responds true when asked from within the UI process.
> Well, there are other processes in MVC as well, and the interrupt handling happens to be from a forked process. As a
> result, ToolBuilder default is always nil in a non-UI process.
> My tentative solution for this is, (but I don't know how this works with multiple projects, if supported):
>
> isActiveBuilder
>     "Answer whether I am the currently active builder"
>     "This is really a way of answering whether 'Smalltalk isMVC'"
>     ScheduledControllers ifNil:[^false].
>     ^(ScheduledControllers activeControllerProcess ifNil:[^false]) isTerminated not
>
>
> I would also qualify as a semi-bug the fact that the Default class variable in ToolBuilder is unused. What looks like
> lazy initialization in #isActiveBuilder never sets the variable. This was quite confusing and it threw me off track for
> a while. If it is not used, (the setter is never called, at least not in the base image, not even indirectly through the
> class pool, I checked :) ), it should be removed.
>

>  On 9/8/2010 1:42 PM, David T. Lewis wrote:
> > On Wed, Sep 08, 2010 at 12:11:45PM -0400, Florin Mateoc wrote:
> >>  On 9/8/2010 6:46 AM, David T. Lewis wrote:
> >>> Florin, Andreas,
> >>>
> >>> Great thanks for this progress! I do get a debugger window now (yay!).
> >>> I'm just heading out the door for the day but look forward to playing
> >>> with this later.
> >>>
> >>> Dave
> >>>
> >> I made a little more progress:
> >>
> >> there is a bug in MVCToolBuilder class>>isActiveBuilder, which only responds true when asked from within the UI process.
> >> Well, there are other processes in MVC as well, and the interrupt handling happens to be from a forked process. As a
> >> result, ToolBuilder default is always nil in a non-UI process.
> >> My tentative solution for this is, (but I don't know how this works with multiple projects, if supported):
> >>
> >> isActiveBuilder
> >>     "Answer whether I am the currently active builder"
> >>     "This is really a way of answering whether 'Smalltalk isMVC'"
> >>     ScheduledControllers ifNil:[^false].
> >>     ^(ScheduledControllers activeControllerProcess ifNil:[^false]) isTerminated not
> >>
> >>
> >> I would also qualify as a semi-bug the fact that the Default class variable in ToolBuilder is unused. What looks like
> >> lazy initialization in #isActiveBuilder never sets the variable. This was quite confusing and it threw me off track for
> >> a while. If it is not used, (the setter is never called, at least not in the base image, not even indirectly through the
> >> class pool, I checked :) ), it should be removed.
> >>
> > Yes the unused Default in ToolBuilder is a semi-bug. Possibly it should be
> > set as a side effect of entering a project (Project>>enter:revert:saveForRevert:).
> > I remember looking at this during the Project refactoring, but I thought at
> > the time that it was safer to leave it alone (setting a global variable as
> > a side effect of some other operation seemed dangerous, and the dynamic
> > calculation seemed to be working fine as it was).
> >
> > Possibly a nicer approach would be to vector it through Project such that
> > the current project always knows its ToolBuilder. But this adds Toolbuilder
> > dependency in the System package, which did not seem like a good idea
> > either.
> >
> > Dave
> >
> >
>
> Finally! There were a couple of bugs in ControlManager>>interruptName:preemptedProcess: (e.g. Debugger does not
> implement #controller)
> I went ahead and simplified it a bit and spelled out the assumptions (as comments).
> With this changeset the notifier now opens for the user interrupt, and you can also do "[1 halt] fork"
>