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) 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> 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
