July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about issue 59

by StÃ©phane Ducasse

Thanks a **lot**. On Jul 4, 2009, at 9:20 AM, Pavel Krivanek wrote: > Finished... see http://code.google.com/p/pharo/issues/detail?id=59 > > so, some comments: > > This patch must be done in *three* separate updates > - the first one loads the ChangesOrganizer class. This class > contains class variables from the ChangeSorter and class-side > methods for changes management. As the postinstallation step the > attached code must be evaluated. It switches the class variables > dictionary from ChangeSorter to ChangesOrganizer > - the second update will load the second changeset. This changeset > switches the usages of ChangeSorter to ChangesOrganizer in methods > that use it for general changes manipulation. > - as the final step the latest changeset removes all class variables > from the ChangeSorter and modifies some methods to delegate its > functionality to ChangesOrganizer. We step must be done in time when > no other class uses the ChangeSorter for changes management. It can > break the update otherwise. > > I hope that this quite radical update will not end with the > headache... > > Cheers, > -- Pavel > > On Fri, Jul 3, 2009 at 9:41 PM, stephane ducasse <stephane.ducasse(a)free.fr > > wrote: > Thanks this is a really fast answer :) > > I'm cleaning the _ ;) > Stef > > > > On Jul 3, 2009, at 9:35 PM, Pavel Krivanek wrote: > > Hi Stef, > > I'll prepare and upload the updated version for latest Pharo > tomorrow. Look at some other issue for now. > > Cheers, > -- Pavel > > On Fri, Jul 3, 2009 at 9:29 PM, stephane ducasse <stephane.ducasse(a)free.fr > > wrote: > Hi pavel > > I'm trying to understand what I should do for integrating this fix > but this is not clear to me. > http://code.google.com/p/pharo/issues/detail?id=59 > > could you help me? > > Stef > > >

July 4, 2009

Re: [Pharo-project] Problem with fork

by Alexandre Bergel

> Also I have near-zero experience with using Squeak or how its > development process works. I'll slowly cut my teeth, starting by > interacting on this mailing list. Welcome! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 4, 2009

[Pharo-project] Deprecation

by StÃ©phane Ducasse

From elliot On Fri, Jul 3, 2009 at 2:41 PM, Ken Causey <ken <at> kencausey.com> wrote: I would like to suggest that we develop a formal deprecation policy. It could be as simple as deprecate in one release, remove in the next. I just think we need to be consistent about it and remove no individual methods without following it. How this relates to the idea of repackaging and removing whole categories of classes, I'm not so sure. It would be good to add a date, version and selector Deprecation as in self deprecated: 'use Foo>>mumble' on: '2009/6/3' in: 'Croquet1.0beta' Move the preference check into Deprecation defaultAction. This would allow logging to collect a set of selectors used in a particular run, e.g. deprecations := Deprecation deprecationsWhile: [self runMyTests] as in the attached

July 4, 2009

Re: [Pharo-project] adding nil to sets

by Igor Stasenko

