November 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 32 vs 64 bits and large integer hash

by Marcus Denker

> On 22 Nov 2018, at 10:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 21 Nov 2018, at 19:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi All, >> >> right now we have the following definition of Large(Positive)Integer>>hash: >> >> hash >> ^ByteArray hashBytes: self startingWith: self species hash >> >> which means that for all integers outside of the 32-bit SmallInteger range (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer different values for hash. >> >> e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 >> but in 32 bits: (2 raisedTo: 30) hash 230045764 >> >> This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to >> >> hash >> ^self digitLength <= 8 >> ifTrue: [self] >> ifFalse: [ByteArray hashBytes: self startingWith: self species hash] >> >> > > Thanks, I added an issue tracker entry: > > https://pharo.fogbugz.com/f/cases/22690/32-vs-64-bits-and-large-integer-hash > > I will do a pull request later (if not someone else is faster to do it). https://github.com/pharo-project/pharo/pull/2009 <https://github.com/pharo-project/pharo/pull/2009> > > -- > Marcus Denker -- marcus(a)2denker.de > http://www.zweidenker.de

Nov. 22, 2018

Re: [Pharo-dev] 32 vs 64 bits and large integer hash

by Marcus Denker

> On 21 Nov 2018, at 19:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > right now we have the following definition of Large(Positive)Integer>>hash: > > hash > ^ByteArray hashBytes: self startingWith: self species hash > > which means that for all integers outside of the 32-bit SmallInteger range (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer different values for hash. > > e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 > but in 32 bits: (2 raisedTo: 30) hash 230045764 > > This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to > > hash > ^self digitLength <= 8 > ifTrue: [self] > ifFalse: [ByteArray hashBytes: self startingWith: self species hash] > > Thanks, I added an issue tracker entry: https://pharo.fogbugz.com/f/cases/22690/32-vs-64-bits-and-large-integer-hash I will do a pull request later (if not someone else is faster to do it). Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.zweidenker.de

Nov. 22, 2018

Re: [Pharo-dev] ZnCharacterReadWriteStream is missing #tab

by Sven Van Caekenberghe

Do you load from https://github.com/svenvc/zinc using the baseline ? I mostly moved to GitHub (well I try to support both). See the Travis CI build as well. > On 22 Nov 2018, at 00:17, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > in latest P7 I get an error when loading my Bootstrap 4 project: > > https://github.com/astares/Seaside-Bootstrap4 > > about > > MessageNotUnderstood: ZnCharacterReadWriteStream>>tab > > This is sent from STONWriter>>newlineIndent. > > To reproduce please use the following load expression: > > Metacello new > baseline:'Bootstrap4'; > repository: 'github://astares/Seaside-Bootstrap4:master/src'; > load > > > If the missing method in ZnCharacterReadWriteStream is implemented like > > tab > writeStream tab > > it works. > > As I'm constantly unclear about how Zinc (and some other externally maintained packages) > are managed now I would kindly ask you to integrate it. Thanks in advance! > > Bye > T. >

Nov. 22, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

> That's "one should not rename classes and expect things to work", isn't > it? Not really, since that is already true anyway. If you rename a class, all references to that class will be broken.

Nov. 22, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

Hi Levente, > >> My questions related to this: > >> - why does Behavior >> #hash rely on the name instead of identity? > > > > If you mean #identityHash, then its because involving an unstable > > value in a #hash calculation is never a good idea. #identityHash can > > be different for the same class between two different images, or if > > the class was ever becomed or reloaded into a new image, etc. > > Is there an actual user of that feature? Several actually. If your primary motivation is improving performance then we could cache the hash value, possibly even straight in the CompiledMethod itself (hard-coded). But we _must not_ destroy stable and deterministic hashes. It would be a huge blow to existing users and even future potential possibilities of future implementations of things. Anything that would try to share #hash calculations between images... Possibly Croquet. It's easy to imagine some things! MagmaDictionary is just a Dictionary except the internal array grows on disk providing size scalability while sparing RAM. The #hash of the objects put into it are calculated by the clients -- it must be consistent between users. source.squeak.org uses a MagmaDictionary for the revision history. It was the best way to introduce the capability without invading Monticello's code at all. > Bob found out that #hash had been changed during the developement of > Squeak 3.9. Therefore this issue is not present in Cuis (forked from 3.7). > And I just checked Pharo and found that Behavior >> #hash had been removed > from there. I think that's a big mistake. There's no need for us to cross the line of a stable hash to a volatile one. We can cache it.

Nov. 22, 2018

Fwd: 32 vs 64 bits and large integer hash

by Sean P. DeNigris

>From Squeak-Dev, seems to be an issue on Pharo as well... Eliot Miranda-2 wrote > Hi All, > > right now we have the following definition of > Large(Positive)Integer>>hash: > > hash > ^ByteArray hashBytes: self startingWith: self species hash > > which means that for all integers outside of the 32-bit SmallInteger range > (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer > different values for hash. > > e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 > but in 32 bits: (2 raisedTo: 30) hash 230045764 > > This is unsatisfactory. I propose changing Large(Positive)Integer>>hash > to > > hash > ^self digitLength <= 8 > ifTrue: [self] > ifFalse: [ByteArray hashBytes: self startingWith: self species hash] > > > P.S. Note that this will not break Float hash, which is defined as > > Float>>hash > "Hash is reimplemented because = is implemented. Both words of the float > are used. (The bitShift:'s ensure that the intermediate results do not > become a large integer.) Care is taken to answer same hash as an equal > Integer." > > (self isFinite and: [self fractionPart = 0.0]) ifTrue: [^self truncated > hash]. > ^ ((self basicAt: 1) bitShift: -4) + > ((self basicAt: 2) bitShift: -4) > > P.P.S. I *think* that "(self isFinite and: [self fractionPart = 0.0])" is > equivalent to "self - self = self fractionPart" ;-) > > _,,,^..^,,,_ > best, Eliot ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 22, 2018

ZnCharacterReadWriteStream is missing #tab

by Torsten Bergmann

Hi Sven, in latest P7 I get an error when loading my Bootstrap 4 project: https://github.com/astares/Seaside-Bootstrap4 about MessageNotUnderstood: ZnCharacterReadWriteStream>>tab This is sent from STONWriter>>newlineIndent. To reproduce please use the following load expression: Metacello new baseline:'Bootstrap4'; repository: 'github://astares/Seaside-Bootstrap4:master/src'; load If the missing method in ZnCharacterReadWriteStream is implemented like tab writeStream tab it works. As I'm constantly unclear about how Zinc (and some other externally maintained packages) are managed now I would kindly ask you to integrate it. Thanks in advance! Bye T.

Nov. 21, 2018

32 vs 64 bits and large integer hash

by Eliot Miranda

Hi All, right now we have the following definition of Large(Positive)Integer>>hash: hash ^ByteArray hashBytes: self startingWith: self species hash which means that for all integers outside of the 32-bit SmallInteger range (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer different values for hash. e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 but in 32 bits: (2 raisedTo: 30) hash 230045764 This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to hash ^self digitLength <= 8 ifTrue: [self] ifFalse: [ByteArray hashBytes: self startingWith: self species hash] P.S. Note that this will not break Float hash, which is defined as Float>>hash "Hash is reimplemented because = is implemented. Both words of the float are used. (The bitShift:'s ensure that the intermediate results do not become a large integer.) Care is taken to answer same hash as an equal Integer." (self isFinite and: [self fractionPart = 0.0]) ifTrue: [^self truncated hash]. ^ ((self basicAt: 1) bitShift: -4) + ((self basicAt: 2) bitShift: -4) P.P.S. I *think* that "(self isFinite and: [self fractionPart = 0.0])" is equivalent to "self - self = self fractionPart" ;-) _,,,^..^,,,_ best, Eliot

Nov. 21, 2018

[Pharo 7.0-dev] Build #1411: 22689-support-reification-value-and-operation-on-LiteralArray

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1411 was: SUCCESS. The Pull Request #2007 was integrated: "22689-support-reification-value-and-operation-on-LiteralArray" Pull request url: https://github.com/pharo-project/pharo/pull/2007 Issue Url: https://pharo.fogbugz.com/f/cases/22689 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 21, 2018

[Pharo 7.0-dev] Build #1410: 22678-Update-calypso-to-v0130

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1410 was: SUCCESS. The Pull Request #1998 was integrated: "22678-Update-calypso-to-v0130" Pull request url: https://github.com/pharo-project/pharo/pull/1998 Issue Url: https://pharo.fogbugz.com/f/cases/22678 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 21, 2018