> > Ronie is working on unifying all the api and proposing one syntax > mechanism for > - nativeBoost back-end > - FFI > and may be Alien
I had a skype session with Eliot the last. He taught me about the callback mechanism and I am actually going to use Alien for the callbacks, by adapting it to perform the marshalling into the UFFI/NativeBoost types. In the future, I am planning in using Lowcode to perform the whole callback process, but now for simplicity I am just going to piggy back in Alien. I still have to finish the callout by fixing a complicated bug. With Eliot we discussed a workaround for this bug. I haven't implemented those workaround yet, because I have been a bit busy with my university studies. As long as we keep what is working, ahem, working. I now depend on quite a > couple of FFI related libs. > > What I need is an easy FFI wrapping tool, like > https://github.com/ronsaldo/swig. Is UFFI going that way? > Well, I made the swig adaptation for NativeBoost. Making it for the UFFI is actually something trivial. So, we are going to have a powerful FFI and a binding generator for it. The only problem with Swig, is that the bindings generated by it are not perfect, because it exposes the exact same C API. A C library that uses some kind of object model, cannot be exposed in a clean object oriented way cleanly by a generic automatic tool. The FFI situation is not good and we know we should improve it. For the record, the current FFI situation can be traced to the historical origins of Smalltalk and even Squeak. The original Smalltalk was an actual operating system, and Squeak was also made as an operating system. Because of this, they were not designed to interact with other languages. Getting a perfect FFI is going to take a lot of time, because of other problems, such as Multi-threading and the mandatory use of non-blocking IO. Fortunately, Eliot made a way to have a threaded FFI, in which a single thread owns the VM at a single time. With this threaded FFI we can have things such as a callback from a different thread, which is required by some libraries such as the sound API of SDL2. Of course the UFFI is going to support this threaded FFI in some point of time. To support the threaded FFI I only have to pin/unpin some object, and call two VM functions, disownVM() and ownVM(). As for getting some actual parallelism in Pharo, this is something that I think is going to take a big amount of time. For now the best thing we can do is to use OpenCL. This week I have been doing some experimenting in making an API for linear algebra, that uses OpenCL to perform computations in parallel. Later I will publish a video. Greetings, Ronie 2014-10-31 19:23 GMT-03:00 Alain Rastoul <alf.mmm....@gmail.com>: > Hi Annick, > > you can't pass smalltalk strings or objects to ffi as parameters, > you have to allocate the buffer member of your structure > on the external heap ( plus to avoid being gc'd before ffi call) > with ExternalAddress allocate: <your buffer/string size +1 for string null > termination> > fill your buffer with byteAt:put: method, > and release this memory with free when you have finished. > > not sure, but you could try something like: > > s := '05:45' copyWith: (Character value: 0). > a := ExternalAddress allocate: s size. > s asByteArray withIndexDo: [ :b :i | a byteAt: i put: b ]. > myStruct time: a. > ... call your ffi ... > a free > > > Regards, > > Alain > > Le 29/10/2014 11:59, Annick Fron a écrit : > > I I have a C struct with a char* >> >> struct result { >> char* time } >> >> I define an ExternalStructure in FFI , with one field of type char* (note >> that the syntax char [5] is not accepted ! ). >> >> defineFields generates the accessors time and time: >> >> If I use >> time: ’05:45’ >> >> I get an error. >> How do I set a string value in an ExternalStructure ? >> >> Annick >> >> >> >> >> >> > > >
