Smalltalk › Pharo › Pharo Smalltalk Developers

Instructions for Pharo 6 64bits

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

48 messages Options

123

Denis Kudriashov

Re: Instructions for Pharo 6 64bits

Hi Esteban.

2016-11-06 17:51 GMT+01:00 Esteban Lorenzano <[hidden email]>:

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

Nicolas Passerini

Re: Instructions for Pharo 6 64bits

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <[hidden email]>:

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

EstebanLM

Re: Instructions for Pharo 6 64bits

On 7 Nov 2016, at 14:39, Nicolas Passerini <[hidden email]> wrote:

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <[hidden email]>:
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

Nicolas Passerini

Re: Instructions for Pharo 6 64bits

Well, maybe we can do it for Pharo 7.

2016-11-07 14:46 GMT+01:00 Esteban Lorenzano <[hidden email]>:

On 7 Nov 2016, at 14:39, Nicolas Passerini <[hidden email]> wrote:

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <[hidden email]>:
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

EstebanLM

Re: Instructions for Pharo 6 64bits

On 7 Nov 2016, at 14:53, Nicolas Passerini <[hidden email]> 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 <[hidden email]>:

On 7 Nov 2016, at 14:39, Nicolas Passerini <[hidden email]> wrote:

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <[hidden email]>:
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

Sven Van Caekenberghe-2

Re: Instructions for Pharo 6 64bits

In reply to this post by EstebanLM

> On 28 Oct 2016, at 11:56, Esteban Lorenzano <[hidden email]> 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

Stephan Eggermont-3

LMDB

In reply to this post by Jan van de Sandt

On 05/11/16 13:55, Jan van de Sandt wrote:
> LMDB is a lean, mean and very fast storage engine. One limitation is
> that you need a 64bit proces before you can store more than 2GB of data.
> That was a downside for me until very recently :-)
>
> LMDB is a low level key-value storage engine that runs on a single host.
> But if that is what you are looking for it seems pretty good. I haven't
> used it in any production systems yet. But it is used as a storage
> engine in quite a few open source projects. For example OpenLDAP.

Do I really need to compile LMDB myself?

Stephan

Jan van de Sandt

Re: LMDB

Hi,

On OSX you can use Homebrew to install LMDB. This will install the 64bit version. If you want the 32bit version you will have to tweak the recipe.

Jan.

On Fri, Nov 11, 2016 at 11:32 AM, Stephan Eggermont <[hidden email]> wrote:

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

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

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

Do I really need to compile LMDB myself?

Stephan

123