- Pharo-dev - lists.pharo.org

Re: [Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!

by StÃ©phane Ducasse

http://book.pharo-project.org/book/TipsAndTricks/FixingUnderscores/ :) On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote: > Hi all, i just wanted to re post the fix underscore code Lukas posted a while ago. > > I've just imported Connectors package into pharo, (i'm trying to get a minimal version working ), and stumbled upon the problem of the underscores.. > but now thanks to SmallInt rules it was easy and fast to overcome this problem! > > Thanks!!!! > > Fernando > > > pd: From previous mail from lukas. > > > 1. Load the code: > > Gofer new > squeaksource: 'rb'; > package: 'AST-Core'; > package: 'Refactoring-Core'; > load. > > 2. Select the code (packages) you want to fix: > > environment := BrowserEnvironment new > forPackageNames: #('Connectors-Base' 'Connectors-Lines and Curves'). > > 3. Create the transformation rule: > > rule := RBUnderscoreAssignmentRule new. > > 4. Perform the search: > > SmalllintChecker runRule: rule onEnvironment: environment. > > 5. Perform the transformation: > > change := CompositeRefactoryChange new. > change changes: rule changes. > change execute > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Levente Uzonyi

On Sun, 11 Apr 2010, Ralph Boland wrote: >> Hi levente/igor > >> this hashedCollection is still on my radar. Now I was wondering if I should > work first on Set with nil or HashedCollection. >> Any idea/suggestion? > >> Stef > > I think moving Dictionary out from under Set is a great idea. > However I am not convinced having a class HashedCollection > to share common code between Set and Dictionary is worth it. > I would just tolerate the code duplication because these classes > are so important. Given that Squeak is going to support I don't see your point here. In Squeak that would mean duplicating 17 + 9 methods (instance/class side) + the two instance variables for no reason. > HashedCollection though, I would hate to see yet another difference > between Pharo and Squeak. I expect that the difference is unlikely > to break code shared between Pharo and Squeak though. > > I was always against allowing the addition of nil to sets. > This change means that every time I accidentally add nil to a set > the error will go undetected and will be difficult to track down once > the problem is discovered. Collections are still not ment to be bug detectors... Btw, do you notice if you add nil as a key to a Dictionary? (or add nil to an OrderedCollection?) > My solution to escape this change in my code will be to subclass > Set and any of its subclasses that I use and add code in the subclasses > to test for addition of nil and report an error when it happens. > This will allow bugs to show up sooner. You can (ab)use PluggableSet if you really need this by adding the nil check to the hashBlock. > An alternative is just to modify Set itself by adding a test for > adding nil to a set and then reporting an error. This change will break > down of course once there are instances of actually adding nil to a set > in Squeak/Pharo. > Are there any such occurrences is Squeak 4.1? Who knows, nil can be everywhere: #(1 2 nil) asSet. > Now that this feature will be in Squeak 4.1, however, we again have > the problem of divergence of code between Pharo and Squeak. The > problem won't be there immediately but eventually this feature > will actually be used in Squeak. > Of course the issue here is how often it is useful to allow > addition of nil to a Set. For the approximately 100,000 lines of > code I have written in Smalltalk the answer is 0 explaining my > opposition to this change. For some others though the answer > must be different. > For me this change will delay my moving my code from Squeak > 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). > Note that I use Sets and Dictionaries a lot. When my Squeak project > runs 80% of the time is spent on Set/Dictionary operations. You could have added nil as a key to a Dictionary and that went undetected... Levente > > Regards, > > Ralph Boland > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Ralph Boland

> Hi levente/igor > this hashedCollection is still on my radar. Now I was wondering if I should > work first on Set with nil or HashedCollection. > Any idea/suggestion? > Stef I think moving Dictionary out from under Set is a great idea. However I am not convinced having a class HashedCollection to share common code between Set and Dictionary is worth it. I would just tolerate the code duplication because these classes are so important. Given that Squeak is going to support HashedCollection though, I would hate to see yet another difference between Pharo and Squeak. I expect that the difference is unlikely to break code shared between Pharo and Squeak though. I was always against allowing the addition of nil to sets. This change means that every time I accidentally add nil to a set the error will go undetected and will be difficult to track down once the problem is discovered. My solution to escape this change in my code will be to subclass Set and any of its subclasses that I use and add code in the subclasses to test for addition of nil and report an error when it happens. This will allow bugs to show up sooner. An alternative is just to modify Set itself by adding a test for adding nil to a set and then reporting an error. This change will break down of course once there are instances of actually adding nil to a set in Squeak/Pharo. Are there any such occurrences is Squeak 4.1? Now that this feature will be in Squeak 4.1, however, we again have the problem of divergence of code between Pharo and Squeak. The problem won't be there immediately but eventually this feature will actually be used in Squeak. Of course the issue here is how often it is useful to allow addition of nil to a Set. For the approximately 100,000 lines of code I have written in Smalltalk the answer is 0 explaining my opposition to this change. For some others though the answer must be different. For me this change will delay my moving my code from Squeak 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). Note that I use Sets and Dictionaries a lot. When my Squeak project runs 80% of the time is spent on Set/Dictionary operations. Regards, Ralph Boland

