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

STHub is fast!!

by Max Leske

To whoever made STHub suddenly run fast: THANK YOU!! SOOOOO MUCH!! Max

March 4, 2015

heads up: Gitorious â Gitlab

by Damien Pollet

I remember there were a few packages managed on Gitorious (VM-related I thinkâ¦ Esteban, Igor?) Well, Gitlab just acquired Gitorious, and projects will have to be migrated before may: https://about.gitlab.com/2015/03/03/gitlab-acquires-gitorious/ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 4, 2015

Re: [Pharo-dev] strange bevahiour between three dependent Metacello configurations

by Dale Henrichs

Stef, You can use the `get` command in the Metacello scripting api[1] to force a reload of a ConfigurationOf/BaselineOf. I don't think that the lastest version of Metacello is loaded into Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] (that'll work for Pharo4.0 and Pharo3.0) .... If you are going to use the Metacello scripting api, then you should be using the scripting api for loading as well ... the scripting API records the versions of projects that you've loaded into the image while the old way of loading calculates the loaded version which is slow and at times just plain wrong. Metacello new configuration: 'GlamourCore'; version: #development; get; load Refreshes the ConfigurationOfGlamourCore and then does the load. There is also a bit more documentation in the Metacello User Guide[3]... Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr… [2] https://github.com/dalehenrich/metacello-work#pharo30 [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… On 03/04/2015 08:57 AM, Stefan Reichhart wrote: > Hi, > > We solved it but we could still need some help from you. > > Without using gofer to load/update metacello configurations > manually/explicitly, is there a way to force metacello to update > existing configurations to the very latest ones while metacello is > loading a configuration ? > > Example: > > The dependencies of the configurations is as follows: > ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + > ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter > ... > Whereas ConfigurationOfGTInspectorCore, > ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already > in a fresh Pharo 4 image (but outdated) > > Updating and loading "ConfigurationOfGToolkitCore" will only load > itself and the latest packages that are defined by the configurations > which are already in the image. But we would actually like to update > those configurations (and their packages) as well. Otherwise the load > would be "incomplete" (dependencies broken). > > Can Metacello do that ? Is there an easy way to do it ? Or is gofer > the only solution ? > > How do you handle configurations that depend on other configurations > (already loaded, but outdated) ? <-> Consistency of dependencies > > > Thanks > stef > > > ---------- > > > What we want is equivalent to the following snippet: > > { 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. > 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. > 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ > :aConfigurationName | > Gofer new > smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; > package: aConfigurationName; > load ]. > (ConfigurationOfGToolkitCore project version: #development) load. > > > > > Am 04/03/15 um 14:53 schrieb Andrei Chis: >> Hi, >> >> We fixed this but we are not sure if the behaviour that we got was a >> result of a bug or a feature in Metacello. >> >> Again our setup is that we have three configurations with linear >> dependencies between them: >> -- ConfigurationOfGTInspectorCore (2.0-baseline) >> -- ConfigurationOfGlamourCore (3.1-baseline) >> -- ConfigurationOfRubric (0.2-baseline) >> >> In ConfigurationOfRubric we had version "1.2.8" that uses >> '0.2-baseline'. >> >> The development version is '0.2-baseline' and the stable version '1.2.8' >> >> [1] (ConfigurationOfGlamourCore project version: #development) record >> loadDirective >> [2] (ConfigurationOfGTInspectorCore project version: #development) >> record loadDirective. >> >> When performing [1] Metacello decides to load Rubric. >> This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" >> (since none was specified before) to figure out whether something should >> be loaded. At a certain point this is executed: >> >> compareCurrentVersion:targetVersionStatus:using: (from above) >> ... >> ... >> ... >> ... >> #allLoadedToSpec = #allLoadedToSpec ===> TRUE >> "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline >> [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE >> ===> Rubric is not removed from the loader list >> >> When performing [2] Metacello decides not to load Rubric. >> In this case Metacello deals first with #ConfigurationOfGlamourCore. But >> after "GlamorCore" has been processed, the operator in the global >> mcLoader is set to ">=". All further specs-to-load >> (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now >> rubric get's removed: >> >> compareCurrentVersion:targetVersionStatus:using: (from above) >> ... >> ... >> ... >> ... >> #allLoadedToSpec >= #allLoadedToSpec ===> TRUE >> "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline >> [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE >> ===> Rubric is removed from the loader list >> >> That's why "Rubric" doesn't show up in the final loader list. The second >> (inner/nested) spec-to-load will remove it (after it has been >> successfully resolved by the previous nested configuration >> ConfigurationOfGlamourCore) because of the operator. >> >> So there is a difference between #ConfigurationOfGlamourCore and >> #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded. >> >> Anybody else encountered this? >> >> Cheers, >> GT team >> >> >> >> >> On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@gmail.com>> wrote: >> >> Hi, >> >> We are having the following problem when trying to update GTolols to >> their latest version in the latest Pharo 4 image: Rubric does not >> get updated. >> We have: >> >> -- ConfigurationOfGTInspectorCore (2.0-baseline) >> -- ConfigurationOfGlamourCore (3.1-baseline) >> -- ConfigurationOfRubric (0.2-baseline) >> >> Performing [1] shows that rubric gets updated (atomic load : >> 0.2-baseline [ConfigurationOfRubric]) >> Performing [2] contains no trace of rubric. >> >> [1] (ConfigurationOfGlamourCore project version: #development) >> record loadDirective >> [2] (ConfigurationOfGTInspectorCore project version: #development) >> record loadDirective. >> >> Loading then the inspector [3] does not update Rubric. >> Loading just Glamour [4] updates it. >> >> [3] (ConfigurationOfGTInspectorCore project version: >> #development) load. >> [4] (ConfigurationOfGlamourCore project version: #development) load >> >> Any ideas or sugestions? Maybe we are missing something trivial. >> This updates the previous configurations to their latest versions: >> >> Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; >> package: 'ConfigurationOfGTInspectorCore'; load. >> Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; >> package: 'ConfigurationOfGlamourCore'; load. >> Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; >> package: 'ConfigurationOfRubric'; load. >> >> >> Cheers, >> Andrei >> >> >

