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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50387 Home: https://github.com/pharo-project/pharo-core

Oct. 16, 2015

[pharo-project/pharo-core] 627eeb: 50387

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 627eebbee0ebdf5822e50eed54a3fb4536c620dd https://github.com/pharo-project/pharo-core/commit/627eebbee0ebdf5822e50eed… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-16 (Fri, 16 Oct 2015) Changed paths: A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/basicTaskThumbnailOfSize_.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/isTaskbarPresent.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/minimizeAfterGeneratingThumbnail.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/restoreBeforeGeneratingThumbnail.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskThumbnailOfSize_.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarButtonClicked.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarButtonEntered_event_in_.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarButtonFor_.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarButtonLeft_event_in_.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarButtonMenu_.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarCloseAllToRight.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarIcon.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarLabel.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarState.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarTask.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarThumbnailExtent.st A Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/worldTaskbar.st M OpalCompiler-Core.package/IRBuilder.class/instance/private/startNewSequence.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/mapping/mapBytesTo_.st R OpalCompiler-Core.package/IRInstruction.class/instance/testing/isJumpOrReturn.st A OpalCompiler-Core.package/IRInstruction.class/instance/testing/transitionsToNextSequence.st M OpalCompiler-Core.package/IRJumpIf.class/instance/acessing/nextBytecodeOffsetAfterJump.st M OpalCompiler-Core.package/IRMethod.class/instance/debugging/instructionForPC_.st A OpalCompiler-Core.package/IRPushClosureCopy.class/instance/testing/isGoto.st A OpalCompiler-Core.package/IRPushClosureCopy.class/instance/testing/isJump.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitInstruction_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitPushClosureCopy_.st A OpalCompiler-Tests.package/MustBeBooleanTests.class/instance/tests/testIfTrueWithClosureAfterJump.st A OpalCompiler-Tests.package/OCClosureTests.class/instance/testing/testBlockTemps.st R Polymorph-TaskbarIcons.package/extension/SystemWindow/instance/taskbarIcon.st R Polymorph-Widgets.package/extension/SystemWindow/instance/basicTaskThumbnailOfSize_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/isTaskbarPresent.st R Polymorph-Widgets.package/extension/SystemWindow/instance/minimizeAfterGeneratingThumbnail.st R Polymorph-Widgets.package/extension/SystemWindow/instance/restoreBeforeGeneratingThumbnail.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskThumbnailOfSize_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarButtonClicked.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarButtonEntered_event_in_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarButtonFor_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarButtonLeft_event_in_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarButtonMenu_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarCloseAllToRight.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarLabel.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarState.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarTask.st R Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarThumbnailExtent.st R Polymorph-Widgets.package/extension/SystemWindow/instance/worldTaskbar.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50386.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50387.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50386.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50387.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50387 16793 Minor protocol cleanup in SystemWindow for taskbar related items https://pharo.fogbugz.com/f/cases/16793 16777 Querying block with many temps fails https://pharo.fogbugz.com/f/cases/16777 http://files.pharo.org/image/50/50387.zip

Oct. 16, 2015

Re: [Pharo-dev] code repository options

by Robert Withers

Thank you for your guidance. I went with bitbucket and gitfiletree. I'm investigating adding my repo to the Monticello browser using gitfiletree. cheers, Robert On 10/16/2015 01:03 AM, Thierry Goubier wrote: > Le 16/10/2015 06:40, Robert Withers a Ã©crit : >> I am interested in keeping my code on github. Is there a way to connect, >> browse, load github-based Pharo code? > > Yes, there is: > > - filetree + git by hand (included in the image) > - gitfiletree (filetree + calls git for you) > (ConfigurationOfGitFileTree) (Windows support is getting better) > - github:// urls (for distribution of your code) (included in the image) > > If you're a lot into branching, you'll have to take a look at the > gitfiletree merge driver (on github). > > Thierry > >> What are all the options for storing code onthe net and interacting with >> it in Pharo? > > All solutions above also work with bitbucket. > > GitFileTree will work with anything which has a git interface. > > Regards, > > Thierry > >> Many thanks, >> R >> >> > >

