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