both are integrated into the image. while NB has been maintained directly, athens should still be loadable (if not the case… we have a problem for the future :P). yes, we are slowly moving in the opposite direction of “all maintained in the image”, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. now, about NB, we do not have special plans. it is in the image and it will be maintained as part of Pharo. now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). Again… this are just ideas for the future :) Esteban

On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess@web.de> wrote:

2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>>: Hi,

were is NB currently maintained? Only within the image as it is integrated or still with an external config and on STHub?

The reason why I ask: when I load the latest NB-Core package from STHub it looks like this one is outdated and back from Pharo3 day (trying to load it gives problems from changes in Pharo 4).

So it looks like NB was originally developed external using STHub, then integrated into standard image and now it is only internally in-image managed. OK.

But the future goal is as far as I understood to manage more and more packages using external configs again.

What is the status and future plan for NB? Will the repo get synchronized? Or will it stay internal only?

Thx T.

I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge. I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what is the plan for the feauture, manage packages for Athens and NB in the image or on sthub.

Le 25/11/14 00:48, Ben Coman a écrit :

Esteban Lorenzano wrote:

...

both are integrated into the image. while NB has been maintained directly, athens should still be loadable (if not the case… we have a problem for the future :P).

yes, we are slowly moving in the opposite direction of “all maintained in the image”, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. now, about NB, we do not have special plans. it is in the image and it will be maintained as part of Pharo.

Maybe a package can be uploaded indicating ".movedIntoPharoImage" or similar ?

...

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). Again… this are just ideas for the future :)

Esteban

I see in [vm-dev] a question about FFI callbacks fro SqueakJS. Will Javascript be able to work with unifiedFFI ?

First we need a good FFI for C and then we will see. Let us not over constraints the solution we want.

cheers -ben

...

...

On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:

2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>>:

Hi,

were is NB currently maintained? Only within the image as it is integrated or still with an external config and on STHub?

The reason why I ask: when I load the latest NB-Core package from STHub it looks like this one is outdated and back from Pharo3 day (trying to load it gives problems from changes in Pharo 4).

So it looks like NB was originally developed external using STHub, then integrated into standard image and now it is only internally in-image managed. OK.

But the future goal is as far as I understood to manage more and more packages using external configs again.

What is the status and future plan for NB? Will the repo get synchronized? Or will it stay internal only?

Thx T.

I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge. I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what is the plan for the feauture, manage packages for Athens and NB in the image or on sthub.

On 25 Nov 2014, at 08:31, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 25 Nov 2014, at 00:48, Ben Coman <btc@openInWorld.com> wrote:

Esteban Lorenzano wrote:

...

both are integrated into the image. while NB has been maintained directly, athens should still be loadable (if not the case… we have a problem for the future :P). yes, we are slowly moving in the opposite direction of “all maintained in the image”, and eventually we plan/dream to have a small kernel and a bunch of configurations to produce Pharo. now, about NB, we do not have special plans. it is in the image and it will be maintained as part of Pharo.

Maybe a package can be uploaded indicating ".movedIntoPharoImage" or similar ?

...

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo). Again… this are just ideas for the future :) Esteban

I see in [vm-dev] a question about FFI callbacks fro SqueakJS. Will Javascript be able to work with unifiedFFI ?

I don’t think so. Also, we are not planning to run pharo over JS right now, there are a lot of things to solve before, like: no matters if VM works, none of the plugins (including FFI) will work, so they need to be rewritten, etc., etc., etc.

also, I have to say that SqueakJS is for now not more than a cool experiment. eToys guys are working on it because they have a valid use case: they want to run eToys in the browser. But: - our VM will always be a lot more efficient than some translation to javascript, then run using V8. - web applications are far more complicated than running a boxed-app inside a browser, as applets debacle shows. cheers, Esteban

...

cheers -ben

...

...

On 24 Nov 2014, at 23:23, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:

2014-11-24 20:41 GMT+01:00 Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>>:

Hi,

were is NB currently maintained? Only within the image as it is integrated or still with an external config and on STHub?

The reason why I ask: when I load the latest NB-Core package from STHub it looks like this one is outdated and back from Pharo3 day (trying to load it gives problems from changes in Pharo 4).

So it looks like NB was originally developed external using STHub, then integrated into standard image and now it is only internally in-image managed. OK.

But the future goal is as far as I understood to manage more and more packages using external configs again.

What is the status and future plan for NB? Will the repo get synchronized? Or will it stay internal only?

Thx T.

