- Pharo-dev - lists.pharo.org

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

by Levente Uzonyi

On Sun, 18 Dec 2011, Mariano Martinez Peck wrote: > Actually, the long test is > "Create some bitmaps" > > numbers := OrderedCollection new. > numbers addAll: (1 to: 1 << 29 by: 1 << 14) asArray. > numbers addAll: ((1 to: 1 << 29 by: 1 << 14) asArray collect: [:each | > each negated] ). > > "Put them in a dictionary using dict as as key" > dict := LargeIdentityDictionary new. > numbers do: [:each | > dict at: each put: dict size + 1. > ]. > > "Check they are correct" > numbers doWithIndex: [:each :index | self assert: index == (dict at: > each)] Fixed. Levente > > On Sun, Dec 18, 2011 at 7:17 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >>>>> 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. >>> >>> >> Hi Levente. First let me say I really appreaciate your effort in make it >> work. It makes definitvly Fuel faster and it would make sense to integrate >> them also in Squeak and Pharo. >> Now, I found another bug. To reproduce it: >> >> | dict | >> dict := LargeIdentityDictionary new. >> dict at: 16941057 put: 1035. >> >> Now, it seems 16941057 largeIdentityHash answers 4096 and the comment of >> #largeIdentityHash says ""Return an integer between 0 and 4095 based on >> all of my bits. Make sure that for nearby receivers the result will not be >> nearby with high probability."" >> >> The thing is that LargeIdentityHashedCollection permuteHash: hash + 1 >> answers 4096, and hence, when in #at:put: you do: >> >> at: key put: value >> >> | hash | >> (keys at: (hash := key largeIdentityHash + 1)) >> >> then you get the out of bounds. >> >> Modyfing >> >> initialize >> >> | rng | >> rng := Random seed: 664399324. >> PermutationMap := (1 to: 4096) asArray shuffleBy: rng >> >> to 4095 make some tests to pass, but there are some other failing. >> >> I will try to continue to see if I find the error. >> >> Thanks! >> >> >>> 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<http://marianopeck.wordpress.com> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>>>> >>>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 18, 2011

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

by Mariano Martinez Peck

Actually, the long test is "Create some bitmaps" numbers := OrderedCollection new. numbers addAll: (1 to: 1 << 29 by: 1 << 14) asArray. numbers addAll: ((1 to: 1 << 29 by: 1 << 14) asArray collect: [:each | each negated] ). "Put them in a dictionary using dict as as key" dict := LargeIdentityDictionary new. numbers do: [:each | dict at: each put: dict size + 1. ]. "Check they are correct" numbers doWithIndex: [:each :index | self assert: index == (dict at: each)] On Sun, Dec 18, 2011 at 7:17 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > >>>> 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. >> >> > Hi Levente. First let me say I really appreaciate your effort in make it > work. It makes definitvly Fuel faster and it would make sense to integrate > them also in Squeak and Pharo. > Now, I found another bug. To reproduce it: > > | dict | > dict := LargeIdentityDictionary new. > dict at: 16941057 put: 1035. > > Now, it seems 16941057 largeIdentityHash answers 4096 and the comment of > #largeIdentityHash says ""Return an integer between 0 and 4095 based on > all of my bits. Make sure that for nearby receivers the result will not be > nearby with high probability."" > > The thing is that LargeIdentityHashedCollection permuteHash: hash + 1 > answers 4096, and hence, when in #at:put: you do: > > at: key put: value > > | hash | > (keys at: (hash := key largeIdentityHash + 1)) > > then you get the out of bounds. > > Modyfing > > initialize > > | rng | > rng := Random seed: 664399324. > PermutationMap := (1 to: 4096) asArray shuffleBy: rng > > to 4095 make some tests to pass, but there are some other failing. > > I will try to continue to see if I find the error. > > Thanks! > > >> 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<http://marianopeck.wordpress.com> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 18, 2011

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

by Mariano Martinez Peck

> >>> 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. > > Hi Levente. First let me say I really appreaciate your effort in make it work. It makes definitvly Fuel faster and it would make sense to integrate them also in Squeak and Pharo. Now, I found another bug. To reproduce it: | dict | dict := LargeIdentityDictionary new. dict at: 16941057 put: 1035. Now, it seems 16941057 largeIdentityHash answers 4096 and the comment of #largeIdentityHash says ""Return an integer between 0 and 4095 based on all of my bits. Make sure that for nearby receivers the result will not be nearby with high probability."" The thing is that LargeIdentityHashedCollection permuteHash: hash + 1 answers 4096, and hence, when in #at:put: you do: at: key put: value | hash | (keys at: (hash := key largeIdentityHash + 1)) then you get the out of bounds. Modyfing initialize | rng | rng := Random seed: 664399324. PermutationMap := (1 to: 4096) asArray shuffleBy: rng to 4095 make some tests to pass, but there are some other failing. I will try to continue to see if I find the error. Thanks! > 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 <http://marianopeck.wordpress.com> >>>>>> >>>>>> >>>> >>>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >> -- Mariano http://marianopeck.wordpress.com

Dec. 18, 2011

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