December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Class rename on materialization

by Yanni Chiu

On 17/12/11 11:00 PM, Martin Dias wrote: > > For example, in the method > > Object >> > arrayWithSomething > ^Array with: OldClass with: #OldClass > > if you inspect Object >> #arrayWithSomething, in the literals you will see: > - for the first array element, an association #OldClass->OldClass, which > is an entry in Smalltalk globals. This association should be > materialized as #NewClass->NewClass. Yes, it should be mapped, in that case. Now, the feature is a renaming of Smalltalk globals, not just classes, if it's implemented in this way, for method literals. > - for the second array element, the symbol #OldClass. Here is my dubt: > 1) materialize as #NewSymbol or 2) as #OldSymbol? > > 1) I think in this case we want to materialize the method as: > > arrayWithSomething > ^Array with: NewClass with: #NewClass Without other information, there's no way in general to know that #OldClass is meant to refer to the OldClass class. IMHO, it's better to leave it alone, in that case. There's usually a facade that would construct the class names from parameters, or the class is known by a fixed name. Trying to address a problem that doesn't occur in real code, might cause other problems. > 2) suppose that in the same file we serialized some other object (not > the above mentioned method) who points to the symbol #OldClass. Maybe we > don't want to rename the symbol in this case. I think it's better to leave it alone, in this case too.

Dec. 18, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Nicolas Cellier

2011/12/18 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2011/12/18 Levente Uzonyi <leves(a)elte.hu>: >> On Sat, 17 Dec 2011, StÃ©phane Ducasse wrote: >> >>> >>> On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote: >>> >>>> Cool. One more thing: in Squeak the method using primitive 132 directly >>>> was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If >>>> this was also added to Pharo, then the #pointsTo: sends should be changed to >>>> #instVarsInclude:, otherwise Array can be reported as included even if it >>>> wasn't added. > > Ah yes, but in this case LargeIdentitySet/Dictionary should use > #instVarInclude: rather than #pointsTo; otherwise here is a bug > > (LargeIdentitySet with: Array identityHash \\ 4096) includes: Array > > Nicolas > Oops, that's just what you were telling, apologize... >>>> I'll upload my LargeIdentityDictionary implementation to the same place >>>> this evening, since it's still 2-3 factor faster than other solutionts and >>>> there seem to be demand for it. >>> >>> >>> Levente >>> >>>> "in Squeak the method using primitive 132 directly was renamed to >>>> #instVarsInclude:, so now #pointsTo: works as expected." >>> >>> I do not get the following. Indeed pointTo: looks like instVarsInclude: >>> now I do not understand the rest of your paragraph. >> >> >> #pointsTo: should answer true if the receiver has a pointer to the argument. >> Every object (except for SmallIntegers and instances of compact classes) >> holds a pointer to its class in the header. Since the primitive only checks >> the slots, it will not always return true if the argument is the object's >> class. This breaks pointer finding/tracing tools, that's why it was changed >> in Squeak. See how #instVarsInclude: and #pointsTo: is implemented there. >> >> >> Levente >> >>> >>> Stef

Dec. 18, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Nicolas Cellier

2011/12/18 Levente Uzonyi <leves(a)elte.hu>: > On Sat, 17 Dec 2011, StÃ©phane Ducasse wrote: > >> >> On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote: >> >>> Cool. One more thing: in Squeak the method using primitive 132 directly >>> was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If >>> this was also added to Pharo, then the #pointsTo: sends should be changed to >>> #instVarsInclude:, otherwise Array can be reported as included even if it >>> wasn't added. Ah yes, but in this case LargeIdentitySet/Dictionary should use #instVarInclude: rather than #pointsTo; otherwise here is a bug (LargeIdentitySet with: Array identityHash \\ 4096) includes: Array Nicolas >>> I'll upload my LargeIdentityDictionary implementation to the same place >>> this evening, since it's still 2-3 factor faster than other solutionts and >>> there seem to be demand for it. >> >> >> Levente >> >>> "in Squeak the method using primitive 132 directly was renamed to >>> #instVarsInclude:, so now #pointsTo: works as expected." >> >> I do not get the following. Indeed pointTo: looks like instVarsInclude: >> now I do not understand the rest of your paragraph. > > > #pointsTo: should answer true if the receiver has a pointer to the argument. > Every object (except for SmallIntegers and instances of compact classes) > holds a pointer to its class in the header. Since the primitive only checks > the slots, it will not always return true if the argument is the object's > class. This breaks pointer finding/tracing tools, that's why it was changed > in Squeak. See how #instVarsInclude: and #pointsTo: is implemented there. > > > Levente > >> >> Stef