I was about to ask the same question for Athens, the packages in pharo4 and sthub diverge. I can merge the sthub and pharo4 version for Athens (and mabe NB), I just don't know what is the plan for the feauture, manage packages for Athens and NB in the image or on sthub.

Please enlighten me as well. I also do not yet understand the idea of this unification layer. So far we have 1. FFI -> not maintained very well, no callbacks 2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination 3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2. According to my knowledge it was the goal to continue with NB, integrate it (which is done) and move it forward as the single solution for external calls and callbacks. So why do we need another layer (and mixed approach with still old FFI) instead of working on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there already work for AsmJit for ARM? Thx T.

Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr Von: "Markus Fritsche" <mfritsche@reauktion.de> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] NativeBoost

On 2014-11-24 23:34, Esteban Lorenzano wrote:

...

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo).

I feel that providing a common abstraction layer on top of the various approaches to interface to C/ C++ libraries won't be useful and should be considered a waste of resources. From what I understood from the documentation, NativeBoost seems to be the most complete interface technology yet. I would rather (as in: If I was capable) try to get NativeBoost into Squeak and add the functionality missing that still justifies the existence of FFI and Alien than creating an abstraction layer that can't cope with the differences in the tools (which was the reason for their first creation despite the available ones).

I tried to play around with FFI and creating plugins in Squeak and failed (I didn't try very hard though). NativeBoost was the first thing I was able to wrap a DLL myself and understand how to do it. The only thing that I wasn't able to wrap my mind around was finalization, but that is also due to the fact that I couldn't find understandable (read: understandable to me) documentation about the underlying concept in Pharo.

(OT: Finalization and concurrency probably is more about the concept rather than the implementation in Pharo?)

This is a piece of opinion. We all know, that unfortunately, one doesn't have to have knowledge to have an opinion, so if my opinion is wrong due to lack of knowledge, please ignore it.

Best regards, Markus

ah, and yes. this is a mess. quitte the oposite to out “ideal situation” Esteban

On 25 Nov 2014, at 14:44, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 25 Nov 2014, at 14:06, Torsten Bergmann <astares@gmx.de> wrote:

Please enlighten me as well. I also do not yet understand the idea of this unification layer.

So far we have 1. FFI -> not maintained very well, no callbacks that’s quitte not true anymore. Eliot has revived this old FFI and added the callback support ported from Alien. this is not yet ported to Pharo, so we are restrained to use Alien.

...

2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination since Eliot merge with FFI, Alien is considered “in maintenance mode”, but since it uses same primitives than regular FFI… is just about the image implementation.

...

3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2. yes… but callbacks are better supported in FFI plugin, I’m afraid.

...

According to my knowledge it was the goal to continue with NB, integrate it (which is done) and move it forward as the single solution for external calls and callbacks.

So why do we need another layer (and mixed approach with still old FFI) instead of working on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there already work for AsmJit for ARM?

NativeBoost will never with with iOS and some other vendors are going in the “close” direction with security reasons/arguments.

Also, now we will have pinned objects and a whole new infrastructure to make fast FFI (lua speeds, they say :P) so we will still need to adapt… better to have a common interface because we cannot be sure how will be the FFI of the future :(

Esteban

...

Thx T.

...

Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr Von: "Markus Fritsche" <mfritsche@reauktion.de> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] NativeBoost

On 2014-11-24 23:34, Esteban Lorenzano wrote:

...

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo).

I feel that providing a common abstraction layer on top of the various approaches to interface to C/ C++ libraries won't be useful and should be considered a waste of resources. From what I understood from the documentation, NativeBoost seems to be the most complete interface technology yet. I would rather (as in: If I was capable) try to get NativeBoost into Squeak and add the functionality missing that still justifies the existence of FFI and Alien than creating an abstraction layer that can't cope with the differences in the tools (which was the reason for their first creation despite the available ones).

