Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R. Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich@gmail.com> a écrit :

I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <damien.cassou@inria.fr> wrote:

...

Hi,

did anyone implement a Random Forest algorithm in Pharo?

https://en.wikipedia.org/wiki/Random_forest

-- Damien Cassou http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. Precisely for that is FFI. not that we have to integrate everything into the image :) but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :) Esteban

On 15 Oct 2015, at 09:51, stepharo <stepharo@free.fr> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> a écrit :

...

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>> a écrit : I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou < <mailto:damien.cassou@inria.fr>damien.cassou@inria.fr <mailto:damien.cassou@inria.fr>> wrote:

...

Hi,

did anyone implement a Random Forest algorithm in Pharo?

https://en.wikipedia.org/wiki/Random_forest <https://en.wikipedia.org/wiki/Random_forest>

-- Damien Cassou http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/>

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

I would see the FFI integration being much more approachable. In R, Python, Tcl, and now Java with JNA things are going nicely. Why is it a pain on our platform and why insist on doing all in Pharo? This is holding us back. Pharo is super strong at some things. We just do not need it to be redoing everything when good business is at hand and industry standard libs available. A reason why we try to use libgit2 I guess. Something external. Phil Le 15 oct. 2015 14:29, "philippe.back@highoctane.be" < philippe.back@gmail.com> a écrit :

I guess you aren't doing lots of random forests.

RFs training is the best way to turn my PC into a heater.

Phil

Phil Le 15 oct. 2015 14:19, "Esteban Lorenzano" <estebanlm@gmail.com> a écrit :

...

yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

On 15 Oct 2015, at 09:51, stepharo <stepharo@free.fr> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, philippe.back@highoctane.be a écrit :

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R. Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich@gmail.com> a écrit :

...

I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou < <damien.cassou@inria.fr>damien.cassou@inria.fr> wrote:

...

Hi,

did anyone implement a Random Forest algorithm in Pharo?

https://en.wikipedia.org/wiki/Random_forest

-- Damien Cassou http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do not know how possible, how much effort or likely it is. Sometimes connecting to an external library is a requirement. It would be nice to be able to easily do so. I had problems with NB and it never happened. But, on the other hand. I am a big believer and advocate of keeping as much as possible in Pharo. Even if there are libraries available via FFI. Now I know being practical and expedient sometimes using the libraries is necessary at least initially. I would love as much as possible in Pharo, in our language. This makes it available for us to improve, fix, and learn. It reduces the barrier for entry for those who only know Pharo. We can't do any of those things if it is in a foreign language in a foreign library. Reinventing the wheel so to speak is not always evil. But we do have to know our resources, time, people, community, skills. And as a Smalltalk or Smalltalk inspired tool. We need to have a long view of the world. We already have a longer history than most languages. We should likewise look forward to an even longer future. Always keep the big picture in front of us to inspire through the tedious minutiae that we may currently have to deal with. And by the way. I would love having Random Forests and other scientific, statistic tools in Pharo. I need to look at the SciSmalltalk stuff. Just a few thoughts. Jimmie [1] http://docs.julialang.org/en/release-0.4/manual/calling-c-and-fortran-code [2] http://luajit.org/ext_ffi_tutorial.html On 10/15/2015 07:51 AM, Esteban Lorenzano wrote:

I agree. My point was not a “let do all in pharo”, it was more against assumptions :)

Esteban

...

On 15 Oct 2015, at 14:34, philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> <philippe.back@gmail.com <mailto:philippe.back@gmail.com>> wrote:

I would see the FFI integration being much more approachable.

In R, Python, Tcl, and now Java with JNA things are going nicely.

Why is it a pain on our platform and why insist on doing all in Pharo?

This is holding us back.

Pharo is super strong at some things.

We just do not need it to be redoing everything when good business is at hand and industry standard libs available.

A reason why we try to use libgit2 I guess. Something external.

Phil

