On Thu, 6 Mar 2014, Chris Muller wrote:

> If, during the act of building and opening the debugger, if something
> causes yet another exception to be triggered (say, a bad printOn: or
> problem building one of the inspector panes), then I think you'll be
> in an unavoidable infinite recursion.  Not sure whether there's any
> way around that...

In theory the emergency evaluator (Transcripter) will pop up instead of 
another debugger. See Object >> #primitiveError:.


Levente

>
> On Wed, Mar 5, 2014 at 11:37 PM, tim Rowledge <tim at rowledge.org> wrote:
>> Y’know what is still annoying the hell out of me when developing? The damn interrupt key stuff. I’ll leave aside the problem with not necessarily interrupting the ‘right’ process, because I know that is really quite difficult.
>>
>> But the spec we agreed something like a decade (or more) ago was that the interrupt key combo, when pressed, would NOT be passed into the image but would immediately trigger the relevant semaphore. That should open a debugger pretty lickety-split. It doesn’t seem to work that way any more, with frequent cases where nothing happens for a very long time, often long enough that you simply give up and force-quit. I *think* this is often in a deep recursion scenario, which I understand can be a problem for collecting all the contexts.
>>
>> I know it worked very well on RISC OS. It doesn’t appear to be doing very well on OS X nor linux/Pi.  So, I have to admit I’m a bit puzzled to see image code (in EventSensor>processEvent:) that purports to handle the interrupt key code that is supposed never to get there. The comment in the related code in InputSensor>primInterruptSemaphore: explicitly refers to the setting of the semaphore for the VM as obsolete, though it does at least actually set it. So far as I can see the prim exists and does the right thing. The only material difference I can find between platforms is that RISC OS does
>>   setInterruptPending(true);
>>   forceInterruptCheck();
>> whereas all others do just
>>   setInterruptPending(true);
>> and perhaps that makes a big difference.
>>
>> Event handling code in the relevant platform files also appears to explicitly *not* pass in a cmd-. key-press which confuses me further, since that makes it seem like the system is actually relying upon the semaphore being signalled by the VM despite the image code.
>>
>> Whatever the details really are, it would certainly be nice to make response to the interrupt key *really* fast.
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Never do at  compile-time what you can put off till run-time
>>
>>
>>
>
>