I tried to play around with FFI and creating plugins in Squeak and failed (I didn't try very hard though). NativeBoost was the first thing I was able to wrap a DLL myself and understand how to do it. The only thing that I wasn't able to wrap my mind around was finalization, but that is also due to the fact that I couldn't find understandable (read: understandable to me) documentation about the underlying concept in Pharo.

(OT: Finalization and concurrency probably is more about the concept rather than the implementation in Pharo?)

This is a piece of opinion. We all know, that unfortunately, one doesn't have to have knowledge to have an opinion, so if my opinion is wrong due to lack of knowledge, please ignore it.

Best regards, Markus

On 2014-11-25 19:37, Eliot Miranda wrote:

I am frustrated that there is no coherence in our work here. I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD

Hello Eliot, my first action if I look into something is to google and open tabs for the first three links that are not a mailing list (the latter I open when I search for a fix) - so maybe http://wiki.squeak.org/squeak/1414 should be updated with links to your blog posts/ mailing list entries. Also, the links for "FFI call DLL functions squeak" (which I would look for if I'm wrapping some C API dll) seem to be mostly outdated/ old. The FUD you criticize seems to be more recent. As I do not understand the low level stuff of callout mechanisms (I can read an API and wrap calls to it and unwrap results though) I have to rely on what I find from an API user perspective, and I tend to think that information that has a more recent date on google is the "latest truth". Kind regards, Mar"smart aleck"kus

On 25 Nov 2014, at 20:27, Markus Fritsche <mfritsche@reauktion.de> wrote:

On Tue, Nov 25, 2014 at 5:06 AM, Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>> wrote: Please enlighten me as well. I also do not yet understand the idea of this unification layer.

"Unification layer" is just a name. IMO Ronie is doing something much more useful. He is architecting the marshalling layer of the FFI so that it can - be portable - work in both the Cog JIT and the Interpreter This is effectively an abstract instruction set for executing low-level machine intsructions. It can be used for FFI call-out marshalling, but it can also be used for low-level code generation, and we are using it in Sista. COnsequently Ronie's "Low code" as it is properly called can be an integral component to both a high-quality FFI and a fast VM.

For me this is a useful substrate for an FFI that can be high quality. But note that it is only one component. The other components are - an image-level ABI compiler whose job it is to generate the correct marshalling code for different platforms. The FFI for processors such as IA64/x86-64 is complex, and a compiler is the only performant way to generate correct marshalling code - callback machinery. I have already designed and implemented this in the context of Alien. The architecture is portable; it can function correctly on x86-64 and ARM, not just x86.

So far we have 1. FFI -> not maintained very well, no callbacks

This is simply false. The FFI was in active use at Qwaq where Cog was first implemented. I have continued to maintain and enhance it, reimplementing it so that it is a pure Smalltalk plugin with no assembler support code, so that it is reentrant. Recently Doug McPherson has implemented the ARM version alongside my original x86 version.

yep, I’m aware and I was trying to have time to bring those changes into Pharo. Hopefully soon.

2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination

Every Cog VM supports Alien callbacks. The Alien package Alien-eem.24 at http://www.squeaksource.com/Alien <http://www.squeaksource.com/Alien> "jsut works", at least in Squeak. Try it.

it works. We have ConfigurationOfOldAlien that loads all required (Is a bad name I choose because there was your sources and a fork from Luc and there were not in sync, so I took your sources and made a Configuration for them :P)

3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2.

I disagree. NativeBoost has not been designed with portability in mind, nor has it been designed with interpretive VMs in mind. Further Igor made no attempt to work with me in providing the support he needs from Cog to integrate NativeBoost when I visited Rmod early this year.

According to my knowledge it was the goal to continue with NB, integrate it (which is done) and move it forward as the single solution for external calls and callbacks.

So why do we need another layer (and mixed approach with still old FFI) instead of working on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there already work for AsmJit for ARM?

We have a functional FFI at the moment, FFI + Alien for callbacks. This is in industrial use, both at Terf (nee Qwaq) and Cadence. We have NativeBoost that does not work on ARM. We have Ronie's work on low code that fits both with a well-architected FFI and with Sista.

I am frustrated that there is no coherence in our work here. I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD ("Alien doesn't work", "FFI doesn't work", "Alien callbacks don't work"; all false). I wish this wasn't the case. I do not have time right now to work on all of Spur, Spur 64, Sista and find time to architect the FFI. But I know how this stuff works (I've implemented what works now) and as the leads VM architect isn't it right that the community try and work with me rather than without me?

Honestly, I’m quite frustrated too. And I cannot agree with you more. But hopefully we will start to work on this problem and remove all discordances soon (I know in all other VM aspects we already did it and now we work aligned, so we can do this for FFI too… in fact last month I wanted to work on it but then other work became more urgent). Esteban

Thx T.

...

Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr Von: "Markus Fritsche" <mfritsche@reauktion.de <mailto:mfritsche@reauktion.de>> An: "Pharo Development List" <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> Betreff: Re: [Pharo-dev] NativeBoost

On 2014-11-24 23:34, Esteban Lorenzano wrote:

...

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo).

