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

Re: [Pharo-project] Abstract classes

by StÃ©phane Ducasse

Lukas I'm not that against the idea proposed by alex. I think that knowing that a class is abstract is important to have and this is not because Smalltalk original language was weak that we could not define now a clear definition. I do not like the definition of RB people because I have class that are not abstract and that are not referenced because I just did not load the package that use them. Now if magritte needed to know that a class should show up in a UI then may be it should be called differently because an abstract class is clearly a class that we should/cannot instantiate. If you take ***any*** book on OOP this is a basic concept. Stef On Oct 28, 2009, at 8:52 PM, Lukas Renggli wrote: >>> 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. > > Lukas > > -- > Lukas Renggli > http://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

Oct. 29, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Alain Plantec

Hi Jannik and all, Laval Jannik a Ã©crit : > On Oct 29, 2009, at 04:27 , Serge Stinckwich wrote: > >> Are you sure, this is not used anywhere ? >> Sometimes you need to draw a morph with a specific heading. >> ... > Now, do you use, sometimes, this functionality in pharoCore ? or do > you think this behavior should be offer by pharoCore ? > > heading is a number which is only use in the rotation behavior. > > I think it must be provided by eToy, not by Core. > This was brought by etoy but it is not etoy specific. Of course the heading message is present in the Morph class, which is not good but I see it more as a TransformationMorph /MatrixTransformationMorph functionality. As this, for now, I think it is not so bad. And what about the scaling behavior for example ? Cheers Alain > No ? > > Cheers, > Jannik > > >> Best regards, >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Smalltalkers do: [:it | All with: Class, (And love: it)] >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> 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 > > >

Oct. 29, 2009

Re: [Pharo-project] PhExample, because well designed tests expand on one another (Sneak Preview)

by Dennis Schetinin

2009/10/27 Niko Schwarz <niko.schwarz(a)googlemail.com> > The example discussed above would read in code as follows: > > EGExample subclass: #ForExampleStack > â¦ > > shouldBeEmpty > "Create the empty stack" > | stack | > stack := Stack new. > stack should be isEmpty. > stack size should = 0. > ^ stack > > shouldPushElement > "Push one element" > | stack | > stack := self given: #shouldBeEmpty. > I'd suggest this to be: stack := self given: [self shouldBeEmpty]. This way it's easier to follow what happenning, and refactoring can be applied. > stack push: 42. > stack should not be isEmpty. > stack size should = 1. > stack top should = 42. > ^ stack > -- Dennis Schetinin

Oct. 29, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Laval Jannik

On Oct 29, 2009, at 04:27 , Serge Stinckwich wrote: > 2009/10/28 Laval Jannik <jannik.laval(a)gmail.com>: >> >> On Oct 28, 2009, at 16:26 , Miguel Enrique CobÃ¡ Martinez wrote: >> >>> El miÃ©, 28-10-2009 a las 07:03 +0100, Laval Jannik escribiÃ³: >>>> So, >>>> >>>> Is anyone use the rotation in pharo-Core ? >>>> If not, I will remove it. >>>> And I will try to put it in another package, which will be loaded >>>> after. >>>> >>> >>> Remove it, please, is not a core feature. >> >> I like this answer :) >> I will do this stuff with pleasure :) > > Are you sure, this is not used anywhere ? > Sometimes you need to draw a morph with a specific heading. This is an eToy thing, so in a perfect world, it should not be used :). Now, do you use, sometimes, this functionality in pharoCore ? or do you think this behavior should be offer by pharoCore ? heading is a number which is only use in the rotation behavior. I think it must be provided by eToy, not by Core. No ? Cheers, Jannik > Best regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > 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] Making packages shipped with Pharo ready for 1.0

by Mariano Martinez Peck

On Wed, Oct 28, 2009 at 11:01 PM, Martin McClure <martin(a)hand2mouse.com>wrote: > Adrian Lienhard wrote: > > > Pharo-core tests failing > > ------------------------ > > - FontTest>>testFallback (assumes different font, to be removed) > > - FontTest>>testParagraphFallback (assumes different font, to be > > removed) > > - FontTest>>testResetAfterEmphasized (assumes different font, to be > > removed) > > - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different > > font, to be removed) > > - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes > > different font, to be removed) > > - TestIndenting>>testSetUp (assumes different font, to be removed) > > - LocaleTest>>testIsFontAvailable (some Japanese font checking that > > fails with DejaVu, to be removed) > > - testFinalizationOfEquals (was on my to do list, but works again: > > remove expected failure tag) > > - testObsoleteClasses: again includes classes from MC and others (have > > to be checked) > > Also note that in a Pharo-core image HostWindowTests>>#testOne fails, > apparently because HostWindows aren't implemented on Linux. I'm guessing > that the test should be conditionalized to not run on Linux, or to > expect to fail on Linux. > f > This has been fixed in latest version. See http://code.google.com/p/pharo/issues/detail?id=1338 > Regards, > > -Martin > > _______________________________________________ > 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] issue 496: Morph>>heading

by Serge Stinckwich

2009/10/28 Laval Jannik <jannik.laval(a)gmail.com>: > > On Oct 28, 2009, at 16:26 , Miguel Enrique CobÃ¡ Martinez wrote: > >> El miÃ©, 28-10-2009 a las 07:03 +0100, Laval Jannik escribiÃ³: >>> So, >>> >>> Is anyone use the rotation in pharo-Core ? >>> If not, I will remove it. >>> And I will try to put it in another package, which will be loaded >>> after. >>> >> >> Remove it, please, is not a core feature. > > I like this answer :) > I will do this stuff with pleasure :) Are you sure, this is not used anywhere ? Sometimes you need to draw a morph with a specific heading. Best regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Oct. 29, 2009

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

