On 01 Aug 2014, at 3:20 , Serge Stinckwich <[email protected]> wrote:
> Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, Speaking of which, when trying to inspect the array, it’s incredibly slow… The main reason for this? BasicIndexedEyeElement >> hash ^super hash bitXor: index hash The super implementation? AbstractEyeElement >> hash ^host hash Guess what the host of an indexedEyeElement is? That’s right, the collection… So every time it tries to find the cached icon of a line (which is, 10-20 times per refresh cycle depending on the view), it iterates through the 100000 element array to calculate its hash… I’d recommend either removing the super call from BasicIndexedEyeElement, or tell the AbstractEyeElement to use the identityHash of its host instead. Bonus: It also invokes a #DNU hander every time, since DictionaryValueHolder >> at:ifAbsentPut: is implemented self at: key ifAbsent: []. instead of value at: key ifAbsent: []. Code quality progress. Yay. Cheers, Henry
signature.asc
Description: Message signed with OpenPGP using GPGMail