I feel that providing a common abstraction layer on top of the various approaches to interface to C/ C++ libraries won't be useful and should be considered a waste of resources. From what I understood from the documentation, NativeBoost seems to be the most complete interface technology yet. I would rather (as in: If I was capable) try to get NativeBoost into Squeak and add the functionality missing that still justifies the existence of FFI and Alien than creating an abstraction layer that can't cope with the differences in the tools (which was the reason for their first creation despite the available ones).

I tried to play around with FFI and creating plugins in Squeak and failed (I didn't try very hard though). NativeBoost was the first thing I was able to wrap a DLL myself and understand how to do it. The only thing that I wasn't able to wrap my mind around was finalization, but that is also due to the fact that I couldn't find understandable (read: understandable to me) documentation about the underlying concept in Pharo.

(OT: Finalization and concurrency probably is more about the concept rather than the implementation in Pharo?)

This is a piece of opinion. We all know, that unfortunately, one doesn't have to have knowledge to have an opinion, so if my opinion is wrong due to lack of knowledge, please ignore it.

Best regards, Markus

-- best, Eliot

Hi Eliot,   first: my post and the three given points were not intended to bash your work or what others have done. I know about the hard work on your and others side to improve the situation. I do not doubt that FFI or Alien is stable or used in (Squeak) commercial applications. Note that my post was written on the pharo-dev list so within the context of Pharo. Not Squeak or others. So I can only tell from the point of view of someone who is from time to time in need in accessing/interfacing with "the outside world".   Let me explain where I got my impressions from: after the last work on FFI package in 2011 by you, Andreas (R.I.P.) and Matthew for Squeak I commited some changes in 2012 to get FFI running in Pharo again. After that there was no activity on the project, at least not in its repo. Still there was and is a config to load FFI into Pharo 3.0. This is accessible from config browser and so far I have only seen that ODBC package is using it. To my knowledge there is no config for Alien in the config browser. So while Alien may work in Squeak there is no out of the box experience in Pharo so far. It was hard to find a VM/image/plugin combination. Others like Joachim Geidel with JNIPort had similar problems (see [1]) and switched over to Native Boost. So "not maintained very well" is IMHO true within the Pharo context until this situation is improved here and I would welcome any effort on this.

From "end user experience" NB is currently more accessible (as it was integrated) and documented also in books so I guess that is the reason that it was and is used more. Some Pharo projects switched over to NB or initially started with it: there is a NB version of DBXTalk, Athens, NBSQLite3, WHTML2PDF, NBOpenGL, LibGit, ... to name just a few.

Also if I remember there was the plan to have NB working also on other architectures: beside the regular AsmJit-x86 there is also an AsmJit-ARM package. I guess that mostly the reason for not driving this forward is the same as on the FFI/Alien side: the lack of time and resources. I did not know that FFI was now really revived from your side as part of your Spur efforts. I did not know about ConfigurationOfOldAlien. I also did not know about the unification layer/Uniform Foreign Function Interface (UFFI) project in detail. A portable common FFI layer would be more than welcomed. I'm sure we are all interested in improving the situation, cant tell anything about synchronization/unfication efforts or barriers on each side as I'm only get my impressions from reading on the mailing list. I hope participating people will resynchronize so we can move forward. I now learned that there is some activity again - which is good! Thanks T.   [1] http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2014-March/0110...   Gesendet: Mittwoch, 26. November 2014 um 23:48 Uhr Von: "Eliot Miranda" <eliot.miranda@gmail.com> An: "Squeak Virtual Machine Development Discussion" <vm-dev@lists.squeakfoundation.org> Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] [Vm-dev] Re: NativeBoost Hi Esteban,   On Tue, Nov 25, 2014 at 11:30 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:    On 25 Nov 2014, at 20:27, Markus Fritsche <mfritsche@reauktion.de[mfritsche@reauktion.de]> wrote:    On Tue, Nov 25, 2014 at 5:06 AM, Torsten Bergmann <astares@gmx.de[astares@gmx.de]> wrote:Please enlighten me as well. I also do not yet understand the idea of this unification layer.   "Unification layer" is just a name.  IMO Ronie is doing something much more useful.  He is architecting the marshalling layer of the FFI so that it can  - be portable - work in both the Cog JIT and the Interpreter This is effectively an abstract instruction set for executing low-level machine intsructions.  It can be used for FFI call-out marshalling, but it can also be used for low-level code generation, and we are using it in Sista.  COnsequently Ronie's "Low code" as it is properly called can be an integral component to both a high-quality FFI and a fast VM.   For me this is a useful substrate for an FFI that can be high quality.  But note that it is only one component.  The other components are - an image-level ABI compiler whose job it is to generate the correct marshalling code for different platforms.  The FFI for processors such as IA64/x86-64 is complex, and a compiler is the only performant way to generate correct marshalling code - callback machinery.  I have already designed and implemented this in the context of Alien.  The architecture is portable; it can function correctly on x86-64 and ARM, not just x86.   So far we have  1. FFI   -> not maintained very well, no callbacks   This is simply false.  The FFI was in active use at Qwaq where Cog was first implemented.  I have continued to maintain and enhance it, reimplementing it so that it is a pure Smalltalk plugin with no assembler support code, so that it is reentrant.  Recently Doug McPherson has implemented the ARM version alongside my original x86 version.   yep, I’m aware and I was trying to have time to bring those changes into Pharo. Hopefully soon.      2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination   Every Cog VM supports Alien callbacks.  The Alien package Alien-eem.24 at http://www.squeaksource.com/Alien[http://www.squeaksource.com/Alien] "jsut works", at least in Squeak.  Try it.     it works.  We have ConfigurationOfOldAlien that loads all required (Is a bad name I choose because there was your sources and a fork from Luc and there were not in sync, so I took your sources and made a Configuration for them :P)    3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2.   I disagree.  NativeBoost has not been designed with portability in mind, nor has it been designed with interpretive VMs in mind.  Further Igor made no attempt to work with me in providing the support he needs from Cog to integrate NativeBoost when I visited Rmod early this year.    According to my knowledge it was the goal to continue with NB, integrate it (which is done) and move it forward as the single solution for external calls and callbacks. So why do we need another layer (and mixed approach with still old FFI) instead of working on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there already work for AsmJit for ARM?   We have a functional FFI at the moment, FFI + Alien for callbacks.  This is in industrial use, both at Terf (nee Qwaq) and Cadence.  We have NativeBoost that does not work on ARM.  We have Ronie's work on low code that fits both with a well-architected FFI and with Sista.   I am frustrated that there is no coherence in our work here.  I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD ("Alien doesn't work", "FFI doesn't work", "Alien callbacks don't work"; all false).  I wish this wasn't the case.  I do not have time right now to work on all of Spur, Spur 64, Sista and find time to architect the FFI.  But I know how this stuff works (I've implemented what works now) and as the leads VM architect isn't it right that the community try and work with me rather than without me?   Honestly, I’m quite frustrated too.  And I cannot agree with you more.    thanks, Esteban.  I find this extremely reassuring.   But hopefully we will start to work on this problem and remove all discordances soon (I know in all other VM aspects we already did it and now we work aligned, so we can do this for FFI too… in fact last month I wanted to work on it but then other work became more urgent).    Esteban     Thx T.

Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr Von: "Markus Fritsche" <mfritsche@reauktion.de[mfritsche@reauktion.de]> An: "Pharo Development List" <pharo-dev@lists.pharo.org[pharo-dev@lists.pharo.org]> Betreff: Re: [Pharo-dev] NativeBoost

