September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo Success Stories on homepage

by Esteban A. Maringolo

Yes please. The co-owner of my company asked me, worried, if we were the only ones using "this technology". :) Esteban A. Maringolo 2014-09-09 12:33 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, we are slowly uploading themâ¦ maybe we should speed up the process :) > > Esteban > > On 09 Sep 2014, at 17:28, Torsten Bergmann <astares(a)gmx.de> wrote: > >> The new homepage shows only 2 (!) success story. But we have so many >> as one can see here: >> >> http://rmod.lille.inria.fr/archives/events/2012PharoConf/SuccessStories >> http://files.pharo.org/successStories >> >> This gives a false impression on the homepage to newcomers. If it is a >> time issue then at least the links should be added. >> >> >> >> > >

Sept. 9, 2014

Re: [Pharo-dev] Pharo Success Stories on homepage

by Esteban Lorenzano

yes, we are slowly uploading themâ¦ maybe we should speed up the process :) Esteban On 09 Sep 2014, at 17:28, Torsten Bergmann <astares(a)gmx.de> wrote: > The new homepage shows only 2 (!) success story. But we have so many > as one can see here: > > http://rmod.lille.inria.fr/archives/events/2012PharoConf/SuccessStories > http://files.pharo.org/successStories > > This gives a false impression on the homepage to newcomers. If it is a > time issue then at least the links should be added. > > > >

Sept. 9, 2014

Pharo Success Stories on homepage

by Torsten Bergmann

The new homepage shows only 2 (!) success story. But we have so many as one can see here: http://rmod.lille.inria.fr/archives/events/2012PharoConf/SuccessStories http://files.pharo.org/successStories This gives a false impression on the homepage to newcomers. If it is a time issue then at least the links should be added.

Sept. 9, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by kilon alios

hmm my mistake, I must have mixed something up I can see now my progress bar On Tue, Sep 9, 2014 at 12:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > I can see your changes in the pharolauncher build 891 > > "Pharo Contribution Jenkins-PharoLauncher-#891" > > PharoLauncher-Core: > > Name: PharoLauncher-Core-kilonAlios.62 > Author: kilonAlios > Time: 8 September 2014, 3:09:22.87321 pm > UUID: 368940aa-996d-e34a-989c-63c618316b37 > Ancestors: PharoLauncher-Core-TimMackinnon.61 > > > > > > > 2014-09-09 10:15 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > >> revise away, downloading in the background sounds very cool. I also have >> some more contributions to make. >> >> By the way my commit was successful >> >> >> http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher/diff/PharoLauncher-Core… >> >> The build was succesful >> >> >> https://ci.inria.fr/pharo-contribution/job/PharoLauncher/PHARO=30,VERSION=b… >> >> but when I downloaded the new PharoLauncher image to my surprise the code >> was nowhere to be found. Its strange because the log says it loads the >> bleeding edge of PharoLauncher so that means it should pull in my change ? >> Am I correct ? Any idea what is wrong here ? >> >> On Mon, Sep 8, 2014 at 3:30 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> kilon alios wrote: >>> >>> It should not be a problem because it affects only the PharoLauncher image >>> and not the images you download with PharoLauncher so the old progress bar >>> will remain in those images. >>> >>> Its personal taste of course but let remember here that a common complain >>> about smalltalk is that it looks weird and for some people ugly. How many >>> progress bars you have seen up left ? What advantage is there for a >>> progress bar to be up left ? >>> >>> Also because when performing such jobs pharo freezes and does not allow for >>> further interactions with the user until the job ends it makes more sense >>> for the progress bar to be in the middle , bigger size so its very visible >>> even from distance if the user decides to leave the screen to grab some >>> coffee or fight with his light saber and if possible even display a "Please >>> wait..." message so the user / beginner Pharoers knows this is not a bug or >>> he /she did not brake Pharo. >>> >>> >>> >>> Thats cool, but I may revise it later if I actually get around to making >>> PharoLauncher download images in the background. A few other things on my >>> plate to clear first. >>> cheers -ben >>> >>> >>> I am not saying Pharo should be an exact copy of the GUIs out there but at >>> least we should respect the user habits and broke those habits only if it >>> is necessary. Or else you will have more and more people looking at the >>> GUI and going "Eeeewwww". >>> >>> On Mon, Sep 8, 2014 at 2:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> <sven(a)stfx.eu> wrote: >>> >>> >>> >>> Nice, but did you see SystemProgressMorph class>>#settingsOn: ? In other >>> words, there are preferences for the location of the progress bar, these >>> should probably be honoured. A big or a small bar also depends a bit on >>> taste I would say. >>> >>> On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> wrote: >>> >>> >>> >>> ok with a bit of help I was able to figure things out, it turns out that >>> >>> >>> it was simple to do difficult to understand :D so here is my answer >>> >>> >>> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >>> >>> I also attached the new progress bar i customised and the old for >>> >>> >>> comparison as attached images >>> >>> >>> <newProgressBar.JPG> >>> >>> <oldProgressBar.JPG> >>> â >>> Personally I would make my code the default Progress Bar for entire >>> >>> >>> Pharo including all operations because its annoying to be that small and up >>> there. This should work well even if there are multiple Progress Bars >>> displayed. But for not its PharoLauncher only progress bar. >>> >>> >>> How I add this code to PharoLauncher ? do I use just the development >>> >>> >>> mode of PharoLauncher and Commit ? I dont want to mess anything up. >>> >>> >>> Next step would be to add an info box for each image so people know what >>> >>> >>> they download before downloading it. >>> >>> >>> On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> >>> >>> wrote: >>> >>> >>> yeah yeah I see it now, there actually many announcers (3 of them ) all >>> >>> >>> seem to signal SystemProgressMorph , oh boy this will be a tricky one . >>> Thanks for the pointer, now I have to find how to capture the instance of >>> that SystemProgressMorph. If I find the instance sending a width: message >>> should do the trick. Looks like I will need to investigate further but at >>> least you are pointed me to the right direction so I no longer feel lost in >>> space. >>> >>> >>> On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier < >>> >>> >>> thierry.goubier(a)gmail.com> wrote: >>> >>> >>> Le 07/09/2014 11:53, kilon alios a Ã©crit : >>> >>> Hello pharoers it has been almost a year since the last time I commited >>> >>> >>> to PharoLauncher so I decided to go for it once again. The first time I >>> added a progress bar for people to see the progress of the download of the >>> image . Now I want to scale and reposition the progress bar as I am not >>> happy at all in the way it looks , its too small and hard to read. >>> >>> >>> So I created a question at stackoverflow with all the details of my >>> >>> >>> problem >>> >>> >>> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >>> >>> I would not mind also some extra details on how I can fetch the Morphs >>> >>> >>> used by UIManager or to even further customise UIManager. I tried to find >>> the answer myself but after an hour of staring at the Pharo system browser >>> I gave up. >>> >>> >>> Hi Kilon, >>> >>> I don't have a stackoverflow account, so here is what I found. >>> >>> From displayProgress: , asJob brings you to Job, which has no morph at >>> >>> >>> all. But, on the class side of Job, you have a job announcer (instance >>> class variable jobAnnouncer). Inspect that variable, search among the >>> subscriptions of the announcer, and you'll find SystemProgressMorph. >>> >>> >>> A good use case of a fairly good design which is a lot harder to unravel >>> >>> >>> than it should be, due to the lack of tools to explore announcer / >>> subscription relations. >>> >>> >>> Thierry >>> >>> >>> >>> >>> >>> >>> >> >

