On Sun, Jan 8, 2012 at 9:25 PM, Stéphane Ducasse <stephane.duca...@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-boun...@lists.gforge.inria.fr [ > pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane > Ducasse [stephane.duca...@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. > >> > > > > > > > > > -- Mariano http://marianopeck.wordpress.com