- Pharo-dev - lists.pharo.org

Re: [Pharo-project] some Announcements related questions

by CÃ©drick BÃ©ler

Hi Igor, I'm not sure but I think the annoucment version that will be included is there : http://source.lukas-renggli.ch/announcements Cheers, 2009/10/29 Igor Stasenko <siguctua(a)gmail.com> > Hello, i loaded the > Announcements package from SqS/AXAnnouncements, > > there are some tests failing because they explicitly comparing block > closures class to be a BlockContext. > But since new closure compiler, it should be BlockClosure instead. > What is a proper test you think? > isClosure or isBlock? > > And next question, that Pharo-core having a classes in > Announcements-Core category, > and comparing to AXAnnouncements there just very basic stuff and its > quite useless. > As i remember pharo is going to adopt announcements in base image, so > the question, is AXAnnouncements is right > thing to load, or there something made specifically for Pharo, but not > loaded in core image? > > -- > 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 > -- CÃ©drick

Oct. 29, 2009

[Pharo-project] some Announcements related questions

by Igor Stasenko

Hello, i loaded the Announcements package from SqS/AXAnnouncements, there are some tests failing because they explicitly comparing block closures class to be a BlockContext. But since new closure compiler, it should be BlockClosure instead. What is a proper test you think? isClosure or isBlock? And next question, that Pharo-core having a classes in Announcements-Core category, and comparing to AXAnnouncements there just very basic stuff and its quite useless. As i remember pharo is going to adopt announcements in base image, so the question, is AXAnnouncements is right thing to load, or there something made specifically for Pharo, but not loaded in core image? -- Best regards, Igor Stasenko AKA sig.

Oct. 29, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by StÃ©phane Ducasse

Nicolas I do not internet now so I cannot check (hospital bed no wifi :)). But yes we want to move on. We waited too long to invent the future :) Stef On Oct 29, 2009, at 10:39 AM, Nicolas Cellier wrote: >> Note that this is closely related to >> http://bugs.squeak.org/view.php?id=1876 and >> http://code.google.com/p/pharo/issues/detail?id=213 >> Amazing the issue is still there when workarounds are known for so >> long... So please do something! >

Oct. 29, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by StÃ©phane Ducasse

Ok since there were some other discussions I think that andres and martin got a consensus on the solution (I had the impression that the one of martin was prefered). So as soon as the code is ok we will integrate that. Stef On Oct 29, 2009, at 10:39 AM, Nicolas Cellier wrote: > After-thoughts: my opinion is: > Martin solution is more pragmatical : it is tailored for getting most > improvment with minimal change in system. > But formally, I prefer Andres design for it's clarity. > - I do not like the idea that #identityHash and #primIdentityHash do > behave differently > - #scaledIdentityHash does clearly express itself on the contrary > But that turns into german discussions ;) > > Nicolas > > 2009/10/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Martin >>> >>> are these changes related to the graphs you sent? >>> I will have a look after my hospital check. >>> Andres? Nicolas? >>> Any feedback? >>> Martin I imagine that I can package the changes :) >>> >>> >>> Stef >>> >> >> This has been pretty well explained by Martin and Andres. >> The decision you have to make is : >> >> - choose Martin change, make speed improvment for most senders of >> #identityHash, but eventually break a few senders and let package >> maintainers fix it (example Magma) >> - choose Andres change, assure 100% compatibility, let the >> responsibility to package maintainers to use new message for >> improving >> speed. >> >> In both cases, package maintainer might have to maintain different >> branch for Squeak and Pharo, but I guess the solution would be >> adopted >> soon in Squeak/trunk. >> >> I would tend to be conservative, but I recently took the opposite >> path >> with #keys and #selectors in trunk, so I just can't give you my >> personal preference, it's 50-50... >> Whatever the choice, #identityHash usage is worth a review by package >> maintainers anyway. >> >> Note that this is closely related to >> http://bugs.squeak.org/view.php?id=1876 and >> http://code.google.com/p/pharo/issues/detail?id=213 >> Amazing the issue is still there when workarounds are known for so >> long... So please do something! >> >> Nicolas >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 29, 2009