Le 15 oct. 2015 14:29, "philippe.back@highoctane.be <mailto:philippe.back@highoctane.be>" <philippe.back@gmail.com <mailto:philippe.back@gmail.com>> a écrit :

I guess you aren't doing lots of random forests.

RFs training is the best way to turn my PC into a heater.

Phil

Phil

Le 15 oct. 2015 14:19, "Esteban Lorenzano" <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> a écrit :

yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

...

On 15 Oct 2015, at 09:51, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> a écrit :

...

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>> a écrit :

I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <damien.cassou@inria.fr <mailto:damien.cassou@inria.fr>> wrote: > Hi, > > did anyone implement a Random Forest algorithm in Pharo? > > https://en.wikipedia.org/wiki/Random_forest > > -- > Damien Cassou > http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/> > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

On 15 Oct 2015, at 15:50, Jimmie Houchin <jlhouchin@gmail.com> wrote:

Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do not know how possible, how much effort or likely it is.

in pharo a FFI call is as easy as: copy: source to: dest <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: ‘libc’. we can improve performance, but I do not think we will succeed on make it easier than that. of course, someone could do a symbol introspector (and I think someone already did something to interpret header files), to be able to have things like: LibC.strcpyWith: dest with: source but I do not thing is a big win over the first one. Esteban

Sometimes connecting to an external library is a requirement. It would be nice to be able to easily do so. I had problems with NB and it never happened.

But, on the other hand. I am a big believer and advocate of keeping as much as possible in Pharo. Even if there are libraries available via FFI. Now I know being practical and expedient sometimes using the libraries is necessary at least initially.

I would love as much as possible in Pharo, in our language. This makes it available for us to improve, fix, and learn. It reduces the barrier for entry for those who only know Pharo. We can't do any of those things if it is in a foreign language in a foreign library. Reinventing the wheel so to speak is not always evil. But we do have to know our resources, time, people, community, skills. And as a Smalltalk or Smalltalk inspired tool. We need to have a long view of the world. We already have a longer history than most languages. We should likewise look forward to an even longer future. Always keep the big picture in front of us to inspire through the tedious minutiae that we may currently have to deal with.

And by the way. I would love having Random Forests and other scientific, statistic tools in Pharo. I need to look at the SciSmalltalk stuff.

Just a few thoughts.

Jimmie

[1] http://docs.julialang.org/en/release-0.4/manual/calling-c-and-fortran-code <http://docs.julialang.org/en/release-0.4/manual/calling-c-and-fortran-code> [2] http://luajit.org/ext_ffi_tutorial.html <http://luajit.org/ext_ffi_tutorial.html>

On 10/15/2015 07:51 AM, Esteban Lorenzano wrote:

...

I agree. My point was not a “let do all in pharo”, it was more against assumptions :)

Esteban

...

On 15 Oct 2015, at 14:34, <mailto:philippe.back@highoctane.be>philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> <philippe.back@gmail.com <mailto:philippe.back@gmail.com>> wrote:

I would see the FFI integration being much more approachable.

In R, Python, Tcl, and now Java with JNA things are going nicely.

Why is it a pain on our platform and why insist on doing all in Pharo?

This is holding us back.

Pharo is super strong at some things.

We just do not need it to be redoing everything when good business is at hand and industry standard libs available.

A reason why we try to use libgit2 I guess. Something external.

Phil

Le 15 oct. 2015 14:29, " <mailto:philippe.back@highoctane.be>philippe.back@highoctane.be <mailto:philippe.back@highoctane.be>" <philippe.back@gmail.com <mailto:philippe.back@gmail.com>> a écrit : I guess you aren't doing lots of random forests.

RFs training is the best way to turn my PC into a heater.

Phil

Phil

Le 15 oct. 2015 14:19, "Esteban Lorenzano" <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> a écrit : yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

...

On 15 Oct 2015, at 09:51, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, <mailto:philippe.back@highoctane.be>philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> a écrit :

