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