Hi Tobias,

    it's potentially a tricky issue for the RPython VM.  I finally fixed the source of the issues with the BalloonPlugin under simulation.  Bastian had changed it from

BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n
"Load a float array transformation from the given oop"

| srcPtr wordDestPtr |

false ifTrue:
[^super loadWordTransformFrom: transformOop into: destPtr length: n].

srcPtr := interpreterProxy firstIndexableField: transformOop.
wordDestPtr := destPtr as: CArrayAccessor.  "Remove float conversion shell"
0 to: n-1 do: [:i | wordDestPtr at: i put: (srcPtr floatAt: i)]

to

BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n 
"Load a float array transformation from the given oop"
| srcPtr wordDestPtr |
false
ifTrue: [^ super
loadWordTransformFrom: transformOop
into: destPtr
length: n].
srcPtr := interpreterProxy firstIndexableField: transformOop.
wordDestPtr := destPtr as: CArrayAccessor.
"Remove float conversion shell"
0 to: n - 1
do: [:i | wordDestPtr at: i put: (srcPtr floatAt: i) asIEEE32BitWord]

i.e. he changed
wordDestPtr at: i put: (srcPtr floatAt: i)
to
wordDestPtr at: i put: (srcPtr floatAt: i) asIEEE32BitWord

This breaks some hidden optimization in the simulator where a BalloonArray has a handle on the "object" in the memory array and a cache of object values in a parallel simArray.  Unless the simArray's values correctly mirror those in the underlying heap object in the simulator's byte array, there are errors in the BalloonPluginSimulation.  I finally fixed these today, changing Bastian's code to

BalloonEngineSimulation>>#loadWordTransformFrom: transformOop into: destPtr length: n 
"Load a float array transformation from the given oop"
| srcPtr |
srcPtr := interpreterProxy firstIndexableField: transformOop.
"Use BalloonArray's float conversion shell.  It stores both the float bits into
the heap object, and the float object into the simArray.  This is needed for
correct simulation, otherwise there will be errors in BalloonArray>>floatAt:"
0 to: n - 1 do: [:i| destPtr at: i put: (srcPtr floatAt: i)]

i.e. nuking the unneeded "wordDestPtr := destPtr as: CArrayAccessor." and changing the code to not send asIEEE32BitWord it the float ti be stored, because this is done inside the BalloonArray that is referred to via destPtr.

So.  I'm strongly confident my code above is correct for simulation but it may break the Python VM.  If it does then I think the RPython VM needs to avoid conflict with simulation subclasses of plugins, such as the BalloonEngineSimulation subclass of BalloonEnginePlugin, e.g. by using a subclassing naming scheme such as BalloonEngineForRPython or some such.  The simulator needs to work :-).

Hope this makes sense.

On Wed, Sep 30, 2015 at 2:12 PM, Tobias Pape <Das.Linux@gmx.de> wrote:

Hi,

On 30.09.2015, at 22:57, Balázs Kósi <kosi.balazs@ezomer.hu> wrote:

> Hi,
>
> It's not me. Most probably you are looking for Bastian Kruck: http://www.bkruck.de/
> ​

Yes, It is Bastian. He worked on this stuff earlier this year, So Eliot, you
can also talk to Tim or me on that matter :)

Best regards
        -Tobias




--
_,,,^..^,,,_
best, Eliot