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

[Esteban Lorenzano]

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  wrote:
> 
>> 
>> On 13 Jan 2016, at 03:46, Ben Coman  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 :
 
 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

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

[Esteban Lorenzano]

not really, underscores are too “anti-Smalltalk”.

> On 13 Jan 2016, at 14:23, Henrik Nergaard <henrik.nerga...@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-boun...@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 <esteba...@gmail.com 
> <mailto:esteba...@gmail.com>> wrote:
>  
> 
> On 13 Jan 2016, at 03:46, Ben Coman <b...@openinworld.com 
> <mailto: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 
> <mailto: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
>  
> 

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

[Christian Haider]

Namespaces – please.

 

Best, Christian

 

Von: Pharo-dev [mailto:pharo-dev-boun...@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-boun...@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 <esteba...@gmail.com 
<mailto:esteba...@gmail.com> > wrote:

 


On 13 Jan 2016, at 03:46, Ben Coman <b...@openinworld.com 
<mailto: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 
<mailto: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

 

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

[Max Leske]

> On 13 Jan 2016, at 11:32, Esteban Lorenzano  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 > > wrote:
>> 
>>> 
>>> On 13 Jan 2016, at 03:46, Ben Coman >> > 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 >:
> 
> 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
> 

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

[Dimitris Chloupis]

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  wrote:

> On 13 Jan 2016, at 11:32, Esteban Lorenzano  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  wrote:
>
>
> On 13 Jan 2016, at 03:46, Ben Coman  > 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 :
>
>
> 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
>
>
>

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

[Esteban Lorenzano]

> On 13 Jan 2016, at 12:56, Max Leske  wrote:
> 
> 
>> On 13 Jan 2016, at 11:32, Esteban Lorenzano > > 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 >> > wrote:
>>> 
 
 On 13 Jan 2016, at 03:46, Ben Coman > 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  >:
>> 
>> 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
>> 
> 

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

[Henrik Nergaard]

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-boun...@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 
<esteba...@gmail.com<mailto:esteba...@gmail.com>> wrote:


On 13 Jan 2016, at 03:46, Ben Coman 
<b...@openinworld.com<mailto: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<mailto: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

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

[Esteban Lorenzano]

another discussion, for another thread :)

> On 13 Jan 2016, at 14:35, Christian Haider 
> <christian.hai...@smalltalked-visuals.com> wrote:
> 
> Namespaces – please.
>  
> Best, Christian
>  
> Von: Pharo-dev [mailto:pharo-dev-boun...@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-boun...@lists.pharo.org 
> <mailto:pharo-dev-boun...@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 <esteba...@gmail.com 
>> <mailto:esteba...@gmail.com>> wrote:
>>  
>>> 
>>> On 13 Jan 2016, at 03:46, Ben Coman <b...@openinworld.com 
>>> <mailto: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 
>>>> <mailto: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

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

[Ben Coman]

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

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

[stepharo]

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


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

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

[Damien Pollet]

UniFFIed ?

On 12 January 2016 at 17:40, Max Leske  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  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

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

[Dimitris Chloupis]

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

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

[Esteban A. Maringolo]

2016-01-12 16:49 GMT-03:00 stepharo :

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

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

[Esteban Lorenzano]

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

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

[Max Leske]

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

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

[Denis Kudriashov]

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 :

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

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

[Denis Kudriashov]

2016-01-12 17:58 GMT+01:00 Denis Kudriashov :

> 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

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

[Thierry Goubier]

2016-01-12 18:08 GMT+01:00 Denis Kudriashov :

>
> 2016-01-12 17:58 GMT+01:00 Denis Kudriashov :
>
>> 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