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@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of St�phane Ducasse [
stephane.ducasse@inria.fr]
> Sent: Sunday, January 08, 2012 2:16 PM
> To:
Pharo-project@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.
>>
>
>
>