Dec. 18, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Levente Uzonyi

On Sun, 18 Dec 2011, Levente Uzonyi wrote: > On Sat, 17 Dec 2011, Mariano Martinez Peck wrote: > >>>>> >>>> >>>> Can't you debug it ? >>>> >>> >>> >> Of course I could do it when I have some time. It already took me 1 hour to >> isolate the bug from Fuel and make a reproducible test. I hope that at >> least you find that useful. I found the bug and I thought I could send my >> progress and see if someone could continue it. Otherwise, I was going to >> debug it as soon as I have some free time (which I don't have much this >> year). >> >> >>> It took 2 minutes to find this sentence at line 19 of >>> LargeDictionary>>at:put: >>> >>> >> But you are so smart and a Collection hacker. Me, I am newbie, and just the >> method at:put: scares me, but I understand if it has to be that way in >> order to be fast. And so far it seems to be fast, so I am happy with it. >> >> >> >>> (values at: hash) at: newIndex put: key >>> >> >> Can you replace key with value and retry the tests ? >>> >>> >> Yes, that works. Thanks! >> >> Now I noticed that SmallIntegers storing is really slow > > This is not entirely true. Every hash table can be made slow if you know how > it's hash function works. Since in your example all numbers are congruent to > 1 modulo 4096 and the size of the array is also 4096, therefore they will be > mapped to the same slot (1). Try using random (or at least more realistic) > numbers in your test. If this is a real problem, then it may be necessary to > implement a new hash method, which uses the primitive for general objects and > does something else with SmallIntegers and that method shoul be used from > these large collections. I uploaded a new mcz to the FuelExperiments repository, which is unaffected by the identity hash differences between Pharo and Squeak and works better with SmallIntegers. It includes both the dictionary and the set and (in theory) has slightly better performance for non-SmallInteger objects. Levente > > > Levente > >> >> numbers := OrderedCollection new. >> numbers add: 1. >> numbers addAll: (1 to: 1 << 29 by: 1 << 14) asArray. >> numbers addAll: ((1 to: 1 << 29 by: 1 << 14) asArray collect: [:each | >> each negated] ). >> >> dict := LargeIdentityDictionary new. >> [numbers do: [:each | >> dict at: each put: dict size + 1. >> ]. >> ] timeToRun >> -> 12657 >> >> >> whereas with IdentityDictionary it is 37. I guess it could be related to >> #identityHash or #basicIdentityHash. I tried in Squeak 4.3 and it is also >> also there. >> I will try to take a look into it during the next week. >> >> Thanks in advance >> >> >> >>> Nicolas >>> >>>>> >>>>> Thanks for any idea. >>>>> >>>>> >>>>> >>>>> On Sat, Dec 17, 2011 at 1:50 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>>> >>>>>> On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote: >>>>>> >>>>>>> Cool. One more thing: in Squeak the method using primitive 132 >>> directly >>>>>>> was renamed to #instVarsInclude:, so now #pointsTo: works as >>> expected. If >>>>>>> this was also added to Pharo, then the #pointsTo: sends should be >>> changed to >>>>>>> #instVarsInclude:, otherwise Array can be reported as included even >>> if it >>>>>>> wasn't added. >>>>>>> I'll upload my LargeIdentityDictionary implementation to the same >>> place >>>>>>> this evening, since it's still 2-3 factor faster than other >>> solutionts and >>>>>>> there seem to be demand for it. >>>>>> >>>>>> Levente >>>>>> >>>>>>> "in Squeak the method using primitive 132 directly was renamed to >>>>>>> #instVarsInclude:, so now #pointsTo: works as expected." >>>>>> I do not get the following. Indeed pointTo: looks like instVarsInclude: >>>>>> now I do not understand the rest of your paragraph. >>>>>> >>>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >

