- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PharoLauncher mac download not the latest version

by kilon alios

ah ok yes I realised that it was a complex process one build triggering the other build but I did not notice it was triggered manually. Yes I agree thats a good idea but I expected this control to be at Configuration level by having a "stable" release. On Wed, Sep 10, 2014 at 12:25 PM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > >> So I re downloaded PharoLauncher using this link >> https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/ >> lastSuccessfulBuild/artifact/pharo-ci/Pharo%203.0.0.dmg >> >> and it is not the latest version as it does not contain the latest commit >> which is my commit with the new progress bar. At first I thought that it >> was loading something else than bleedingEdge configuration but I don't see >> anything else in the ConfigurationOfPharoLauncher. Am I doing something >> wrong ? >> > > Notice at [1] that its upstream trigger is [2] which has no upstream > project, and all builds have been started by Damien by hand (hover over the > person icons). I guess the approach is that uploads to the PharoLauncher > repository can be fairly unrestricted, with only the risk only of breaking > [3] as the bleeding edge CI job (also trigger by Pharo bleeding edge > updates). I like this approach since it helps collaboration and review of > changes, with less fear uploading a change will break the world, with more > quality control applied to [1] as a "Release" mechanism. > [1] https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/ > [2] https://ci.inria.fr/pharo-contribution/job/ > PharoLauncherFinalUserImage/ > [3] https://ci.inria.fr/pharo-contribution/job/PharoLauncher/ > > cheers -ben > >

Sept. 10, 2014

Re: [Pharo-dev] PharoLauncher mac download not the latest version

by Ben Coman

kilon alios wrote: > So I re downloaded PharoLauncher using this link > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/lastSu… > > and it is not the latest version as it does not contain the latest > commit which is my commit with the new progress bar. At first I > thought that it was loading something else than bleedingEdge > configuration but I don't see anything else in the > ConfigurationOfPharoLauncher. Am I doing something wrong ? Notice at [1] that its upstream trigger is [2] which has no upstream project, and all builds have been started by Damien by hand (hover over the person icons). I guess the approach is that uploads to the PharoLauncher repository can be fairly unrestricted, with only the risk only of breaking [3] as the bleeding edge CI job (also trigger by Pharo bleeding edge updates). I like this approach since it helps collaboration and review of changes, with less fear uploading a change will break the world, with more quality control applied to [1] as a "Release" mechanism. [1] https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/ [2] https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/ [3] https://ci.inria.fr/pharo-contribution/job/PharoLauncher/ cheers -ben

Sept. 10, 2014

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

by ClÃ©ment Bera

2014-09-10 10:16 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Thanks ClÃ©ment, but it was really easy and trivial - Nicolai did the hard > work with the pragma builder. > Ok I thought you did both. Thanks Nicolai too then. > > I was wondering, does the optimiser also deal with #to:do:by as well as > #to:do: ? Yes. To have the optimizer working you need a comparison to escape the loop with < <= > or >= as selector, the comparison needs to compare a temp holding a smallinteger (the loop iterator) against another temp or self, and then you need an operation in the loop body that increments or decrements the loop iterator by a smallinteger constant. If all the conditions are met then the smallintegers operations and the array access have their overflow and bounds checks moved ahead of the loop body instead of at each iteration (and even removed if possible) based on the ranges the variables can have. The current problem was that with #whileTrue: the loop comparison was against an instance variable. Instance variables are problematic because then can be changed from other methods called by the loop body. Basically the optimizer can optimize mostly the receiver and the temporary variables, because to edit them from the outside of the method you need to do #become: or context access, and both cases are handled specifically. But we're at least a year from production so don't expect too much now :/. > > On 10 Sep 2014, at 10:13, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > I like your slice Sven. The code is easier to read now in > OrderedCollection and my optimizer can perform better. > > > > Thanks :) > > > > 2014-09-10 9:04 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > I added a slice for > https://pharo.fogbugz.com/f/cases/13985/OrderedCollection-do-and-reverseDo-… > > > > On 09 Sep 2014, at 12:53, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > fogbugz entry for fixing the menu builder > > > 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. 10, 2014

PharoLauncher mac download not the latest version

by kilon alios

So I re downloaded PharoLauncher using this link https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/lastSu… and it is not the latest version as it does not contain the latest commit which is my commit with the new progress bar. At first I thought that it was loading something else than bleedingEdge configuration but I don't see anything else in the ConfigurationOfPharoLauncher. Am I doing something wrong ?