Sept. 9, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 9, 2014

[pharo-project/pharo-core] b8f125: 40215

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b8f1253e51bede13b294f6b1c6c90df2b43161e8 https://github.com/pharo-project/pharo-core/commit/b8f1253e51bede13b294f6b1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-09 (Tue, 09 Sep 2014) Changed paths: M Monticello.package/MCFileBasedRepository.class/instance/accessing/readableFileNames.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script215.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40215.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40215 13421 Problem in Monticello and the cached packages https://pharo.fogbugz.com/f/cases/13421 http://files.pharo.org/image/40/40215.zip

Sept. 9, 2014

Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix

by Nicolai Hess

fogbugz entry for fixing the menu builder 13979 <https://pharo.fogbugz.com/default.asp?13979> PragmaMenuBuilder relies on modifying a collection while iterating over it. 2014-09-03 22:59 GMT+02:00 stepharo <stepharo(a)free.fr>: > Clement we should fix the code of the menu :) > > Stef > > > On 3/9/14 15:25, ClÃ©ment Bera wrote: > > Hello, > > Sven you are right, the old compiler was consistent in the sense that it > always iterated over all the elements, including the ones added with #add: > and #addLast: while iterating over the collection. > On the other hand, VW is consistent with the Opal implementation for > #to:do: in the sense that they iterate only on the elements of the > collection excluding the ones added while iterating. > > #add:after: and co do not work well if you edit the collection while > iterating over it for sure :). > > It's too late for "don't modify a collection while iterating it" because > the system does it, for example, to build the world menu. So I think the > solution is in two steps: > - removing code which edit the collection while iterating over it. As most > frameworks work both on Pharo and VW and that the behavior is different I > think there shouldn't be that much, so fixing the Pharo image may be enough. > - be consistent in our collection protocol, basically by rewriting do: and > reverseDo: like that: > > FROM: > do: aBlock > "Override the superclass for performance reasons." > | index | > index := firstIndex. > [index <= lastIndex] > whileTrue: > [aBlock value: (array at: index). > index := index + 1] > TO: > do: aBlock > "Override the superclass for performance reasons." > firstIndex to: lastIndex do: [ :index | > aBlock value: (array at: index) ] > > > > > > 2014-09-03 14:05 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com>: > >> >> On 3 sept. 2014, at 11:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> > Hello guys, >> > >> > I was looking into the OrderedCollection protocols recently to see how >> well the sista optimizer perform with it methods, and I realized that this >> is completely broken. >> > >> > For example: >> > >> > col := #(1 2 3 4 5) asOrderedCollection. >> > col do: [ :elem | elem trace . >> > elem < 4 ifTrue: [ col add: col size + 1 ]]. >> > >> > => '12345678' >> > >> > However: >> > >> > col := #(1 2 3 4 5) asOrderedCollection. >> > col collect: [ :elem | elem trace . >> > elem < 4 ifTrue: [ col add: col size + 1 ]]. >> > >> > => '12345' >> > >> > This means that #do: and #reverseDo: iterate over all the elements of >> the collection,*including* the ones that you are adding while iterating >> over the collection, whereas all the other OrderedCollection protocols, >> such as #collect:, #select:, iterates over all the elements of the >> collection, *excluding* the ones you are adding while iterating over the >> collection. >> > >> > Marcus argued that one should not edit a collection while iterating >> over it, however this point is not valid as the World menu relies on this >> feature, using #do: to iterate over the elements of the OrderedCollection >> including the one it is adding while iterating over the collection. >> Changing the implementation makes the world menu display half of its items. >> > >> > I don't like this difference because it is inconsistent. For example, >> refactoring a #do: into a #collect: can simply not work because they do not >> iterate over the same elements if you are editing the collection while >> iterating over it. >> > >> > In VW, the protocols are consistent and iterating over a collection >> never iterates over the elements one is adding while iterating over it. >> Therefore, I believe most frameworks should expect this behavior (at least >> the ones cross smalltalk) which sounds the most correct. >> > >> > I think we should fix the world menu implementation and make the >> protocols consistent. Alternatively, we can let VW be a much more >> consistent Smalltalk environment than Pharo. What do you think ? >> >> >> The thing is to find alternative implementations that are efficient >> enough (no copy). Maybe we can get some inspirations from VW for that (how >> do they do BTW?). >> You should also check with other kinds of collection because they may act >> differently than OrderedCollection. >> So in the end it depends on the amount of effort needed to make all >> collections consistent with this new requirement and on the resulting >> overhead. >> If it's too much, I think that following the old advice "don't modify a >> collection while iterating it" is enough. If one really needs to do such >> kind of things he should consider an alternative design like using a zipper >> for example. >> >> Camille >> >> > >> > Clement >> > >> >> >> > >

