> On 15 Oct 2015, at 15:50, Jimmie Houchin <[email protected]> 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:[email protected]>[email protected]
>>> <mailto:[email protected]> <[email protected]
>>> <mailto:[email protected]>> 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:[email protected]>[email protected]
>>> <mailto:[email protected]>" <[email protected]
>>> <mailto:[email protected]>> 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" <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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:[email protected]>[email protected]
>>>> <mailto:[email protected]> 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:[email protected]>[email protected]
>>>>> <mailto:[email protected]>> 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:[email protected]>[email protected]
>>>>> <mailto:[email protected]>> 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/>
>>>>>
>>>>
>>>
>>
>