...

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" < <mailto:serge.stinckwich@gmail.com>serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>> a écrit : I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou < <mailto:damien.cassou@inria.fr>damien.cassou@inria.fr <mailto:damien.cassou@inria.fr>> wrote:

...

Hi,

did anyone implement a Random Forest algorithm in Pharo?

<https://en.wikipedia.org/wiki/Random_forest>https://en.wikipedia.org/wiki/Random_forest <https://en.wikipedia.org/wiki/Random_forest>

-- Damien Cassou <http://damiencassou.seasidehosting.st/>http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/>

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

On 15 Oct 2015, at 16:51, Jimmie Houchin <jlhouchin@gmail.com> wrote:

Thanks for the example.

On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:

...

...

On 15 Oct 2015, at 15:50, Jimmie Houchin < <mailto:jlhouchin@gmail.com>jlhouchin@gmail.com <mailto:jlhouchin@gmail.com>> wrote:

Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do not know how possible, how much effort or likely it is.

in pharo a FFI call is as easy as:

copy: source to: dest <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: ‘libc’.

we can improve performance, but I do not think we will succeed on make it easier than that.

of course, someone could do a symbol introspector (and I think someone already did something to interpret header files), to be able to have things like:

LibC.strcpyWith: dest with: source

but I do not thing is a big win over the first one.

Esteban

That does not look to difficult.

Now my current problem is that we are being told that NativeBoost is going away. Then what does FFI look like and with what?

NB is going away in spur, BUT NOT his syntax… you still will do FFI calls in the old way. This is going to be 95% compatible (so far, I needed to introduce changes on: structures and callbacks… all the rest is same… and the changes are not really complicated to adapt). Now, is a bit frustrating because I have said this millions of times (at least once for each one I say we are removing NB… and I’m the only one saying it :P) Esteban

The main problem I had with NativeBoost is that it had problems I couldn't understand or fix. And problems that Igor didn't have time for. I was writing a wrapper around a proprietary library. The small part I had written to test out Pharo and NB worked on Windows and crashed in Linux. Exact same code.

This message from April 3, 2013 is my request for help. http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934... <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934...>

I never got anywhere with that project. Thus goes my tortured history with Pharo and programming. Not a judgment against Igor or Pharo. I know the resources of both are stretched to the max. And I am complicit in the problem as I have to few skills to help myself. So it did and sometimes does, send me on programming journeys to explore other languages and tools to empower me within my abilities. I could have done that project in LuaJIT or Julia when it matures a little more. Julia might be approaching that point.

My torture is pursuing the language/environment I enjoy, Pharo. Which sometimes can or sometimes can not easily do what I need within my skill set. Or pursuing learning other languages and tools which are better at integrating other external libraries. Or do to the much larger communities have already ready to use wrappers around most anything you want to do.

I am no longer pursuing that project. My requirements have changed and I do not require wrapping a proprietary C library.

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So at the moment I am studying SQL and then possibly spend some time learning C so that I can better help myself and the community and not be as dependent. That way when the dust settles on the FFI as will be in Pharo5/6. I can hopefully be better to use and contribute.

Thanks.

Jimmie Jimmie

[snip]

On 10/15/2015 10:51 AM, Jimmie Houchin wrote:

Thanks for the example.

On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:

...

...

On 15 Oct 2015, at 15:50, Jimmie Houchin <<mailto:jlhouchin@gmail.com>jlhouchin@gmail.com> wrote:

Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do not know how possible, how much effort or likely it is.

in pharo a FFI call is as easy as:

copy: source to: dest <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: ‘libc’.

we can improve performance, but I do not think we will succeed on make it easier than that.

of course, someone could do a symbol introspector (and I think someone already did something to interpret header files), to be able to have things like:

LibC.strcpyWith: dest with: source

but I do not thing is a big win over the first one.

Esteban

That does not look to difficult.

Now my current problem is that we are being told that NativeBoost is going away. Then what does FFI look like and with what?

