- Pharo-dev - lists.pharo.org

[Pharo-project] question about results of MessageTally
by Laval Jannik Oct. 26, 2009

Oct. 26, 2009

Hi, when I use MassageTally>>spyOn: on the creation of a Dictionary, results have not the same details according to the size of Dictionary. For example: === |n| MessageTally spyOn:[ n := Dictionary new. 1 to: 400000 do:[:each | n at: each put:each]. ] === returns this results: ==== - 1745 tallies, 1751 msec. **Tree** -------------------------------- Process: (40s) 1964: nil -------------------------------- 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: |43.6% {763ms} Dictionary(Set)>>fullCheck | |39.4% {690ms} Dictionary(Set)>>grow | | |27.2% {476ms} Dictionary>>noCheckAdd: | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: | | | | |23.6% {413ms} Dictionary>>scanFor: | | | | |1.6% {28ms} primitives | | | |2.0% {35ms} primitives | | |9.2% {161ms} primitives | | |3.0% {53ms} Array(SequenceableCollection)>>do: | |2.4% {42ms} primitives | |1.8% {32ms} SmallInteger(Magnitude)>>max: |2.2% {39ms} primitives 22.4% {392ms} Association class>>key:value: |18.9% {331ms} Association class(LookupKey class)>>key: | |16.3% {285ms} Association(LookupKey)>>key: | |2.6% {46ms} primitives |1.9% {33ms} Association>>value: |1.6% {28ms} primitives 4.4% {77ms} Dictionary(Set)>>findElementOrNil: |2.3% {40ms} primitives |2.1% {37ms} Dictionary>>scanFor: 1.9% {33ms} primitives ==== But, if I do: === |n| MessageTally spyOn:[ n := Dictionary new. 1 to: 4000000 do:[:each | n at: each put:each]. ] === results are: ==== - 179772 tallies, 180312 msec. **Tree** -------------------------------- Process: (40s) 1964: nil -------------------------------- 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: |2.8% {5049ms} Dictionary(Set)>>fullCheck | 2.3% {4147ms} Dictionary(Set)>>grow | 1.3% {2344ms} Dictionary>>noCheckAdd: 1.0% {1803ms} Association class>>key:value: ==== Where are the rest of the process ? Does anybody understand this behavior ? can you explain ? Cheers, Jannik

5 9

[Pharo-project] Dynamic Traits
by John Toohey Oct. 26, 2009

Oct. 26, 2009

Is is possible to apply a Trait to an object after it has been created? I have a situation where I have a collection of object that have been populated from a database, and depending on a typeId property, I would like to apply different Traits to that object. Each Trait would have the same method signatures, but the calculations performs by those methods would be different in each case. -- -JT

2 1

Re: [Pharo-project] (a = b) => (a hash = b hash)
by Ralph Boland Oct. 26, 2009

Oct. 26, 2009

> I agree with Nicolas, but I think that it's really important that we > have this discussion, reach a consensus, and them implement it! > > That's why I posted the message here rather than just posting a bug > report. > > There used to be a method called hasSameElementsAs: (now called, > inexplicably, sameElements:) that could be pressed into service so > that two intervals, or an array and and interval, can have the same > elements but still be unequal. Â But the role of species was to define > when things could be equal... > > Maybe we need a method "hasSameSequenceOfElementsAs:" which would be > applicable to any pair of Â sequenceable collections, as well as being > faster to implement, than sameElements: (which is currently quadratic). I assume that by quadratic you mean a quadratic number of compares. If you implement hasSameElementsAs: by putting the elements of at least one of your collections into a set and assume the include: operation for sets is O(1) compares then the cost of hasSameElementsAs: is linear compares. If you want to count duplicates then you need to use bags instead of sets. Perhaps you already knew this. Ralph Boland

1 0

[Pharo-project] New inspector: pain when inspecting large collections
by Igor Stasenko Oct. 26, 2009

Oct. 26, 2009

Try this: SystemOrganization inspect -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] Test what primitive is faster #clone, of #basicNew?
by Igor Stasenko Oct. 26, 2009

Oct. 26, 2009

Hello, creating a new objects is quite fast, but i wonder, what if it could be made even faster for objects of fixed size (not variable sized ones) by using a #clone primitive instead of #basicNew? The trick to use #clone is, that we can keep a 'sample' in class instance variable: Mytestclass class instanceVariableNames: 'sample' Mytestclass class>>initialize sample := self basicNew and then: Mytestclass class>>new ^ sample clone initialize The problem, that i can't make a benchmark , which could really tell the difference between those two ways, so we could be 100% sure what is faster. Any ideas how to bench it? -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] [ANN] Pharo rc1dev10491 - Win32 Installer
by Torsten Bergmann Oct. 25, 2009

Oct. 25, 2009

Forgot to mention: Windows Installer 1.0-10491-rc1dev09.10.5 is up on the download page. Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

3 2

[Pharo-project] Some bugs I ran into while working on hashing
by Andres Valloud Oct. 25, 2009

Oct. 25, 2009

