October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Mult-language browsers - MLB (was: Re: Random forest in Pharo)

by Torsten Bergmann

Hi Robert, did you see http://scg.unibe.ch/research/helvetia? Bye T. > Gesendet: Donnerstag, 15. Oktober 2015 um 18:33 Uhr > Von: "Robert Withers" <robert.w.withers(a)gmail.com> > An: pharo-dev(a)lists.pharo.org > Betreff: [Pharo-dev] Mult-language browsers - MLB (was: Re: Random forest in Pharo) > > > > On 10/15/2015 11:57 AM, Robert Withers wrote: > > > > > > On 10/15/2015 11:46 AM, Esteban Lorenzano wrote: > >> > >> but wellâ¦ in the mean time we learn and do steps. We will have a cool > >> FFI, donât worryâ¦ sooner than later :D > > > > I was thinking about ASMJIT and it's audience. You may attract a broader > > audience with JVMJIT, including JNI. That would be something, then > > support cross-calling between Pharo, Newspeak, Groovy, Scala and Java > > plus dynamic jar loading. You'd need an army to pull that off though. > > Please excuse the reply to the reply, but I was thinking about a JVMJIT > and cross-calling. The key to me, experientially, is to have the same > browser for all languages. We need a multi-language browser, a MLB. > > Depending on the CompiledMethod selected, pick the right set of parsers: > compiler, pretty printer, code completion, type inferencer and the MLB's > method pane would be an editor for the language specified in the > compiled method. > > Furthermore, to support cross-calling, when you are working is a > specific language, you can set that as the interaction language and the > browser will present interfaces from other languages in the language you > have selected, such that a cross-call is really just a native call to an > auto-generated wrapper around the other language. > > Think of Cincom's Distributed Smalltalk talking Corba with their I3 > (Implicit Invocation Interface): > http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DSTAppDevGuid… > > I found this thread on Corba and Squeak: > http://squeak-dev.squeakfoundation.narkive.com/AbWTL8Kh/smalltalk-and-corba. > Bringing I3 support, into the browser would offer the foundations for > the MLB. > > Any feedback is really appreciated! > > Regards, > Robert > >

Oct. 15, 2015

Re: [Pharo-dev] GTools merging configurations

by Tudor Girba

That is one beautiful analysis :) Doru On Thu, Oct 15, 2015 at 6:24 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 15-10-15 09:48, stepharo wrote: > >> I can imagine that well. >> Up to you but I think that having modular parts is nice too. >> What we should is a way to automatically update configurations. >> > > I love modular parts. I see a ripple effect > > Stephan > > p.s. Alex: this breaks the normalizer RTMultiLinearColorForIdentity. > > | data b s d | > data := OrderedCollection new. > #(GTDebugger GTInspector GTInspectorCore GTPlayground GTPlaygroundCore > GTSpotter GToolkitCore GlamourCore Rubric) do: [ :aPackageName | > data addAll: (('ConfigurationOf', aPackageName) asClass methods > select: [ :each | > each selector asString beginsWith: 'version' ] > thenCollect: [ :method | > Array > with: aPackageName > with: (DateAndTime today - (DateAndTime fromString: (method stamp > substrings second))) days ])]. > > b := RTTimeline new. > > s := RTTimelineSet new. > s objects: data. > s shape color: Color green. > s lineIdentifier: #first. > s start: #second. > s end: #second. > b add: s. > > b axisX > numberOfLabels: 5; > labelRotation: -45. > > d := RTVerticalTickLineDecorator new. > d shape line color: Color white. > b addDecorator: d. > > b build. > ^ b view > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 15, 2015

Re: [Pharo-dev] One more question about the transformation rules

by Thierry Goubier

Le 15/10/2015 15:00, Yuriy Tymchuk a Ã©crit : > 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? Not sure about the 'before signaling that method is bad', but the match is on a method which creates an infinite loop by calling itself. Thierry

Oct. 15, 2015

Re: [Pharo-dev] One more question about the transformation rules

by Max Leske

> On 15 Oct 2015, at 15:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > 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? Yes, I would say so. Although why that check is done to find matching methods I donât know. > > Uko

Oct. 15, 2015

Mult-language browsers - MLB (was: Re: Random forest in Pharo)

by Robert Withers