April 12, 2010

Re: [Pharo-project] [squeak-dev] WeakSet but no WeakIdentitySet?

by Levente Uzonyi

On Sun, 11 Apr 2010, Igor Stasenko wrote: > Hello, > > i need to keep a bunch of CompiledMethods in WeakSet, > but i am a bit afraid, that it wont work as i want to, because of > CompiledMethod>>= implementation, > because a code, which i currently writing doesn't changing a method's > bytecode, but changing its trailer instead, > and so, this could lead to undesirable effects.. > > If i could have a WeakIdentitySet... We can add it to 4.2. Levente > > Meanwhile, i think i have nothing else, but just use a degenerate > WeakIdentityKeyDictionary , with methods in keys and nils in values. > :( > > -- > Best regards, > Igor Stasenko AKA sig. > >

April 12, 2010

[Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!

by Fernando olivero

Hi all, i just wanted to re post the fix underscore code Lukas posted a while ago. I've just imported Connectors package into pharo, (i'm trying to get a minimal version working ), and stumbled upon the problem of the underscores.. but now thanks to SmallInt rules it was easy and fast to overcome this problem! Thanks!!!! Fernando pd: From previous mail from lukas. 1. Load the code: Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; load. 2. Select the code (packages) you want to fix: environment := BrowserEnvironment new forPackageNames: #('Connectors-Base' 'Connectors-Lines and Curves'). 3. Create the transformation rule: rule := RBUnderscoreAssignmentRule new. 4. Perform the search: SmalllintChecker runRule: rule onEnvironment: environment. 5. Perform the transformation: change := CompositeRefactoryChange new. change changes: rule changes. change execute

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by StÃ©phane Ducasse

Yes! So I will follow your steps as soon as I have a bit of time. Stef On Apr 11, 2010, at 11:48 PM, Levente Uzonyi wrote: > On Sun, 11 Apr 2010, StÃ©phane Ducasse wrote: > >> Hi levente/igor >> >> this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. >> Any idea/suggestion? > > I think it's easier to add HashedCollection first, then the nil support for Set, because this way you can be sure that the changes added to Set (for the nil support) won't affect Dictionary. > > > Levente > >> >> Stef >> >> >> On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: >> >>> On Sun, 14 Mar 2010, stephane ducasse wrote: >>> >>>> Hi levente and others >>>> >>>> I always wanted to have Dictionary not be a subclass of Set and you did it. >>>> Now when you introduced that in Squeak, we were busy. >>>> But now I'm so found of this change (like other Smalltalk -> SmalltalkImage current --- which we stopped in the >>>> middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. >>>> Do you have any specific recommandations (like not shooting in our own foot)? >>> >>> IIRC this is what I did: >>> - created a copy of Set named HashedCollection >>> - changed it's category to Collections-Abstract >>> - changed Set's superclass to HashedCollection while removed it's instance variables >>> - removed Set specific methods from HashedCollection >>> - copied Dictionary specific methods from Set to Dictionary >>> - changed Dictionary's superclass to HashedCollection >>> - removed Dictionary specific methods from Set >>> - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) >>> >>> But if you change these classes now, you'll have to update AndrÃ©s' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. >>> >>> >>> Levente >>> >>>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 11, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by StÃ©phane Ducasse

Ok I will do that. Stef On Apr 11, 2010, at 11:39 PM, Igor Stasenko wrote: > On 12 April 2010 00:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi levente/igor >> >> this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. >> Any idea/suggestion? >> > HashedCollection is more important/basic refactoring than nils in sets. > So, adopt them first. > >> Stef >> >> >> On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: >> >>> On Sun, 14 Mar 2010, stephane ducasse wrote: >>> >>>> Hi levente and others >>>> >>>> I always wanted to have Dictionary not be a subclass of Set and you did it. >>>> Now when you introduced that in Squeak, we were busy. >>>> But now I'm so found of this change (like other Smalltalk -> SmalltalkImage current --- which we stopped in the >>>> middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. >>>> Do you have any specific recommandations (like not shooting in our own foot)? >>> >>> IIRC this is what I did: >>> - created a copy of Set named HashedCollection >>> - changed it's category to Collections-Abstract >>> - changed Set's superclass to HashedCollection while removed it's instance variables >>> - removed Set specific methods from HashedCollection >>> - copied Dictionary specific methods from Set to Dictionary >>> - changed Dictionary's superclass to HashedCollection >>> - removed Dictionary specific methods from Set >>> - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) >>> >>> But if you change these classes now, you'll have to update AndrÃ©s' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. >>> >>> >>> Levente >>> >>>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 11, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Levente Uzonyi

On Sun, 11 Apr 2010, StÃ©phane Ducasse wrote: > Hi levente/igor > > this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. > Any idea/suggestion? I think it's easier to add HashedCollection first, then the nil support for Set, because this way you can be sure that the changes added to Set (for the nil support) won't affect Dictionary. Levente > > Stef > > > On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: > >> On Sun, 14 Mar 2010, stephane ducasse wrote: >> >>> Hi levente and others >>> >>> I always wanted to have Dictionary not be a subclass of Set and you did it. >>> Now when you introduced that in Squeak, we were busy. >>> But now I'm so found of this change (like other Smalltalk -> SmalltalkImage current --- which we stopped in the >>> middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. >>> Do you have any specific recommandations (like not shooting in our own foot)? >> >> IIRC this is what I did: >> - created a copy of Set named HashedCollection >> - changed it's category to Collections-Abstract >> - changed Set's superclass to HashedCollection while removed it's instance variables >> - removed Set specific methods from HashedCollection >> - copied Dictionary specific methods from Set to Dictionary >> - changed Dictionary's superclass to HashedCollection >> - removed Dictionary specific methods from Set >> - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) >> >> But if you change these classes now, you'll have to update AndrÃ©s' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. >> >> >> Levente >> >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 11, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Igor Stasenko

On 12 April 2010 00:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi levente/igor > > this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. > Any idea/suggestion? > HashedCollection is more important/basic refactoring than nils in sets. So, adopt them first. > Stef > > > On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: > >> On Sun, 14 Mar 2010, stephane ducasse wrote: >> >>> Hi levente and others >>> >>> I always wanted to have Dictionary not be a subclass of Set and you did it. >>> Now when you introduced that in Squeak, we were busy. >>> But now I'm so found of this change (like other Smalltalk -> SmalltalkImage current --- which we stopped in the >>> middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. >>> Do you have any specific recommandations (like not shooting in our own foot)? >> >> IIRC this is what I did: >> - created a copy of Set named HashedCollection >> - changed it's category to Collections-Abstract >> - changed Set's superclass to HashedCollection while removed it's instance variables >> - removed Set specific methods from HashedCollection >> - copied Dictionary specific methods from Set to Dictionary >> - changed Dictionary's superclass to HashedCollection >> - removed Dictionary specific methods from Set >> - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) >> >> But if you change these classes now, you'll have to update AndrÃ©s' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. >> >> >> Levente >> >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 11, 2010

Re: [Pharo-project] Open Pharo debugger from a Seaside wallback

by Lukas Renggli

I don't have windows, so I cannot help. It would be cool if some Windows/Firefox user could figure out a permanent solution for our side, as this problem keeps on reappearing. Luas 2010/4/11 Facundo Vozzi <facundov79(a)gmail.com>: > Yes, it's seems to be that issue but its solution didn't repair my problem. > I > think that the problem is relationated with a network configuration issue so > i will > continue trying in that way. > Thank you Lukas. > Facundo > On Sun, Apr 11, 2010 at 5:24 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> This seems to be a known problem: >> >> >> http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/20959 >> >> Lukas >> >> 2010/4/11 Facundo Vozzi <facundov79(a)gmail.com>: >> > Hi people, >> > I'm using Pharo RC2 with Seaside 2.8.4 version and it's very slow when >> > IÂ trying to debugging a seaside application. In other words, I press the >> > debugÂ link on the seaside application walback and it take to Pharo over >> > 40 >> > seconds to open de imagen debugger. I tried with Seaside 3 developer >> > image >> > and it was the same situation. >> > I'm using pharo on 32 bits Windows 7 in a Core 2 Duo and 2 GB ram >> > memory. >> > Has anybody experimented the same problem or behavior? >> > Tranks, >> > Facundo >> > ps: Please, excuse my poor english. >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Facundo Vozzi > InfOil S.A. > Project Leader > (+54-11) 4542-9999 x108 > fvozzi(a)infoil.com.ar > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

April 11, 2010