Oct. 16, 2015

Re: [Pharo-dev] image livelock

by Sven Van Caekenberghe

What do you mean by 'livelock' ? I would assume you mean 'the Pharo UI becoming unresponsive', right ? Pharo is properly multithreading, but (1) it is pretty easy to do something so that the UI thread is busy (2) it is pretty easy to do enough work in another thread so that things get very slow In both cases, Pharo would feel pretty dead, but it technically is not (completely) > On 16 Oct 2015, at 06:13, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > I've noticed my image livelocks occassionally, when running tests from a category and other times as well. So when I am in my system, which is crazy with asynchronous evaluation, and I livelock, I wonder: is this due to Pharo locking as I have seen or is there an issue in my code? > > Has there been previous reports of livelock? Any clues where the issue may reside? > > thanks ^^ > Robert >

Oct. 16, 2015

Re: [Pharo-dev] code repository options

by Thierry Goubier

Le 16/10/2015 06:40, Robert Withers a Ã©crit : > I am interested in keeping my code on github. Is there a way to connect, > browse, load github-based Pharo code? Yes, there is: - filetree + git by hand (included in the image) - gitfiletree (filetree + calls git for you) (ConfigurationOfGitFileTree) (Windows support is getting better) - github:// urls (for distribution of your code) (included in the image) If you're a lot into branching, you'll have to take a look at the gitfiletree merge driver (on github). Thierry > What are all the options for storing code onthe net and interacting with > it in Pharo? All solutions above also work with bitbucket. GitFileTree will work with anything which has a git interface. Regards, Thierry > Many thanks, > R > >

Oct. 16, 2015

code repository options

by Robert Withers

I am interested in keeping my code on github. Is there a way to connect, browse, load github-based Pharo code? What are all the options for storing code onthe net and interacting with it in Pharo? Many thanks, R

Oct. 16, 2015

image livelock

by Robert Withers

I've noticed my image livelocks occassionally, when running tests from a category and other times as well. So when I am in my system, which is crazy with asynchronous evaluation, and I livelock, I wonder: is this due to Pharo locking as I have seen or is there an issue in my code? Has there been previous reports of livelock? Any clues where the issue may reside? thanks ^^ Robert

Oct. 16, 2015

RPackage design documentation

by Esteban A. Maringolo

Where can I find documentation about how the RPackage system? I want to learn how RPackageOrganizer, RPackageTag/classTag and similar classes are supposed to work together. :) Thank you! Esteban A. Maringolo

Oct. 16, 2015

ConfigurationOf versions with development blessing

by Juraj Kubelka

