2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:

VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ Image here: http://files.pharo.org/get-files/60/pharo-64.zip

Thanks.

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.

I'll make myself a Makefile for it and test; if I see it stable enough, I'll try to use it on a regular basis and report. Thierry

cheers, Esteban

On 28 Oct 2016, at 10:39, Thierry Goubier <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

I faced an issue that FFI calls fail with arguments of type size_t or the value that was passed to C function was completely wrong. For example you pass 1 but get 29834693165 Cheers, Alex On 28 October 2016 at 14:22, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2016-10-28 12:29 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:

...

VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ Image here: http://files.pharo.org/get-files/60/pharo-64.zip

Thanks.

...

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.

I'll make myself a Makefile for it and test; if I see it stable enough, I'll try to use it on a regular basis and report.

Report:

apart from the missing SSL support which makes loading complex stuff from github a bit painfull, it seems to be usable enough.

OSProcess and GitFileTree work fine. Which means gitfiletree:// urls work, but not github:// urls.

I loaded a large project (a compiler!) and saw no issues (apart from a freetype / wrong glyph issue?). All SmaCC tests are green on it, and my project tests were green as well.

Thierry

...

Thierry

...

cheers, Esteban

On 28 Oct 2016, at 10:39, Thierry Goubier <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

does 64 bit means that we can now take full advantage of the memory of our system and not have to adhere to a specific limit ? Is that something the current build does or is it planned for future releases ? On Fri, Oct 28, 2016 at 4:19 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 28 Oct 2016, at 14:22, Thierry Goubier <thierry.goubier@gmail.com> wrote:

apart from the missing SSL support which makes loading complex stuff from github a bit painfull, it seems to be usable enough.

I should work on this :)

Esteban

awesome thank you guys On Fri, Oct 28, 2016 at 7:05 PM stepharo <stepharo@free.fr> wrote:

Le 28/10/16 à 16:59, Dimitris Chloupis a écrit :

does 64 bit means that we can now take full advantage of the memory of our system

yes

and not have to adhere to a specific limit ?

well probably the one of your OS :)

Is that something the current build does or is it planned for future releases ?

This one.

On Fri, Oct 28, 2016 at 4:19 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 28 Oct 2016, at 14:22, Thierry Goubier <thierry.goubier@gmail.com> wrote:

apart from the missing SSL support which makes loading complex stuff from github a bit painfull, it seems to be usable enough.

I should work on this :)

Esteban

I cannot see the text I type into the Spotter’s search bar. Otherwise everything is great so far. Uko

On 29 Oct 2016, at 17:09, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Le 28/10/2016 à 15:18, Esteban Lorenzano a écrit :

...

...

On 28 Oct 2016, at 14:22, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

apart from the missing SSL support which makes loading complex stuff from github a bit painfull, it seems to be usable enough.

I should work on this :)

Anything we can be of help on this?

In the meantime, I'm becoming expert at writing wget requests to github to get tarballs of smalltalk projects :)

Thierry

...

Esteban

Hi Esteban, Le 28/10/2016 à 11:56, Esteban Lorenzano a écrit :

VM here: http://bintray.com/estebanlm/pharo-vm/build#files/

What is the difference between the various x86_64 versions? I chose the itimer one for my tests. The threaded one is the "run external calls in their own thread" vm? Thanks, Thierry

On 29 Oct 2016, at 01:23, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Thierry,

On Fri, Oct 28, 2016 at 11:23 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote: Hi Esteban,

Le 28/10/2016 à 11:56, Esteban Lorenzano a écrit : VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ <http://bintray.com/estebanlm/pharo-vm/build#files/>

What is the difference between the various x86_64 versions? I chose the itimer one for my tests. The threaded one is the "run external calls in their own thread" vm?

No. The "threaded" one uses a separate thread for generating the heartbeat. The timer one uses a signal-based interval timer. You want the threaded one. The signal-based implementation causes havoc with external code.

^ this. but the threaded one requires a config on linux. (executing it by command line will point you to the correct NOTE, just s/squeak/pharo :) ) Esteban

Thanks,

Thierry

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

OMG, this thing is for real: A Pharo image using 20 GB virtual memory, about 6/7 GB for real on macOS Sierra, after playing around a bit allocating massive amounts of memory. Pharo in the above screenshot holds two 2 basic inspectors open on two different 1 GB byte arrays, after GC consuming about 2.2 GB. This is a game changer. Yeah ! 2 ** 30 timesRepeat: [ Transcript crShow: 'Thank you !' ].

On 28 Oct 2016, at 11:56, Esteban Lorenzano <estebanlm@gmail.com> wrote:

VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ Image here: 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> wrote:

Hi all,

anybody knows how to get (and test) the 64bits version of the Pharo vm and image?

Thanks,

Thierry

BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to do... Best regards, Casimiro Barreto Em 03-11-2016 13:53, Thierry Goubier escreveu:

Hi Esteban,

Another question about Pharo 64 bits.

Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides them with the same version numbers, more or less. (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, SDL and ssh are the exact same versions).