The main problem I had with NativeBoost is that it had problems I couldn't understand or fix. And problems that Igor didn't have time for. I was writing a wrapper around a proprietary library. The small part I had written to test out Pharo and NB worked on Windows and crashed in Linux. Exact same code.

This message from April 3, 2013 is my request for help. http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934...

I never got anywhere with that project. Thus goes my tortured history with Pharo and programming. Not a judgment against Igor or Pharo. I know the resources of both are stretched to the max. And I am complicit in the problem as I have to few skills to help myself. So it did and sometimes does, send me on programming journeys to explore other languages and tools to empower me within my abilities. I could have done that project in LuaJIT or Julia when it matures a little more. Julia might be approaching that point.

My torture is pursuing the language/environment I enjoy, Pharo. Which sometimes can or sometimes can not easily do what I need within my skill set. Or pursuing learning other languages and tools which are better at integrating other external libraries. Or do to the much larger communities have already ready to use wrappers around most anything you want to do.

I am no longer pursuing that project. My requirements have changed and I do not require wrapping a proprietary C library.

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So at the moment I am studying SQL and then possibly spend some time learning C so that I can better help myself and the community and not be as dependent. That way when the dust settles on the FFI as will be in Pharo5/6. I can hopefully be better to use and contribute.

Exactly right, I feel the same way. I thank you for expressing yourself thusly and being a mirror in words of my own passion. Best, Robert

Thanks.

Jimmie Jimmie

[snip]

On 10/15/2015 11:46 AM, Esteban Lorenzano wrote:

...

On 15 Oct 2015, at 17:35, Robert Withers <robert.w.withers@gmail.com> wrote:

On 10/15/2015 10:51 AM, Jimmie Houchin wrote:

...

Thanks for the example.

On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:

...

...

On 15 Oct 2015, at 15:50, Jimmie Houchin <<mailto:jlhouchin@gmail.com>jlhouchin@gmail.com> wrote:

Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do not know how possible, how much effort or likely it is.

in pharo a FFI call is as easy as:

copy: source to: dest <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: ‘libc’.

we can improve performance, but I do not think we will succeed on make it easier than that.

of course, someone could do a symbol introspector (and I think someone already did something to interpret header files), to be able to have things like:

LibC.strcpyWith: dest with: source

but I do not thing is a big win over the first one.

Esteban

That does not look to difficult.

Now my current problem is that we are being told that NativeBoost is going away. Then what does FFI look like and with what?

The main problem I had with NativeBoost is that it had problems I couldn't understand or fix. And problems that Igor didn't have time for. I was writing a wrapper around a proprietary library. The small part I had written to test out Pharo and NB worked on Windows and crashed in Linux. Exact same code.

This message from April 3, 2013 is my request for help. http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934...

I never got anywhere with that project. Thus goes my tortured history with Pharo and programming. Not a judgment against Igor or Pharo. I know the resources of both are stretched to the max. And I am complicit in the problem as I have to few skills to help myself. So it did and sometimes does, send me on programming journeys to explore other languages and tools to empower me within my abilities. I could have done that project in LuaJIT or Julia when it matures a little more. Julia might be approaching that point.

My torture is pursuing the language/environment I enjoy, Pharo. Which sometimes can or sometimes can not easily do what I need within my skill set. Or pursuing learning other languages and tools which are better at integrating other external libraries. Or do to the much larger communities have already ready to use wrappers around most anything you want to do.

I am no longer pursuing that project. My requirements have changed and I do not require wrapping a proprietary C library.

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So at the moment I am studying SQL and then possibly spend some time learning C so that I can better help myself and the community and not be as dependent. That way when the dust settles on the FFI as will be in Pharo5/6. I can hopefully be better to use and contribute.

Exactly right, I feel the same way. I thank you for expressing yourself thusly and being a mirror in words of my own passion.

