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