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

32 vs 64 bits and large integer hash
by Eliot Miranda Nov. 22, 2018

Nov. 22, 2018

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

2 2

ZnCharacterReadWriteStream is missing #tab
by Torsten Bergmann Nov. 22, 2018

Nov. 22, 2018

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.

2 1

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash
by Chris Muller Nov. 22, 2018

Nov. 22, 2018

> 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.

1 0

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash
by Chris Muller Nov. 22, 2018

Nov. 22, 2018

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.

1 0

Fwd: 32 vs 64 bits and large integer hash
by Sean P. DeNigris Nov. 22, 2018

Nov. 22, 2018

>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

1 0

[Pharo 7.0-dev] Build #1411: 22689-support-reification-value-and-operation-on-LiteralArray
by ci-pharo-ci-jenkins2＠inria.fr Nov. 21, 2018

Nov. 21, 2018

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…

1 0

[Pharo 7.0-dev] Build #1410: 22678-Update-calypso-to-v0130
by ci-pharo-ci-jenkins2＠inria.fr Nov. 21, 2018

Nov. 21, 2018

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…

1 0

glamorous toolkit alpha.3
by Tudor Girba Nov. 21, 2018

Nov. 21, 2018

Hi, Another month has swooshed and now itâs time for Glamorous Toolkit alpha.3: https://feenk.com/gt The key things that changed are as follows: - We rewrote Documenter. This was challenge, but the results are more than worth it. One visible thing is that now the previews get cached, and as a consequence we can actually work inside the document. But, perhaps the more impactful thing is that we can now toggle the visibility of Pillar markup. We think it significantly improves the experience and consequently, the value of the live documents. - We advanced the work on the method Coder. To explore the boundaries, we reimagined the extract method refactoring. Thatâs : https://twitter.com/feenkcom/status/1064823381407748096 - We enhanced the navigation in Playground / Inspector: https://twitter.com/feenkcom/status/1064823381407748096 A more complete list of issues we addressed is found here: https://github.com/feenkcom/gtoolkit/milestone/1?closed=1 Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

3 2

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash
by Chris Muller Nov. 21, 2018

Nov. 21, 2018

> To make things more clear, the current implementation of Behavior >> #hash > has two negative side effects: > - behaviors stored in collections relying on the hash value (e.g. Set, > Dictionary) will have to be rehashed whenever a behavior is renamed > - objects using Behavior >> #hash to implement their own #hash, like what > Eliot just did to Message will suffer from the same issue. So Sets and > Dictionaries holding those kind of objects will have to be rehashed as > well upon the rename of the behavior. > > 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. > - do we want to fix those issues mentioned above or do we just say that > one should not rename classes and expect things to work? Neither. We just say that when one renames a class to rehash all relevant HashedCollections. - Chris

1 0

Re: [Pharo-dev] [Cuis-dev] Message>>#= & Message>>#hash
by Eliot Miranda Nov. 20, 2018

Nov. 20, 2018

Hi Juan, On Tue, Nov 20, 2018 at 8:00 AM Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Eliot, > > (below) > On 19/11/2018 02:32 p.m., Eliot Miranda via Cuis-dev wrote: > > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > comparison. This is, to say the least, annoying. Any objections to > implementing comparing in Message to match VisualWorks? > > _,,,^..^,,,_ > best, Eliot > > > Just added these implementations to Cuis: > > = aMessage > "Any object is equal to itself" > self == aMessage ifTrue: [ ^ true ]. > self class == aMessage class ifFalse: [ ^false ]. > selector = aMessage selector ifFalse: [ ^false ]. > lookupClass = aMessage lookupClass ifFalse: [ ^false ]. > ^args = aMessage arguments > this last line should be ^args literalEqual: aMessage arguments and this is very important :-) > > hash > "Hash is reimplemented because = is implemented." > ^selector hash bitXor: args hash > > Do they look ok? (I considered lookupClass for #=, but not for hash, as > collisions because of that seem unlikely, and in any case, grouping them > that way could be useful). > > Cheers, > > -- > Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smallt… > @JuanVuletich > > -- _,,,^..^,,,_ best, Eliot

1 0