On 2014-11-24 23:34, Esteban Lorenzano wrote:

...

now, since the most common use of NB is for FFI, and NB is not present in all platforms, we are working (Ronie, in this case) in a “unified FFI”, which will provide a common abstraction layer for several FFI frameworks (NB, OldFFI, Alien…). With that, we can choose which one of the frameworks we use depending on the situation (but ideally, we will maintain just one, the one that fits better in Pharo).

I feel that providing a common abstraction layer on top of the various approaches to interface to C/ C++ libraries won't be useful and should be considered a waste of resources. From what I understood from the documentation, NativeBoost seems to be the most complete interface technology yet. I would rather (as in: If I was capable) try to get NativeBoost into Squeak and add the functionality missing that still justifies the existence of FFI and Alien than creating an abstraction layer that can't cope with the differences in the tools (which was the reason for their first creation despite the available ones).

I tried to play around with FFI and creating plugins in Squeak and failed (I didn't try very hard though). NativeBoost was the first thing I was able to wrap a DLL myself and understand how to do it. The only thing that I wasn't able to wrap my mind around was finalization, but that is also due to the fact that I couldn't find understandable (read: understandable to me) documentation about the underlying concept in Pharo.

(OT: Finalization and concurrency probably is more about the concept rather than the implementation in Pharo?)

This is a piece of opinion. We all know, that unfortunately, one doesn't have to have knowledge to have an opinion, so if my opinion is wrong due to lack of knowledge, please ignore it.

Best regards,     Markus

    --  best, Eliot   -- best, Eliot