- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Esteban Lorenzano

> On 16 Oct 2015, at 14:06, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > > > On 10/16/2015 07:58 AM, Esteban Lorenzano wrote: >> >>> On 16 Oct 2015, at 13:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers(a)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. Iâm saying *the syntax* will not change. That means, if you want to call memcpy, syntax will still be: #(void *memcpy ( void* dest, void *src)) what can (and will) change is the method invoking itâ¦ ffiCall:module: vs. ffiAsyncCall:callback:module: Esteban > > 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

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by Robert Withers

On 10/16/2015 07:58 AM, Esteban Lorenzano wrote: > >> On 16 Oct 2015, at 13:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers(a)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 >>>> >>>> >>> >> > >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by Robert Withers

(+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(a)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 >>> >>> >> > >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 16 Oct 2015, at 13:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers(a)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. 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 >>> >>> >> >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers(a)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 >> >> >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 16 Oct 2015, at 12:56, stepharo <stepharo(a)free.fr> wrote: > > Personally I do not want to be forced to deploy R or whatever when I deploy Pharo. Period. but why would you? nowâ¦ if you have to use a special function, you might need to install a package+an external library. > 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. no one said this is going to be in Pharo, AFAIR > > 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? > > 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). > > 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 < <mailto:stepharo@free.fr>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" <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 <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/> >>>> >>> >> >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by phil＠highoctane.be

On Fri, Oct 16, 2015 at 12:56 PM, stepharo <stepharo(a)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(a)free.fr>stepharo(a)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> > philippe.back(a)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> 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> >> 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/ >> >> > > >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by Robert Withers

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: - will existing NB syntax require change with the introduction of a MTVM? - to what degree will NB syntax need to be extended to support threaded callouts. - what NB syntax changes are needed for callbacks. - timing: when is MTVM expected and can we operate on the leading edge? 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 > >

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by stepharo

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

Oct. 16, 2015

Re: [Pharo-dev] Random forest in Pharo

by stepharo

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? 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). 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(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 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> 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. 16, 2015