I will rename FFI-NB to UnifiedFFI
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
In order of preference: 1. UnifiedFFI 2. FFI-Unified (suggests that there may be multiple FFI implementations) 3. UFFI (not clear to me that this is an FFI) Cheers, Max
On 12 Jan 2016, at 16:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
UniFFIed ? On 12 January 2016 at 17:40, Max Leske <maxleske@gmail.com> wrote:
In order of preference:
1. UnifiedFFI 2. FFI-Unified (suggests that there may be multiple FFI implementations) 3. UFFI (not clear to me that this is an FFI)
Cheers, Max
On 12 Jan 2016, at 16:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Hi UFFI reminds me UFO which can be translated like Unified Foreign Objects. And it has some relation to Alien name. But maybe it is too much funny name 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm@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
2016-01-12 17:58 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
UFFI reminds me UFO which can be translated like Unified Foreign Objects. And it has some relation to Alien name.
And objects outside image look really like unidentified flying objects. It's just address, blob of bytes and they fly outside smalltalk world
2016-01-12 18:08 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
2016-01-12 17:58 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
UFFI reminds me UFO which can be translated like Unified Foreign Objects. And it has some relation to Alien name.
And objects outside image look really like unidentified flying objects. It's just address, blob of bytes and they fly outside smalltalk world
:) Let's go outside and watch in the starry night UFFI objects ! Thierry
Le 12/1/16 17:58, Denis Kudriashov a écrit :
Hi
UFFI reminds me UFO which can be translated like Unified Foreign Objects. And it has some relation to Alien name. But maybe it is too much funny name
Quite cool :) Stef
2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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
Ah I forgot the name UFFI is also used by the Common Lisp http://www.cliki.net/UFFI On Tue, Jan 12, 2016 at 9:50 PM stepharo <stepharo@free.fr> 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 it has some relation to Alien name. But maybe it is too much funny name
Quite cool :)
Stef
2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm@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
2016-01-12 16:49 GMT-03:00 stepharo <stepharo@free.fr>:
Le 12/1/16 17:58, Denis Kudriashov a écrit :
Hi
UFFI reminds me UFO which can be translated like Unified Foreign Objects. And it has some relation to Alien name. But maybe it is too much funny name
Quite cool :)
+1 UFFI is concise too. Esteban A. Maringolo
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. 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?
2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm@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
On 13 Jan 2016, at 03:46, Ben Coman <btc@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@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
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 <estebanlm@gmail.com> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@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@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
On 13 Jan 2016, at 11:32, Esteban Lorenzano <estebanlm@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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com <mailto:btc@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@gmail.com <mailto:estebanlm@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
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 <maxleske@gmail.com> wrote:
On 13 Jan 2016, at 11:32, Esteban Lorenzano <estebanlm@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 <estebanlm@gmail.com> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com <btc@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@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
On 13 Jan 2016, at 12:56, Max Leske <maxleske@gmail.com> wrote:
On 13 Jan 2016, at 11:32, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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.
no, it will answer a string or a children of FFILibrary (for instance LibC), thatâs how we deal with different platforms (like libc.so.6, libc.dylib, etc.) Originally it was like you said, but it changed⦠I just forget to refactor it. Esteban
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@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com <mailto:btc@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@gmail.com <mailto:estebanlm@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
(cross-posted from pharo-dev) On Wed, Jan 13, 2016 at 6:32 PM, Esteban Lorenzano <estebanlm@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@gmail.com> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@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@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
If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example). Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Wednesday, January 13, 2016 11:33 AM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI 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 <estebanlm@gmail.com<mailto:estebanlm@gmail.com>> wrote: On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com<mailto:btc@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@gmail.com<mailto:estebanlm@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
Namespaces â please. Best, Christian Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Henrik Nergaard Gesendet: Mittwoch, 13. Januar 2016 14:24 An: Pharo Development List <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example). Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Wednesday, January 13, 2016 11:33 AM To: Pharo Development List <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI 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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > wrote: On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com <mailto:btc@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@gmail.com <mailto:estebanlm@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
another discussion, for another thread :)
On 13 Jan 2016, at 14:35, Christian Haider <Christian.Haider@smalltalked-visuals.com> wrote:
Namespaces â please.
Best, Christian
Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Henrik Nergaard Gesendet: Mittwoch, 13. Januar 2016 14:24 An: Pharo Development List <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI
If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example).
Best regards, Henrik
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] On Behalf Of Esteban Lorenzano Sent: Wednesday, January 13, 2016 11:33 AM To: Pharo Development List <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI
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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com <mailto:btc@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@gmail.com <mailto:estebanlm@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
not really, underscores are too âanti-Smalltalkâ.
On 13 Jan 2016, at 14:23, Henrik Nergaard <henrik.nergaard@uia.no> wrote:
If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example).
Best regards, Henrik
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Wednesday, January 13, 2016 11:33 AM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI
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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 13 Jan 2016, at 03:46, Ben Coman <btc@openInWorld.com <mailto:btc@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@gmail.com <mailto:estebanlm@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
<example.PNG>
Esteban Lorenzano wrote:
People has pointed (and they are right) that the name of the new FFI front-end is misleading.
"People" means more than just a single person (me). Glad that I'm not the only one who lamented ;)
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?
+1 Given that we already have abbreviations in "NB" and "FFI" it's not a problem to go for "UFFI". But "UnifiedFFI" would be fine as well. Damien Pollet
UniFFIed ?
Would be funny, but given that some people already have a problem with "SmallTalk" vs. "Smalltalk" I would not use it. Thanks T. << THE HARDEST PART IN PROGRAMMING IS FINDING PROPER NAMES >>
Why not "Pharo FFI" ? since it will be the official FFI of Pharo. I also like like lighthouse references like "LightSpeed" , "LightForce" , "LightWave" , "Lighting", "LightHouse" etc. On Tue, Jan 12, 2016 at 5:57 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
participants (12)
-
Ben Coman -
Christian Haider -
Damien Pollet -
Denis Kudriashov -
Dimitris Chloupis -
Esteban A. Maringolo -
Esteban Lorenzano -
Henrik Nergaard -
Max Leske -
stepharo -
Thierry Goubier -
Torsten Bergmann