<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 24, 2018 at 3:14 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 24 Nov 2018, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
<br>
> Eliot Miranda uploaded a new version of Kernel to project The Trunk:<br>
> <a href="http://source.squeak.org/trunk/Kernel-eem.1198.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/trunk/Kernel-eem.1198.mcz</a><br>
><br>
> ==================== Summary ====================<br>
><br>
> Name: Kernel-eem.1198<br>
> Author: eem<br>
> Time: 24 November 2018, 1:44:47.526422 pm<br>
> UUID: 100137c4-2514-4b7f-9064-3dcdfe7d8cc9<br>
> Ancestors: Kernel-eem.1197<br>
><br>
> Redefine LargePositiveInteger hash for compatibility between 32-bit and 64-bit systems.<br>
><br>
> =============== Diff against Kernel-eem.1197 ===============<br>
><br>
> Item was changed:<br>
> ----- Method: LargePositiveInteger>>hash (in category 'comparing') -----<br>
> hash<br>
> + "Answer an integer value that is related to the value of the receiver.<br>
> + Take care that the hash value is the same in both 32-bit and 64-bit versions.<br>
> + Since the integers are by definition perfectly distributed a SmallInteger's hash is itself<br>
> + (it is impossible to derive a hash function that is better distributed than the SmallIntegers<br>
> + themselves). Therefore, for integers that could possibly fit in the SmallInteger range, answer<br>
> + self. For values well outside of the SmallInteger range on 64-bits answer a hash that avoids<br>
> + large integer arithmetic."<br>
> + ^self digitLength <= 8<br>
> + ifTrue: [self]<br>
> + ifFalse:<br>
> + [ByteArray<br>
> + hashBytes: self<br>
> + startingWith: self species hash]!<br>
> - <br>
> - ^ByteArray<br>
> - hashBytes: self<br>
> - startingWith: self species hash!<br>
><br>
> Item was changed:<br>
> ----- Method: SmallInteger>>hash (in category 'comparing') -----<br>
> hash<br>
> + "Answer an integer value that is related to the value of the receiver.<br>
> + Since the integers are by definition perfectly distributed answer self<br>
> + (it is impossible to derive a hash function that is better distributed<br>
> + than the SmallIntegers themselves). c.f. LargePositiveInteger hash."<br>
><br>
> ^self!<br>
><br>
> Item was changed:<br>
> (PackageInfo named: 'Kernel') postscript: '"below, add code to be run after the loading of this package"<br>
> + "Since Kernel-eem.1198 redefines LargePositiveInteger hash,<br>
> + rehash all hashed collections that contain hashed large integers."<br>
> + HashedCollection allSubclassesDo:<br>
> + [:c| | f |<br>
> + f := (c includesBehavior: Set)<br>
> + ifTrue: [[:i| i]]<br>
> + ifFalse: [[:i| i keys]].<br>
> + c allInstancesDo:<br>
> + [:h|<br>
> + ((f value: h) detect: [:e| e isInteger and: [e class ~~ SmallInteger]] ifNone: nil) ifNotNil:<br>
> + [h halt rehash]]]'!<br>
<br>
Is there a reason for that #halt to be there?<br></blockquote><div><br></div><div>Damn. I was debugging the script to make sure it would work (there are no such dictionaries or sets in a normal image), and I forgot to remove the halt. I shall submit a new version...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Levente<br>
<br>
> - ((ByteArray subclasses includes: CompiledMethod)<br>
> - and: [CompiledMethod superclass ~= ByteArray]) ifTrue:<br>
> - [ByteArray removeSubclass: CompiledMethod].<br>
> - (Smalltalk classNamed: #FullBlockClosure) ifNotNil:<br>
> - [:fbc|<br>
> - (fbc identityHash ~= 38) ifTrue:<br>
> - [fbc tryPrimitive: 161 withArgs: #(38 true)]]'!<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>