[Pharo-project] Best way for FFI in Pharo

Stéphane Ducasse stephane.ducasse at inria.fr
Sun Jan 8 14:16:35 EST 2012

thanks for the feedback.
We will come back you soon :)
Because we should get FFI and NativeBoost fully working :).


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.

More information about the Pharo-dev mailing list