FFI is a complicated issue, and we have made some mistakes. There is no shame on being upset with it… we tried to do something cool and at the end we failed, now we are following a different path (as cool as the other, but different). I hope we will stabilise FFI this version (Pharo 5), but of course, I cannot promise 100% crash-free, specially when what you are doing (call out the vm) escapes to vm control :)

Oh, you're good, but enough blame-shifting, let's fix the real problem. :)

but well… in the mean time we learn and do steps. We will have a cool FFI, don’t worry… sooner than later :D

I was thinking about ASMJIT and it's audience. You may attract a broader audience with JVMJIT, including JNI. That would be something, then support cross-calling between Pharo, Newspeak, Groovy, Scala and Java plus dynamic jar loading. You'd need an army to pull that off though. Robert

Esteban

...

Best, Robert

...

Thanks.

Jimmie Jimmie

[snip]

Hi Robert, did you see http://scg.unibe.ch/research/helvetia? Bye T.

Gesendet: Donnerstag, 15. Oktober 2015 um 18:33 Uhr Von: "Robert Withers" <robert.w.withers@gmail.com> An: pharo-dev@lists.pharo.org Betreff: [Pharo-dev] Mult-language browsers - MLB (was: Re: Random forest in Pharo)

On 10/15/2015 11:57 AM, Robert Withers wrote:

...

On 10/15/2015 11:46 AM, Esteban Lorenzano wrote:

...

but well… in the mean time we learn and do steps. We will have a cool FFI, don’t worry… sooner than later :D

I was thinking about ASMJIT and it's audience. You may attract a broader audience with JVMJIT, including JNI. That would be something, then support cross-calling between Pharo, Newspeak, Groovy, Scala and Java plus dynamic jar loading. You'd need an army to pull that off though.

Please excuse the reply to the reply, but I was thinking about a JVMJIT and cross-calling. The key to me, experientially, is to have the same browser for all languages. We need a multi-language browser, a MLB.

Depending on the CompiledMethod selected, pick the right set of parsers: compiler, pretty printer, code completion, type inferencer and the MLB's method pane would be an editor for the language specified in the compiled method.

Furthermore, to support cross-calling, when you are working is a specific language, you can set that as the interaction language and the browser will present interfaces from other languages in the language you have selected, such that a cross-call is really just a native call to an auto-generated wrapper around the other language.

Think of Cincom's Distributed Smalltalk talking Corba with their I3 (Implicit Invocation Interface): http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DSTAppDevGuide...

I found this thread on Corba and Squeak: http://squeak-dev.squeakfoundation.narkive.com/AbWTL8Kh/smalltalk-and-corba. Bringing I3 support, into the browser would offer the foundations for the MLB.

Any feedback is really appreciated!

Regards, Robert

In pharodays presentations we explictly mentioned our strategy: - we keep NB syntax - we change the assembly generation to be able to get Spur. Stef I can tell you that if I could get a lua kind of jit now I would sign immediately and also for having pharo as a dll. Now it takes time to do soemthing. Le 15/10/15 17:35, Robert Withers a écrit :

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So

On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers@gmail.com> wrote:

Bonjour Stef,

I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:

multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.

- will existing NB syntax require change with the introduction of a MTVM?

nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes. now we have: nbCall:module: to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility) So I can imagine an API like this: ffiAsyncCall:callback:module: So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)

- to what degree will NB syntax need to be extended to support threaded callouts.

as described, I suppose. No exact idea until we implement.

- what NB syntax changes are needed for callbacks.

NB used some magic there. Shadow classes and etc. We do not need/want that anymore. now you have a new FFICallback api, where you can do: FFICallback signature: #(int (int handle, int *pitch, int x, int y, int w, int h)) block: [ :handle :pitch :x :y :w :h | pitch signedLongAt: 1 put: (self get_stride: handle). self get_data: handle ] (I extracted that example from my ongoing port of Athens)

- timing: when is MTVM expected and can we operate on the leading edge?

