> On 25 Nov 2014, at 14:06, Torsten Bergmann <[email protected]> wrote: > > Please enlighten me as well. I also do not yet understand the idea of this > unification layer. > > So far we have > 1. FFI -> not maintained very well, no callbacks that’s quitte not true anymore. Eliot has revived this old FFI and added the callback support ported from Alien. this is not yet ported to Pharo, so we are restrained to use Alien.
> 2. Alien -> should provide the callbacks, hard to find a predefined > package/VM combination since Eliot merge with FFI, Alien is considered “in maintenance mode”, but since it uses same primitives than regular FFI… is just about the image implementation. > 3. NativeBoost was supposed to be the better one, was based on AsmJit and > replace 1. and 2. yes… but callbacks are better supported in FFI plugin, I’m afraid. > > According to my knowledge it was the goal to continue with NB, integrate it > (which is done) > and move it forward as the single solution for external calls and callbacks. > > So why do we need another layer (and mixed approach with still old FFI) > instead of working > on bringing NB to the other platforms as well and work on a good NativeBoost. > Wasn't there > already work for AsmJit for ARM? NativeBoost will never with with iOS and some other vendors are going in the “close” direction with security reasons/arguments. Also, now we will have pinned objects and a whole new infrastructure to make fast FFI (lua speeds, they say :P) so we will still need to adapt… better to have a common interface because we cannot be sure how will be the FFI of the future :( Esteban > > Thx > T. > >> Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr >> Von: "Markus Fritsche" <[email protected]> >> An: "Pharo Development List" <[email protected]> >> Betreff: Re: [Pharo-dev] NativeBoost >> >> On 2014-11-24 23:34, Esteban Lorenzano wrote: >> >>> now, since the most common use of NB is for FFI, and NB is not present >>> in all platforms, we are working (Ronie, in this case) in a “unified >>> FFI”, which will provide a common abstraction layer for several FFI >>> frameworks (NB, OldFFI, Alien…). With that, we can choose which one >>> of the frameworks we use depending on the situation (but ideally, we >>> will maintain just one, the one that fits better in Pharo). >> >> I feel that providing a common abstraction layer on top of the various >> approaches to interface to C/ C++ libraries won't be useful and should >> be considered a waste of resources. From what I understood from the >> documentation, NativeBoost seems to be the most complete interface >> technology yet. I would rather (as in: If I was capable) try to get >> NativeBoost into Squeak and add the functionality missing that still >> justifies the existence of FFI and Alien than creating an abstraction >> layer that can't cope with the differences in the tools (which was the >> reason for their first creation despite the available ones). >> >> I tried to play around with FFI and creating plugins in Squeak and >> failed (I didn't try very hard though). NativeBoost was the first thing >> I was able to wrap a DLL myself and understand how to do it. The only >> thing that I wasn't able to wrap my mind around was finalization, but >> that is also due to the fact that I couldn't find understandable (read: >> understandable to me) documentation about the underlying concept in >> Pharo. >> >> (OT: Finalization and concurrency probably is more about the concept >> rather than the implementation in Pharo?) >> >> This is a piece of opinion. We all know, that unfortunately, one doesn't >> have to have knowledge to have an opinion, so if my opinion is wrong due >> to lack of knowledge, please ignore it. >> >> Best regards, >> Markus >> >> >> >
