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

Re: [Pharo-project] Fwd: A design question

by Alexandre Bergel

Hi Stef, >> So far so good. >> Now however, I had to change >> ClassDescription>>package >> ^ RPackage packageOrganizerClass default packageOf: self name. >> "use RPackage packageClassOrganizer instead of the singleton >> because tests use the mock" >> >> instead of simply >> >> ClassDescription>>package >> ^ RPackage default packageOf: self name. >> >> >> I was thinking that if I really want to be as fast as possible I >> could >> separate the package and put the tests in a separate package and >> use overrides..... >> so that >> >> ClassDescription>>package >> ^ RPackage packageOrganizerClass default packageOf: self name. >> "use RPackage packageClassOrganizer instead of the singleton >> because tests use the mock" >> >> is only used when the tests are loaded >> Berk >> >> So do we have another simple solution at hand? Why not to redefine package on your fixture ? Let's say you define a class named #Fixture for your test. You can simply redefined Fixture class>>package. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 23, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by Nicolas Cellier

2009/12/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Apparently sort: is not understood by SortedCollection :( > And sortBlock: is not understood by ArrayedCollection subclasses :( > So this is cool OrderedCollection does not understand sort: > > Could we dare to fix that? Does anybody have a solution? > > Stef > > ArrayedCollection>>sort: aSortBlock > Â Â Â Â "Sort this array using aSortBlock. The block should take two arguments > Â Â Â Â and return true if the first element should preceed the second one." > > Â Â Â Â self > Â Â Â Â Â Â Â Â mergeSortFrom: 1 > Â Â Â Â Â Â Â Â to: self size > Â Â Â Â Â Â Â Â by: aSortBlock > > > SortedCollection>>sortBlock: aBlock > Â Â Â Â "Answer an instance of me such that its elements are sorted according to > Â Â Â Â the criterion specified in aBlock." > > Â Â Â Â ^(super new: 10) sortBlock: aBlock > > Oh that one bugs me... You also have asSortedArray asSortedCollection asSortedCollection: sortBy: A bit too many selectors? The different semantics currently are: - sort in place - #sort and #sort: - make a sorted copy - #asSortedArray does except if already isMemberOf: Array and isSorted, #sortBy: does too but is only understood by SequenceableCollection (stupid) - make a sorted collection that can further sort added elements - #asSortedCollection #asSortedCollection: #sortBlock: has 2 semantics: instance creation and modifying the sort block of an instance... And I would like another message to avoid all these keys asArray sort I spreaded in trunk: - sort in place if possible (if Sequenceable), or create a sorted sequence otherwise But you can understand I did not dare adding a new selector :) Nicolas > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by StÃ©phane Ducasse

No but I will look because I do not remember where I saw the difference and we need it. Stef On Dec 23, 2009, at 10:08 AM, Nicolas Cellier wrote: > isSameSquenceAs

Dec. 23, 2009

Re: [Pharo-project] Fwd: semantics of overrides

by StÃ©phane Ducasse

On Dec 23, 2009, at 9:37 AM, Lukas Renggli wrote: >>> May be this is MC that does this? Does anybody knows about it? > > MC uses the changes file to restore methods that are put into an > *packagename-override protocol, see MCMethodDefinition>>#unload. > Practically this does not work, because it makes all kind of generally > invalid assumptions. Thanks lukas. OK I have the impression that the package should know m1 is an override and when I unload I should put back the method I overrode but > >>> Then I have also another question related to the order >>> >>> P1>>*m >>> p1 >>> P2>>*m >>> p2 >>> P3>>*m >>> p3 >>> >>> right now is the load order preserved? >>> ie does P3 takes precedence over p2 and p1 > > I don't understand that question/syntax. *m means that the package P1 overrdies m1 and return ^ 'p1' Originally I did not like overrides but sometimes you cruelly need them and I want package to be backwards > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 23, 2009

Re: [Pharo-project] Fwd: All mailinglist messages on gmane are dublicated

by Mariano Martinez Peck

I don't see them duplicated. On Wed, Dec 23, 2009 at 9:16 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > > can somebody have a look? > > > > Stef > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Nicolas Cellier

2009/12/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > > Hi > > (SortedCollection new addAll: #(9 2 3 ); yourself) > hasEqualElements: (OrderedCollection withAll: #(9 2 3)) -> false > > hasEqualElements: otherCollection > "Answer whether the receiver's size is the same as otherCollection's > size, and each of the receiver's elements equal the corresponding > element of otherCollection. > This should probably replace the current definition of #= ." > > | size | > (otherCollection isKindOf: SequenceableCollection) ifFalse: [^ false]. > (size := self size) = otherCollection size ifFalse: [^ false]. > 1 to: size do: > [:index | > (self at: index) = (otherCollection at: index) ifFalse: [^ false]]. > ^ true > > For me the name of this method is misleading and I would really like to > renaming it > hasStructurallyEqualElements: and have new one doing hasEqualElements: > > What do you think? > I would like a beautiful world.... > > Stef (freezing with a flu in my bed.... cool christmax). > > Didn't VW had a #isSameSquenceAs: Nicolas > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2009

Re: [Pharo-project] Fwd: semantics of overrides

by Lukas Renggli

>> May be this is MC that does this? Does anybody knows about it? MC uses the changes file to restore methods that are put into an *packagename-override protocol, see MCMethodDefinition>>#unload. Practically this does not work, because it makes all kind of generally invalid assumptions. >> Then I have also another question related to the order >> >> Â Â Â P1>>*m >> Â Â Â Â Â Â Â Â Â Â Â p1 >> Â Â Â P2>>*m >> Â Â Â Â Â Â Â Â Â Â Â p2 >> Â Â Â P3>>*m >> Â Â Â Â Â Â Â Â Â Â Â p3 >> >> right now is the load order preserved? >> ie does P3 takes precedence over p2 and p1 I don't understand that question/syntax. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 23, 2009

[Pharo-project] [update 1.1] #11112

by Marcus Denker

11112 ----- Issue 1652: Behavior >> #allSubclassesDo: depends on #subclassesDo: which is defined in Class and friends only Thanks, Adrian Kuhn Issue 1633: Object allSubInstances appears to loop forever Thanks, Eliot Miranda (from Squeak) Issue 1655: MethodFinder Fixes Thanks, Bert Freudenberg (from Squeak) Issue 1654: SpeedUpCommandHistory Thanks, Eliot Miranda (from Squeak)

Dec. 23, 2009

[Pharo-project] Fwd: semantics of overrides

by StÃ©phane Ducasse

> Hi > > I'm starting to think to add override to my new implementation of Package. > Now I wonder how PackageInfo keeps information the fact that when an overridding method > is unload, the overridden is added back to the class. > May be this is MC that does this? Does anybody knows about it? > > Then I have also another question related to the order > > P1>>*m > p1 > P2>>*m > p2 > P3>>*m > p3 > > right now is the load order preserved? > ie does P3 takes precedence over p2 and p1 > > If I unload P2 and P3 do I get P1, I remember that alex got problems > with that some years ago. > > Stef > >

Dec. 23, 2009

[Pharo-project] Fwd: sort: and sortBlock:

by StÃ©phane Ducasse

Apparently sort: is not understood by SortedCollection :( And sortBlock: is not understood by ArrayedCollection subclasses :( So this is cool OrderedCollection does not understand sort: Could we dare to fix that? Does anybody have a solution? Stef ArrayedCollection>>sort: aSortBlock "Sort this array using aSortBlock. The block should take two arguments and return true if the first element should preceed the second one." self mergeSortFrom: 1 to: self size by: aSortBlock SortedCollection>>sortBlock: aBlock "Answer an instance of me such that its elements are sorted according to the criterion specified in aBlock." ^(super new: 10) sortBlock: aBlock

Dec. 23, 2009