[squeak-dev] Re: MVC debugging
andreas.raab at gmx.de
Fri Sep 10 16:13:27 UTC 2010
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:
"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?
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
More information about the Squeak-dev