Hi Igor: Lets look at the current code, and let me explain what currently happens on the RoarVM. "Code as in Pharo 1.0" eventLoop "Fetch pending raw events from the VM. This method is run at high priority." | eventBuffer | "STEFAN: this is fine, it is an optimization but should not be a problem (Squeak has that also outside of the inner loop)" eventBuffer := Array new: 8. [true] whileTrue: [ | type window | self waitForInput. [ "STEFAN: here things break on RoarVM the problem is, that eventBuffer is not filled with anything useful if there is no new event. In case there is non new event, the content of eventBuffer seems to be the same content as it was before. However, on all other forks, RoarVM seems to supply the right 'there is no event (EventTypeNone = 0)' value to eventBuffer" self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [ "Patch up the window index in case we don't get one" window := eventBuffer at: 8. (window isNil or: [window isZero]) ifTrue: [eventBuffer at: 8 put: 1]. self signalEvent: eventBuffer]] I will have a look at what happen inside the VM later. Best regards Stefan On 03 Nov 2010, at 22:07, Igor Stasenko wrote:

On 3 November 2010 21:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

can you open a bug entry?

it was my idea putting

eventBuffer := Array new: 8.

outside of loop, since InputEventSensor anyways copying it before placing in queue:

handleEvent: evt self queueEvent: evt shallowCopy.

i have no idea, what can go wrong with it when running under RoarVM.

...

Stef

...

...

Hi Yes, is on a x86_64-linux, Debian squeeze. I use that setup on one of the machines, too. Should not be problem with the 32bit libraries.

...

The problem was some libraries... but with a good symbolic links compile fine, but, Pharo 1.2 doesn't works, it freezes. Pharo works currently only with a single core, I think. And there might be one of my latest fixes missing in the current change set for Pharo. The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive.

Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM.

!InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547! eventLoop "Fetch pending raw events from the VM. This method is run at high priority."

[true] whileTrue: [ | window eventBuffer type | self waitForInput. [eventBuffer := Array new: 8. self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. ((type = EventTypeNone) or: [type isNil])] whileFalse: [ "Patch up the window index in case we don't get one" window := eventBuffer at: 8. (window isNil or: [window isZero]) ifTrue: [eventBuffer at: 8 put: 1].

self signalEvent: eventBuffer]]. RVMPrimitives printOnConsole: 'ended event loop'.! !

...

Someone could it on a x86_64-linux ?

Thanks! El mié, 03-11-2010 a las 18:18 +0100, Stefan Marr escribió:

...

Hello Felipe:

On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote:

...

Hi, how can i compile this on a x86_64 environment ? until now i hace some problems with lstdc++

RoarVM does not support compilation as 64bit. So you will need the 32bit compatibility libraries.

I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common

What is the exact system you are running on, some Linux is suppose?

Best regards Stefan

-- Estudiante de Ingeniería Civil en Computación Departamento de Ciencias de la Computación Universidad de Chile

http://www.dcc.uchile.cl/~fvalverd/public_key.asc

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

-- Best regards, Igor Stasenko AKA sig.

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Hi Igor: On 03 Nov 2010, at 22:36, Igor Stasenko wrote:

"so, placing: "

eventBuffer at: 1 put: EventTypeNone.

"should solve the promblem?" Ok, I found the difference. Probably our VM is behaving slightly different from what the SqueakVM. (Not sure what the 'right' thing to do is thought)

From my understanding, the idea is that if there is no event, the primitive will fail. And all other images have that case covered. They set the first array index to EventTypeNone.

Thus, "InputEventFetcher>>primGetNextEvent: array" should look like: primGetNextEvent: array "Store the next OS event available into the provided array. Essential." <primitive: 94> array at: 1 put: EventTypeNone. "STEFAN: Added this line" ^nil However, since Pharo works on the other VM, I guess the primitive there is filling in the first slot of the array anyway. So, what is the specification? I think the primitives have changed since 'the bluebook'. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

On 5 November 2010 16:49, Stefan Marr <pharo@stefan-marr.de> wrote:

Hi:

On 03 Nov 2010, at 23:59, Stefan Marr wrote:

...

Probably our VM is behaving slightly different from what the SqueakVM. (Not sure what the 'right' thing to do is thought)

From my understanding, the idea is that if there is no event, the primitive will fail. And all other images have that case covered. They set the first array index to EventTypeNone.

Thus, "InputEventFetcher>>primGetNextEvent: array" should look like:

primGetNextEvent: array       "Store the next OS event available into the provided array.       Essential."       <primitive: 94>       array at: 1 put: EventTypeNone. "STEFAN: Added this line"       ^nil

However, since Pharo works on the other VM, I guess the primitive there is filling in the first slot of the array anyway. So, what is the specification? I think the primitives have changed since 'the bluebook'.

Just to ask that question again: What is the conclusion, is the bug in the image or in the VM?

Here the Squeak implementation of it: primGetNextEvent: array "Store the next OS event available into the provided array. Essential. If the VM is not event driven the ST code will fall back to the old-style mechanism and use the state based primitives instead." | kbd buttons modifiers pos mapped | <primitive: 94> "Simulate the events" array at: 1 put: EventTypeNone. "assume no more events" "First check for keyboard" kbd := super primKbdNext. kbd = nil ifFalse:[ "simulate keyboard event" array at: 1 put: EventTypeKeyboard. "evt type" array at: 2 put: Time millisecondClockValue. "time stamp" array at: 3 put: (kbd bitAnd: 255). "char code" array at: 4 put: EventKeyChar. "key press/release" array at: 5 put: (kbd bitShift: -8). "modifier keys" ^self]. "Then check for mouse" buttons := super primMouseButtons. pos := super primMousePt. modifiers := buttons bitShift: -3. buttons := buttons bitAnd: 7. mapped := self mapButtons: buttons modifiers: modifiers. (pos = mousePosition and:[(mapped bitOr: (modifiers bitShift: 3)) = mouseButtons]) ifTrue:[^self]. array at: 1 put: EventTypeMouse; at: 2 put: Time millisecondClockValue; at: 3 put: pos x; at: 4 put: pos y; at: 5 put: mapped; at: 6 put: modifiers. so, i assume that problem is in Pharo , which does not handling a primitive failure correctly (by setting array at: 1 put: EventTypeNone. )

Thanks Stefan

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax:   +32 2 629 3525

-- Best regards, Igor Stasenko AKA sig.