On Wed, Sep 08, 2010 at 03:35:27PM -0400, Florin Mateoc wrote:
>  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"
> 

Bravo Florin!!! Well done!

Dave