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

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