- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11019

by StÃ©phane Ducasse

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.

Oct. 25, 2009

Re: [Pharo-project] Some bugs I ran into while working on hashing

by Nicolas Cellier

2009/10/25 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/10/25 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> >> 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 :). > > If http://bugs.squeak.org were not down, I would even provide a link > with these enhancements > google says it should be http://www.google.fr/bugs.squeak.org/view.php?id=7099. Or go to the source http://blogten.blogspot.com/2008/06/drove-to-reno-today.html http://blogten.blogspot.com/2008/06/update-on-sqrtrounded.html >> >> Andres. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 25, 2009

Re: [Pharo-project] Thread-safe collections

by Philippe Marschall

Igor Stasenko wrote: > 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> I just looked around for thread-safe collections, and found nothing that looks like a shared dictionary. The squeak-dev archives contain the obligatory newbie posts (wanting all collections to be thread safe) and the expected replies, some of which are overly dismissive of the idea. Something that protects things like #at:ifAbsentPut: and friends is _really_ useful. Am I missing an existing implementation? >> > > Imo, there's only one shared collection which is useful - shared queue. :) Yeah, sure. Where again do I store my Seaside sessions? Oh, it's no problem, because we use only one worker thread and process requests on after another. Geez, problem solved. Cheers Philippe

Oct. 25, 2009

Re: [Pharo-project] ClassOrganizer oddities

by StÃ©phane Ducasse

knowing that this is roel that probably wrote that I would pay really attention because it is certainly something tricky. On Oct 25, 2009, at 1:36 PM, Igor Stasenko wrote: > I discovered a puzzling behavior: > > removeElement: element > | oldCat | > oldCat := self categoryOfElement: element. > SystemChangeNotifier uniqueInstance doSilently: [ > super removeElement: element]. > self notifyOfChangedSelector: element from: oldCat to: (self > categoryOfElement: element). > > > I staring at it and i wonder, what the author meant by doing: > > super removeElement: element > > which effectively wipes out given element, but then next line uses: > > self categoryOfElement: element > > huh??? > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2009

Re: [Pharo-project] (a = b) => (a hash = b hash)

by Nicolas Cellier

2009/10/24 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Nicolas, >> Yes, large Array hash has severe performance penalty anyway. >> Maybe we shall not hash each and every element. >> > > I disagree. Â The issue is that if hashing a very large array (or string) > becomes a performance problem, then we should engineer applications so > that we hash the metadata as opposed to the data. > > In other words, assume you're hashing arbitrary 1kb strings. Â You can't > have more than ~1 million of those in memory at any given time, and > there are only so many you can store in a database. Â Chances are those > 1kb strings represent chunks of data that can be uniquely identified > with no more than e.g.: 64 bits. Â Then, just hash those 64 bits and be > done with it. Â In the absence of assumptions on the hashed data, though, > you have no option other than to hash everything. > Good point. Where is the balance between expensive hash and expensive collisions ? The cost of collisions is - perform hash and = on each successive keys untill hash is different or = is true Omitting a single byte in a ByteString leads to 256 possible collisions... So with this POV, it is better to spend time in hash to reduce the cost of worst-case distribution of keys with default hash algorithm. My POV was to reduce cost for some distribution of keys, without caring too much about worst case... One then has to provide its own hash function for optimizing its problem... But maybe that was not a good tradeoff... In any case, restricting hash to leading characters is the worst choice because it leads to late detection of string1 ~= string2 for strings of equal hash... >> And, even forgetting about equality with Array, Inteval>>#= and >> Interval>>#hash do not agree in Squeak and Pharo: >> >> Â Â Â (1 to: 10 by: 5) Â = (1 to: 9 by: 5). -> true >> Â Â Â (1 to: 10 by: 5) hash = (1 to: 9 by: 5) hash. -> false >> >> > > Sometimes the end points of intervals are important... maybe it's better > to have equality fail than "fixing" hash in this case. > > Andres. > Either changing Interval>>#= or Interval>>#hash is NECESSARY. I note that Interval is used for Text selection, and in this context (3 to: 2) is different from (4 to: 3), though they both equal #(). But this usage is related to another oddity (empty Interval have a first and a last element !). IMO, we should not let Array hash ~= Interval hash coexist with Array = Interval Because it's like putting some traps on programmers path. One day or the other an application will exhibit a non repeatable error, just because the size of a Set was different and caused a collision. A general purpose library has to be robust, reliable and provide repeatable behavior. If behavior changes just because of allocated size of a container, then it is a bad library. I feel OK with the solution of having Array ~= Interval, if we have to trade this feature against spoiling hashedCollection efficiency. Of course, this could impact some code... Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2009

Re: [Pharo-project] Some bugs I ran into while working on hashing

by Nicolas Cellier

2009/10/25 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > > 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 :). If http://bugs.squeak.org were not down, I would even provide a link with these enhancements > > Andres. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2009

[Pharo-project] ClassOrganizer oddities

by Igor Stasenko

I discovered a puzzling behavior: removeElement: element | oldCat | oldCat := self categoryOfElement: element. SystemChangeNotifier uniqueInstance doSilently: [ super removeElement: element]. self notifyOfChangedSelector: element from: oldCat to: (self categoryOfElement: element). I staring at it and i wonder, what the author meant by doing: super removeElement: element which effectively wipes out given element, but then next line uses: self categoryOfElement: element huh??? -- Best regards, Igor Stasenko AKA sig.

Oct. 25, 2009

Re: [Pharo-project] Some bugs I ran into while working on hashing

by StÃ©phane Ducasse

thanks andres can you open bug entries? > 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. It has always been like that in squeak since years. in Squeak cs do not record actual change but just that something changed. > * 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2009

Re: [Pharo-project] Traits composition question

by Igor Stasenko

2009/10/25 Adrian Lienhard <adi(a)netstyle.ch>: > No, this is not possible. You can only exclude single methods but not > whole traits. > Too bad, specifying dozens of methods for exclusion is not very funny :) > Adrian > > On Oct 25, 2009, at 06:37 , Igor Stasenko wrote: > >> Suppose i having a trait grouping >> >> Trait named: #TraitGroup >> uses: TraitA + TraitB + .... TraitN >> category: 'foo' >> >> and suppose i want to use TraitGroup in one of my classes, but >> excluding one of the traits in the list above.. i.e. something like: >> >> Object subclass: #Myclass >> uses: TraitGroup - TraitA >> .. >> >> but the above code don't seem to work.. >> Any clues, how i can do that? >> Is such kind of composition possible at all? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 25, 2009

Re: [Pharo-project] Feature request: All uses of Trait

by Igor Stasenko

2009/10/25 Adrian Lienhard <adi(a)netstyle.ch>: > TClassAndTraitDescription users > err.. i didn't meant to get them programmatically. I meant the tools support :) > Cheers, > Adrian > > On Oct 25, 2009, at 06:26 , Igor Stasenko wrote: > >> It would be cool to have a 'references-to' support for traits. >> Or maybe its there already? >> >> How can i quickly look, what classes using the trait? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 25, 2009