Dec. 18, 2011

Re: [Pharo-project] Order of method categories in browser

by StÃ©phane Ducasse

Janko This is not that we do not have ideas :) What we need is manpower? For the idea why not I have plenty of them on UI and navigation. Stef > Hi guys, > > What if the order of method categories in System browser would be a bit > more clever and not just alphabetical? By clever I mean that private* > categories are always on bottom while initialize* on top. And so on.. > > This can be settable in Settings, switched on by default. > > What do you think? > > Best regards > Janko > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Dec. 18, 2011

[Pharo-project] Order of method categories in browser

by Janko MivÅ¡ek

Hi guys, What if the order of method categories in System browser would be a bit more clever and not just alphabetical? By clever I mean that private* categories are always on bottom while initialize* on top. And so on.. This can be settable in Settings, switched on by default. What do you think? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 18, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by StÃ©phane Ducasse

Thanks I will have a look On Dec 18, 2011, at 12:43 AM, Levente Uzonyi wrote: > On Sat, 17 Dec 2011, StÃ©phane Ducasse wrote: > >> >> On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote: >> >>> Cool. One more thing: in Squeak the method using primitive 132 directly was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If this was also added to Pharo, then the #pointsTo: sends should be changed to #instVarsInclude:, otherwise Array can be reported as included even if it wasn't added. >>> I'll upload my LargeIdentityDictionary implementation to the same place this evening, since it's still 2-3 factor faster than other solutionts and there seem to be demand for it. >> >> Levente >> >>> "in Squeak the method using primitive 132 directly was renamed to #instVarsInclude:, so now #pointsTo: works as expected." >> I do not get the following. Indeed pointTo: looks like instVarsInclude: now I do not understand the rest of your paragraph. > > #pointsTo: should answer true if the receiver has a pointer to the argument. Every object (except for SmallIntegers and instances of compact classes) holds a pointer to its class in the header. Since the primitive only checks the slots, it will not always return true if the argument is the object's class. This breaks pointer finding/tracing tools, that's why it was changed in Squeak. See how #instVarsInclude: and #pointsTo: is implemented there. > > > Levente > >> >> Stef

Dec. 18, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Nicolas Cellier