Re: [Pharo-project] Hashed collection changes, the performance graphs

by StÃ©phane Ducasse

> > We agree, mod I wouldn't want to impose version maintenance homework > on > maintainers of large packages. For the sake of illustration only, and > using Magma without knowing if it would be affected, I wouldn't want > whoever is maintaining Magma to maintain two branches... one for Pharo > 1.xyz, and one for Pharo 1.xyz++. They will have to and metacello will help them for that. Evolution has a price and I think that it should be low enough when considering advantage that this will be ok. >>> Well, more or less, because with scaledIdentityHash you'd need to > implement it in SmallInteger as ^self... but yes, I think hashed > collections shouldn't be put into a position where they judge what's a > good hash value and what isn't (and spend CPU time doing so at > runtime!!!). Java does this, and as far as I could see back when I > studied Java's hashing implementation, IMO it's not a good idea. Stef

Oct. 29, 2009

Re: [Pharo-project] Hashed collection changes, the performance graphs

by StÃ©phane Ducasse

What I can tell you is that I ***loves*** this discussion. It illustrates the spirit of pharo that we want to push. Let's make a better and cooler smalltalk :) And people are even learning nice knowledge. Thanks On Oct 29, 2009, at 3:14 AM, Andres Valloud wrote: > Martin, > > One of the constituencies I thought of when I decided to leave > identityHash alone was folks like you. Now, as a representative, if > you > are ok with dealing with broken identityHash senders (which I hope > will > be few), then most of my motivation for leaving identityHash unchanged > is gone. Thus, I would not mind changing identityHash and > implementing > primIdentityHash. > > What about others? Would anybody mind if identityHash was changed? > > Some comments below... > >> I took a survey of the senders of #identityHash in the latest web >> image. >> There aren't that many. The largest category is those that want the >> printString of the identityHash. >> > > These would probably need to be changed to get the printString of the > primIdentityHash. > >> Of those that care about the value of the identityHash, there are >> several that use it in #hash methods. The most common is this >> definition: >> >> hash >> ^self identityHash >> >> These are presumably overriding superclass behavior to restore Object >> behavior. > > I'd like to take a look at these, I suspect there may be low hanging > fruit waiting to be fixed. > >> If the authors knew about the limited range of #identityHash, that is >> entirely possible. I tend to think it more likely that in most cases >> these implementations are just the simplest way to follow the dictate >> that 'a=b -> a hash = b hash', and that they didn't really think >> about >> the impact on collection performance. >> > > Or maybe they chose identityHash because they can assume uniqueness (= > effectively being ==)... > >> 5 improved, 2 harmed. And one of the listed harmed is >> MethodDictionary, >> whose performance would not be harmed, but I assume the VM would >> not be >> happy if their hashing was changed (anybody know for sure whether >> that's >> true?) >> > > The VM probably knows a lot about identityHash values, and most likely > uses the primIdentityHash values because then it doesn't have to shift > on access. > >> They could, and I admit to having written this kind of code in the >> past, >> but I doubt that I'm typical in doing so. Do you know of any Pharo >> code >> that actually *does* this sort of thing? There isn't any in the >> distributed web image, but I didn't look at every package that is >> meant >> to be loadable in Pharo. >> > > I might suspect that Magma does this kind of stuff... but that's > just a > guess. I didn't immediately see any code doing so. As long as > package > maintainers are fine with two quite different versions of Pharo with > very different identityHash method behaviors, then I do not have a > problem. > >>> Clever hacks such as >>> >>> SomeObject>>hash >>> >>> ^(self variableA identityHash bitShift: 12) + self variableB >>> identityHash >>> >>> >>> would also remain undisturbed. >>> >> >> Yes, if #identityHash is changed it's the clever hacks that will >> have to >> change. This could be a disadvantage of this approach, but often, >> as in >> the case of IdentityDictionary, IdentitySet, and >> WeakIdentityKeyDictionary, the necessary change is simply to remove >> the >> clever hack, get simpler code, and enjoy better performance than >> you got >> with the clever hack, so making the change is IMO an improvement. >> > > We agree, mod I wouldn't want to impose version maintenance homework > on > maintainers of large packages. For the sake of illustration only, and > using Magma without knowing if it would be affected, I wouldn't want > whoever is maintaining Magma to maintain two branches... one for Pharo > 1.xyz, and one for Pharo 1.xyz++. > >>> Finally, I do not know of any Smalltalk >>> in which identityHash does not answer the actual object header >>> bits for >>> the identity hash. If we change identityHash, then AFAIK Pharo would >>> become the only Smalltalk in which identityHash does not answer >>> consecutive values between 0 and (2^k)-1 (k=12 for Squeak/Pharo, >>> k=14 >>> for VisualWorks 32 bits, k=20 for VisualWorks 64 bits, IIRC k=15 >>> for VA >>> and VisualSmalltalk). >>> >> >> GemStone is a Smalltalk that does not answer consecutive values for >> identityHash. > > Haha, I was thinking of "regular" image based Smalltalks... > >> In GemStone the identityHash is computed from the object's >> OOP, and OOPs are not consecutive. > > Not necessarily, although I suspect identityHash values map to an > integer interval along the lines of [0, 2^40-1]. So, if you look at > hash(x) as a function, the image of hash(x) is a set of consecutive > intervals. Using bitShift: to scale identityHash values would make > the > image of hash(x) sparse (with the exception of small integers, > characters and, to some extent in VW 64 bit, small doubles). > >> And Smalltalk-80 basically used the >> same scheme, though you could only have 32K objects, every one had a >> different identityHash based on OOP. >> > > These are also consecutive values... [0, 2^15-1], basically. > >> Also, most (all?) Smalltalks with limited ranges for identityHash do >> have a larger range of identityHash for SmallIntegers (usually >> ^self), >> so you can't use the clever hacks if you might have any >> SmallIntegers in >> your collection. So any general-purpose collection must already deal >> with the full SmallInteger range of identity hashes as keys, cannot >> use >> the clever hacks, and so is likely to only be improved by changing >> #identityHash. This is a key point that I forgot to bring up last >> night. >> > > Well, more or less, because with scaledIdentityHash you'd need to > implement it in SmallInteger as ^self... but yes, I think hashed > collections shouldn't be put into a position where they judge what's a > good hash value and what isn't (and spend CPU time doing so at > runtime!!!). Java does this, and as far as I could see back when I > studied Java's hashing implementation, IMO it's not a good idea. > > Andres. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 29, 2009

