Smalltalk › tODE

[tode_st] tODE & GCI in Pharo 5?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

86 messages Options

12345

Dale Henrichs-3

Re: [tode_st] tODE & GCI in Pharo 5?

On 4/17/16 12:05 PM, Mariano Martinez Peck wrote:

Good question. I really don't know. I am asking Esteban. Will let you know.

The obvious mapping does not work, does it?

self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )

Btw...is there a unit test I could run once I have a solution?

I had to head out shortly, so I was hoping for a solution when I got back. so I didn't try anything at the time ... I don't think that worked in the old FFI and debugging segmentation faults from incorrect specs is always a pain ... I was in the process of writing a test case for another feature when I realized I could use GciSaveObjs and then :)

Upon reflection I realize that it is probably similar to the declaration for GciPerformNoDebug_( OopType receiver, const char selector[],
const OopType args[], int numArgs, int flags, ushort environmentId), which doesn't use `GsGciOopType[] args`, using `ulong args` --- so I'll be brave and see if `self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )` since converting FFI calls to "alternate but equivalent" is not the best solution ...

Thanks a ton, I should have a bit of time to try things out ..

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Mariano Martinez Peck

Re: [tode_st] tODE & GCI in Pharo 5?

On Sun, Apr 17, 2016 at 8:16 PM, Dale Henrichs <[hidden email]> wrote:

On 4/17/16 12:05 PM, Mariano Martinez Peck wrote:

Good question. I really don't know. I am asking Esteban. Will let you know.

The obvious mapping does not work, does it?

self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )

Btw...is there a unit test I could run once I have a solution?

I had to head out shortly, so I was hoping for a solution when I got back. so I didn't try anything at the time ... I don't think that worked in the old FFI and debugging segmentation faults from incorrect specs is always a pain ... I was in the process of writing a test case for another feature when I realized I could use GciSaveObjs and then :)

OKok, if you finally get that reproducible test case, it would be even simpler for me!

Upon reflection I realize that it is probably similar to the declaration for GciPerformNoDebug_( OopType receiver, const char selector[],
const OopType args[], int numArgs, int flags, ushort environmentId),

that's right!!! that's exactly the same situation.

which doesn't use `GsGciOopType[] args`, using `ulong args` --- so I'll be brave and see if `self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )` since converting FFI calls to "alternate but equivalent" is not the best solution ...

uhhhg good finding. I honestly don't remember doing that on purpose. I think I simply copied it from old FFI? I am checking old ffi now:

apiGciPerformNoDebug: anOopType a: aString a: anArray a: anInteger a: flagInteger

" EXTERN_GCI_DEC(OopType)

GciPerformNoDebug( OopType receiver, const char selector[],

const OopType args[], int numArgs, int flags);"

<apicall: OopType64 'GciPerformNoDebug' (OopType64 char* ulong long long) >

^self externalCallFailed

So... what I can tell you, is that GsGciOopType is considered a ulonglong (see FFIGemstone64HandleType >> externalType)

So.....I suspect the correct mapping could be (for 64 bits gemstone):

self ffiCall: #( GciSaveObjs(ulonglong theOops, int numOops) )

if that doesn't work, you can try the original I said (which looks much better!!!)

self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )

Let me know how it goes!

Thanks a ton, I should have a bit of time to try things out ..

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Mariano
http://marianopeck.wordpress.com

Mariano Martinez Peck

Fwd: [tode_st] tODE & GCI in Pharo 5?

In reply to this post by Mariano Martinez Peck

Dale,

Please read Esteban answer (he is not in the list)

let me know how things go!!

---------- Forwarded message ----------
From: Esteban Lorenzano <[hidden email]>
Date: Mon, Apr 18, 2016 at 8:54 AM
Subject: Re: [tode_st] tODE & GCI in Pharo 5?
To: Mariano Peck <[hidden email]>
Cc: [hidden email]

no direct support for arrays yet (NB didn’t have it either)… I started an implementation but is still far from ready.

In this case, I think you can declare the [] as pointer… something like:

self ffiCall: #( void GciSaveObjs(GsGciOopType *theOops, int numOops) )

should work, but you need to call it with something like this (supposing your function is called by method GciSaveObjs:size:):

| array |

array := FFIExternalArray newType: GsGciOopType size: 42.

