Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

> 3) method renaming, from ffiLibraryName to ffiLibrary (we didn’t talk about
> this, but I’m introducing it because is better name :P)
>
> I *think* #2 can be skipped, but #1 and #3 are a must.
>
> opinions?
>
> Esteban
>
> On 13 Jan 2016, at 11:28, Esteban Lorenzano <[hidden email]> wrote:
>
>
> On 13 Jan 2016, at 03:46, Ben Coman <[hidden email]> wrote:
>
> Le 12/1/16 17:58, Denis Kudriashov a écrit :
>
> Hi
>
> UFFI reminds me UFO which can be translated like Unified Foreign Objects.
> And objects outside image look really like unidentified flying objects. It's
> just address, blob of bytes and they fly outside smalltalk world
> And it has some relation to Alien name.
> But maybe it is too much funny name
>
>
> I guess we are considering...
>
> Prefix: UFO   (shorter)
> Package: Unified Foreign Objects    (longer)
>
> Prefix: UFFI   (longer)
> Package: UnifiedFFI    (shorter)
>
> I like your thinking, but I have mixed feelings.  Name is cool.  The
> shorter prefix may be a benefit (though the "I" doesn't add much).
> But it implies more semantics as an external "object" than external
> blobs of memory (for example) for C libraries.
> I like "Unified" because it brings together parts of several
> implementations (if I understand correctly) and fixes a point of
> divergence at the VM level making it harder for limited resources to
> collaborate there.
> So in the end I think I prefer Unified.
>
>
> yes, I suppose you are right.
> but I was not considering changing prefix from FFI to UFFI, just repackaging
> as UnifiedFFI :P
>
> now… probably I will do it (not many changes to adapt and probably better
> for understanding in the long way).
>
>
> cheers -ben
>
> P.S.  As I understand it, NativeBoost performs a bit better than
> UnifiedFFI, but it hindered cross-architecture compatibility - but
> UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if
> its technically feasible for NativeBoost to become a plug-in backend
> for UnifiedFFI, that could be used is special circumstances that
> super-performance is required only on supported platforms?
>
>
> actually (though I do not test it since a couple of months) it should be
> more or less compatible… it was at the beginning, then I made some changes…
> what is not compatible anymore is the vm who needs to be changed to use
> executable memory.
>
> Also… yes, NativeBoost is faster (callouts, not callbacks) because you
> cannot compete with ASM, but you can compite in activation time and
> optimised code… so who knows, in the future that advantage can not exist
> anymore.
>
> cheers,
> Esteban
>
>
>
>
>
> 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <[hidden email]>:
>
>
> Hi,
>
> People has pointed (and they are right) that the name of the new FFI
> front-end is misleading.
> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for
> short) is a better name… and to keep packages prox. to regular FFI I was
> thinking on rename FFI-NB packages to FFI-Unified… but maybe is better just
> to rename them as UFFI or UnifiedFFI…
> what do you think?
>
> Esteban
>
>