Sept. 10, 2014

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

by Sven Van Caekenberghe

Thanks ClÃ©ment, but it was really easy and trivial - Nicolai did the hard work with the pragma builder. I was wondering, does the optimiser also deal with #to:do:by as well as #to:do: ? On 10 Sep 2014, at 10:13, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > I like your slice Sven. The code is easier to read now in OrderedCollection and my optimizer can perform better. > > Thanks :) > > 2014-09-10 9:04 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I added a slice for https://pharo.fogbugz.com/f/cases/13985/OrderedCollection-do-and-reverseDo-… > > On 09 Sep 2014, at 12:53, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > fogbugz entry for fixing the menu builder > > 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. 10, 2014

Re: [Pharo-dev] from time to time I get a crash when increasing the main window size

by ClÃ©ment Bera

It happens while loading code with Monticello, isn't it ? 2014-09-10 9:48 GMT+02:00 stepharo <stepharo(a)free.fr>: > basicNew > value: > new: > replaceFrom:to:with:startingAt: > new: > basicNew > new: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > value: > primShowRectLeft:right:top:bottom: > value: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > primShowRectLeft:right:top:bottom: > > I will try to reproduce it. > > > >

Sept. 10, 2014

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

by ClÃ©ment Bera

I like your slice Sven. The code is easier to read now in OrderedCollection and my optimizer can perform better. Thanks :) 2014-09-10 9:04 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I added a slice for > https://pharo.fogbugz.com/f/cases/13985/OrderedCollection-do-and-reverseDo-… > > On 09 Sep 2014, at 12:53, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > fogbugz entry for fixing the menu builder > > 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. 10, 2014

Re: [Pharo-dev] latex exporter in Pillar

by kilon alios

last time I asked footnotes were not supported by Pillar. However you can use Latex syntax to add a footnote. see section 3.9 here about using Latex syntax ---> https://www.gitbook.io/book/damiencassou/pillar and here is how to add footnotes in Latex ---> http://en.wikibooks.org/wiki/LaTeX/Footnotes_and_Margin_Notes On Wed, Sep 10, 2014 at 2:27 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > How can I have a footnote? > > Alexandre > > > On Sep 7, 2014, at 5:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > I just tried to do the following: > > > > 1. I took the book skeleton > > https://github.com/pillar-markup/book-skeleton > > > > 2. I executed download.sh > > > > 3. I executed compile.sh > > > > This works out of the box. > > > > Could you point us more exactly to where the problem appears? > > > > Cheers, > > Doru > > > > > > On Fri, Sep 5, 2014 at 9:53 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > I have discovered another problem. > > > > In my latex template I have: > > > > \chapter{{{{title}}}} > > > > In the produced .tex file, this lines becomes > > > > \chapter} > > > > This is a rather serious issue that prevents me from using Pillar :-( > > Is there a chance to see this fixed? > > > > Instead of {{{ â¦ }}} which heavily conflicts with Latex, can it be {-{ â¦ > }-} instead ? > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > On Sep 4, 2014, at 3:03 AM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > > > >> On Wed, Sep 3, 2014 at 9:24 PM, Alexandre Bergel > >> <alexandre.bergel(a)me.com> wrote: > >>> -=-=-=-= > >>> \newcommand{\ct}[1]} > >>> -=-=-=-= > >> > >> > >> I know the problem. I think this is a bad interaction between the > >> mustache template and LaTeX use of '}}'. > >> > >> The workaround for you would be to specify your own LaTeX template > >> where all macros are in a dedicated external file (copy/paste what we > >> do for the book from > >> > https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english/tr… > ). > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> "Success is the ability to go from one failure to another without > >> losing enthusiasm." > >> Winston Churchill > >> > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Sept. 10, 2014

from time to time I get a crash when increasing the main window size

by stepharo

basicNew value: new: replaceFrom:to:with:startingAt: new: basicNew new: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: value: primShowRectLeft:right:top:bottom: value: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: I will try to reproduce it.

Sept. 10, 2014

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

by Sven Van Caekenberghe

I added a slice for https://pharo.fogbugz.com/f/cases/13985/OrderedCollection-do-and-reverseDo-… On 09 Sep 2014, at 12:53, Nicolai Hess <nicolaihess(a)web.de> wrote: > fogbugz entry for fixing the menu builder > 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. 10, 2014