Collectively, those three libs are ~ 5M.

Thierry

2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

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

-- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417*

Le 03/11/2016 à 19:25, Esteban Lorenzano a écrit :

...

On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto <casimiro.barreto@gmail.com <mailto:casimiro.barreto@gmail.com>> wrote:

BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to do…

no, is not hard. you just need to add this file:

pharo.conf *hardrtprio2 *soft rtprio2

to:

/etc/security/limits.d

And reboot for this to be applied. Thierry

Esteban

...

Best regards,

Casimiro Barreto

Em 03-11-2016 13:53, Thierry Goubier escreveu:

...

Hi Esteban,

Another question about Pharo 64 bits.

Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides them with the same version numbers, more or less. (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, SDL and ssh are the exact same versions).

Collectively, those three libs are ~ 5M.

Thierry

2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

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

-- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

==

This email may be signed using PGP key *ID: 0x4134A417*

Le 03/11/2016 à 22:16, Eliot Miranda a écrit :

Hi Thierry,

On Thu, Nov 3, 2016 at 1:06 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

Le 03/11/2016 à 19:25, Esteban Lorenzano a écrit :

On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto <casimiro.barreto@gmail.com <mailto:casimiro.barreto@gmail.com> <mailto:casimiro.barreto@gmail.com <mailto:casimiro.barreto@gmail.com>>> wrote:

BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to do…

no, is not hard. you just need to add this file:

pharo.conf *hardrtprio2 *soft rtprio2

to:

/etc/security/limits.d

And reboot for this to be applied.

To be accurate, one only needs to login again.

I'm too accustomed to a single user laptop :) But that 64bits version working is really great. Thierry