self GciSaveObjs: array getHandle size: 42

Notice the #getHandle message. This is because function cannot directly transform the array into a reference. You could also declare your function as this:

self ffiCall: #( void GciSaveObjs(FFIExternalArray theOops, int numOops) )

then you can call it like this:

self GciSaveObjs: array size: 42.

Both approaches should work…

Esteban

On 17 Apr 2016, at 21:05, Mariano Martinez Peck <[hidden email]> wrote:

Good question. I really don't know. I am asking Esteban. Will let you know.

The obvious mapping does not work, does it?

self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )

Btw...is there a unit test I could run once I have a solution?

Thanks!

On Sun, Apr 17, 2016 at 12:57 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

I've got the following declaration and I'm not sure how to declare

GciSaveObjs(const OopType theOops[], int numOops);

using UFFI ... I've poked around a little bit and didn't see any examples in the tests and thought you might know offhand.

Thanks in advance,

Dale

/* ==========================================================================
* GciSaveObjs (behavior has changed in Gemstone64)
*
* If called from a user action
* adds specified objects to the user action's exportSet,
* else
* adds the specified objects to the sessions internal PureExportSet.
* to prevent their being garabage collected.
*
* The user action's export set does not contributed to objects appearing
* in the ExportedDirtyObjs set .
*
* This will prevent Gemstone garbage collection from causing
* the objects to disappear during a session because they are unreferenced.
* Does NOT cause the objects to be referenced from a permanent object,
* and thus there is no guarantee that they will be saved to disk at commit.
*
* Note that for results of GciNew*, GciCreate*, GciSend*, GciPerform*,
* GciExecute* GciResolve* and GciI64ToOop
* an automatic GciSaveObjs() is performed with the results as argument.
* GciRelease* calls may be used to cancel the effect of a GciSaveObjs call,
* thus making objects eligible for garbage collection.
*
* See also GciDirtyExportedObjs() .
*
* arguments: theOops, an array of oops,
* numOops, the number of elements in theOops
* ==========================================================================
*/
GCI_ALIGN_STACK EXTERN_GCI_DEC(void)
GciSaveObjs(const OopType theOops[], int numOops);

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
Mariano
http://marianopeck.wordpress.com

Mariano
http://marianopeck.wordpress.com

Stephan Eggermont-3

Re: [tode_st] tODE & GCI in Pharo 5?

In reply to this post by Dale Henrichs-3

On Sunday, April 17, 2016 at 12:59:06 AM UTC+2, Dale Henrichs wrote:

So in your use case, you _could_ install a custom builder for the
inspector to create a client element with the fields that you need for
your inspector --- which is a function of the type of operations you
expect to perform on the object ...

That sounds interesting, indeed.

This is where some shared example code (ideally on GitHub) would make it
easier to illustrate what I'm talking about ...

I was just doing

result := aSession executeString: 'String streamContents: [:stream | |obj index |

obj := (Object _objectForOop: ',oop asString,').

index := 1.

obj class allInstVarNames do: [:each | |instVarValue |

stream nextPutAll: each;crlf.

instVarValue := obj instVarAt: index.

stream nextPutAll: instVarValue asOop asString;crlf.

stream nextPutAll: instVarValue inspectorName;crlf.

index := index+1]]'.

Dale Henrichs-3

Re: Fwd: [tode_st] tODE & GCI in Pharo 5?

In reply to this post by Mariano Martinez Peck

Mariano,

Thanks for chasing this down ... the method used in "perform withArgs" was similar to what Esteban suggest, but I was creating the Handle directly ... I much prefer the getHandle technique and will use it shortly...

Da

On 04/18/2016 08:17 AM, Mariano Martinez Peck wrote:

Dale,

Please read Esteban answer (he is not in the list)

let me know how things go!!

---------- Forwarded message ----------
From: Esteban Lorenzano <[hidden email]>
Date: Mon, Apr 18, 2016 at 8:54 AM
Subject: Re: [tode_st] tODE & GCI in Pharo 5?
To: Mariano Peck <[hidden email]>
Cc: [hidden email]

no direct support for arrays yet (NB didn’t have it either)… I started an implementation but is still far from ready.
In this case, I think you can declare the [] as pointer… something like:

