April 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Inserting halts using pragmas?

by Fernando olivero

Hi, can we inserts halt's into methods without modifying source code, using pragmas maybe? Has there been work on this? Thanks, Fernando

April 12, 2010

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

by StÃ©phane Ducasse

done. It is pier so everybody can edit it :) Stef On Apr 12, 2010, at 9:32 AM, Lukas Renggli wrote: > Gofer new > squeaksource: 'rb'; > version: 'AST-Core-lr.67'; > version: 'Refactoring-Core-lr.122'; > load.

April 12, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by David Harvey

Henrik, all, thanks for your help with this. I've been away from the codeface for a while and haven't yet tried all of the fixes. I did get things rendering well by caching the form canvas and redrawing that when required (just as the HandMorph does - as I said, the rendering while dragging is always OK). Relevant code below: >>>> drawOn: aCanvas super drawOn: aCanvas. cachedCanvas isNil ifTrue: [ cachedCanvas := (aCanvas allocateForm: self bounds extent) getCanvas. self drawContentsOn: cachedCanvas. ]. aCanvas translucentImage: cachedCanvas form at: self bounds origin. <<<< Best David ------------------ David Harvey www.teamsandtechnology.com www.cateams.com @david_harvey On 7 April 2010 12:45, David Harvey <david(a)teamsandtechnology.com> wrote: > Hi list, > > I'm writing a little charting morph, and while playing with rotating text > for axis labels came across something which I've noted in Morphs text > handling a couple of times. > > If I apply a transform in a drawing operation, rotated text _appears_ to be > drawn twice, slightly offset, giving a scrappy bold look. It seems only to > do this when drawing on a form canvas that's backed onto the display: if you > pick and drag the morph, the text is rendered beautifully. > > The test morph attached isolates the problem. The transcript logging is an > attempt to see what might be happening: looking at the output it appears > that there are circumstances in which the during: block is invoked twice. > > Any thoughts? > > David > > ------------------ > David Harvey > www.teamsandtechnology.com > www.cateams.com > @david_harvey >

April 12, 2010

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

by Lukas Renggli

It would be good to hardcode the version numbers and to tell that a Pharo 1.0 image has to be used: Gofer new squeaksource: 'rb'; version: 'AST-Core-lr.67'; version: 'Refactoring-Core-lr.122'; load. Pharo 1.1 won't be able to load underscore assignments anymore. Lukas On 12 April 2010 09:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > > > _______________________________________________ > 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 12, 2010

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 11, 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 11, 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