RoarVM - Pharo and Squeak on Multicore

> Wow, exciting times!
>
> On 3 November 2010 09:10, Torsten Bergmann <[hidden email]> wrote:
>> Read more:
>>
>> http://astares.blogspot.com/2010/11/roarvm-pharo-and-squeak-on-multicore.html
>> --
>> GRATIS! Movie-FLAT mit über 300 Videos.
>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

>
> 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

>> 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
>
>

> 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
>>
>>
>
>
>

> On 3 November 2010 21:48, Stéphane Ducasse <[hidden email]> 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.
>

> 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 <[hidden email]> 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
>
>
>

> 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'.

> 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?
>

> 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
>
>
>

>>> 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.
>