Ned Konz <ned at squeakland.org> wrote:

> On Thursday 18 March 2004 10:30 am, Andreas Raab wrote:
> 
> > Damn. I had totally forgotten that we moved the interrupt key processing up
> > into the image.
> 
> > Hm ... looks like the right sequence of installing the 
> > interrupt watcher setting the interrupt key etc. might do the trick.
> 
> What do you mean? I don't believe that the primitives that actually set the 
> flag are getting called any more.

How funny that I was asking about this in off-list email just yesterday
:-) It still works fine on RISC OS because I'd never gotten around to
removing it... looks like laziness _does_ pay off occasionally.

> > Note that I am *not* sure if that works on all VMs if used 
> > with the event primitives so you may want to have a look at your VM sources
> > first to make sure it does signal the interrupt semaphore when it sees an
> > interrupt keydown event (rather than just stuffing it straight into the
> > event queue). I *think* it'll work but it's better to check first.

> 100000 timesRepeat: [ 3.15434345345 printString ].
Breaks promptly on RISC OS.

In the (possibly out of date due all this moving and being offline so
much) platform code I have sitting here:-
 - Mac appears to setInterruptPending within
 fakeMouseWheelKeyboardEvents which looks to be called only if a mouse
 wheel moved, and in recordKeystroke and recordKeyboardEventCarbon

 -  *nix calls it in recordKeystroke which is commented as being
 deprecated.
 - no apparent use in win32

I'd suggest a trivial VM change to fix this. It might be worth doing
something a bit smarter for the default keypress value than 2094 (see
initializeInterpreter). RISC OS checks for its usual interrupt key as
well as whatever 'interruptKeycode' is set to.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: TVO: Type Various Obscenities