- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 3 September 2014 14:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 03 Sep 2014, at 14:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> 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 ? >> >> > Wrong wrong wrong.. > you either iterate over collection, or modify it.. not both. > > > So you actually agree :-) > I didn't read carefully enough.. but people start the discussion about 'how to fix OrderedColletion' which, as to me, bad signal since it goes wrong way. I am violently against it. You don't 'fix' core classes to make some abuses work. Fix abuses instead. Making abuses work, is opening can of worms, because today you pleased one abuse, tomorrow you will be forced to please another one.. and the finale of it will be complete loss of so beloved consistency. > Marcus > > -- Best regards, Igor Stasenko.

Sept. 3, 2014

Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube

by Esteban A. Maringolo

I'm sure he's building some sort of bot to reach every Pharo mention in web and beyond :D Esteban A. Maringolo 2014-09-03 6:14 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Man, are you sure that you want to advertise publicly that you are listening > to this music? :)) > > Doru > > > On Wed, Sep 3, 2014 at 11:00 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Yes I saw it too :) >> >> >> >> On 3/9/14 09:40, Sven Van Caekenberghe wrote: >>> >>> We should sue this guy ;-) >>> >>> https://www.youtube.com/watch?v=S3uktGJVebE >>> >>> >>> >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Sept. 3, 2014

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

by Tudor Girba

:) On Wed, Sep 3, 2014 at 2:47 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 03 Sep 2014, at 14:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> 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 ? >> >> > Wrong wrong wrong.. > you either iterate over collection, or modify it.. not both. > > > So you actually agree :-) > > Marcus > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 3, 2014

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

by Marcus Denker

On 03 Sep 2014, at 14:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > > 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 ? > > > Wrong wrong wrong.. > you either iterate over collection, or modify it.. not both. So you actually agree :-) Marcus

Sept. 3, 2014

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

by Sven Van Caekenberghe

I think we should change OrderedCollection>>#do: aBlock "Override the superclass for performance reasons." firstIndex to: lastIndex do: [ :index | aBlock value: (array at: index) ] Clement, Do you happen to know exactly where the world menu building goes wrong ? Sven On 03 Sep 2014, at 13:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Clement, > > I am not sure, but could this not be a compiler issue ? > Not with Opal but with the old compiler ?! > > I mean, if you look at the implementations of OrderedCollection>>#do: and OrderedCollection>>#collect: they basically do the same thing, going from firstIndex to lastIndex, both of which are instance variables, but in the first case, the #do:, the end test is evaluated on each iteration, while in the second case, the #to:do:, the end test should be evaluated only once. Since lastIndex changes while iterating, one iteration sees it, the other not. > > Looking at the byte codes seems to confirm that: the compilation of the #:to:do is different: Opal correctly moves both instance variables to temps, while the old compiler keeps on referring to the second instance variable (lastIndex) directly on each loop - which is plain wrong IMHO. > > I am with Marcus that you should not modify a collection that you iterate over. What if you would be inserting values at arbitrary places ? > > I am with you that both (all) enumerations should be consistent. Like in VW, delegating to the simplest #do: seems best. > > Sven > > On 03 Sep 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 ? >> >> Clement >> >

Sept. 3, 2014

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

by Igor Stasenko

On 3 September 2014 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. > > An arbitrary rule. The whole world does not defines what to expect from collection when you modifying it during iterating over it.. You can introduce any rule.. but don't expect this won't surprise the users.. because there's no obvious / 'least surprising' behavior can be defined. > 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 ? > > Wrong wrong wrong.. you either iterate over collection, or modify it.. not both. We must fix wrong uses of collections.. not collection. It is all right with collection implementation. You put expectations into a place where should be none: the behavior of iterating over collection while modifying it is *undefined* That's the only rule which should be there. Period. > Clement > > -- Best regards, Igor Stasenko.

Sept. 3, 2014

speed up with:do: by not checking size

by Marcus Denker

with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock "Evaluate twoArgBlock with corresponding elements from this collection and otherCollection." otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… Marcus

Sept. 3, 2014

Re: [Pharo-dev] Undeclared dictionary

by Yuriy Tymchuk

Thank you Marcus! This is very helpful. Uko On 03 Sep 2014, at 13:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, can someone explain me how Undeclared dictionary works? > > > So imagine you want to load code where a variable is not defined (e.g. due to loading old code, > or because it references a variable that will only be loaded in a second step). > > In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), > it just loads the wrong code and for every undeclared variable, it adds an entry in the > Undeclared dictionary. > (the bytecode to read and write is the same as used for Globals and Class variables: > pushLiteralVariable, which means "push the value of the association", the store bytecode > for assignment therefore is "store in the value of that association". > > So if you actually run code that has Undeclared, it will work: it will be nil by default, > but when you assign it will store into the Undeclared dictionary. > > When you add a new Global to the SystemDictionary, it will check Undeclared and > move the value over. Same for Class vars. > (this means that loading a class will automatically fix all Undeclared references to it) > > > Because as I look at it, all the values are nil. Is it possible for them to be not nil? > > yes. > > Maybe we should have a âglobal variable commentsâ for this situations :) > > > Ideed. > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de

Sept. 3, 2014

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

by Camille Teruel

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. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2014