Hi! Andrei and I have had an issue loading our configuration using the following script: Gofer it smalltalkhubUser: 'Moose' project: 'GToolkit'; configurationOf: 'GTSpotter'; loadDevelopment. It was loading an old version, instead of expected one. Moreover, the following script worked: Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTSpotter'; load. (ConfigurationOfGTSpotter project version: #'development') load. Then, we have found out that one version has blessing set to development: version102: spec <version: '1.0.2' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'developmentâ. but it was incorrect. There is about 105 versions with development blessing (Moose 6.0 image). You can check it out using: ((SystemNavigation default allSendersOf: #blessing:) select: [ :each | (each selector beginsWith: 'version') and: [ each methodClass name beginsWith: 'ConfigurationOf' ] ] ) select: [ :each | each sourceCode includesSubstring: 'blessing: #''development''.' ]. If project distinguish between bleeding edge version and development version, it is correct. But if not, it could be a problem (like in our case of Spotter). So I suggest you to check your project and fix it if appropriate. There is list of projects that define version with development blessing: ConfigurationOfOSWindow ConfigurationOfMagritte3 ConfigurationOfVersionner ConfigurationOfMoose ConfigurationOfZincHTTPComponents ConfigurationOfGrease ConfigurationOfPetitParser ConfigurationOfMerlin ConfigurationOfPastell ConfigurationOfMooseAlgos ConfigurationOfRubric ConfigurationOfCommandShell ConfigurationOfTxText It may save your or other developers' time :-) Cheers, Juraj

Oct. 15, 2015

Re: [Pharo-dev] Mult-language browsers - MLB

by Robert Withers

Thanks for your reply, Torsten. This looks really interesting and in Pharo, as well. It's in my little list of links for this topic. cheers, Robert On 10/15/2015 05:29 PM, Torsten Bergmann wrote: > 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] 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

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

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

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 <philippe.back(a)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 < <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> >>> > >>> > -- >>> > 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. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

> On 15 Oct 2015, at 14:29, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > > I guess you aren't doing lots of random forests. > I do not do any :) In fact I didnât know what was about until I read the wiki page ;) Esteban > 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 < <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> >>> > >>> > -- >>> > 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. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by philippe.back＠highoctane.be

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" < philippe.back(a)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> 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> 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> 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>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. 15, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50386 Home: https://github.com/pharo-project/pharo-core

Oct. 15, 2015

[pharo-project/pharo-core] c64067: 50386

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c640677ad5f963c154e0a9a83f67ab52253c4c64 https://github.com/pharo-project/pharo-core/commit/c640677ad5f963c154e0a9a8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-15 (Thu, 15 Oct 2015) Changed paths: M Kernel.package/PharoKernelAssembly.class/class/meta-data/parts.st M Manifest-Core.package/SmalllintManifestChecker.class/instance/accessing/criticsOf_.st M Manifest-Core.package/SmalllintManifestChecker.class/instance/actions/runRules_onPackage_withoutTestCase_.st M Manifest-Core.package/TheManifestBuilder.class/instance/manifest/isFalsePositive_onRule_version_.st A Manifest-Core.package/extension/RBPackageEnvironment/instance/smallLintCritics.st A Manifest-Core.package/extension/RPackage/instance/criticNameOn_.st M Morphic-Widgets-Windows.package/SystemWindow.class/definition.st M Morphic-Widgets-Windows.package/SystemWindow.class/instance/announcement/announce_.st R Morphic-Widgets-Windows.package/SystemWindow.class/instance/announcement/announcer.st M Refactoring-Critics.package/PharoCriticRules.class/class/default rules/pharoHardLintRules.st A Refactoring-Critics.package/RBArchitectureLintRule.class/README.md A Refactoring-Critics.package/RBArchitectureLintRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBArchitectureLintRule.class/class/testing/isVisible.st A Refactoring-Critics.package/RBArchitectureLintRule.class/definition.st A Refactoring-Critics.package/RBArchitectureLintRule.class/instance/accessing/group.st A Refactoring-Critics.package/RBArchitectureLintRule.class/instance/accessing/resultClass.st A Refactoring-Critics.package/RBArchitectureLintRule.class/instance/testing/isArchitecturalRule.st A Refactoring-Critics.package/RBCompositeLintRule.class/instance/running/checkPackage_.st A Refactoring-Critics.package/RBLintRule.class/instance/running/checkPackage_.st A Refactoring-Critics.package/RBLintRule.class/instance/testing/isArchitecturalRule.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/README.md A Refactoring-Critics.package/RBPharoBootstrapRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/definition.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/instance/accessing/bootstrapPackages.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/instance/accessing/collectionsPackages.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/instance/accessing/name.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/instance/checking/assertNoNewExternalDependency.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/instance/checking/checkPackage_.st A Refactoring-Critics.package/RBPharoBootstrapRule.class/instance/private/dependencyChecker.st M Refactoring-Critics.package/RBSmalllintChecker.class/instance/actions/run.st A Refactoring-Critics.package/RBSmalllintChecker.class/instance/private/checkPackage_.st M Refactoring-Critics.package/RBUnaryAccessingMethodWithoutReturnRule.class/instance/running/basicCheck_.st M Refactoring-Environment.package/RBBrowserEnvironment.class/instance/environments/withoutClasses_.st A Refactoring-Tests-Critics.package/RBPharoBootstrapAnalyzerStubWithNewDependency.class/README.md A Refactoring-Tests-Critics.package/RBPharoBootstrapAnalyzerStubWithNewDependency.class/definition.st A Refactoring-Tests-Critics.package/RBPharoBootstrapAnalyzerStubWithNewDependency.class/instance/accessing/dependenciesOf_.st A Refactoring-Tests-Critics.package/RBPharoBootstrapAnalyzerStubWithNoNewDependency.class/README.md A Refactoring-Tests-Critics.package/RBPharoBootstrapAnalyzerStubWithNoNewDependency.class/definition.st A Refactoring-Tests-Critics.package/RBPharoBootstrapAnalyzerStubWithNoNewDependency.class/instance/accessing/dependenciesOf_.st A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/README.md A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/definition.st A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/instance/running/setUp.st A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/instance/running/tearDown.st A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/instance/tests/testRuleDoesNotFailIfAppliedOnNonBootstrapPackage.st A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/instance/tests/testRuleDoesNotFailIfNoNewExternalDependency.st A Refactoring-Tests-Critics.package/RBPharoBootstrapRuleTest.class/instance/tests/testRuleFailsIfAnyNewExternalDependencyFound.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50385.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50386.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50385.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50386.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-Base.package/extension/RPackage/instance/browse.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/menu/menu_shifted_.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/private/applyRules.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/addAllItems.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/addItems.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/removeAllItems.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/removeItems.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/sort_.st A Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/sort_withAll_.st A Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/sort_withoutAll_.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/class/instance creation/openWithEnvironment_removeTestCase_.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/removeItems.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/whenSelectedItemChangesOnListModel.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/addNavigationMenuItemsTo_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/browseCritic.st A Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/browseDependencies.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/menu_shifted_.st Log Message: ----------- 50386 16789 RBUnaryAccessingMethodWithoutReturnRule refers to #nodes instead of #statements https://pharo.fogbugz.com/f/cases/16789 16758 Unify SystemWindow announcing with Morph announcing https://pharo.fogbugz.com/f/cases/16758 16653 Add an architectural rule for the bootstrap layer https://pharo.fogbugz.com/f/cases/16653 http://files.pharo.org/image/50/50386.zip

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by philippe.back＠highoctane.be

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> 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> 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> 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> >> 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. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by Esteban Lorenzano

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> 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 < <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> >> > >> > -- >> > 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. 15, 2015

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

by Yuriy Tymchuk

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] Storing System Settings using STON

by Damien Cassou

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] tests should be green