Hello, are these problems known? I am using the latest RC build. * Create changeset X. Touch method Foo>>bar. Create changeset Y. Touch method Foo>>bar again. Fileout changeset X. The fileout has the code for changeset Y. * Delete the first ! in a changeset with a preamble. Try to load it from the file tool. You get a syntax error. However, the progress bar does not go away. Is the file handle released? * Integer>>isPrime should not be probabilistic. Suggestion: rename it to Integer>>isMostLikelyPrime or something similar. Implement a deterministic prime check for isPrime (even if it is slow --- users then can decide whether they want a deterministic or probabilistic answer). Here's a rough sketch of Integer>>isPrime: isPrime | guess guessSquared delta selfSqrtFloor | self <= 1 ifTrue: [^self error: 'operation undefined']. self even ifTrue: [^self = 2]. guess := 1 bitShift: self highBit + 1 // 2. [ guessSquared := guess * guess. delta := guessSquared - self // (guess bitShift: 1). delta = 0 ] whileFalse: [guess := guess - delta]. guessSquared = self ifFalse: [guess := guess - 1]. selfSqrtFloor := guess. 3 to: selfSqrtFloor by: 2 do: [:each | self \\ each = 0 ifTrue: [^false]]. ^true Also, the above code can be used to implement sqrtFloor and sqrtRounded in Integer. I am sure Nicolas Cellier remembers this :). Finally, I'm not sure that isPrime should fail with "undefined operation" if the receiver is <= 1. 1 is certainly not prime. Primes must be positive, so zero and the negatives could just answer false. ???... * Open an inspector on e.g.: Smalltalk. In the code pane, type: self keys inject: Set new into: [:t :x | t add: x class; yourself] Using the mouse, select the expression, and inspect the result using the right button menu item. The result comes up. However, the inspector on Smalltalk experiences a failure in one of its panes because lines is nil in MultiNewParagraph(NewParagraph)>>fastFindFirstLineSuchThat: Andres.

3 4

Re: [Pharo-project] hashing collections
by Ralph Boland Oct. 25, 2009

Oct. 25, 2009

> > Watch out for cancellation effects... if the collections are > sequenceable and the hash values of their contents are not well > distributed, you may end up with performance issues because the hash > values cancel each other because the hash function commutes. Â Consider > for example the hash value of the following collections: > > #(1 2 3) > #(1 2 3 4 4) > #(1 2 3 5 5) > #(1 4 2 3 4) > #(5 4 3 2 1 4 5) > > #(6) > #(1 2 3 4 5 6 5 4 3 2 1) > > I am not familiar with your application, though, so perhaps the data > does not cause these problems. > > Andres. > You are right. These are serious problems with my idea and I retract the proposal that the idea may be preferable to the problems we have with putting the standard collections into Sets and Dictionaries. It works well in my application because in each case the collections have no duplicates and order doesn't matter. That is, in my application, the hash collections are all effectively sets or dictionaries in compacted form. I use a bit of code specific to my application to ensure they then are compared efficiently. Ralph > Ralph Boland wrote: >> Food for thought: >> >> In my finite state machine generator I do a lot of >> hashing of sometimes large collections. >> For performance reasons I created hash value storing versions >> of the relevant collection classes. Â Getting the hash value >> of the hashed version of a collection was then very fast >> (accessing an instance value) and the hash values were good. >> >> For example, for Array I created HashArray Â The hash >> value of a HashArray was the XOR of the hash values of >> the elements of the HashArray. Â Note that this meant >> that each time you changed the entry in a HashArray >> you had to update the hash value. >> So for HashArray Â Â at: index put: object Â Â would look something >> like: >> >> Â Â Â hash := (hash xor: object hash) xor: (self at: index). >> Â Â Â super at: index put: object. >> >> If you like living on the edge you could instead leave out updating >> the hash value until you put the HashArray object where its hash >> value would be needed (like a Set or Dictionary (key)). >> This is of course error prone but then >> putting collections in Sets or Dictionaries (keys) >> is inherently error prone anyway because modifying the collection >> changes its hash value thus breaking every Set or Dictionary >> containing the collection. >> >> I would be temped to have all real collection classes (e.g. not Interval) >> not be storable in Sets or Dictionaries (key) at all and instead require >> hash versions of the collection be used but of course this would >> surely break a lot of things. >> >> Ralph Boland >> >> >>

1 0

[Pharo-project] Improve pharo modularity: a first step
by Laval Jannik Oct. 25, 2009

Oct. 25, 2009

Hi all, I would like to improve the modularity of packages in pharo. A first simple thing that I see, is methods "example" use a lot of things in the system. And create cycles between packages. So, I propose to create a new package named "Examples" and put in it all methods named "example2"... Jannik

5 6

Oct. 25, 2009

11019 ----- - Issue 1343: System-Pragmas - new system category which includes Pragma class and Pragma related stuffs from System-Settings - Reorganized Kernel package by moving Pragma class from Kernel- Methods to Kernel-Pragmas system category - Moved PragmaCollector and related stuff from System-Settings to Kernel-Pragmas.

1 0