- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Random forest in Pharo

by Robert Withers

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(a)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/07693… > > 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]

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Jimmie Houchin

Thanks for the information. And thank you for all that you do to move Pharo forward. I know some of this must be tedious. But Pharo is getting more beautiful all the time. Jimmie On 10/15/2015 10:02 AM, Esteban Lorenzano wrote: > >> On 15 Oct 2015, at 16:51, Jimmie Houchin <jlhouchin(a)gmail.com >> <mailto: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 <jlhouchin(a)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/07693… >> >> 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] >

Oct. 15, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Dale Henrichs

...and developers can substitute their own protocol compatible classes and extend the settings being managed and/or customize the behavior upon certain triggers ... with the added benefit of being editable outside of an image ... .... been doing this for awhile in tODE:) Dale On 10/15/15 7:26 AM, Juraj Kubelka wrote: > And there are more values that has to be treated differently, e.g. fonts, file paths, theme. > > Cheers, > Juraj > >> On Oct 15, 2015, at 08:32, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> First of all you can add additional data like a version of the project for which the setting should work. >> >> Secondly it depends how much do we want to stress the developers. Because you cannot serialize classes in STON. So either we store âStoredSettingâ and âStoredClassSettingâ where the second one knows that is has to convert a value to a class, or we force developers to do that. I late the second one moreâ¦ >> >> Uko >> >>> On 15 Oct 2015, at 13:09, Damien Cassou <damien.cassou(a)inria.fr> wrote: >>> >>> >>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >>> >>>> It is like that: >>>> >>>> [ >>>> StoredSetting { >>>> #settingNodeIdentifier : '#shoreLine#autoSubmit', >>>> #realValue : true >>>> }, >>>> StoredSetting { >>>> #settingNodeIdentifier : '#reIgnore', >>>> #realValue : Set [ ] >>>> } >>>> ] >>> why not: >>> >>> { >>> '#shoreLine#autoSubmit' : true, >>> '#reIgnore' : Set [ ] >>> } >>> >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." --Winston Churchill >>> >> >

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 15 Oct 2015, at 16:51, Jimmie Houchin <jlhouchin(a)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(a)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/07693… <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/07693…> > > 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]

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Jimmie Houchin

Thanks for the example. On 10/15/2015 09:04 AM, Esteban Lorenzano wrote: > >> On 15 Oct 2015, at 15:50, Jimmie Houchin <jlhouchin(a)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? 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/07693… 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]

Oct. 15, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Juraj Kubelka

And there are more values that has to be treated differently, e.g. fonts, file paths, theme. Cheers, Juraj > On Oct 15, 2015, at 08:32, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > First of all you can add additional data like a version of the project for which the setting should work. > > Secondly it depends how much do we want to stress the developers. Because you cannot serialize classes in STON. So either we store âStoredSettingâ and âStoredClassSettingâ where the second one knows that is has to convert a value to a class, or we force developers to do that. I late the second one moreâ¦ > > Uko > >> On 15 Oct 2015, at 13:09, Damien Cassou <damien.cassou(a)inria.fr> wrote: >> >> >> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: >> >>> It is like that: >>> >>> [ >>> StoredSetting { >>> #settingNodeIdentifier : '#shoreLine#autoSubmit', >>> #realValue : true >>> }, >>> StoredSetting { >>> #settingNodeIdentifier : '#reIgnore', >>> #realValue : Set [ ] >>> } >>> ] >> >> why not: >> >> { >> '#shoreLine#autoSubmit' : true, >> '#reIgnore' : Set [ ] >> } >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> > >

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 15 Oct 2015, at 15:50, Jimmie Houchin <jlhouchin(a)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(a)highoctane.be <mailto:philippe.back@highoctane.be> <philippe.back(a)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(a)highoctane.be <mailto:philippe.back@highoctane.be>" <philippe.back(a)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(a)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(a)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(a)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(a)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(a)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/> >>>>> >>>> >>> >> >

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Serge Stinckwich

On Thu, Oct 15, 2015 at 3:50 PM, Jimmie Houchin <jlhouchin(a)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. > > 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. You can join on SciSmalltalk mailing-list: https://groups.google.com/forum/#!forum/scismalltalk We have a repository here also: https://github.com/SergeStinckwich/SciSmalltalk Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Jimmie Houchin

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(a)highoctane.be >> <mailto:philippe.back@highoctane.be> <philippe.back(a)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(a)highoctane.be >> <mailto:philippe.back@highoctane.be>" <philippe.back(a)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(a)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(a)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(a)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(a)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(a)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/ >>>> >>> >> >

Oct. 15, 2015

One more question about the transformation rules

by Yuriy Tymchuk

Hi, when a transformation rule checks a method, except for only checking whether it matches the rule, it also checks if self class recursiveSelfRule executeTree: rewriteRule tree initialAnswer: false evaluates to false. #recursiveSelfRule is '`@methodName: `@args | `@temps | self `@methodName: `@args1' '`@methodName: `@args | `@temps | ^ self `@methodName: `@args1â Do I understand correctly that before signaling that method is bad the rule makes sure that the transformation will not create a recursion? Uko

Oct. 15, 2015