October 2009 - Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

> > Yes. Filenames and URLs are particularly problematic. Fortunately > they > tend to be O(100) in size, as opposed to O(1000) in size. Thus, the > less demanding path of just hashing the characters is efficient enough > for the cases I've seen so far. > >> IMO, we should not let Array hash ~= Interval hash coexist with >> Array = Interval >> Because it's like putting some traps on programmers path. >> > > Yes, I agree. I'd vote on breaking #=, with the caveat that chances > are > some code will be broken. Does Pharo have a release strategy that > allows more fundamental changes to go in, as opposed to > maintenance/improvement fixes? yes we talk then we summarize and describe a bug entry and Now I'm thinking that it would be good to have a page with important changes per version I would put there the discussions about the float changes we did in 1.0. Stef

Oct. 27, 2009

Re: [Pharo-project] update server down?

by StÃ©phane Ducasse

apparently the forge was down yesterday evening. Not sure that this is available now. On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: > i'm getting timeouts from the update server. can someone confirm? > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2009

Re: [Pharo-project] Preferences refactoring pushed

by Igor Stasenko

2009/10/27 Alain Plantec <alain.plantec(a)free.fr>: > Hi all, > > In InBox: > SLICE-AnnotationPanesAndDecorateBrowserButtonsAndMenuButtonInToolPaneAndOptionalButtonsPrefsCleaning-AlainPlantec.1 > > * Remove the annotationPane preference (no more annotation pane in > browsers and MC) +100.. the 'message pane missin' spam in transcript is really annoying :) > * Remove decorateBrowserButtons preference > * Remove menuButtonInToolPane preference > * Remove optionalButtons preferences (optional buttons are always > present except in the ChangeSetSorter) > > Cheers > Alain > > _______________________________________________ > 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. 27, 2009

Re: [Pharo-project] Thread-safe collections

by Igor Stasenko

2009/10/27 Igor Stasenko <siguctua(a)gmail.com>: > 2009/10/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Philippe, Stef, >> >> That's fine for Seaside, but what about other users of weak collections? Â I think I have found the weakness (pun intended) in Squeak/Pharo: weaklings do only half of what they should do. Â They (correctly) do not prevent garbage collection of the objects they reference, but they apparently fail to clean up after these objects have been finalized. >> >> In Dolphin, the following returns an empty array: >> >> | map | >> map := WeakLookupTable new >> Â Â Â Â Â Â Â Â at:2 put:String new; >> Â Â Â Â Â Â Â Â yourself. >> MemoryManager current collectGarbage. >> map keys asArray. >> >> >> Pharo is content to answer nil from #at:put: but still keep the key: >> >> | map | >> map := WeakValueDictionary new >> Â Â Â Â Â Â Â Â at:2 put:String new; >> Â Â Â Â Â Â Â Â yourself. >> 5 timesRepeat:[ Smalltalk garbageCollect. ]. >> map keys asArray. >> > > and why the key should go away? > I think that this is an implementation nuance, but not bug or missing feature. > No-one would expect from dictionary keys to automatically mutate > depending on the state of the associated values. > If you want such behavior, why not implement own WeakLookupTable ? > suppose, one may want to know, what values became garbage, to do additional _custom_ processing. While its currently possible using WeakValueDictionary , it will be problematic using WeakLookupTable , because you wont know what values are gone. -- Best regards, Igor Stasenko AKA sig.

Oct. 27, 2009

[Pharo-project] Preferences refactoring pushed

by Alain Plantec

Hi all, In InBox: SLICE-AnnotationPanesAndDecorateBrowserButtonsAndMenuButtonInToolPaneAndOptionalButtonsPrefsCleaning-AlainPlantec.1 * Remove the annotationPane preference (no more annotation pane in browsers and MC) * Remove decorateBrowserButtons preference * Remove menuButtonInToolPane preference * Remove optionalButtons preferences (optional buttons are always present except in the ChangeSetSorter) Cheers Alain

Oct. 27, 2009

Re: [Pharo-project] Thread-safe collections

by Igor Stasenko

2009/10/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Philippe, Stef, > > That's fine for Seaside, but what about other users of weak collections? Â I think I have found the weakness (pun intended) in Squeak/Pharo: weaklings do only half of what they should do. Â They (correctly) do not prevent garbage collection of the objects they reference, but they apparently fail to clean up after these objects have been finalized. > > In Dolphin, the following returns an empty array: > > | map | > map := WeakLookupTable new > Â Â Â Â Â Â Â Â at:2 put:String new; > Â Â Â Â Â Â Â Â yourself. > MemoryManager current collectGarbage. > map keys asArray. > > > Pharo is content to answer nil from #at:put: but still keep the key: > > | map | > map := WeakValueDictionary new > Â Â Â Â Â Â Â Â at:2 put:String new; > Â Â Â Â Â Â Â Â yourself. > 5 timesRepeat:[ Smalltalk garbageCollect. ]. > map keys asArray. > and why the key should go away? I think that this is an implementation nuance, but not bug or missing feature. No-one would expect from dictionary keys to automatically mutate depending on the state of the associated values. If you want such behavior, why not implement own WeakLookupTable ? > Gary reported a lack of thread saftey in the weak collections almost two years ago. Â See Mantis #6955. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Philippe Marschall > Sent: Sunday, October 25, 2009 9:44 AM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > 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 > > > _______________________________________________ > 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. 27, 2009

Re: [Pharo-project] Traits composition question

by Igor Stasenko