March 4, 2015

Re: [Pharo-dev] PetitParser Tests Failing in Pharo 4.0

by Sven Van Caekenberghe

> On 04 Mar 2015, at 17:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > On Mar 4, 2015, at 11:02 AM, "Marcus Denker-4 [via Smalltalk]" <[hidden email]> wrote: >> We either do that change or we donât. There is no way to keep it backward compatible. > > Thanks for the info. Sorry about my frustration :/ But I just had a huge Aha that may help understanding changes in the future. I went to the GitHub mirror and discovered something /really/ cool... Yes, we are very cool ;-) Seriously though: good explanation. This is again an example of multiple smaller things coming together and amplifying each other. > 1. I navigated to the class side of RBVariableNode and noticed the button with the clock & backward arrow on it > > 2. Clicking it, lead me to a list of commits perfectly scoped to the methods in question. There, I clicked on the SHA of the last commit > > 3. I was presented with a) the image version where it was integrated b) the issues integrated, and c) the method diffs!!! > > I didn't realize that e.g. the update and issue numbers were on github. This is really great. > Cheers, > Sean > > View this message in context: Re: PetitParser Tests Failing in Pharo 4.0 > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2015

Re: [Pharo-dev] strange bevahiour between three dependent Metacello configurations

by Stefan Reichhart

