[squeak-dev] Re: MVC debugging

Florin Mateoc fmateoc at gmail.com
Sat Sep 11 05:42:32 UTC 2010


 On 9/10/2010 9:33 PM, Florin Mateoc wrote:
>  On 9/10/2010 7:48 AM, David T. Lewis wrote:
>> I think that your changes are pretty non-controversial, certainly open1... is not a good selector :)
>>
>> But I would have hoped that the community would play a little with these changes before they get cleaned up and
>> integrated (Hopefully that's what Andreas is doing ;) )
>> There are many possible scenarios (multiple projects, morphic and mvc combinations, switching back and forth (with the
>> debugger up) - I did get some walkback when switching back to morphic but did not investigate - , hitting errors during
>> debugging, debugging with no windows (screen only) versus with windows, exceptions from ui and from non-ui).
>> Well, we still have some work to do to get ControlManager>>interruptName:preemptedProcess:
>> working right. Background is at http://bugs.squeak.org/view.php?id=1041
>> but the basic idea is that all four of the following should be interruptable:
>>
>>    "[true] whileTrue"
>>    "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
>>    "Smalltalk createStackOverflow"
>>    "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
>>
>> I spent some time trying to get this working last night, but have not yet
>> come up with a solution. The basic idea is if the low space interrupt watcher
>> process has called #interruptName:preemptedProcess: passing it theInterruptedProcess,
>> then we want the debugger to open on theInterruptedProcess rather than on
>> activeControllerProcess. This is a bit tricky to debug for obvious reasons ;)
>>
>> Dave
>>
> Of course that if we pass the preempted process, we have to honor that request.
> But I am not sure if I understand correctly. If I have a runaway non-ui process, I don't think that the user interrupt
> should try to find it and interrupt it. I think user interrupt is and should be dedicated to the ui process. Now once
> you open a debugger, you can have a list of currently running processes from which you can select and debug.
>
> Florin
>
>

Ok, with the current changeset you can interrupt "[true] whileTrue" or "Smalltalk createStackOverflow", and if you let
"Smalltalk createStackOverflow" run, it will trigger the low space watcher and you can then recover.

For interrupting processes running at higher priority I think the appropriate solution is not the debugger but an
emergency evaluator running at an even higher priority

Florin



More information about the Squeak-dev mailing list