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

[Ben Coman]

(cross-posted from pharo-dev)

On Wed, Jan 13, 2016 at 6:32 PM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> So, recapitulation:
>
> I want to introduce:
>
> 1) package renaming, from FFI-NB to UnifiedFFI
> 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they
> will remain ffi* so this is maybe a problem…)

Actually I suggested this without thinking it through.  We should be
consider cross-platform compatibility with Squeak at this low level
close to image interface to the rest of the world, where its probably
harder for average Joe to deal with the differences.  I'm not familiar
enough with either platform's FFI to comment more.
cheers -ben

> 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 <estebanlm at gmail.com> wrote:
>
>
> On 13 Jan 2016, at 03:46, Ben Coman <btc at openInWorld.com> 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 <estebanlm at gmail.com>:
>
>
> 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
>
>