2011/12/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> > >> > Can't you debug it ? >> > >> > > Of course I could do it when I have some time. It already took me 1 hour to > isolate the bug from Fuel and make a reproducible test. I hope that at least > you find that useful. I found the bug and I thought I could send my progress > and see if someone could continue it. Otherwise, I was going to debug it as > soon as I have some free time (which I don't have much this year). > Yes, great job, thank you. But that's what amazed me, you stopped just before the easiest part ;) >> >> It took 2 minutes to find this sentence at line 19 of >> Â LargeDictionary>>at:put: >> > > But you are so smart and a Collection hacker. Me, I am newbie, and just the > method at:put: scares me, but I understand if it has to be that way in order > to be fast. And so far it seems to be fast, so I am happy with it. > I'm not born a "Collection hacker", nor have any Collection diploma. I'm just driven by curiosity, and in this case, no need to understand the code, reviewing it with the symptom you discovered in mind is enough. It seems to me that you put unnecessary mental barriers ;) Oh but maybe you're not so smart, you're just a casual VM hacker, and succeeded to carry Fuel project just by luck ;) I just don't believe you Nicolas > >> >> (values at: hash) at: newIndex put: key >> >> >> Can you replace key with value and retry the tests ? >> > > Yes, that works. Thanks! > > Now I noticed that SmallIntegers storing is really slow > > Â Â Â numbers :=Â OrderedCollection new. > Â Â Â numbers add: 1. > Â Â Â numbers addAll: (1 to: 1 << 29 by: 1 << 14) asArray. > Â Â Â numbers addAll: ((1 to: 1 << 29 by: 1 << 14) asArray collect: [:each | > each negated] ). > > Â Â Â dict := LargeIdentityDictionary new. > Â Â Â [numbers do: [:each | > > Â Â Â Â Â Â Â dict at: each put: dict size + 1. > Â Â Â Â Â Â ]. > Â Â Â ] timeToRun > Â Â Â Â -> 12657 > > > whereas with IdentityDictionary it is 37.Â I guess it could be related to > #identityHash or #basicIdentityHash.Â I tried in Squeak 4.3 and it is also > also there. > I will try to take a look into it during the next week. > > Thanks in advance > > >> >> Nicolas >> >> >> >> >> Thanks for any idea. >> >> >> >> >> >> >> >> On Sat, Dec 17, 2011 at 1:50 PM, StÃ©phane Ducasse >> >> <stephane.ducasse(a)inria.fr> wrote: >> >>> >> >>> >> >>> On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote: >> >>> >> >>> > Cool. One more thing: in Squeak the method using primitive 132 >> >>> > directly >> >>> > was renamed to #instVarsInclude:, so now #pointsTo: works as >> >>> > expected. If >> >>> > this was also added to Pharo, then the #pointsTo: sends should be >> >>> > changed to >> >>> > #instVarsInclude:, otherwise Array can be reported as included even >> >>> > if it >> >>> > wasn't added. >> >>> > I'll upload my LargeIdentityDictionary implementation to the same >> >>> > place >> >>> > this evening, since it's still 2-3 factor faster than other >> >>> > solutionts and >> >>> > there seem to be demand for it. >> >>> >> >>> Levente >> >>> >> >>> > "in Squeak the method using primitive 132 directly was renamed to >> >>> > #instVarsInclude:, so now #pointsTo: works as expected." >> >>> I do not get the following. Indeed pointTo: looks like >> >>> instVarsInclude: >> >>> now I do not understand the rest of your paragraph. >> >>> >> >>> Stef >> >> >> >> >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 18, 2011

Re: [Pharo-project] Class rename on materialization

by Martin Dias

On Sun, Dec 18, 2011 at 12:05 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 17/12/11 9:28 PM, Martin Dias wrote: > >> >> Well, so I guess we will change just the classes and traits, and >> not every symbol. >> >> I was in favor of renaming every symbol because the "class rename" >> refactoring changes any method who mention the original name. >> > > That's a reference to a class, by its global name, and it's the right > thing to rename it when refactoring. > > Now I'm not sure what is meant by "renaming every symbol". Is there some > structure in a compiled method (which holds a class name symbol) which is > going to be renamed? Or, are you talking about any serialized symbol, which > happened to be the same as the class to be renamed, would be renamed? Or > are both these scenarios the same? > For example, in the method Object >> arrayWithSomething ^Array with: OldClass with: #OldClass if you inspect Object >> #arrayWithSomething, in the literals you will see: - for the first array element, an association #OldClass->OldClass, which is an entry in Smalltalk globals. This association should be materialized as #NewClass->NewClass. - for the second array element, the symbol #OldClass. Here is my dubt: 1) materialize as #NewSymbol or 2) as #OldSymbol? 1) I think in this case we want to materialize the method as: arrayWithSomething ^Array with: NewClass with: #NewClass But... 2) suppose that in the same file we serialized some other object (not the above mentioned method) who points to the symbol #OldClass. Maybe we don't want to rename the symbol in this case.

Dec. 18, 2011

Re: [Pharo-project] Class rename on materialization

by Yanni Chiu

On 17/12/11 9:28 PM, Martin Dias wrote: > > Well, so I guess we will change just the classes and traits, and > not every symbol. > > I was in favor of renaming every symbol because the "class rename" > refactoring changes any method who mention the original name. That's a reference to a class, by its global name, and it's the right thing to rename it when refactoring. Now I'm not sure what is meant by "renaming every symbol". Is there some structure in a compiled method (which holds a class name symbol) which is going to be renamed? Or, are you talking about any serialized symbol, which happened to be the same as the class to be renamed, would be renamed? Or are both these scenarios the same?

Dec. 18, 2011