Also on FreeBSD, there is no security/limits config, so on FreeBSD, I am not able to run heartbeat VM as normal user at all :( Ins't there any other solution? Why "realtime" threads? Isn't possible to run "heartbeat" thread with normal priority and all other threads with lower priorities to provide the same behaviour? How to deploy application based on Pharo to the normal (UNIX) users, if security reconfiguration is needed? pf P.S. VM wihout heartbeat is crashing on FreeBSD randomly with error "stack page bytes 4096 available headroom 2788 minimum unused headroom 3020" :(

BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to do...

Best regards,

Casimiro Barreto

Em 03-11-2016 13:53, Thierry Goubier escreveu:

...

Hi Esteban,

Another question about Pharo 64 bits.

Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides them with the same version numbers, more or less. (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, SDL and ssh are the exact same versions).

Collectively, those three libs are ~ 5M.

Thierry

2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

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

-- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

==

This email may be signed using PGP key *ID: 0x4134A417*

Hi Petr,

On Nov 4, 2016, at 3:56 PM, Petr Fischer <petr.fischer@me.com> wrote:

Also on FreeBSD, there is no security/limits config, so on FreeBSD, I am not able to run heartbeat VM as normal user at all :(

Ins't there any other solution? Why "realtime" threads?

There's nothing special about the heartbeat thread apart from needing to have a higher priority than the VM thread.

Isn't possible to run "heartbeat" thread with normal priority and all other threads with lower priorities to provide the same behaviour?

This should work provided one can create a thread of lower priority, and providing having the VM thread being lower priority doesn't impact VM performance when other applications are running. IIRC it wasn't possible on the linux pthreads implementation in the 2.4.x kernel dats when I first got Cog working in linux to have a thread at higher or lower priority; there was only one priority available to user programs. Have you tried to create a couple of threads with different priorities on FreeBSD?

How to deploy application based on Pharo to the normal (UNIX) users, if security reconfiguration is needed?

pf

P.S. VM wihout heartbeat is crashing on FreeBSD randomly with error "stack page bytes 4096 available headroom 2788 minimum unused headroom 3020" :(

...

BTW, the threaded version requires to be run as super user because it tries to do a pthread_setschedparam(). I tried to fiddle with /etc/security/limits.conf... but it's not something fancy to do...

Best regards,

Casimiro Barreto

Em 03-11-2016 13:53, Thierry Goubier escreveu:

...

Hi Esteban,

Another question about Pharo 64 bits.

Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides them with the same version numbers, more or less. (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, SDL and ssh are the exact same versions).

Collectively, those three libs are ~ 5M.

Thierry

2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

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

-- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

==

This email may be signed using PGP key *ID: 0x4134A417*

Le 03/11/2016 à 22:17, Casimiro de Almeida Barreto a écrit :

Em 03-11-2016 13:53, Thierry Goubier escreveu:

...

Hi Esteban,

Another question about Pharo 64 bits.

Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides them with the same version numbers, more or less. (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm, SDL and ssh are the exact same versions).

Collectively, those three libs are ~ 5M.

There are some troubles with ssl in Fedora (didn't test it in Ubuntu). While loading Woden (for instance) there's a crash (exception) because ZdcPluginSSLSession fails.

Yes, this is the SSL plugin not being compiled in. Github-based projects may still be accessed by using gitfiletree (or a command-line wget + filetree). FFI-support isn't complete yet as well so this would probably make Woden non-working for the time being. Thierry

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

Hi Sven, LMDB is a lean, mean and very fast storage engine. One limitation is that you need a 64bit proces before you can store more than 2GB of data. That was a downside for me until very recently :-) LMDB is a low level key-value storage engine that runs on a single host. But if that is what you are looking for it seems pretty good. I haven't used it in any production systems yet. But it is used as a storage engine in quite a few open source projects. For example OpenLDAP. Jan. On Sat, Nov 5, 2016 at 1:43 PM, Jan van de Sandt <jvdsandt@gmail.com> wrote:

Hi,

The only thing I had to do was to regenerate the accessors of the structure classes MDBValue and MDBStat. The offsets for the fields are different on 32 versus 64 bit systems. Perhaps we can think of a way to generate the field accessors of structure classes such that they work in both environments.

For now just you can just use #rebuildFieldAccessors

Jan.

On Sat, Nov 5, 2016 at 12:27 PM, 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?

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

On 05/11/16 13:55, Jan van de Sandt wrote:

LMDB is a lean, mean and very fast storage engine. One limitation is that you need a 64bit proces before you can store more than 2GB of data. That was a downside for me until very recently :-)

LMDB is a low level key-value storage engine that runs on a single host. But if that is what you are looking for it seems pretty good. I haven't used it in any production systems yet. But it is used as a storage engine in quite a few open source projects. For example OpenLDAP.

Do I really need to compile LMDB myself? Stephan

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

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.

[1] http://www.instantiations.com/docs/862/wwhelp/wwhimpl/js/html/wwhelp.htm#hre... <http://www.instantiations.com/docs/862/wwhelp/wwhimpl/js/html/wwhelp.htm#hre...>

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

...

On 5 Nov 2016, at 12:27, Thierry Goubier <thierry.goubier@gmail.com <mailto: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 <http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB> [2] https://symas.com/products/lightning-memory-mapped-database/ <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> <mailto: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/> <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> <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> <mailto: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

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:

NativeStructure subclass : #SDL_Point layout : StructureLayout slots: { #x &=> #int. #y &=> #int} ... (I got example of Ronie definition from his paper https://hal.inria.fr/ hal-01353884/document). So all offsets logic will go to one place StructureLayout and slots. And also we will not forced to use accessors anymore.

I like this idea. But one question, would it be backwards compatible? (I mean, if I have current FFI invocations that use a structure in the traditional way, will I have to change all these functions if I try to migrate to this new idea?)

Well, maybe we can do it for Pharo 7. 2016-11-07 14:46 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:

On 7 Nov 2016, at 14:39, Nicolas Passerini <npasserini@gmail.com> wrote:

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

NativeStructure subclass : #SDL_Point layout : StructureLayout slots: { #x &=> #int. #y &=> #int} ... (I got example of Ronie definition from his paper https://hal.inria.fr/hal-01353884/document). So all offsets logic will go to one place StructureLayout and slots. And also we will not forced to use accessors anymore.

I like this idea. But one question, would it be backwards compatible? (I mean, if I have current FFI invocations that use a structure in the traditional way, will I have to change all these functions if I try to migrate to this new idea?)

no, and that’s why I didn’t considered it for now. this is an api change, non backwards compatible and then it breaks my own criteria about Pharo6 development: no more API changes.

but yes, in general, I like the idea… just we cannot break things just like that (I know, I break things… but this is not willingly :P)

Esteban

Le 05/11/2016 à 15:10, Esteban Lorenzano a écrit :

...

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.

I'd really like, as I told Eliot a long time ago, to have fine control on this sort of choices. Mostly because in low-level libs and performance sensitive code, a 32 bits and a 64bits lib may have a very different API (in terms of structure size, padding and alignment) (and even between versions of, say, a 64bits lib). A C developper is allowed to handle and generate differences by using #ifdefs and __attributes__ and typeof/alignof, including things like that : typedef struct { long long __max_align_ll __attribute__((__aligned__(__alignof__(long long)))); long double __max_align_ld __attribute__((__aligned__(__alignof__(long double)))); } max_align_t; Because a Pharo image (and a package) may be executed on a large set of target platforms / versions, then it seems necessary to me to have the ability to write ourself the code that adapt a FFI interface to the target platform (boiler plate code to detect a target change at image startup, default code for rebuilding the accessors, and the ability to customize that default code). Thierry

I never got around to it resurrecting it (I don't have the skill, yet (ever?) ;) ) but there is the BerkeleyDbPlugin which should be portable to LMDB here: https://github.com/pdebruic/BerkeleyDBPlugin Jan van de Sandt wrote

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!

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@

> wrote:

...

VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ Image here: 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@

>

...

wrote:

Hi all,

anybody knows how to get (and test) the 64bits version of the Pharo vm and image?

Thanks,

Thierry

-- View this message in context: http://forum.world.st/Instructions-for-Pharo-6-64bits-tp4920476p4921798.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.