Instructions for Pharo 6 64bits
Locked
123
123
Re: Instructions for Pharo 6 64bits
 
|
Le 03/11/2016 à 19:25, Esteban Lorenzano a écrit :
> >> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto >> <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> >>> 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 >>>> <[hidden email] <mailto:[hidden email]>> >>>> 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* > |
Re: Instructions for Pharo 6 64bits
|
|
Hi Thierry,
On Thu, Nov 3, 2016 at 1:06 PM, Thierry Goubier <[hidden email]> wrote: Le 03/11/2016 à 19:25, Esteban Lorenzano a écrit : To be accurate, one only needs to login again.
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Thierry Goubier
Em 03-11-2016 13:53, Thierry Goubier
escreveu:
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.
--
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 |
signature.asc (876 bytes)
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by Eliot Miranda-2
Le 03/11/2016 à 22:16, Eliot Miranda a écrit :
> Hi Thierry, > > On Thu, Nov 3, 2016 at 1:06 PM, Thierry Goubier > <[hidden email] <mailto:[hidden email]>> wrote: > > Le 03/11/2016 à 19:25, Esteban Lorenzano a écrit : > > > On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> 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 |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by CdAB63
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 |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by EstebanLM
> On Nov 3, 2016, at 1:25 PM, Esteban Lorenzano <[hidden email]> wrote: > > >> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto <[hidden email]> 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 > * hard rtprio 2 > * soft rtprio 2 > > to: > > /etc/security/limits.d Has anyone tried this in a docker container environment? Someone tried to setup a docker container with the VM for me, but the VM wouldn’t start. After a few attempts, I decided that we could use the non-heartbeat thread VM. John Brant |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by CdAB63
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 <[hidden email] > > <mailto:[hidden email]>>: > > > > 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 > >> <[hidden email] <mailto:[hidden email]>> 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* |
|
|
this is more a question for vm-dev list I think.
I have not idea on how to overcome this problem… doesn’t look very possible, thinking in general. Maybe in freebsd (who I also do not know at all) there is another way to change limits? also, I think itimer could be less efficient, but should be possible… crashing do not looks like a nice output :) Esteban > On 4 Nov 2016, at 23:56, Petr Fischer <[hidden email]> 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? 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> >>> 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 >>>> <[hidden email] <mailto:[hidden email]>> 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* > > > > |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by EstebanLM
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. On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <[hidden email]> wrote:
|
Re: Instructions for Pharo 6 64bits
|
|
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 <[hidden email] > <mailto:[hidden email]>> 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 >> <[hidden email] <mailto:[hidden email]>> wrote: >> >> Hi all, >> >> anybody knows how to get (and test) the 64bits version of the >> Pharo vm and image? >> >> Thanks, >> >> Thierry > > |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by Jan van de Sandt
Wow, this LMDB thing seems pretty cool.
Actually, it sounds as if there are no downsides. What are the limitations ? > On 5 Nov 2016, at 12:12, Jan van de Sandt <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> >> Hi all, >> >> anybody knows how to get (and test) the 64bits version of the Pharo vm and image? >> >> Thanks, >> >> Thierry > > |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by Thierry Goubier
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 <[hidden email]> wrote: Le 05/11/2016 à 12:12, Jan van de Sandt a écrit : |
Re: Instructions for Pharo 6 64bits
|
|
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 <[hidden email]> wrote:
|
|
|
In reply to this post by Thierry Goubier
> On 5 Nov 2016, at 12:27, Thierry Goubier <[hidden email]> 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 <[hidden email] >> <mailto:[hidden email]>> 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 >>> <[hidden email] <mailto:[hidden email]>> wrote: >>> >>> Hi all, >>> >>> anybody knows how to get (and test) the 64bits version of the >>> Pharo vm and image? >>> >>> Thanks, >>> >>> Thierry >> >> > > |
|
|
In reply to this post by Jan van de Sandt
Hi jan
will you contact to add Pharo to the list of languages because this is good for us to be in this list.
Stef Le 5/11/16 à 13:55, Jan van de Sandt a
écrit :
|
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by EstebanLM
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 <[hidden email]> wrote:
|
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by EstebanLM
Le 05/11/2016 à 15:10, Esteban Lorenzano a écrit :
> >> On 5 Nov 2016, at 12:27, Thierry Goubier <[hidden email]> 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 |
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by Jan van de Sandt
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
|
Re: Instructions for Pharo 6 64bits
|
|
In reply to this post by Petr Fischer
Hi Petr,
> On Nov 4, 2016, at 3:56 PM, Petr Fischer <[hidden email]> 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> >>> 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 >>>> <[hidden email] <mailto:[hidden email]>> 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* > > > > |
|
|
In reply to this post by Jan van de Sandt
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
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |