- Pharo-dev - lists.pharo.org

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

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