[squeak-dev] Re: MVC debugging

Florin Mateoc fmateoc at gmail.com
Fri Sep 10 13:16:18 UTC 2010


 On 9/10/2010 9:03 AM, Florin Mateoc wrote:
>  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 

Just trying to be more clear:

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




More information about the Squeak-dev mailing list