Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-10 Thread Sven Van Caekenberghe

> On 28 Oct 2016, at 11:56, Esteban Lorenzano  wrote:
> 
> Image here: http://files.pharo.org/get-files/60/pharo-64.zip

In the above image I get the following output on the Transcript while sending 
#ast to all methods

AthensCairoGradientPaint>>initializeRadialBetween:extending:and:extending:withColorRamp:(origin
 is shadowed)
DynamicSpecExample>>openOnString(ui is shadowed)
DynamicSpecExample>>openOnInteger(ui is shadowed)
ExternalForm>>setExtent:depth:bits:(pointer is shadowed)
ExternalForm>>primCreateManualSurfaceWidth:height:rowPitch:depth:isMSB:(width 
is shadowed)
ExternalForm>>primCreateManualSurfaceWidth:height:rowPitch:depth:isMSB:(height 
is shadowed)
ExternalForm>>primCreateManualSurfaceWidth:height:rowPitch:depth:isMSB:(depth 
is shadowed)
ExternalForm>>primManualSurface:setPointer:(pointer is shadowed)
ExternalType>>asPointerType:(pointerSize is shadowed)
RBRefactoryTestDataApp>>tempVarOverridesInstVar(temporaryVariable is shadowed)
RBSmalllintTestObject>>tempVarOverridesInstVar(temporaryVariable is shadowed)
TraitDescription>>fileOutLocalMethodsInCategory:on:(localSelectors is shadowed)

Just to let you know,

Sven




Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-07 Thread Esteban Lorenzano

> On 7 Nov 2016, at 14:53, Nicolas Passerini  wrote:
> 
> Well, maybe we can do it for Pharo 7.

unless of course we find that doing it like this is incredibly easy and also we 
can do an “automigration tool” style the autodeprecation tool ;)

Esteban

> 
> 2016-11-07 14:46 GMT+01:00 Esteban Lorenzano  >:
> 
>> On 7 Nov 2016, at 14:39, Nicolas Passerini > > wrote:
>> 
>> 
>> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov > >:
>> 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
> 
> 



Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-07 Thread Nicolas Passerini
Well, maybe we can do it for Pharo 7.

2016-11-07 14:46 GMT+01:00 Esteban Lorenzano :

>
> On 7 Nov 2016, at 14:39, Nicolas Passerini  wrote:
>
>
> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov :
>
>> 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
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-07 Thread Esteban Lorenzano

> On 7 Nov 2016, at 14:39, Nicolas Passerini  wrote:
> 
> 
> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov  >:
> 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



Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-07 Thread Nicolas Passerini
2016-11-07 10:37 GMT+01:00 Denis Kudriashov :

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


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-07 Thread Denis Kudriashov
Hi Esteban.

2016-11-06 17:51 GMT+01:00 Esteban Lorenzano :

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

I have feeling that Slots could solve this problem really well and also
improve the way how we work with external structures.
If you saw how Ronie describes external structures then you could imaging
what I am talking about.
For now on class side we always have #fieldDesc: method like:

SDL_Point>>fieldsDesc
"
self initializeAccessors
"
^#(
int x;
int y;
  )

where code in comments generates accessors.
And with Ronie approach this description will go directly to class
definition:

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.

What you think?

Best regards,
Denis


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-06 Thread Esteban Lorenzano
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  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#href=pr/stpr451.html
>  
> 
> 
> 
> On Sat, Nov 5, 2016 at 3:10 PM, Esteban Lorenzano  > wrote:
> 
> > On 5 Nov 2016, at 12:27, Thierry Goubier  > > 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  >> 
> >> >> 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
> >>> 
> >>> >> 
> >>> wrote:
> >>>
> >>>Hi all,
> >>>
> >>>anybody knows how to get (and test) 

Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Eliot Miranda
Hi Petr,

> On Nov 4, 2016, at 3:56 PM, Petr Fischer  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 >> >:
>>> 
>>>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
> 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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Paul DeBruicker
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.



Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Thierry Goubier

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



On 5 Nov 2016, at 12:27, Thierry Goubier  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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Jan van de Sandt
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#href=pr/stpr451.html


On Sat, Nov 5, 2016 at 3:10 PM, Esteban Lorenzano 
wrote:

>
> > On 5 Nov 2016, at 12:27, Thierry Goubier 
> 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 <
> esteba...@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
> >>>>
> wrote:
> >>>
> >>>Hi all,
> >>>
> >>>anybody knows how to get (and test) the 64bits version of the
> >>>Pharo vm and image?
> >>>
> >>>Thanks,
> >>>
> >>>Thierry
> >>
> >>
> >
> >
>
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread stepharo

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 :

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

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

>> wrote:

Hi all,

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

Thanks,

Thierry











Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Esteban Lorenzano

> On 5 Nov 2016, at 12:27, Thierry Goubier  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 > > 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
>>>> wrote:
>>> 
>>>Hi all,
>>> 
>>>anybody knows how to get (and test) the 64bits version of the
>>>Pharo vm and image?
>>> 
>>>Thanks,
>>> 
>>>Thierry
>> 
>> 
> 
> 




Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Jan van de Sandt
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  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.goub...@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 >> > 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
 >
 wrote:

 Hi all,

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

 Thanks,

 Thierry

