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

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

by ClÃ©ment Bera

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

Re: [Pharo-dev] nil pointersTo size

by Ben Coman

Sept. 3, 2014

Re: [Pharo-dev] Proportional Tab Stops

by J.F. Rick

Sure. I'll add a ticket to Fogbugz since nobody has any real objections to my proposed solution. Once I have some time, I might try to solve it myself. Cheers, Jeff On Wed, Sep 3, 2014 at 1:36 PM, Ben Coman <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > > Hi, > > Glad to hear from you. > > Thanks for spotting the issue with tabbing. I think your suggestion of > having tabs spacing being proportional with the font size makes sense. > Could we interest you in submitting a slice for this? :) > > Cheers, > Doru > > > I think he indicated he did not have time right now :) > > Rick, I think that sounds like a good idea. Maybe you could log a ticket > on Fogbugz, so you can... > * stay updated with any action on it > * be involved in testing any proposed solutions > * when you back into the Pharo groove, if its still an outstanding issue > you might have a shot at it yourself. > > cheers -ben > > > > > > On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick <self(a)je77.com> wrote: > >> Hi everyone, >> >> I'm writing for two reasons. First, I wanted to let people know that I >> haven't disappeared. I'm just having to take a break as I finish up with my >> current academic post. As I am no longer going to be there, Pharo >> contributions don't help the department. So, I can't justify devoting any >> time to Pharo. But, I'm still interested in Athens, multitouch support, and >> Pharo for beginners. In October, I move back to Atlanta and will start a >> company. At that point, I aim to be back, though I may concentrate a bit >> more on server technology (full version of newest QRCode specifications >> half way done). >> >> Second, I wanted to mention a slight annoyance and suggest a solution. >> Background: I taught a class on introduction / intermediate programming in >> Pharo the last few years. One thing I try to teach my students is to use >> proper indention for their code. Unlike Python (great syntax for a first >> language), you do not need to indent in Smalltalk for code to work properly >> so students don't have to properly use indention to organize their code. >> For tiny bits of code (as is required in introductory programming), >> indention is not that important but it gets more important as they advance. >> Even my better students often used bad indention practices, though I >> emphasized it in class and all sample code I gave them was properly >> indented. In class, I often solved problems and demonstrated code. So that >> students could see what I typed, I increased the size of the font (24pt >> standard font). Though the font increased, the tab spacing remained the >> same. So, when I indented with one tab, it looked much smaller than a tab >> would have looked on their 10pt code editor. I saw people using spaces to >> indent code, which I never talked about. My guess is that they were trying >> to replicate the amount of space that my code was indented. They saw that a >> tab looked too big and used spaces. A simple solution is for tab spacing in >> code panes to increase proportionally with the font size. I feel like >> suggesting that as an improvement for Pharo 4. Does that seem reasonable? >> Are there arguments against it? >> >> Cheers, >> >> Jeff >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 3, 2014

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