by John McIntosh

I looked at the squeak identityHash in squeak a few years back (a) how efficient was the algorithm? Attempted at one time to replace with a fixed array of numbers. There was some benefit on slow machines. (b) only calculate the identity hash when required, but then how do you mark the oops with that fact when all the identityHash values are in use in the image. The hassle of fixing an image to use the new hash logic wasn't worth the gain which was difficult to measure. In both cases I was more interested in the cpu usage on those 68K machines. On Wed, Oct 28, 2009 at 7:14 PM, Andres Valloud < avalloud(a)smalltalk.comcastbiz.net> wrote: > Martin, > > One of the constituencies I thought of when I decided to leave > identityHash alone was folks like you. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 29, 2009

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

by Andres Valloud

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.

Oct. 29, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Martin McClure

Adrian Lienhard wrote: > Pharo-core tests failing > ------------------------ > - FontTest>>testFallback (assumes different font, to be removed) > - FontTest>>testParagraphFallback (assumes different font, to be > removed) > - FontTest>>testResetAfterEmphasized (assumes different font, to be > removed) > - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different > font, to be removed) > - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes > different font, to be removed) > - TestIndenting>>testSetUp (assumes different font, to be removed) > - LocaleTest>>testIsFontAvailable (some Japanese font checking that > fails with DejaVu, to be removed) > - testFinalizationOfEquals (was on my to do list, but works again: > remove expected failure tag) > - testObsoleteClasses: again includes classes from MC and others (have > to be checked) Also note that in a Pharo-core image HostWindowTests>>#testOne fails, apparently because HostWindows aren't implemented on Linux. I'm guessing that the test should be conditionalized to not run on Linux, or to expect to fail on Linux. Regards, -Martin

Oct. 29, 2009

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

by Martin McClure

Andres Valloud wrote: > Stephane et al, > > Martin and I discussed this yesterday night at the PDX Smalltalk user > group meeting. Mostly we agree, with perhaps one small exception. In > order to make hashed collections simpler and identity hash handling more > straightforward, hashed collections should get a small integer range > identity hash value. Something between 0 and SmallInteger maxVal, for > example. The issue is how to get that. Hi Andres, Oh, good; you started the discussion while I was being interrupted in the middle of writing my previous message -- thanks. :-) [...good description of the choices omitted...] > There are two kinds of senders of identityHash. [...] 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. 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. If Object>>hash were to be defined to answer 'self scaledIdentityHash' then these methods would also need to be changed in order to get the performance improvement for collections containing those objects. If, OTOH, #identityHash itself changes, these classes get the benefit with no change. > Some (most) do not care >> whether the answer is well distributed or not. Typically, these are >> implementors of #hash, for example: >> >> SomeObject>>hash >> >> ^self someInstanceVariable identityHash And indeed there are also some do this. > If, on one hand, we change identityHash, then the behavior of these hash > methods improve because the values they answer would be distributed more > uniformly. Nevertheless, precisely because they send identityHash, it > could be argued that these hash methods were implemented assuming there > would be just a few of these objects in hashed collections. 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. > > Some (a few) other senders of identityHash assume that the answer has a > particular distribution (in Squeak's/Pharo's case, 0 through 4095). Here are the senders I found that care about the actual values returned, along with whether they'd be harmed or improved by increasing the range returned: FixedIdentitySet -- harmed IdentityDictionary -- somewhat improved IdentitySet -- somewhat improved KeyedIdentitySet -- greatly improved MethodDictionary -- harmed RefactoryTyper -- probably improved WeakIdentityKeyDictionary -- somewhat improved 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?) > Consequently, the senders may do things like this: > > SomeObject>>hash > > ^(self variableA identityHash bitShift: 12) + self variableB identityHash 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. > > > If, on the other hand, we provide a new scaledIdentityHash method, then > all senders of identityHash keep behaving the same way as they do now. > Hashed collections, which currently send identityHash, would need to > change so that they send scaledIdentityHash instead. Furthermore, any > implementor of hash such as > > SomeObject>>hash > > ^self someInstanceVariable identityHash > > > would need to be rewritten as > > SomeObject>>hash > > ^self someInstanceVariable scaledIdentityHash Yes. I believe that this is a disadvantage of the #scaledIdentityHash approach. > > > if hashed collections are expected to contain numerous instances of > SomeObject. If these are not rewritten, then they would continue to > have the same performance characteristics they have today (which may be > adequate to begin with). True, if the collections are expected to remain small their performance is already adequate. However, small collections will still have good performance if #identityHash is changed, and collections that the authors thought would remain small when they were written back in the days of sub-megabyte memory may now get bigger than their authors intended. > 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. > 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. In GemStone the identityHash is computed from the object's OOP, and OOPs are not consecutive. Every object's identityHash is different, the range is not limited (at least in 32-bit GemStone; I'd have to check what we do in 64-bit). And Smalltalk-80 basically used the same scheme, though you could only have 32K objects, every one had a different identityHash based on OOP. 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. > > So that's where we stand. I think I understand where Martin is coming > from, and I think Martin understands where I am coming from. One way or > the other, we also agree that something should be done to make hashed > collections faster in Pharo. Yes, Andres and I are in far more agreement than disagreement about the hashing changes. Regards, -Martin

Oct. 29, 2009