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