EventSensor>processEvent: has bogus code

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; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- RIGOR MORRIS - The cat is dead

On 01-03-2013, at 3:54 PM, tim Rowledge <[hidden email]> 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; [hidden email]; 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; [hidden email]; 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 <[hidden email]>:

Cheers,
Juan Vuletich

On 01-03-2013, at 5:22 PM, "Juan Vuletich (mail lists)" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Act naturally

On 2013-03-02, at 00:54, tim Rowledge <[hidden email]> 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.

> 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 2013-03-02, at 01:25, tim Rowledge <[hidden email]> wrote:

>
> On 01-03-2013, at 3:54 PM, tim Rowledge <[hidden email]> 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 02-03-2013, at 3:22 AM, Bert Freudenberg <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RC: Rewind Core