>>>
>>>
>>>
>>
>>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Jan van de Sandt
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 
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 > > 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
>>> >
>>> wrote:
>>>
>>> Hi all,
>>>
>>> anybody knows how to get (and test) the 64bits version of the
>>> Pharo vm and image?
>>>
>>> Thanks,
>>>
>>> Thierry
>>>
>>
>>
>>
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Sven Van Caekenberghe
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  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  
> 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  wrote:
>> 
>> Hi all,
>> 
>> anybody knows how to get (and test) the 64bits version of the Pharo vm and 
>> image?
>> 
>> Thanks,
>> 
>> Thierry
> 
> 




Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Jan van de Sandt
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 
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 
> wrote:
>
> Hi all,
>
> anybody knows how to get (and test) the 64bits version of the Pharo vm and
> image?
>
> Thanks,
>
> Thierry
>
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread Esteban Lorenzano
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  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 >> >:
>>> 
>>>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
> 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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-04 Thread Petr Fischer
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  > >:
> >
> > 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
> >> > 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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread John Brant

> On Nov 3, 2016, at 1:25 PM, Esteban Lorenzano  wrote:
> 
> 
>> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto 
>>  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 
> * hardrtprio  2
> * softrtprio  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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Thierry Goubier

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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Thierry Goubier

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

Hi Thierry,

On Thu, Nov 3, 2016 at 1:06 PM, Thierry Goubier
> wrote:

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


On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto

>> 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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Casimiro de Almeida 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.

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.

>
> Thierry
>
> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano  >:
>
> 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
>> > 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*


signature.asc
Description: OpenPGP digital signature


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Eliot Miranda
Hi Thierry,

On Thu, Nov 3, 2016 at 1:06 PM, Thierry Goubier 
wrote:

> Le 03/11/2016 à 19:25, Esteban Lorenzano a écrit :
>
>>
>> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto
>>> > 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.


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

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


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


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Thierry Goubier

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



On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto
> 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 >:

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
>
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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Esteban Lorenzano

> On 3 Nov 2016, at 19:12, Casimiro de Almeida Barreto 
>  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 
*   hardrtprio  2
*   softrtprio  2

to: 

/etc/security/limits.d

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 > >:
>> 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 >> > 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: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Casimiro de Almeida Barreto
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  >:
>
> 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
>> > 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*


signature.asc
Description: OpenPGP digital signature


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-03 Thread Thierry Goubier
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 :

> 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 
> wrote:
>
> Hi all,
>
> anybody knows how to get (and test) the 64bits version of the Pharo vm and
> image?
>
> Thanks,
>
> Thierry
>
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-01 Thread Yuriy Tymchuk
And roassal is not working probably because of some Cairo bindings


> On 1 Nov 2016, at 10:39, Yuriy Tymchuk  wrote:
> 
> 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  wrote:
>> 
>> Le 28/10/2016 à 15:18, Esteban Lorenzano a écrit :
>>> 
 On 28 Oct 2016, at 14:22, Thierry Goubier > 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
>> 
>> 
> 
> 




Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-01 Thread Yuriy Tymchuk
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  wrote:
> 
> Le 28/10/2016 à 15:18, Esteban Lorenzano a écrit :
>> 
>>> On 28 Oct 2016, at 14:22, Thierry Goubier >> > 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
> 
> 




Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-29 Thread Thierry Goubier

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



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





Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-29 Thread Esteban Lorenzano

> On 29 Oct 2016, at 01:23, Eliot Miranda  wrote:
> 
> Hi Thierry,
> 
> On Fri, Oct 28, 2016 at 11:23 AM, Thierry Goubier  > wrote:
> 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?
> 
> 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



Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Eliot Miranda
Hi Thierry,

On Fri, Oct 28, 2016 at 11:23 AM, Thierry Goubier  wrote:

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

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.

Thanks,
>
> Thierry
>

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


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Thierry Goubier

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



Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Dimitris Chloupis
awesome thank you guys

On Fri, Oct 28, 2016 at 7:05 PM stepharo  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 
> wrote:
>
>
> On 28 Oct 2016, at 14:22, Thierry Goubier 
> 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
>
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread stepharo



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 > wrote:




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





Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Dimitris Chloupis
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 
wrote:

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


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Esteban Lorenzano

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

Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Aliaksei Syrel
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 
wrote:

>
>
> 2016-10-28 12:29 GMT+02:00 Thierry Goubier :
>
>>
>>
>> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano :
>>
>>> 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 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> anybody knows how to get (and test) the 64bits version of the Pharo vm
>>> and image?
>>>
>>> Thanks,
>>>
>>> Thierry
>>>
>>>
>>>
>>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Thierry Goubier
2016-10-28 12:29 GMT+02:00 Thierry Goubier :

>
>
> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano :
>
>> 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 
>> wrote:
>>
>> Hi all,
>>
>> anybody knows how to get (and test) the 64bits version of the Pharo vm
>> and image?
>>
>> Thanks,
>>
>> Thierry
>>
>>
>>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Thierry Goubier
2016-10-28 11:56 GMT+02:00 Esteban Lorenzano :

> 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 
> wrote:
>
> Hi all,
>
> anybody knows how to get (and test) the 64bits version of the Pharo vm and
> image?
>
> Thanks,
>
> Thierry
>
>
>


Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread Esteban Lorenzano
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  wrote:
> 
> Hi all,
> 
> anybody knows how to get (and test) the 64bits version of the Pharo vm and 
> image?
> 
> Thanks,
> 
> Thierry