self ffiCall: #( void GciSaveObjs(GsGciOopType *theOops, int numOops) )

should work, but you need to call it with something like this (supposing your function is called by method GciSaveObjs:size:):

| array |

array := FFIExternalArray newType: GsGciOopType size: 42.

self GciSaveObjs: array getHandle size: 42

Notice the #getHandle message. This is because function cannot directly transform the array into a reference. You could also declare your function as this:

self ffiCall: #( void GciSaveObjs(FFIExternalArray theOops, int numOops) )

then you can call it like this:

self GciSaveObjs: array size: 42.

Both approaches should work…

Esteban

On 17 Apr 2016, at 21:05, Mariano Martinez Peck <[hidden email]> wrote:

Good question. I really don't know. I am asking Esteban. Will let you know.

The obvious mapping does not work, does it?

self ffiCall: #( GciSaveObjs(GsGciOopType[] theOops, int numOops) )

Btw...is there a unit test I could run once I have a solution?

Thanks!

On Sun, Apr 17, 2016 at 12:57 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I've got the following declaration and I'm not sure how to declare

GciSaveObjs(const OopType theOops[], int numOops);

using UFFI ... I've poked around a little bit and didn't see any examples in the tests and thought you might know offhand.

Thanks in advance,

Dale

/* ==========================================================================
* GciSaveObjs (behavior has changed in Gemstone64)
*
* If called from a user action
* adds specified objects to the user action's exportSet,
* else
* adds the specified objects to the sessions internal PureExportSet.
* to prevent their being garabage collected.
*
* The user action's export set does not contributed to objects appearing
* in the ExportedDirtyObjs set .
*
* This will prevent Gemstone garbage collection from causing
* the objects to disappear during a session because they are unreferenced.
* Does NOT cause the objects to be referenced from a permanent object,
* and thus there is no guarantee that they will be saved to disk at commit.
*
* Note that for results of GciNew*, GciCreate*, GciSend*, GciPerform*,
* GciExecute* GciResolve* and GciI64ToOop
* an automatic GciSaveObjs() is performed with the results as argument.
* GciRelease* calls may be used to cancel the effect of a GciSaveObjs call,
* thus making objects eligible for garbage collection.
*
* See also GciDirtyExportedObjs() .
*
* arguments: theOops, an array of oops,
* numOops, the number of elements in theOops
* ==========================================================================
*/
GCI_ALIGN_STACK EXTERN_GCI_DEC(void)
GciSaveObjs(const OopType theOops[], int numOops);

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dale Henrichs-3

Re: [tode_st] tODE & GCI in Pharo 5?

In reply to this post by Stephan Eggermont-3

On 04/18/2016 08:19 AM, Stephan Eggermont wrote:

On Sunday, April 17, 2016 at 12:59:06 AM UTC+2, Dale Henrichs wrote:
So in your use case, you _could_ install a custom builder for the
inspector to create a client element with the fields that you need for
your inspector --- which is a function of the type of operations you
expect to perform on the object ...

That sounds interesting, indeed.

This is where some shared example code (ideally on GitHub) would make it
easier to illustrate what I'm talking about ...

I was just doing

result := aSession executeString: 'String streamContents: [:stream | |obj index |

obj := (Object _objectForOop: ',oop asString,').

index := 1.

obj class allInstVarNames do: [:each | |instVarValue |

stream nextPutAll: each;crlf.

instVarValue := obj instVarAt: index.

stream nextPutAll: instVarValue asOop asString;crlf.

stream nextPutAll: instVarValue inspectorName;crlf.

index := index+1]]'.

Okay ... not quite as expensive as it would have been if you had been doing all of the work on the client:) and running code on the server _is_ the idea ...

I've made good progress on the Minimal tODE client[1] and before I turn it loose for you. I expect to include support for running a tODE command from the client, handling the result for simple commands (i.e., "eval `3+4`") and also providing a hook for handling client elements (i.e., "eval `3+4`; edit") --- no windows will come up but it will give you and opportunity to build an inspector example based on the standard client element produced by tODE --- including menu items and "on click" actions ... then you can consider creating different client elements to support the functionality you want in your inspector GUI and I can show you how to arrange to create your new client elements ...

Dale

[1] https://github.com/dalehenrich/tode/issues/253

12345