Re: [Pharo-project] Hashed collection changes, the performance graphs

by StÃ©phane Ducasse

Yes this is my gut feeling too. > If the authors knew about the limited range of #identityHash, that is > entirely possible. I tend to think it more likely that in most cases > these implementations are just the simplest way to follow the dictate > that 'a=b -> a hash = b hash', and that they didn't really think about > the impact on collection performance.

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Nicolas Cellier

2009/10/29 <csrabak(a)bol.com.br>: > Em 29/10/2009 08:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> escreveu: >> 2009/10/28 <csrabak(a)bol.com.br>: >> > Em 28/10/2009 17:52, Lukas Renggli <renggli(a)gmail.com> escreveu: >> > >> >> >> >> >> What would be your isAbstract Â be useful for? Â To know whether >> >> > it is wise to instantiate a class or not >> > >> >> That would be Â a pure guess then. Presumably Â you will still have >> >> to look at the implementation, at the documentation, at its users >> >> or study the Â coding conventions of the project Â to know for sure >> >> what to do with the thing. >> > Yes. >> > Thinking Â aloud: Â if Â we want Â to Â insure Â a Â class shall Â not Â be >> > instantiated, shouldn't we put an error in #new of that class? >> Â That Â would Â be Â the Â shortest Â way Â to Â freeze Â you Â image: >> Â Object>>#freezeMyImage > Â ^self subclassResponsibility > > That was not the way I envisaged. . . see below. > Yes, sorry my message was not clear. I extrapolated, using Alexandre technique for the goal you exposed (restricting #new). Of course that does not apply to your aloud thinking. Nicolas >> Â ...and Â you Â could Â not Â create Â any instance Â of Â Object Â and Â its >> Â subclasses Â anymore Â (but Â via Â a Â few Â primitives Â bypassing Â this >> Â mechanism). > > Again what I was thinking aloud (and continuing) is less of putting > some 'magical' method in Object that detects if it's abstract or not > but a reasonable way of the programmer when constructing the class put > int in the code: > > Say we had: > > Object>>isAbstract > Â ^false > > When a class is added to the system the one would do: > > > SomeClass class>>new > Â ^self raise: Error. > > SomeClass>>isAbstract > Â ^true > >> Â Beside, do Â you want a runtime Â check at each creation? Â We would >> Â have to cache the information at least... > > I don't any use of the mechanism if it is not enforceable > automatically. > > Otherwise, I could cynically say that the easiest way to attain the > objective would have the programmer inspect the class code [s]he is > thinking of instantiating! > > OTOH, notice that mainstream languages use explicit declarations to > have its classes Abstract, not the way around (I mean having the > programming environment detect using its characteristics). > > my 0.01999999.... > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by csrabak＠bol.com.br