we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas). So… my plan is: - NB to FFI port (should be ready soon) - spur32 bits (should be ready soon, we are just waiting the NB to FFI) - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo) - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here... - FFI MT So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts. Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated. If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can. hope this helps Esteban

Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.

Regards, Robert

On 10/16/2015 06:59 AM, stepharo wrote:

...

In pharodays presentations we explictly mentioned our strategy: - we keep NB syntax - we change the assembly generation to be able to get Spur.

Stef

I can tell you that if I could get a lua kind of jit now I would sign immediately and also for having pharo as a dll. Now it takes time to do soemthing.

Le 15/10/15 17:35, Robert Withers a écrit :

...

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So

On 10/16/2015 07:58 AM, Esteban Lorenzano wrote:

...

On 16 Oct 2015, at 13:53, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers@gmail.com> wrote:

Bonjour Stef,

I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:

multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.

...

- will existing NB syntax require change with the introduction of a MTVM?

nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.

now we have:

nbCall:module:

to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)

So I can imagine an API like this:

ffiAsyncCall:callback:module:

So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)

Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside). But still, I do not expect call syntax will change at all.

Are you saying all FFI callouts would become threaded or would there be an unthreaded callout and a threaded callout? I was assuming the second scenario. Robert

Esteban

...

...

- to what degree will NB syntax need to be extended to support threaded callouts.

as described, I suppose. No exact idea until we implement.

...

- what NB syntax changes are needed for callbacks.

NB used some magic there. Shadow classes and etc. We do not need/want that anymore.

now you have a new FFICallback api, where you can do:

FFICallback signature: #(int (int handle, int *pitch, int x, int y, int w, int h)) block: [ :handle :pitch :x :y :w :h | pitch signedLongAt: 1 put: (self get_stride: handle). self get_data: handle ]

(I extracted that example from my ongoing port of Athens)

...

- timing: when is MTVM expected and can we operate on the leading edge?

we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).

So… my plan is:

- NB to FFI port (should be ready soon) - spur32 bits (should be ready soon, we are just waiting the NB to FFI) - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo) - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here... - FFI MT

So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.

Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.

If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.

hope this helps

Esteban

...

Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.

Regards, Robert

On 10/16/2015 06:59 AM, stepharo wrote:

...

In pharodays presentations we explictly mentioned our strategy: - we keep NB syntax - we change the assembly generation to be able to get Spur.

Stef

I can tell you that if I could get a lua kind of jit now I would sign immediately and also for having pharo as a dll. Now it takes time to do soemthing.

Le 15/10/15 17:35, Robert Withers a écrit :

...

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So

(+vm-dev) Esteban, thanks very much for your views. You write: On 10/16/2015 07:53 AM, Esteban Lorenzano wrote:

So… my plan is:

- NB to FFI port (should be ready soon) - spur32 bits (should be ready soon, we are just waiting the NB to FFI) - spur64 bits (Eliot is working on the JIT, I need to manage the

migration of Pharo)

- FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here... - FFI MT

and of course you are buried in existing tasks, especially the transition to 64-bits. It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes. Kinda why I would desire MTVM before 64-bits, then I assume less work would be needed overall. But that's my uneducated guess. Perhaps Eliot could shine some light for us on the progress of MTVM and what's needed. Because of that assumption I've made and without the responsibilities you have, Esteban, but recognizing modernizing NB to FFI, my desired list is: - NB to FFI port (should be ready soon) - spur32 bits (should be ready soon, we are just waiting the NB to FFI) - FFI MT - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo) - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...

If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.

Yes, please, and I appreciate you willingness to mentor. Best, Robert On 10/16/2015 07:53 AM, Esteban Lorenzano wrote:

...

On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers@gmail.com> wrote:

Bonjour Stef,

I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:

multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.

...

- will existing NB syntax require change with the introduction of a MTVM?

nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.

now we have:

nbCall:module:

to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)

So I can imagine an API like this:

ffiAsyncCall:callback:module:

So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)

...

- to what degree will NB syntax need to be extended to support threaded callouts.