Sept. 9, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by Nicolai Hess

I can see your changes in the pharolauncher build 891 "Pharo Contribution Jenkins-PharoLauncher-#891" PharoLauncher-Core: Name: PharoLauncher-Core-kilonAlios.62 Author: kilonAlios Time: 8 September 2014, 3:09:22.87321 pm UUID: 368940aa-996d-e34a-989c-63c618316b37 Ancestors: PharoLauncher-Core-TimMackinnon.61 2014-09-09 10:15 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > revise away, downloading in the background sounds very cool. I also have > some more contributions to make. > > By the way my commit was successful > > > http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher/diff/PharoLauncher-Core… > > The build was succesful > > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher/PHARO=30,VERSION=b… > > but when I downloaded the new PharoLauncher image to my surprise the code > was nowhere to be found. Its strange because the log says it loads the > bleeding edge of PharoLauncher so that means it should pull in my change ? > Am I correct ? Any idea what is wrong here ? > > On Mon, Sep 8, 2014 at 3:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> kilon alios wrote: >> >> It should not be a problem because it affects only the PharoLauncher image >> and not the images you download with PharoLauncher so the old progress bar >> will remain in those images. >> >> Its personal taste of course but let remember here that a common complain >> about smalltalk is that it looks weird and for some people ugly. How many >> progress bars you have seen up left ? What advantage is there for a >> progress bar to be up left ? >> >> Also because when performing such jobs pharo freezes and does not allow for >> further interactions with the user until the job ends it makes more sense >> for the progress bar to be in the middle , bigger size so its very visible >> even from distance if the user decides to leave the screen to grab some >> coffee or fight with his light saber and if possible even display a "Please >> wait..." message so the user / beginner Pharoers knows this is not a bug or >> he /she did not brake Pharo. >> >> >> >> Thats cool, but I may revise it later if I actually get around to making >> PharoLauncher download images in the background. A few other things on my >> plate to clear first. >> cheers -ben >> >> >> I am not saying Pharo should be an exact copy of the GUIs out there but at >> least we should respect the user habits and broke those habits only if it >> is necessary. Or else you will have more and more people looking at the >> GUI and going "Eeeewwww". >> >> On Mon, Sep 8, 2014 at 2:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> <sven(a)stfx.eu> wrote: >> >> >> >> Nice, but did you see SystemProgressMorph class>>#settingsOn: ? In other >> words, there are preferences for the location of the progress bar, these >> should probably be honoured. A big or a small bar also depends a bit on >> taste I would say. >> >> On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> wrote: >> >> >> >> ok with a bit of help I was able to figure things out, it turns out that >> >> >> it was simple to do difficult to understand :D so here is my answer >> >> >> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >> >> I also attached the new progress bar i customised and the old for >> >> >> comparison as attached images >> >> >> <newProgressBar.JPG> >> >> <oldProgressBar.JPG> >> â >> Personally I would make my code the default Progress Bar for entire >> >> >> Pharo including all operations because its annoying to be that small and up >> there. This should work well even if there are multiple Progress Bars >> displayed. But for not its PharoLauncher only progress bar. >> >> >> How I add this code to PharoLauncher ? do I use just the development >> >> >> mode of PharoLauncher and Commit ? I dont want to mess anything up. >> >> >> Next step would be to add an info box for each image so people know what >> >> >> they download before downloading it. >> >> >> On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> >> >> wrote: >> >> >> yeah yeah I see it now, there actually many announcers (3 of them ) all >> >> >> seem to signal SystemProgressMorph , oh boy this will be a tricky one . >> Thanks for the pointer, now I have to find how to capture the instance of >> that SystemProgressMorph. If I find the instance sending a width: message >> should do the trick. Looks like I will need to investigate further but at >> least you are pointed me to the right direction so I no longer feel lost in >> space. >> >> >> On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier < >> >> >> thierry.goubier(a)gmail.com> wrote: >> >> >> Le 07/09/2014 11:53, kilon alios a Ã©crit : >> >> Hello pharoers it has been almost a year since the last time I commited >> >> >> to PharoLauncher so I decided to go for it once again. The first time I >> added a progress bar for people to see the progress of the download of the >> image . Now I want to scale and reposition the progress bar as I am not >> happy at all in the way it looks , its too small and hard to read. >> >> >> So I created a question at stackoverflow with all the details of my >> >> >> problem >> >> >> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >> >> I would not mind also some extra details on how I can fetch the Morphs >> >> >> used by UIManager or to even further customise UIManager. I tried to find >> the answer myself but after an hour of staring at the Pharo system browser >> I gave up. >> >> >> Hi Kilon, >> >> I don't have a stackoverflow account, so here is what I found. >> >> From displayProgress: , asJob brings you to Job, which has no morph at >> >> >> all. But, on the class side of Job, you have a job announcer (instance >> class variable jobAnnouncer). Inspect that variable, search among the >> subscriptions of the announcer, and you'll find SystemProgressMorph. >> >> >> A good use case of a fairly good design which is a lot harder to unravel >> >> >> than it should be, due to the lack of tools to explore announcer / >> subscription relations. >> >> >> Thierry >> >> >> >> >> >> >> >

