ah, and yes. this is a mess. quitte the oposite to out “ideal situation”
Esteban > On 25 Nov 2014, at 14:44, Esteban Lorenzano <[email protected]> wrote: > > > >> 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 >>> >>> >>> >> >
