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