Hi, We solved it but we could still need some help from you. Without using gofer to load/update metacello configurations manually/explicitly, is there a way to force metacello to update existing configurations to the very latest ones while metacello is loading a configuration ? Example: The dependencies of the configurations is as follows: ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter ... Whereas ConfigurationOfGTInspectorCore, ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already in a fresh Pharo 4 image (but outdated) Updating and loading "ConfigurationOfGToolkitCore" will only load itself and the latest packages that are defined by the configurations which are already in the image. But we would actually like to update those configurations (and their packages) as well. Otherwise the load would be "incomplete" (dependencies broken). Can Metacello do that ? Is there an easy way to do it ? Or is gofer the only solution ? How do you handle configurations that depend on other configurations (already loaded, but outdated) ? <-> Consistency of dependencies Thanks stef ---------- What we want is equivalent to the following snippet: { 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ :aConfigurationName | Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; package: aConfigurationName; load ]. (ConfigurationOfGToolkitCore project version: #development) load. Am 04/03/15 um 14:53 schrieb Andrei Chis: > Hi, > > We fixed this but we are not sure if the behaviour that we got was a > result of a bug or a feature in Metacello. > > Again our setup is that we have three configurations with linear > dependencies between them: > -- ConfigurationOfGTInspectorCore (2.0-baseline) > -- ConfigurationOfGlamourCore (3.1-baseline) > -- ConfigurationOfRubric (0.2-baseline) > > In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'. > > The development version is '0.2-baseline' and the stable version '1.2.8' > > [1] (ConfigurationOfGlamourCore project version: #development) record > loadDirective > [2] (ConfigurationOfGTInspectorCore project version: #development) > record loadDirective. > > When performing [1] Metacello decides to load Rubric. > This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" > (since none was specified before) to figure out whether something should > be loaded. At a certain point this is executed: > > compareCurrentVersion:targetVersionStatus:using: (from above) > ... > ... > ... > ... > #allLoadedToSpec = #allLoadedToSpec ===> TRUE > "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline > [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE > ===> Rubric is not removed from the loader list > > When performing [2] Metacello decides not to load Rubric. > In this case Metacello deals first with #ConfigurationOfGlamourCore. But > after "GlamorCore" has been processed, the operator in the global > mcLoader is set to ">=". All further specs-to-load > (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now > rubric get's removed: > > compareCurrentVersion:targetVersionStatus:using: (from above) > ... > ... > ... > ... > #allLoadedToSpec >= #allLoadedToSpec ===> TRUE > "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline > [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE > ===> Rubric is removed from the loader list > > That's why "Rubric" doesn't show up in the final loader list. The second > (inner/nested) spec-to-load will remove it (after it has been > successfully resolved by the previous nested configuration > ConfigurationOfGlamourCore) because of the operator. > > So there is a difference between #ConfigurationOfGlamourCore and > #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded. > > Anybody else encountered this? > > Cheers, > GT team > > > > > On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>> wrote: > > Hi, > > We are having the following problem when trying to update GTolols to > their latest version in the latest Pharo 4 image: Rubric does not > get updated. > We have: > > -- ConfigurationOfGTInspectorCore (2.0-baseline) > -- ConfigurationOfGlamourCore (3.1-baseline) > -- ConfigurationOfRubric (0.2-baseline) > > Performing [1] shows that rubric gets updated (atomic load : > 0.2-baseline [ConfigurationOfRubric]) > Performing [2] contains no trace of rubric. > > [1] (ConfigurationOfGlamourCore project version: #development) > record loadDirective > [2] (ConfigurationOfGTInspectorCore project version: #development) > record loadDirective. > > Loading then the inspector [3] does not update Rubric. > Loading just Glamour [4] updates it. > > [3] (ConfigurationOfGTInspectorCore project version: #development) load. > [4] (ConfigurationOfGlamourCore project version: #development) load > > Any ideas or sugestions? Maybe we are missing something trivial. > This updates the previous configurations to their latest versions: > > Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'ConfigurationOfGTInspectorCore'; load. > Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; > package: 'ConfigurationOfGlamourCore'; load. > Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; > package: 'ConfigurationOfRubric'; load. > > > Cheers, > Andrei > >

March 4, 2015

Re: [Pharo-dev] PetitParser Tests Failing in Pharo 4.0

by Sean P. DeNigris

On Mar 4, 2015, at 11:02 AM, "Marcus Denker-4 [via Smalltalk]" <ml-node+s1294792n4809514h22(a)n4.nabble.com> wrote: > We either do that change or we donât. There is no way to keep it backward compatible. Thanks for the info. Sorry about my frustration :/ But I just had a huge Aha that may help understanding changes in the future. I went to the GitHub mirror and discovered something /really/ cool... 1. I navigated to the class side of RBVariableNode and noticed the button with the clock & backward arrow on it 2. Clicking it, lead me to a list of commits perfectly scoped to the methods in question. There, I clicked on the SHA of the last commit 3. I was presented with a) the image version where it was integrated b) the issues integrated, and c) the method diffs!!! I didn't realize that e.g. the update and issue numbers were on github. This is really great. Screenshot 2015-03-04 11.50.34.png (182K) <http://forum.world.st/attachment/4809534/0/Screenshot%202015-03-04%2011.50.…> Screenshot 2015-03-04 11.48.09.png (94K) <http://forum.world.st/attachment/4809534/1/Screenshot%202015-03-04%2011.48.…> Screenshot 2015-03-04 11.48.37.png (325K) <http://forum.world.st/attachment/4809534/2/Screenshot%202015-03-04%2011.48.…> ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-Tests-Failing-in-Pharo-4-0-tp4809513p4809… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2015

ÐÑÐ²: [Pharo-dev] New Pharo Collections: Question about MultiDictionary

by ÐÐ»ÐµÐºÑÐ°Ð½Ð´Ñ ÐÑÐµÐ½ÑÐµÐ²

Thank you for all of your suggestions. I also think, that name "MultiValue Dictionary" suits to this collection much better. I am not so good at TDD for now, but I'll try to do my best. Tests are coming. Values are stored in ordered collection. So, I'll just explore the whole Dictionary API and try to rework some methods to the idea of values stored in ordered collection, if they'll need this. I'll also think about Max's idea of add: implemetation.Â Best wishes Alexander Brenchev

March 4, 2015

Re: [Pharo-dev] PetitParser Tests Failing in Pharo 4.0

by Nicolai Hess

2015-03-04 16:59 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > RBVariableNode DNU #identifierToken: > > Removed since Pharo 3.0. > No deprecation. > Searching dev list & fogbugz -> 0 hits. > - > 11992 <https://pharo.fogbugz.com/default.asp?11992> Remove tokens from the AST-Core-Node classes > > Guys, we need some discipline. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/PetitParser-Tests-Failing-in-Pharo-4-0-tp4809513.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 4, 2015

Re: [Pharo-dev] PetitParser Tests Failing in Pharo 4.0

by Marcus Denker

> On 04 Mar 2015, at 16:59, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > RBVariableNode DNU #identifierToken: > > Removed since Pharo 3.0. > No deprecation. > Searching dev list & fogbugz -> 0 hits. > > Guys, we need some discipline. > We changes the AST to have no tokens anymore. We either do that change or we donât. There is no way to keep it backward compatible. Marcus

March 4, 2015

PetitParser Tests Failing in Pharo 4.0

by Sean P. DeNigris

RBVariableNode DNU #identifierToken: Removed since Pharo 3.0. No deprecation. Searching dev list & fogbugz -> 0 hits. Guys, we need some discipline. ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-Tests-Failing-in-Pharo-4-0-tp4809513.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2015