2009/7/4 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Heh, I just realized that weak sets won't be able to hold their weak > object tombstone either... I think the game can't be won as framed. > Right. But WeakSet is a subclass of Set, and as any other subclass is more concrete in doing something than the base class. So, i don't see any problem with that: Base class is more generic (allows nils as elements), while subclass doesn't. > Reinout Heeck wrote: >> On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: >> >>> Since I am here allow me to state my opinion on the matter. >>> We should not add the ability to add nil to Sets. Â While I admit I >>> don't >>> know for sure, I believe the number of instances where we need to add >>> nil to a set is rare. >>> >> >> >> I am of the opposite opinion (and quite strongly so :-) >> >> When writing code that uses sets I don't want to be bothered with the >> need to think about special cases (like nil). >> I agree that the number of instances where it *actually* happens is >> small but it does force authors to think of it *every* time they write >> code that adds objects to sets -- particularly hard to keep up when >> those objects are handed in from yet another module not under their >> control. >> >> Smalltalk being about abstractions and Pharo being about raising >> squeak to a 'professional' level I think it is very important to >> isolate the Pharo programmer from such library implementation >> idiosyncrasies -- they should be allowed to write abstract (naive if >> you will) code without fear that it breaks on such special cases. >> >> >> >>> Â For the rare cases in which it is needed we should >>> create a class Â SetSupportingNils which has two instance variables: >>> Â Â containsNil: Â a boolean set to true iff Â the SetSupportingNils >>> Â Â instance contains nil. >>> >> >> >> IMO such a set should be named 'Set' and the one that optimizes for >> not holding nil should be the one that is given a special name. >> >> As a critique of the proposed implementation: If you put the sentinel >> in the newly introduced ivar (instead of a boolean) the implementation >> will be simplified (all nil checks become checks against the sentinel >> as opposed to introducing 'case statements' in most of its >> implementation). >> >> I think that Andres' suggestion of using self as sentinel might be >> hitting a very sweet spot as a tradeoff between special cases and run- >> time efficiency. >> >> >> >>> Issue: >>> Â Â I suppose we need a Â BagSupportingNils class too. >>> >> >> Yes, and it should be named 'Bag' ;-) >> >> >> Now there clearly are costs associated with doing this: >> >> Set instantiation requires overwriting nils put there by the VM, this >> could be mitigated in the future by adding object instantiation >> protocol that is handed the sentinel. Perhaps in the short run this >> can be decoupled from the VM by using a plugin -- but I don't know if >> a plugin is allowed to take over object allocation. >> >> Custom set subclasses will break (but only if they explicitly check >> for nilled slots) -- but this seems like a mostly fail-fast scenario >> to me so it requires a code maintenance investment that seems mostly >> limited to a one-off cost. Anyway, finding all subclasses of Set >> doesn't seem too hard to me ;-) >> >> In short: Set is cheating and it is doing it poorly, it gets caught >> when code happens to stuff a very public object called nil in it. >> It should be taught to cheat better so it doesn't pollute code at >> other levels of abstraction with special cases. >> >> And yes: this requires an investment... >> >> R >> - >> >> >> _______________________________________________ >> 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.

July 4, 2009

Re: [Pharo-project] FasterSets improvements

by Andres Valloud

Whether it's a bug depends on your point of view. According to the ANSI spec, it's not a bug because the behavior in that case is undefined. On the other hand, at first sight it seems Set should behave like Dictionary... Reinout Heeck wrote: >>> In >>> VW, adding nil is a no-op. >>> > > Which is a bug that still needs fixing, it should raise an exception > (like dictionary does in VW). > > > >> In that case I would not let nil to be a possible element and avoid >> incompatibility. >> > > Oh, how compatible does Pharo need to be/intend to be with bugs of > other platforms? > > > > R > - > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

July 3, 2009

Re: [Pharo-project] adding nil to sets

by Andres Valloud

Heh, I just realized that weak sets won't be able to hold their weak object tombstone either... I think the game can't be won as framed. Reinout Heeck wrote: > On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: > >> Since I am here allow me to state my opinion on the matter. >> We should not add the ability to add nil to Sets. While I admit I >> don't >> know for sure, I believe the number of instances where we need to add >> nil to a set is rare. >> > > > I am of the opposite opinion (and quite strongly so :-) > > When writing code that uses sets I don't want to be bothered with the > need to think about special cases (like nil). > I agree that the number of instances where it *actually* happens is > small but it does force authors to think of it *every* time they write > code that adds objects to sets -- particularly hard to keep up when > those objects are handed in from yet another module not under their > control. > > Smalltalk being about abstractions and Pharo being about raising > squeak to a 'professional' level I think it is very important to > isolate the Pharo programmer from such library implementation > idiosyncrasies -- they should be allowed to write abstract (naive if > you will) code without fear that it breaks on such special cases. > > > >> For the rare cases in which it is needed we should >> create a class SetSupportingNils which has two instance variables: >> containsNil: a boolean set to true iff the SetSupportingNils >> instance contains nil. >> > > > IMO such a set should be named 'Set' and the one that optimizes for > not holding nil should be the one that is given a special name. > > As a critique of the proposed implementation: If you put the sentinel > in the newly introduced ivar (instead of a boolean) the implementation > will be simplified (all nil checks become checks against the sentinel > as opposed to introducing 'case statements' in most of its > implementation). > > I think that Andres' suggestion of using self as sentinel might be > hitting a very sweet spot as a tradeoff between special cases and run- > time efficiency. > > > >> Issue: >> I suppose we need a BagSupportingNils class too. >> > > Yes, and it should be named 'Bag' ;-) > > > Now there clearly are costs associated with doing this: > > Set instantiation requires overwriting nils put there by the VM, this > could be mitigated in the future by adding object instantiation > protocol that is handed the sentinel. Perhaps in the short run this > can be decoupled from the VM by using a plugin -- but I don't know if > a plugin is allowed to take over object allocation. > > Custom set subclasses will break (but only if they explicitly check > for nilled slots) -- but this seems like a mostly fail-fast scenario > to me so it requires a code maintenance investment that seems mostly > limited to a one-off cost. Anyway, finding all subclasses of Set > doesn't seem too hard to me ;-) > > In short: Set is cheating and it is doing it poorly, it gets caught > when code happens to stuff a very public object called nil in it. > It should be taught to cheat better so it doesn't pollute code at > other levels of abstraction with special cases. > > And yes: this requires an investment... > > R > - > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >

July 3, 2009

Re: [Pharo-project] adding nil to sets

by Andres Valloud

Oh... I meant to see what happens in VW, where there are numerous dictionary and set classes. Moreover, every so often there's the need for e.g.: a hash bucketed set with mutex protection, such as for the symbol table. Since the base classes do not have pluggable strategies, then the special set has to be reimplemented from scratch... StÃ©phane Ducasse wrote: > andres > > >> Something that could be considered down the road is restructuring the >> collection hierarchy to, among other things, allow pluggable hashed >> storage strategies for hashed collections. This approach should >> drastically reduce the number of classes in the hashed collection >> class >> hierarchy (c.f.: what happens in VW). >> > > andres do you mean that this is done in VW. > > > >>> Thanks ralph. >>> I think that this is not a so good idea to have nil as element. >>> >>> BTW: just to make sure. Our is not to hijack people from the squeak >>> community >>> (because when I scanned some emails there I thought that we were >>> considered as evil >>> and bad guys - people have a short memory). >>> Our goal is to build an agile Smalltalk with faster, better.... code. >>> And to make sure that people can reinvent the future because they can >>> use cool >>> abstractions. >>> >>> Stef >>> >>> >>> On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: >>> >>> >>> >>>> Please note the change of topic; adding the ability to add nil to >>>> sets >>>> won't make sets faster and may well make them slower so has nothing >>>> to to with the FasterSets package. >>>> >>>> Since I am here allow me to state my opinion on the matter. >>>> We should not add the ability to add nil to Sets. While I admit I >>>> don't >>>> know for sure, I believe the number of instances where we need to >>>> add >>>> nil to a set is rare. For the rare cases in which it is needed we >>>> should >>>> create a class SetSupportingNils which has two instance variables: >>>> containsNil: a boolean set to true iff the SetSupportingNils >>>> instance contains nil. >>>> >>>> set: an instance of Set or one of its subclasses and used to >>>> store any object added to the SetSupportingNils instance except >>>> of course nil. >>>> >>>> This means that SetSupportingNils would need to recognize >>>> any message that Sets or its subclasses can understand. >>>> Any message not understood by SetSupportingNils would be >>>> forwarded to its set instance variable. >>>> My proposal is not very efficient when adding nil to a set is >>>> needed but it requires no modifications to Set or any of its >>>> subclasses. >>>> That a rarely used class is somewhat inefficient is acceptable. >>>> >>>> Issue: >>>> I suppose we need a BagSupportingNils class too. >>>> Are there any other classes we need? >>>> Can they be combined into one class? >>>> >>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >> > > . > >

July 3, 2009

[Pharo-project] [ANN] 10353

by StÃ©phane Ducasse

Hi guys some more :) (this is good when I do not have to fix my house). - Issue 924: Cursor Class cannot be initialized! - Issue 925: Replace _ by := on all the packages Stef PS: lukas wrote a couple of nice SmallLint rules to check instanceVariables classVariables _ use :)

July 3, 2009

[Pharo-project] Fwd: [ANN] 10352

by StÃ©phane Ducasse

> > Hi guys > > We got some fun with lukas and did: > > Issue 923: remove the check when defining methods on the class side. > Now you do not get > this isScarySelector invoke and the Parser is not called twice. > > Issue 922: Should remove inst var and class var checks. > it was a good idea but we will achieve the same with smallLint'. > > > Stef and Lukas pre sprinting > > > >

July 3, 2009

Re: [Pharo-project] proposed fix for issue 913

by StÃ©phane Ducasse

Thanks dale. We will doing some fixes with lukas and tomorrow there is the sprint :) Stef > > > http://code.google.com/p/pharo/issues/detail?id=913 > > I wasn't able to directly reproduce the problem in my tests, but > upon code inspection > it was obvious that an empty Dictionary should be returned by > BytecodeEncoder>>blockExtentsToTempRefs instead of nil. None of the > senders would be > adversely affected by the change. > > Of course the changes are in the Compiler package, so it's worth > having an extra set of eyes take a look. > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 3, 2009