[Pharo-project] Best way for FFI in Pharo

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sun Jan 8 22:13:28 CET 2012


Agreed, except for thinking that changing all of the module names is not a big deal :)   An external library subclass is the way to go.  I know this already exists in FFI, but the evolving chapter on Spock does not mention it - it should not only mention it, but recommend it, IMHO.

Stef, does it make sense yet?




________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianopeck at gmail.com]
Sent: Sunday, January 08, 2012 3:52 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Best way for FFI in Pharo



On Sun, Jan 8, 2012 at 9:25 PM, Stéphane Ducasse <stephane.ducasse at inria.fr<mailto:stephane.ducasse at inria.fr>> wrote:
can you give an example that I understand
"One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0 "


Bill:  that already exists in FFI.
Stef: what Bill says is that if you bind to a specific library you have to put its library name in each method that calls a ffi function. Example of DBX:

apiErrorType: handle number: err
    "int odbx_error_type( odbx_t*, int )"
    <cdecl: long 'odbx_error_type' (ulong long) module: 'opendbx'>
    ^ self externalCallFailed

----

apiInitialize: handle backend: backend host: host port: port
    "long odbx_init(odbx_t**, char*, char*, char*)"
    <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'>
    ^self externalCallFailed

---

xxx

---

Notice the "module: 'opendbx"
So...if now the library is renamed or whatever, you have to change all methods. But I don't think this is a real big deal. There are much worst things.

Finaly, I copy paste an answer from Andreas from a previous thread:


The Right Way to do this is to have a subclass of ExternalLibrary and implement the class-side method #moduleName along the lines of:

MyLibrary class>>moduleName
 "Answer the module name to use for this library"
 Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll'].
 Smalltalk platformName = 'unix' ifTrue:[
    "check various locations and versions"
    #('/usr/lib/libMyLibrary.so'
      '/usr/lib/libMyLibrary.so.1'
      '/usr/lib/libMyLibrary.so.2'
      '/usr/share/libMyLibrary.so.1'
      '/usr/share/libMyLibrary.so.2'
) do:[:location|
         (FileDirectory fileExists: location) ifTrue:[^location].
    ].
    ^self error:'MyLibrary is not installed'
  ].


Tx

On Jan 8, 2012, at 9:18 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> Absent the NB experience, +1 to the comments below.  FFI has pretty much "just worked" for me.  We need double arrays.  Callbacks would be great.  One thing I strongly recommend is to favor #moduleName over pragmas listing the library - imagine changing 2000+ GSL calls if the library name changes =:0  It makes a LOT more sense to have a class per library, and that class knows the name to use.  That's all the more true when one considers code such as ODBC that can run on multiple platforms with different names.  #moduleName can test the OS and answer the correct name.
>
> Bill
>
>
> ________________________________________
> From: pharo-project-bounces at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr> [pharo-project-bounces at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr>] on behalf of Stéphane Ducasse [stephane.ducasse at inria.fr<mailto:stephane.ducasse at inria.fr>]
> Sent: Sunday, January 08, 2012 2:16 PM
> To: Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>
> Subject: Re: [Pharo-project] Best way for FFI in Pharo
>
> thanks for the feedback.
> We will come back you soon :)
> Because we should get FFI and NativeBoost fully working :).
>
> Stef
>
> On Jan 8, 2012, at 7:29 PM, ncalexan wrote:
>
>>
>> fstephany wrote
>>>
>>> I'm also a bit lost between all the different options (plugins,
>>> NativeBoost, FFI, Alien).
>>>
>>
>> I also found this confusing, so let me tell my recent experience and my
>> conclusion.
>>
>> I have written bindings to the SDL game programming library for use with
>> Pharo.  SDL is cross-platform, and I want to support Mac (most of all),
>> Windows (one must), and Linux (if I must).  As far as I can tell, Alien is
>> not cross-platform and not maintained, so I have not spent time
>> investigating it.
>>
>> Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package
>> which parses the relevant C header files and then writes either an NB or FFI
>> callout class tree.  I need to define a few structures, make a class pool
>> with some constants, and then define lots of callouts, many of which take
>> references to structures (like 'foo(struct x*)').
>>
>> I was able to make both work, more or less, on my Macbook Pro, using stock
>> Pharo 1.3 images and Igor's NBCog.app.
>>
>> I found NB to be a nicer programmer experience but I found that the FFI just
>> works.  There are a lot of gratuitous differences, but:
>>
>> * NB requires a VM compiled with a separate plugin (that I built from source
>> with no trouble -- Igor has done splendid work with CMakeVMMaker).
>> * NB should be faster than the FFI at pretty much everything, but I can't
>> say since I haven't measured.
>> * NB has useful primitives for determining if your external objects are
>> still valid and for determining the current operating system (I intend to
>> use these even if I don't use NB).
>> * NB has very few tests and examples and essentially no documentation.
>> * NB has a simple conceptual model, but it is still not as simple as the FFI
>> model.
>> * NB uses variableByteClasses to great advantage -- this is very cool.
>>
>> * NB makes it easy to crash your image, since you are evaluating native code
>> in image.
>> * NB is still, to my eye, raw and untested on Mac.  I had problems with
>> stack alignments in bizarre places, and NB's interaction with garbage
>> collection basically ended my attempts to use it.
>> * NB is basically impossible to debug if you aren't very strong with x86
>> assembly (I'm not even strong with x86 assembly), and the stack
>> manipulations rendered GDB pretty much useless for me.
>> * NB does not integrate well with the Pharo tools -- I think the
>> MethodTrailers are screwing up references, implementors, and source views,
>> but I haven't investigated.
>> * NB does not seem to support indirections very easily -- I struggled to
>> understand how to interface to foreign C functions with specs like
>> 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually
>> gave up.
>>
>> I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings
>> crash horribly for me, and although I was able to fix them, it I just don't
>> hack enough x86 assembly to figure out all the tricks Igor is doing.  The
>> thought of making it all work on 3 platforms, and fix all the tool
>> integration, was just too much for me.
>>
>> In conclusion, I prefer the FFI.  It is old, cross platform, well tested,
>> somewhat documented, and reliable.  I think Igor has done some amazing work
>> and I do not want to bash his project (and certainly not his code -- the
>> man's a magician) but the fancy features are not necessary for my project.
>>
>>
>> fstephany wrote
>>>
>>> Will this interface handle callbacks ?
>>>
>>
>> I do not need callbacks so cannot speak to this issue.
>>
>> Yours,
>> Nick Alexander
>>
>> --
>> View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>
>
>





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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120108/fdc8fb84/attachment.htm>


More information about the Pharo-project mailing list