as described, I suppose. No exact idea until we implement.

...

- what NB syntax changes are needed for callbacks.

NB used some magic there. Shadow classes and etc. We do not need/want that anymore.

now you have a new FFICallback api, where you can do:

FFICallback signature: #(int (int handle, int *pitch, int x, int y, int w, int h)) block: [ :handle :pitch :x :y :w :h | pitch signedLongAt: 1 put: (self get_stride: handle). self get_data: handle ]

(I extracted that example from my ongoing port of Athens)

...

- timing: when is MTVM expected and can we operate on the leading edge?

we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).

So… my plan is:

- NB to FFI port (should be ready soon) - spur32 bits (should be ready soon, we are just waiting the NB to FFI) - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo) - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here... - FFI MT

So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.

Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.

If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.

hope this helps

Esteban

...

Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.

Regards, Robert

On 10/16/2015 06:59 AM, stepharo wrote:

...

In pharodays presentations we explictly mentioned our strategy: - we keep NB syntax - we change the assembly generation to be able to get Spur.

Stef

I can tell you that if I could get a lua kind of jit now I would sign immediately and also for having pharo as a dll. Now it takes time to do soemthing.

Le 15/10/15 17:35, Robert Withers a écrit :

...

I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So

On 15 Oct 2015, at 14:29, philippe.back@highoctane.be <philippe.back@gmail.com> wrote:

I guess you aren't doing lots of random forests.

I do not do any :) In fact I didn’t know what was about until I read the wiki page ;) Esteban

RFs training is the best way to turn my PC into a heater.

Phil

Phil

Le 15 oct. 2015 14:19, "Esteban Lorenzano" <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> a écrit : yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

...

On 15 Oct 2015, at 09:51, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> a écrit :

...

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich@gmail.com <mailto:serge.stinckwich@gmail.com>> a écrit : I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou < <mailto:damien.cassou@inria.fr>damien.cassou@inria.fr <mailto:damien.cassou@inria.fr>> wrote:

...

Hi,

did anyone implement a Random Forest algorithm in Pharo?

https://en.wikipedia.org/wiki/Random_forest <https://en.wikipedia.org/wiki/Random_forest>

-- Damien Cassou http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/>

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

On Fri, Oct 16, 2015 at 12:56 PM, stepharo <stepharo@free.fr> wrote:

Personally I do not want to be forced to deploy R or whatever when I deploy Pharo. Period. We have enough dependencies to external libraries dll and other. If for one of your project you want to use a hyper cool super hyper coool external libraries then perfect. Not for Pharo.

Now we should focus on what is important for core pharo and my remark is about the core.

About the FFI, would be good that people stop complaining and help. We supported Igor NB (Laurent wrote a tutorial that I spent time to revisit even if I never did a FFI call) so where were you?

Actually reading it and putting it to use in a project.

Where are you pharoers when it is about to write something for the community?

For your information we are in discussion with ronie (I do not know the status of his back-end), esteban spent 4 months working on a new FFI front-end using NB syntax and back end using FFI. The idea is that we can plug the back-end of ronie.

Our team on his **own** money will invite ronie to work with us (Now we lost the money of our of our sponsors so times will be difficult).

One more reason to make money with Pharo and leverage what's out there in terms of capabilities. Going to use Pharo in a hackathon next monday. I'll see if I can get things done or be buried into the ground by the people using other tech.

Stef

Le 15/10/15 14:18, Esteban Lorenzano a écrit :

yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

On 15 Oct 2015, at 09:51, stepharo < <stepharo@free.fr>stepharo@free.fr> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, <philippe.back@highoctane.be> philippe.back@highoctane.be a écrit :

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R. Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich@gmail.com> a écrit :

...

I don't think so.

I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-)

On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <damien.cassou@inria.fr> wrote:

...

Hi,

did anyone implement a Random Forest algorithm in Pharo?

https://en.wikipedia.org/wiki/Random_forest

-- Damien Cassou http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/