by Nicolai Hess

2015-10-15 9:36 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Yes, > > -> there is a bug somewhere that flattens traits in some cases > Any idea how to fix this? I already provided a fix for the package fileout: ( 10808 Bad behavior on FileOut/FileIn tool when using traits) But for Monticello packages, this works differently. A quick look at MCPackage>>#snapshot shows: .... rPackageSet methods do: [:ea | definitions add: ea asMCMethodDefinition] displayingProgress: [ :ea| 'Snapshotting methods...' ]. rPackageSet overriddenMethods do: [:ea | definitions add: (rPackageSet changeRecordForOverriddenMethod: ea) asMCMethodDefinition] displayingProgress: [ :ea| 'Searching for overrides in ', ea asString ]. ... here, rPackageSet methods and rPackageSet overrriddenMethods create RGMethodDefinition for all, trait and non trait methods. We could try to solve this by adding a #reject: rPackageSet methods reject:#isFromTrait ..... > -> we need to write a script to delete all the wrong methods. > > > On 14 Oct 2015, at 17:16, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > Please, someone can look at the Collections-Tests > > The ReleaseTest complains about > > > > testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits > > (These are all Test-subclasses that use traits, but all(!) trait method > are > > compiled in the class instead, this happened after someone moved the Test > > packages (for bootstrap?) > > > > OrderedCollectionTest > > FloatArrayTest > > ArrayTest > > DateTest > > HeapTest > > MorphicTextAdapter > > LinkedListTest > > DatePrintFormatTester > > StackTest > > CheckboxButtonMorph > > IntervalTest > > DateAndTimeTest > > SimpleButtonMorph > > MethodDictionaryTest > > SetTest > > DictionaryTest > > BagTest > > SymbolTest > > StringTest > > CollectionRootTest > > SortedCollectionTest > > > >

Oct. 15, 2015

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

by Yuriy Tymchuk