Em 29/10/2009 08:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> escreveu: > 2009/10/28 <csrabak(a)bol.com.br>: > > Em 28/10/2009 17:52, Lukas Renggli <renggli(a)gmail.com> escreveu: > > > >> > >> >> What would be your isAbstract be useful for? To know whether > >> > it is wise to instantiate a class or not > > > >> That would be a pure guess then. Presumably you will still have > >> to look at the implementation, at the documentation, at its users > >> or study the coding conventions of the project to know for sure > >> what to do with the thing. > > Yes. > > Thinking aloud: if we want to insure a class shall not be > > instantiated, shouldn't we put an error in #new of that class? > That would be the shortest way to freeze you image: > Object>>#freezeMyImage ^self subclassResponsibility That was not the way I envisaged. . . see below. > ...and you could not create any instance of Object and its > subclasses anymore (but via a few primitives bypassing this > mechanism). Again what I was thinking aloud (and continuing) is less of putting some 'magical' method in Object that detects if it's abstract or not but a reasonable way of the programmer when constructing the class put int in the code: Say we had: Object>>isAbstract ^false When a class is added to the system the one would do: SomeClass class>>new ^self raise: Error. SomeClass>>isAbstract ^true > Beside, do you want a runtime check at each creation? We would > have to cache the information at least... I don't any use of the mechanism if it is not enforceable automatically. Otherwise, I could cynically say that the easiest way to attain the objective would have the programmer inspect the class code [s]he is thinking of instantiating! OTOH, notice that mainstream languages use explicit declarations to have its classes Abstract, not the way around (I mean having the programming environment detect using its characteristics). my 0.01999999.... -- Cesar Rabak

Oct. 29, 2009

Re: [Pharo-project] Code Critic

by Simon Denier

On 29 oct. 2009, at 14:37, Andrew P. Black wrote: > Can someone please explain to me how to run code critic on a single > class or a single package? In short, use refactoring scope (environment browser) Follow the nice screencast of Lukas http://www.lukas-renggli.ch/blog/ob-rb-3 > > I managed to run it (overnight) on Smalltalk. It found 70189 > problems, many of them jaw-dropping. But I would like to focus it > on my code! > > Andrew > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Oct. 29, 2009