Hi Jan, 

I���m sorry but I will not even look at it :( 
nothing personal, I respect a lot the instantiations people and their product (and I know they will do a good work). 
Is just that I care a lot about Pharo being open source MIT and I do not want to pollute my code with something I might have seen elsewhere (and copyrighted elsewhere)��� 
But of course, I can discuss my idea here and with whoever wants :)

So, I have this idea who is very simple: keep structure offsets separately. 
Today all structure has something like this:

height
"This method was automatically generated"
^handle doubleAt: 17

height: anObject
"This method was automatically generated"
handle doubleAt: 17 put: anObject

which of course does not work.
with my idea this will become like this: 

height
"This method was automatically generated"
^handle doubleAt: HEIGHT_OFFSET

height: anObject
"This method was automatically generated"
handle doubleAt: HEIGHT_OFFSET put: anObject

and HEIGHT_OFFSET can be initialised per session��� or with a minimal intelligence per session with a ���architecture changed��� verification. 

I think this is very easy to implement and will work��� but of course I still didn���t do anything more than think about��� we���ll see when I try to implement it :)

Esteban


On 5 Nov 2016, at 17:05, Jan van de Sandt <jvdsandt@gmail.com> wrote:

Hi Esteban,

Instantiations is also busy porting their VM to 64bits. They have already created a new API for OStructures so that the offsets are re calculated based on the platform alignment rules and the VM type [1].

I know Pharo is open source and VA Smalltalk is not. But a bit of cooperation should be possible I think. Both platforms benefit if libraries are easy to port and not re-inventing this wheel saves time.

Jan.



On Sat, Nov 5, 2016 at 3:10 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

> On 5 Nov 2016, at 12:27, Thierry Goubier <thierry.goubier@gmail.com> wrote:
>
> Le 05/11/2016 �� 12:12, Jan van de Sandt a ��crit :
>> Hi,
>>
>> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
>> looking good. I'm testing a small library of mine [1] to interface with
>> LMDB [1], a memory mapped key-value database. Almost all tests are
>> green. This is great progress!
>
> Hi Jan,
>
> did you have to change your UFFI definitions to match the 64bits version of your lib?

no.
but structures do change (because of sizes, of course).
I���m thinking a way to define a generic representation (keeping offsets somewhere instead hardcoding it), but for now they have to be redefined for each platform.

Esteban

>
> Thierry
>
>> I only ran into one issue, a PrimitiveFailed error with
>> #basicIdentityHash in the SmallFloat64 class.
>>
>> Cheers,
>> Jan.
>>
>> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
>> [2] https://symas.com/products/lightning-memory-mapped-database/
>>
>>
>> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <estebanlm@gmail.com
>> <mailto:estebanlm@gmail.com>> wrote:
>>
>>    VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>    <http://bintray.com/estebanlm/pharo-vm/build#files/>
>>    Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>    <http://files.pharo.org/get-files/60/pharo-64.zip>
>>
>>    this is still not official (that���s why is not in official place) so
>>    there are a couple of known problems:
>>
>>    - version format is different, and that breaks some things in image
>>    that depends on it to know what happens
>>    - command line is different and probably you���ll need to play a bit
>>    with options (one or two dashes).
>>    - UFFI has some failing tests (but most of it works).
>>
>>    I would appreciate some help to report and/or fix the emerging
>>    problems.
>>
>>    cheers,
>>    Esteban
>>
>>>    On 28 Oct 2016, at 10:39, Thierry Goubier
>>>    <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
>>>
>>>    Hi all,
>>>
>>>    anybody knows how to get (and test) the 64bits version of the
>>>    Pharo vm and image?
>>>
>>>    Thanks,
>>>
>>>    Thierry
>>
>>
>
>