2009/10/26 Alexandre Bergel <alexandre(a)bergel.eu>: >>> For traits, requirements were programmatically inferred instead of >>> using #explicitRequirement. >>> >> Not sure i understood. > > Is it really necessary that you provides 'self shouldBeImplemented' as > method body? > yes, it is. :) Trait , in this case covers the protocol without any gaps. Which is good from design perspective i think, because developer who never dealt with given trait before, could easily see what he should care about. Doing otherwise, you leaving him clueless and stealing his time, which he will spend on (re)discovering the complete necessary behavior when using this trait. >> Is there a way to tell to not override the method automatically, if it >> provided in base class? > > > No that I know. But this goes against the idea of Traits. A class that > uses a trait is rigorously equivalent to having the class implements > the methods defined in the trait. > As a consequence, if you trait defines a method 'foo Â self > shouldBeImplemented' and your class C uses the trait, then 'C new foo' > will execute 'self shouldBeImplemented', independently whether #foo > was implemented or not in superclasses of C. > I disagree. It doesn't. You already can exclude the trait's methods from composition, but only explicitly and in direct way. What i'm wanting is to have more flexible & little bit indirect way i.e.: TraitDescription>> - anArrayOfSelectorsOrTrait ^TraitExclusion with: self exclusions: anArrayOfSelectorsOrTrait Another thing is to have ' apply only once' option, means that if particular trait has already used in one of superclasses, then exclude it from composition. > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > _______________________________________________ > 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. 27, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Igor Stasenko

2009/10/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > so what is the fix? > I would really like to get announcement instead of event > systemNotification but I'm sure that this > can be a bit tricky. > Yes, tricky :) Here what i have in mind: Any change to system should be captured _before_ it applied. This allows us to introduce a policy which can validate the change and decide whether it allowed to be made or not. I made the SystemChangeEvent class, which having following state: - changeKind - a symbol, which identifies the change - parameters - a dictionary , which holding different parameters, important for change - subject - the object which is going to be changed (or taking a main role in change) - action - a block closure which , if evaluated, will apply the change to system For example, here the method which creates & populates the system change event: classify: element under: heading suppressIfDefault: aBoolean (self subject newSystemEvent: #changeSelectorCategory) subject: element; param: #behavior->self subject; param: #category->heading asSymbol; param: #suppressIfDefault->aBoolean; action: [ super classify: element under: heading suppressIfDefault: aBoolean ]; signal. --------- The event handling procedure is following: - first of all, an event passed to a system arbiter object - a system arbiter checking with the policy - if everything ok, change is applied by evaluating action. - and finally, change is announced to any interesting parties I want to make each package to hold own policy (a set of flags identified by name, to ease fileout). Then, any event could be validated by policy by issuing: package policy validate: change For example, lets see , what validations we could introduce for method recategorization event. - lets take most interesting case, when we want to recategorize the method in ClassA, which belongs to PackageA, and putting it into extension category, like *PackageB - check, if we allow any changes to ClassA (policy of PackageA) - check if PackageA allows method extensions (policy of PackageA) - check if PackageB allows extending the classes of another packages (policy of PackageB) - check if extension overrides existing method - and of course, we should check that given extension does not creates a circular dependency between the packages. There, of course, some problems which arising. - changes nesting. Some changes is complex ones, and even a simple method recategorization could lead to another event - creating a new category in class. Optimally, it would be cool to have only most basic events, which can't be nested. And any action which may lead to multiple changes, should be split on a number of basic ones. A SystemChangeNotifier solving this by allowing doing things silently: SystemChangeNotifier uniqueInstance doSilently: [ ... ]. so, any changes within the block , if any, won't be announced. - atomicity support. To support the bulk model updating, i can imagine the framework, which capturing any changes without applying them, by building/collecting all changes in parallel, and then applying them by a single mass-become. This is what SystemEditor does. - metaprogramming. There should be a means to leave a room for metaprogramming. We wouldn't want to signal a system change for anonymous classes, and many other things, which can be tricky here. P.S. as you can see , the plans is quite bold, and will require numerous refactorings :) So, the more people is interested in that, the better. > Stef > -- Best regards, Igor Stasenko AKA sig.

Oct. 27, 2009

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

by Andres Valloud

Nicolas, > 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. > In general, yes. > 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... > Yes. Filenames and URLs are particularly problematic. Fortunately they tend to be O(100) in size, as opposed to O(1000) in size. Thus, the less demanding path of just hashing the characters is efficient enough for the cases I've seen so far. > IMO, we should not let Array hash ~= Interval hash coexist with Array = Interval > Because it's like putting some traps on programmers path. > Yes, I agree. I'd vote on breaking #=, with the caveat that chances are some code will be broken. Does Pharo have a release strategy that allows more fundamental changes to go in, as opposed to maintenance/improvement fixes? Andres.

Oct. 26, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Philippe, Stef, That's fine for Seaside, but what about other users of weak collections? I think I have found the weakness (pun intended) in Squeak/Pharo: weaklings do only half of what they should do. They (correctly) do not prevent garbage collection of the objects they reference, but they apparently fail to clean up after these objects have been finalized. In Dolphin, the following returns an empty array: | map | map := WeakLookupTable new at:2 put:String new; yourself. MemoryManager current collectGarbage. map keys asArray. Pharo is content to answer nil from #at:put: but still keep the key: | map | map := WeakValueDictionary new at:2 put:String new; yourself. 5 timesRepeat:[ Smalltalk garbageCollect. ]. map keys asArray. Gary reported a lack of thread saftey in the weak collections almost two years ago. See Mantis #6955. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Philippe Marschall Sent: Sunday, October 25, 2009 9:44 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2009