It is like that: [ StoredSetting { #settingNodeIdentifier : '#shoreLine#autoSubmit', #realValue : true }, StoredSetting { #settingNodeIdentifier : '#reIgnore', #realValue : Set [ ] } ] > On 15 Oct 2015, at 09:54, stepharo <stepharo(a)free.fr> wrote: > > Cool! > > Could you send an example of the file contents? > > > Stef > > > Le 12/10/15 21:45, Juraj Kubelka a Ã©crit : >> Hi, >> >> we have a slice that introduce new storage solution for System Settings. See: https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON <https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON> >> >> You can load it using: >> >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; >> package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; >> load. >> >> When you open the Setting Browser, you can see that every setting has new items in context menu: >> >> <Mail Attachment.png> >> >> Thanks for reviewing it. >> Cheers, >> Juraj >

Oct. 15, 2015

Re: [Pharo-dev] GTools merging configurations

by Yuriy Tymchuk

In my opinion it depends on the project size. When itâs small and evolves fast you can have everything in one conf. If the projects get big and evolve more slowly, it makes sense to keep them in separate configurationsâ¦ I think that itâs about time for managing configurations vs time for managing projects. Also you can make a one conf that relies on 3 others. I like having baselines, but then you have to still make a confâ¦ Uko > On 15 Oct 2015, at 09:48, stepharo <stepharo(a)free.fr> 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. > > Stef > > Le 14/10/15 22:20, Andrei Chis a Ã©crit : >> Hi, >> >> For the GTInspector, GTPlayground and GTSpotter we now have distinct configurations. >> However, this complicates the integration process with Pharo as a lot of configurations need to be updated. >> So we'd like to merge them in ConfigurationOfGToolkitCore. >> >> What do you think? >> This will simplify a lot the integration process. >> >> Cheers, >> Andrei > >

Oct. 15, 2015

[ANN] Pharo Consortium New Gold Member: Lifeware

by Marcus Denker

The Pharo Consortium is very happy to announce that Lifeware has joined the Consortium as an Gold Member. About - Lifeware: http://www.lifeware.ch - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Oct. 15, 2015

Re: [Pharo-dev] Autonomous Shark-Monitoring Drone

by Serge Stinckwich

On Wed, Oct 7, 2015 at 5:54 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Dear Friends and Colleagues, Hi Eliot, > as you may know, Sharks, as apex predators, are vital to maintaining > healthy marine ecosystems, and at the same time, their populations are > plummeting due to human actions. It is estimated for example that the > population of pelagic oceanic white tip sharks is reducing by 17% per year > [1] and I've heard (can't find a reference) that populations in the eastern > indian/western pacific are at 1% of normal levels. Such reductions in > populations create "trophic cascades" that produce wide-ranging changes in > populations of different species all the way down the food chain [2]. And > the marine ecosystem is a key source of human nutrition; it comprises > between 13% and 17% of global human protein intake [3]. Recently, I talk with some people from my research institute who are working on Shark behavior modeling in the CHARC program : http://www.la-reunion.ird.fr/le-programme-charc Sorry this is in French only They use acoustic marks on sharks in order to locate them thanks to a surveillance network. The idea is not only to manage the risks regarding sharks but also to use them to have information about ocean's environment parameters. I start to discuss a little bit with them in order to model sharks behavior. > As you may also know, there is currently a shark attack crisis in New > South Wales [4]. While most people in the region oppose killing sharks in > response to the crisis, existing solutions, netting and culling reduce those > same threatened populations of sharks upon which the sustainability of > marine food supply d ecosystems depend [5], and are arguably ineffective > [6]. Apparently the most successful approach at avoiding attacks is the use > of human spotters, as used in Cape Town, where people in tall towers scan > the sea close to shore [6]. > > But please watch this Youtube video [7] from Pismo Beach, California. The > shark is spotted at about 1:20 into the video. This drone, a phantom 3, is > sending live video back to the operators, who are using remote control. > What we can see from this video is that the point of view of drones is far > superior to that of spotters. > > My first thought is that autonomous drones could provide a cheap and > scalable solution to patrolling beaches to prevent shark attacks. I expect > that processors like the Pi 2 have easily enough processing power to both > plan and execute search patterns along beaches, and perform the image > recognition necessary to reliably detect potentially dangerous sharks. A > drone might also be able autonomously to visit surfers and swimmers near to > the shark and warn them, either by some signal such as flashing red LEDs or > an audible message (language issues notwithstanding). The drone would have > to be able to identify swimmers and surfers in the water (not easy; sharks > confuse seals and surfers all the time), but computing an optimal route to > visit suspected swimmers should be relatively easy :-). > > I imagine that sooner or later it will be possible to construct cheap > rugged solar powered docking/charging shelters that drones could depart from > and return to, to charge and shelter from the elements after patrols. > Satellite communications could provide status reports for maintenance. This is a really interesting project. My lab is also interested by using drones for environmental surveillance. I can talk with my colleagues working on sharks if this is something that they envision for the future. Another idea is to use marine drones. 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] Storing System Settings using STON

by stepharo

Cool! Could you send an example of the file contents? Stef Le 12/10/15 21:45, Juraj Kubelka a Ã©crit : > Hi, > > we have a slice that introduce new storage solution for System > Settings. See: > https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON > > > You can load it using: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; > package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; > load. > > When you open the Setting Browser, you can see that every setting has > new items in context menu: > > > Thanks for reviewing it. > Cheers, > Juraj

Oct. 15, 2015

Re: [Pharo-dev] Random forest in Pharo

by stepharo

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 <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 > > > > "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

Re: [Pharo-dev] GTools merging configurations

by stepharo

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. Stef Le 14/10/15 22:20, Andrei Chis a Ã©crit : > Hi, > > For the GTInspector, GTPlayground and GTSpotter we now have distinct > configurations. > However, this complicates the integration process with Pharo as a lot > of configurations need to be updated. > So we'd like to merge them in ConfigurationOfGToolkitCore. > > What do you think? > This will simplify a lot the integration process. > > Cheers, > Andrei

Oct. 15, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50385 Home: https://github.com/pharo-project/pharo-core

Oct. 15, 2015

[pharo-project/pharo-core] 4b94be: 50385

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 4b94be1f472909b6628f145ea97f8ff0148efe3f https://github.com/pharo-project/pharo-core/commit/4b94be1f472909b6628f145e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-15 (Thu, 15 Oct 2015) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/accessing/model_.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToAnnouncements.st R Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToMCAnnouncements.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToSystemAnnouncements.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToTestAnnouncements.st A Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/unregisterToAnnouncements.st A Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/unregisterToGroupAnnouncements.st A Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/unregisterToSystemAnnouncements.st A Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/unregisterToTestAnnouncements.st M Nautilus.package/AbstractNautilusUI.class/instance/displaying/open.st M OpalTools.package/GTBytecodeBrowser.class/instance/building/sourceIn_.st M OpalTools.package/GTIRBrowser.class/instance/building/sourceIn_.st M OpalTools.package/GTOpalScopeBrowser.class/instance/building/sourceIn_.st M OpalTools.package/extension/IRInstruction/instance/gtInspectorSourceCodeIn_.st M OpalTools.package/extension/IRSequence/instance/gtInspectorSourceCodeIn_.st M OpalTools.package/extension/OCAbstractScope/instance/gtInspectorSourceCodeIn_.st M OpalTools.package/extension/OCClassScope/instance/gtInspectorSourceCodeIn_.st M OpalTools.package/extension/OCInstanceScope/instance/gtInspectorSourceCodeIn_.st M OpalTools.package/extension/SymbolicBytecode/instance/gtInspectorSourceCodeIn_.st A Refactoring-Critics.package/RBAddRemoveDependentsRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBAddRemoveDependentsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBAddRemoveDependentsRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBAssignmentOnBlockArgumentRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBAssignmentOnBlockArgumentRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBBadMessageRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBBadMessageRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBBadMessageRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBClassNameInSelectorRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBClassNameInSelectorRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBClassNameInSelectorRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBClassNotReferencedRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBClassNotReferencedRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBClassNotReferencedRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBClassVariableCapitalizationRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBClassVariableCapitalizationRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBCollectionCopyEmptyRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBCollectionCopyEmptyRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBCollectionCopyEmptyRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBCompositeLintRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBDefinesEqualNotHashRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBDefinesEqualNotHashRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBDefinesEqualNotHashRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBExcessiveArgumentsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBExcessiveArgumentsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBExcessiveArgumentsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBExcessiveInheritanceRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBExcessiveInheritanceRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBExcessiveInheritanceRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBExcessiveMethodsRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBExcessiveMethodsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBExcessiveMethodsRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBExcessiveVariablesRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBExcessiveVariablesRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBExcessiveVariablesRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBImplementedNotSentRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBImplementedNotSentRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBImplementedNotSentRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBInconsistentMethodClassificationRule.class/class/testing/checksMethod.st R Refactoring-Critics.package/RBInconsistentMethodClassificationRule.class/instance/accessing/resultClass.st A Refactoring-Critics.package/RBInconsistentMethodClassificationRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBInconsistentMethodClassificationRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBInstVarInSubclassesRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBInstVarInSubclassesRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBInstanceVariableCapitalizationRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBInstanceVariableCapitalizationRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBJustSendsSuperRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBJustSendsSuperRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBJustSendsSuperRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBLintRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBLintRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBLintRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBLiteralArrayContainsCommaRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBLiteralArrayContainsCommaRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBLiteralArrayContainsCommaRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBLocalMethodsOfAClassNotInItsTraitComposition.class/class/testing/checksClass.st A Refactoring-Critics.package/RBLocalMethodsOfAClassNotInItsTraitComposition.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBLongMethodsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBLongMethodsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBLongMethodsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBMethodHasNoTimeStampRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBMethodHasNoTimeStampRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBMethodHasNoTimeStampRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBMethodSourceContainsLinefeedsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBMethodSourceContainsLinefeedsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBMethodSourceContainsLinefeedsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBMissingSubclassResponsibilityRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBMissingSubclassResponsibilityRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBMissingSuperSendsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBMissingSuperSendsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBMissingSuperSendsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBNoClassCommentRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBNoClassCommentRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBNoClassCommentRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBOnlyReadOrWrittenVariableRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBOnlyReadOrWrittenVariableRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBOverridesSpecialMessageRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBOverridesSpecialMessageRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBParseTreeLintRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBParseTreeLintRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBParseTreeLintRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBRefersToClassRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBRefersToClassRule.class/instance/running/basicCheck_.st R Refactoring-Critics.package/RBRefersToClassRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBRefersToClassRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBReturnsBooleanAndOtherRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBReturnsBooleanAndOtherRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBReturnsBooleanAndOtherRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBSendsDifferentSuperRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBSendsDifferentSuperRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBSendsMethodDictRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBSendsMethodDictRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBSendsMethodDictRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBSentNotImplementedRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBSentNotImplementedRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBSubclassResponsibilityNotDefinedRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBSubclassResponsibilityNotDefinedRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBSubclassResponsibilityNotDefinedRule.class/instance/running/checkClass_.st A Refactoring-Critics.package/RBSuperSendsNewRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBSuperSendsNewRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBSuperSendsNewRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBTemporaryVariableCapitalizationRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBTemporaryVariableCapitalizationRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBTempsReadBeforeWrittenRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBTempsReadBeforeWrittenRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBTransformationRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBTransformationRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBTransformationRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBUnaryAccessingMethodWithoutReturnRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUnaryAccessingMethodWithoutReturnRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBUnaryAccessingMethodWithoutReturnRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBUnclassifiedMethodsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUnclassifiedMethodsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBUnclassifiedMethodsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBUncommonMessageSendRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUncommonMessageSendRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBUndeclaredReferenceRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUndeclaredReferenceRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBUnpackagedCodeRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBUnpackagedCodeRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUnpackagedCodeRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBUnpackagedCodeRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBUnpackagedCodeRule.class/instance/running/checkMethod_.st R Refactoring-Critics.package/RBUnpackagedCodeRule.class/instance/running/isUnpackaged_.st A Refactoring-Critics.package/RBUnreferencedVariablesRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBUnreferencedVariablesRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBUsesTrueRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUsesTrueRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBUsesTrueRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBUtilityMethodsRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBUtilityMethodsRule.class/instance/running/basicCheck_.st M Refactoring-Critics.package/RBUtilityMethodsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/RBVariableAssignedLiteralRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBVariableAssignedLiteralRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBVariableNotDefinedRule.class/class/testing/checksMethod.st A Refactoring-Critics.package/RBVariableNotDefinedRule.class/instance/running/basicCheck_.st A Refactoring-Critics.package/RBVariableReferencedOnceRule.class/class/testing/checksClass.st A Refactoring-Critics.package/RBVariableReferencedOnceRule.class/instance/running/basicCheck_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50384.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50385.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50384.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50385.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50385 16770 Create a basic version of checking methods in LintRules https://pharo.fogbugz.com/f/cases/16770 16785 Replace the usages of #smalltalkCode in OpalTools https://pharo.fogbugz.com/f/cases/16785 16525 Nautilus leaking SystemAnnouncements https://pharo.fogbugz.com/f/cases/16525 http://files.pharo.org/image/50/50385.zip

Oct. 15, 2015

Re: [Pharo-dev] tests should be green

by Marcus Denker

Yes, -> there is a bug somewhere that flattens traits in some cases -> we need to write a script to delete all the wrong methods. > On 14 Oct 2015, at 17:16, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Please, someone can look at the Collections-Tests > The ReleaseTest complains about > > testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits > (These are all Test-subclasses that use traits, but all(!) trait method are > compiled in the class instead, this happened after someone moved the Test > packages (for bootstrap?) > > OrderedCollectionTest > FloatArrayTest > ArrayTest > DateTest > HeapTest > MorphicTextAdapter > LinkedListTest > DatePrintFormatTester > StackTest > CheckboxButtonMorph > IntervalTest > DateAndTimeTest > SimpleButtonMorph > MethodDictionaryTest > SetTest > DictionaryTest > BagTest > SymbolTest > StringTest > CollectionRootTest > SortedCollectionTest >

Oct. 15, 2015

Re: [Pharo-dev] TestPGConnection>>testNotify2 fails

by Levente Uzonyi

Notices and notifications are entirely different things in Postgresql, so I guess something got mixed up here. Levente On Wed, 14 Oct 2015, Esteban A. Maringolo wrote: > Problem Â¿solved? > > I ran the test against a PostgreSQL 9.2 and the test passed. > > However the test passes... but it is failing silently, because it > should raise a NoticeResponse and it's throwing a PGErrorResponse > instead. > > It seems like this has been buried for years, and because nobody ever > complained about it I guess nobody uses it. > > Regards! > > Esteban A. Maringolo > > > 2015-10-14 14:20 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> I have a failing test in my computer when running the test mentioned >> in the subject, I get the following error: "PGConnection has a >> defective state machine" >> >> Stack: >> PGConnection(Object)>>error: >> PGConnection(PGActiveObject)>>stCantHappen: >> PGConnection>>stCantHappen: >> PGConnection(PGActiveObject)>>processEvent: >> PGConnection(PGActiveObject)>>generateEvent:to: >> PGConnection(PGActiveObject)>>saProcessEventsUntil: >> PGConnection>>copy:withStream: >> TestPGConnection>>testNotify2 >> >> I tested in my computer with Pharo4, Pharo3 and Pharo2, and I get the >> same error in all the images with the latest version of it, and also >> with the oldest I could load (in Pharo 2, Name: PostgresV2-Maiano.24). >> >> My PostgreSQL server version is 9.3.7. >> >> Does it fail for you too? >> >> Regards! >> >> Esteban. > >

Oct. 14, 2015

GTools merging configurations

by Andrei Chis

Hi, For the GTInspector, GTPlayground and GTSpotter we now have distinct configurations. However, this complicates the integration process with Pharo as a lot of configurations need to be updated. So we'd like to merge them in ConfigurationOfGToolkitCore. What do you think? This will simplify a lot the integration process. Cheers, Andrei

Oct. 14, 2015