[squeak-dev] Re: MVC debugging

Florin Mateoc fmateoc at gmail.com
Sat Sep 11 01:26:44 UTC 2010


 On 9/10/2010 12:13 PM, Andreas Raab wrote:
> 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
>>
>>
>
>
>

What!? You don't like my meaning-conveying open1 ? :)

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.

Florin



More information about the Squeak-dev mailing list