Thanks for the comments. There are many things missing in the book yet, because we still don't have so many usage examples. We are trying to incorporate them as we get more usage experience. With the cairo wrapper and igor's help I got some experience, so I tried to put the learnt lessons in the book. If you find some example you would like to have, or some thing missing, just tell and we'll try to add it. Of course this is a work in progress, but igor's work on nativeboost is very complete.
One last thing, as Igor told me one time, many people think that FFI is like rocket science, but that's not the case. I encourage people to try and start with it, because it's really easy and we are here to help. The base of the cairo wrapper took 1 afternoon, and the same happened with the X lib wrapper. Cheers, Javier On Wed, Nov 30, 2011 at 11:18 PM, Schwab,Wilhelm K <[email protected]>wrote: > Stef, Sig, > > Thanks for the preview! > > One thing that jumped out at me so far is the passing of strings by copy. > Interestingly, I can't find an example (in my code where I would have > sworn I had a few) of having an external library fill a string, but I know > I have encountered it and wonder if/how Spock would handle it. This > reminds me of Dolphin's default "pass by reference" (albeit in reverse) for > external byte objects. > > In short, the Dolphin vm automatically passes the address of certain > objects, and it often does what one wants. It also makes some things > difficult to do. For example, one time I had to pass a COM interface > pointer from one component to another, and to do it in Dolphin, I had to > construct an intermediate byte object to hold the pointer, just so the vm > would have a gratuitous level of indirection to remove in making the call. > In fairness, I encountered very few such examples, but OA did ultimately > express some regret over the decision. FWIW. > > A comment in the document asks about the available types, citing float, > double and boolean. All good examples. We also need a full range of > integer sizes (8, 16, 32, 64 bytes), signed and unsigned, and in array > form. We need Float and double arrays too. Floats are sometimes used to > save space (especially in multi-dimensional settings), and some researchers > might care to use floats and doubles separately to look at roundoff error > in computations. The real reason to have floats and doubles is that there > are libraries that use both types. > > Another type that crops up is long double. So far, I can't say they have > been critical to my work, but I have had to hack around appearances of them. > > The chapter shows the use of <primitive:module:> and states that it avoids > the need to create instances. Very true, but I pose the question of > whether we should encourage formal library (handle body) instances? The > idea is that it provides some hope of being able to unload a library while > the image is running. Whether that has any teeth is open for debate (I > recall having trouble getting libraries to actually unload on a certain OS > that will remain nameless<g>). In fairness to that OS, I do not recall the > circumstances, but it sure seemed like yet another weirdness. > > Another advantage of placing the library name in one method is that it can > be edited in one place. GSL has *thousands* of functions and hence > thousands of wrapper methods. Tweaking every one would be ugly. Worse, > ODBC goes by different names on Windows and Linux, and I doubt it is alone. > There is a real role for #moduleName to test the OS and answer the > appropriate string - something that can't be done with <primitive:module:>. > > Dolphin uses a class per library and a singleton instance of each; it > "felt right," and Pharo's FFI will work that way. I subclass > ExternalLibrary and do not specify a module name for each function call. > Bottom line, if you get callbacks working, I'll play along regardless of > small details :) > > > Bill > > > ________________________________________ > From: [email protected] [ > [email protected]] on behalf of Stéphane > Ducasse [[email protected]] > Sent: Wednesday, November 30, 2011 2:00 PM > To: [email protected] > Subject: Re: [Pharo-project] VM page in pharo book is outdated > > everything is public no secret > > https://gforge.inria.fr/scm/viewvc.php/?root=pharobooks > > just a lot of work …. and pain with english > > Stef > > > > On Nov 30, 2011, at 7:19 PM, Igor Stasenko wrote: > > > On 30 November 2011 18:56, Schwab,Wilhelm K <[email protected]> > wrote: > >> Stef, > >> > >> Apologies if I am exploiting something you meant to send privately, but > "draft of a chapter" on FFI?????!!!!!! :) :) :) > >> > >> I'm no expert, but I certainly like to see what is being written. It > is difficult to imagine how I could fail to learn something from it. > >> > > hmm, i seen a draft in my mailbox, but i cannot remember if i received > > privately or from public mailing list. > > > > And of course, there is no reason to keep it private: i think the more > > reviewers/readers it has, the better it will be. > > > >> Bill > >> > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- Lic. Javier Pimás Ciudad de Buenos Aires
