I'm trawling around in the bowels of Scratch and spotted some ugly soreta-event code. I've checked a nice recent image and although the ugly is different it still seems to be there in spirit at least. Same basic code is in Cuis as well - EventSensor>processSensorEvent:
For a while now - about a decade I'd think - the VMs have *not* reported the use of the set interrupt key (which is *still* set to cmd-. Mac style and not to a platform suited value except on RISC OS) as a keyboard event. Thus the clause in EventSensor>processEvent: where " type = EventTypeKeyboard ifTrue: [ "Check if the event is a user interrupt" ((evt at: 4) = 0 and: [((evt at: 3) bitOr: (((evt at: 5) bitAnd: 8) bitShift: 8)) = interruptKey]) ifTrue: ["interrupt key is meta - not reported as event" ^ interruptSemaphore signal].
" does the testing is bogus. It even has a comment explaining why it is bogus.
Unless I'm missing things (it's Friday afternoon ok?) this clause really ought to be removed.
And really - we still have all those long obsolete io prims called in there too? Oh my. You can just about excuse the VMs having the code to support ancient images, but not modern images.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- RIGOR MORRIS - The cat is dead
On 01-03-2013, at 3:54 PM, tim Rowledge tim@rowledge.org wrote:
For a while now - about a decade I'd think - the VMs have *not* reported the use of the set interrupt key (which is *still* set to cmd-. Mac style and not to a platform suited value except on RISC OS) as a keyboard event.
It gets funnier; on my iMac running the Squeak4.2.4 vm the cmd-. *does* actually get reported as a keypress event despite the code in the VM that (along with all the others) explicitly disavows it. If I comment out the code that ought to be unsued I can't interrupt the ssytem, so clearly something is not happening as the code seems to require.
Using the very same image on RISC OS it works as apparently specified.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The computing field is always in need of new cliches.
For anyone interested in what is in the VM code, see files sqRPCEvents.c sqUnixEvents.c sqWin32Window.c sqMacUIEvents.c
and look for uses of getInterruptKeycode() So far as I can see each one checks for the interrupt key code and whacks the interrrupt Semaphore instead of saving the keypress. Somewhere, the Mac code is managing to both not hit the semaphore and still pass in the keypress. Are any of the others?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programming is an art form that fights back.
Haven't checked VM sources, but a quick test on Windows shows same behavior as you describe on Mac.
Quoting tim Rowledge tim@rowledge.org:
For anyone interested in what is in the VM code, see files sqRPCEvents.c sqUnixEvents.c sqWin32Window.c sqMacUIEvents.c
and look for uses of getInterruptKeycode() So far as I can see each one checks for the interrupt key code and whacks the interrrupt Semaphore instead of saving the keypress. Somewhere, the Mac code is managing to both not hit the semaphore and still pass in the keypress. Are any of the others?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programming is an art form that fights back.
Cheers, Juan Vuletich
On 01-03-2013, at 5:22 PM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
Haven't checked VM sources, but a quick test on Windows shows same behavior as you describe on Mac.
Yeah, it's weird. All platforms have explicity claiming to not pass in a cmd-. keypress but all except RISC OS ( & unix? anyone care to try?) seem to nonetheless. Clearly the claimed behaviour *can* work since it does on RISC OS.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Act naturally
On 2013-03-02, at 01:25, tim Rowledge tim@rowledge.org wrote:
On 01-03-2013, at 3:54 PM, tim Rowledge tim@rowledge.org wrote:
For a while now - about a decade I'd think - the VMs have *not* reported the use of the set interrupt key (which is *still* set to cmd-. Mac style and not to a platform suited value except on RISC OS) as a keyboard event.
It gets funnier; on my iMac running the Squeak4.2.4 vm the cmd-. *does* actually get reported as a keypress event despite the code in the VM that (along with all the others) explicitly disavows it. If I comment out the code that ought to be unsued I can't interrupt the ssytem, so clearly something is not happening as the code seems to require.
Using the very same image on RISC OS it works as apparently specified.
Hunting down why sometimes the interrupt key doesn't actually interrupt would be great. If the VM is not triggering the semaphore, that might be a clue we had missed so far.
- Bert -
On 2013-03-02, at 00:54, tim Rowledge tim@rowledge.org wrote:
I'm trawling around in the bowels of Scratch and spotted some ugly soreta-event code. I've checked a nice recent image and although the ugly is different it still seems to be there in spirit at least. Same basic code is in Cuis as well - EventSensor>processSensorEvent:
For a while now - about a decade I'd think - the VMs have *not* reported the use of the set interrupt key (which is *still* set to cmd-. Mac style and not to a platform suited value except on RISC OS) as a keyboard event. Thus the clause in EventSensor>processEvent: where " type = EventTypeKeyboard ifTrue: [ "Check if the event is a user interrupt" ((evt at: 4) = 0 and: [((evt at: 3) bitOr: (((evt at: 5) bitAnd: 8) bitShift: 8)) = interruptKey]) ifTrue: ["interrupt key is meta - not reported as event" ^ interruptSemaphore signal].
" does the testing is bogus. It even has a comment explaining why it is bogus.
The comment just says that *if* this gets reported as a keyboard event from the VM, it will *not* be passed on as an event from the Sensor, but *instead* signal the interruptSemaphore directly.
Unless I'm missing things (it's Friday afternoon ok?) this clause really ought to be removed.
Why? It doesn't hurt anyone, even if no current VM sends these events.
And really - we still have all those long obsolete io prims called in there too? Oh my. You can just about excuse the VMs having the code to support ancient images, but not modern images.
They shouldn't be called on a modern VM that supports events, true. But there are always new VM platforms, and implementing the polling on the VM side is certainly easier than the events, no?
- Bert -
On 02-03-2013, at 3:22 AM, Bert Freudenberg bert@freudenbergs.de wrote:
The comment just says that *if* this gets reported as a keyboard event from the VM, it will *not* be passed on as an event from the Sensor, but *instead* signal the interruptSemaphore directly.
Yes but the VM code is supposed to have already signalled the interrupt semaphore; so there is certainly potential for a double-tap instead of a single signal and thus the specified VM requirement to not pass on the keypress. I remember working on this with Andreas something like 10 years ago and the whole idea was to avoid the input sensor being involved.
Unless I'm missing things (it's Friday afternoon ok?) this clause really ought to be removed.
Why? It doesn't hurt anyone, even if no current VM sends these events.
It hurts my eyes to see wrong code. It wastes cycles, which matters to me as well, just on principal. It wastes other people's time because it is complication that distracts.
And really - we still have all those long obsolete io prims called in there too? Oh my. You can just about excuse the VMs having the code to support ancient images, but not modern images.
They shouldn't be called on a modern VM that supports events, true. But there are always new VM platforms, and implementing the polling on the VM side is certainly easier than the events, no?
Having done a few I think I'd say no. Clearly it strictly depends on the platform in extremis.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RC: Rewind Core
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Juan Vuletich (mail lists) -
tim Rowledge