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. >
