Hi Guille, Thanks for your efforts, we really appreciate it!
I was intrigued by Stephan and tried to prepare something for the book, like a subtitle/small chapter "Exotic types", but then I noticed that you already put some additional content to the book on GitHub since the pdf at pharo.org was created last year - the text that cleared some of my challenges. I went through UFFI complexities over and over with the debugger, so I have relatively good picture of what is going on when a call is "converted" to bytecode, however I'm constantly finding new pearls inside. UFFI is really great and heavy package! Anyways, I don't think that I can add anything substantial to the content of the book, however I can help with the feedback and suggestions, I can also test the examples if you need. As for the "missing pieces & understandable", I will fire right away :-) Most of my FFI experiences are coming from fiddling with the "mysterious" Win32WideString implementation or wchar_t*, char16_t*, char32_t* … family of wide strings on Windows. It seems to me that Win32WideString class is only half made, or maybe it was made before UFFI -> I'm just guessing, however it's a subclass of ExternalObject and not the subclass of FFIExternalObject. When you pass it through UFFI as an argument, everything is OK, however when it is returned from a function call it is not automagically treated as a proper Win32WideString - you have to "manually" convert the data at the ExternalAddress. And now my suggestions on the book :-) - I hardly found (on the net, Pharo books ...) any explanation on ExternalObject's handle, which is quite often used in FFIExternalObjects, too; what's the difference between a handle and a pointer, and what exactly the various implementations of #fromHandle: are supposed to do. #fromHandle is now mentioned in the book, based on this discussion <http://forum.world.st/UFFI-correct-way-to-cast-void-td5067008.html> about casting, however if you are dealing with an "exotic type" then it would be nice to have some guidelines about the purpuse of it. To illustrate, in Win32WideString the handle is implemented as a ByteArray with the data itself, in other objects that I know of it's normally an (external) address/pointer, huh? - When the UFFI call ends, and the return argument's value is put onto the stack right after the #send:invokeWithArguments:, what happens with that value - is there anything that can be done with it - can the "casting" be performed "automatically"? Of course one can always prepare a "wrapper" to do that, however … I found FFIExternalType>>#emitReturnArgument:context: where "loader" gets onto the scene, but this leads to heavy lifting with bytecodes, is I understand :-) - In relation to that, there is a bit vague explanation in the book about objects under the title External Objects ("... But often, frameworks will allocate structures, pointers, etc. which actually represents ”an object” (not in the same sense as a Smalltalk object, but can be interpreted like one) ..."). This "interpretation" is a kind of mysterious :-) A couple of suggestions about possible directions would be nice to have. - As far as I can see, the FFIExternalValueHolder is not mentioned in the book yet. It is nicely described in its comment, however the missing information is that the type (the resulting subclass of FFIExternalValueHolder) should be defined as a class variable - without that the signature parser cannot find it. The purpose of FFIExternalValueHolder is similar to FFIExternalType class>>#newBuffer. I hope you find these suggestions helpful. Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
