the ideal for me would be that Library to be an Object and returns its path via SomeFFILibrary path or SomeFFILibrary name , if it uses a environment path
On Wed, Jan 13, 2016 at 1:57 PM Max Leske <maxle...@gmail.com> wrote: > On 13 Jan 2016, at 11:32, Esteban Lorenzano <esteba...@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…) > 3) method renaming, from ffiLibraryName to ffiLibrary (we didn’t talk > about this, but I’m introducing it because is better name :P) > > > But isn’t the answered object a string? Then I would vote for > #ffiLibraryName. Otherwise I’d expect a “Library” object. > > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > > On 13 Jan 2016, at 11:28, Esteban Lorenzano <esteba...@gmail.com> wrote: > > > On 13 Jan 2016, at 03:46, Ben Coman <b...@openinworld.com > <b...@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 <esteba...@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 > > >
