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 "
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: [email protected] > [[email protected]] on behalf of Stéphane Ducasse > [[email protected]] > Sent: Sunday, January 08, 2012 2:16 PM > To: [email protected] > 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. >> > > >