Sept. 9, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 9, 2014

[pharo-project/pharo-core] f681e6: 40214

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f681e684b87198b4254c801cab43063920e9661c https://github.com/pharo-project/pharo-core/commit/f681e684b87198b4254c801c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-09 (Tue, 09 Sep 2014) Changed paths: M Refactoring-Critics.package/RBAbstractClassRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBAssignmentOnBlockArgumentRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBClassNotReferencedRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBImplementedNotSentRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBJustSendsSuperRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBLongMethodsRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBMethodSourceContainsLinefeedsRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBNoClassCommentRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBParseTreeLintRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBReturnsBooleanAndOtherRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSendsDifferentSuperRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSendsMethodDictRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSentNotImplementedRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSuperSendsNewRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTemporaryVariableCapitalizationRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTempsReadBeforeWrittenRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTransformationRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBUncommonMessageSendRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBUndeclaredReferenceRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBUnreferencedVariablesRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBUtilityMethodsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/extension/CompiledMethod/instance/selfMessages.st A Refactoring-Critics.package/extension/CompiledMethod/instance/superMessages.st A Refactoring-Critics.package/extension/SystemNavigation/instance/implementorsExistOf_.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/possible bugs/abstractClass.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/unnecessary code/classNotReferenced.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/unnecessary code/implementedNotSent.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/unnecessary code/unreferencedVariables.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script214.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40214.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40214 13955 Rewrite Lint rules to use common tools https://pharo.fogbugz.com/f/cases/13955 http://files.pharo.org/image/40/40214.zip

Sept. 9, 2014