On 10/15/2015 11:57 AM, Robert Withers wrote: > > > On 10/15/2015 11:46 AM, Esteban Lorenzano wrote: >> >> but wellâ¦ in the mean time we learn and do steps. We will have a cool >> FFI, donât worryâ¦ sooner than later :D > > I was thinking about ASMJIT and it's audience. You may attract a broader > audience with JVMJIT, including JNI. That would be something, then > support cross-calling between Pharo, Newspeak, Groovy, Scala and Java > plus dynamic jar loading. You'd need an army to pull that off though. Please excuse the reply to the reply, but I was thinking about a JVMJIT and cross-calling. The key to me, experientially, is to have the same browser for all languages. We need a multi-language browser, a MLB. Depending on the CompiledMethod selected, pick the right set of parsers: compiler, pretty printer, code completion, type inferencer and the MLB's method pane would be an editor for the language specified in the compiled method. Furthermore, to support cross-calling, when you are working is a specific language, you can set that as the interaction language and the browser will present interfaces from other languages in the language you have selected, such that a cross-call is really just a native call to an auto-generated wrapper around the other language. Think of Cincom's Distributed Smalltalk talking Corba with their I3 (Implicit Invocation Interface): http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DSTAppDevGuid… I found this thread on Corba and Squeak: http://squeak-dev.squeakfoundation.narkive.com/AbWTL8Kh/smalltalk-and-corba. Bringing I3 support, into the browser would offer the foundations for the MLB. Any feedback is really appreciated! Regards, Robert

Oct. 15, 2015

Re: [Pharo-dev] GTools merging configurations

by Stephan Eggermont

On 15-10-15 09:48, stepharo wrote: > I can imagine that well. > Up to you but I think that having modular parts is nice too. > What we should is a way to automatically update configurations. I love modular parts. I see a ripple effect Stephan p.s. Alex: this breaks the normalizer RTMultiLinearColorForIdentity. | data b s d | data := OrderedCollection new. #(GTDebugger GTInspector GTInspectorCore GTPlayground GTPlaygroundCore GTSpotter GToolkitCore GlamourCore Rubric) do: [ :aPackageName | data addAll: (('ConfigurationOf', aPackageName) asClass methods select: [ :each | each selector asString beginsWith: 'version' ] thenCollect: [ :method | Array with: aPackageName with: (DateAndTime today - (DateAndTime fromString: (method stamp substrings second))) days ])]. b := RTTimeline new. s := RTTimelineSet new. s objects: data. s shape color: Color green. s lineIdentifier: #first. s start: #second. s end: #second. b add: s. b axisX numberOfLabels: 5; labelRotation: -45. d := RTVerticalTickLineDecorator new. d shape line color: Color white. b addDecorator: d. b build. ^ b view

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Robert Withers

On 10/15/2015 11:46 AM, Esteban Lorenzano wrote: > >> On 15 Oct 2015, at 17:35, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> >> >> 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. > > FFI is a complicated issue, and we have made some mistakes. There is no shame on being upset with itâ¦ we tried to do something cool and at the end we failed, now we are following a different path (as cool as the other, but different). > I hope we will stabilise FFI this version (Pharo 5), but of course, I cannot promise 100% crash-free, specially when what you are doing (call out the vm) escapes to vm control :) Oh, you're good, but enough blame-shifting, let's fix the real problem. :) > > but wellâ¦ in the mean time we learn and do steps. We will have a cool FFI, donât worryâ¦ sooner than later :D I was thinking about ASMJIT and it's audience. You may attract a broader audience with JVMJIT, including JNI. That would be something, then support cross-calling between Pharo, Newspeak, Groovy, Scala and Java plus dynamic jar loading. You'd need an army to pull that off though. Robert > > Esteban > > >> >> Best, >> Robert >> >> >>> >>> >>> Thanks. >>> >>> Jimmie >>> Jimmie >>> >>> [snip] >> > >

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 15 Oct 2015, at 17:35, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > > > 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. FFI is a complicated issue, and we have made some mistakes. There is no shame on being upset with itâ¦ we tried to do something cool and at the end we failed, now we are following a different path (as cool as the other, but different). I hope we will stabilise FFI this version (Pharo 5), but of course, I cannot promise 100% crash-free, specially when what you are doing (call out the vm) escapes to vm control :) but wellâ¦ in the mean time we learn and do steps. We will have a cool FFI, donât worryâ¦ sooner than later :D Esteban > > Best, > Robert > > >> >> >> Thanks. >> >> Jimmie >> Jimmie >> >> [snip] >

Oct. 15, 2015

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