- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

levente I compared in Squeak Arrayed ... sort: nil mergeFirst: first middle: middle last: last into: dst by: aBlock ... [ (i1 <= middle) and: [ i2 <= last ] ] whileTrue: [ (aBlock ifNil: [ val1 <= val2 ] ifNotNil: [ aBlock value: val1 value: val2 ]) ifTrue: [ dst at: (out := out + 1) put: val1. val1 := self at: (i1 := i1 + 1)] ifFalse: [ dst at: (out := out + 1) put: val2. (i2 := i2 + 1) <= last ifTrue: [ val2 := self at: i2 ] ] ]. ... in pharo Arrayed ... sort: [:a :b | a <= b] mergeFirst: first middle: middle last: last into: dst by: aBlock ... [(i1 <= middle) and: [i2 <= last]] whileTrue: [(aBlock value: val1 value: val2) ifTrue: [dst at: (out := out + 1) put: val1. val1 := self at: (i1 := i1 + 1)] ifFalse: [dst at: (out := out + 1) put: val2. i2 := i2 + 1. i2 <= last ifTrue: [val2 := self at: i2]]]. what is the best? Stef

Dec. 23, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by csrabak＠bol.com.br

Em 23/12/2009 16:10, Eliot Miranda < eliot.miranda(a)gmail.com > escreveu: > > Core.SequenceableCollection comparing > isSameSequenceAs: 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." > > | size | > (size := self size) = otherCollection size ifFalse: [^false]. > 1 to: size do: [:index | > (self at: index) = (otherCollection at: index) ifFalse: [^false]]. > ^true > > i.e. trust the caller is providing a sequence and if > otherCollection doesn't implement at: there will be a run-time > error, hence any otherCollection isKindOf: SequenceableCollection is > just wasted cycles. > I don't think that "trusting the caller" makes sense in this case, so I propose instead that you implementation be complemented by: Object>>isSameSequenceAs: otherCollection ^false -- Cesar Rabak

Dec. 23, 2009

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

by StÃ©phane Ducasse

> That is not that simple, because packages can be unloaded in a > different order they are installed. I think a better strategy is to > allow methods to be defined in multiple packages. I have no constraint about method belonging to only one package. > Right. Maintain a global package load order. Maintain a dictionary from method reference to set of package/method pairs for each method that is overridden. When a package is removed search overrides and compute the overridden methods to be reinstalled, computing the uppermost method depending on the new package order. > > A package could mean for example an MC package and loading a new version of a package is an unload of the old version and a load of the new version. This is important to avoid overrides building up. The system must effectively GC overrides for unloaded packages so that the overridden methods only correspond to loaded packages. > > When I first tried this in VW with parcels I got the data structure badly wrong and chose a stack per override, ad had no global load order, because I hadn't thought through the arbitrary load/unload order properly. But I think sets of overrides plus a global load order will work. I see what you mean. Overrides hell. Now this is MC that defines the semantics not the package and I do not want to substitute MC just having a fast implementation of PackageInfo. But I was wondering how I would implement it to understand if the package should provide a specific infrastructure or just a list to start with. Stef

Dec. 23, 2009

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

by Nicolas Cellier

2009/12/23 Julian Fitzell <jfitzell(a)gmail.com>: > On Wed, Dec 23, 2009 at 1:45 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 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 :) > > Funnily I just spent last week with John O'Keefe looking at > non-VASt-compatible protocol that Seaside uses, comparing it across > platforms, and pondering which pieces to include tests for in Grease > and which to stop using in Seaside. (by the way, he was happy to add a > whole bunch of "useful" protocol to their base image, which is great > news). I need to write a summary of everything we came up with as well > over the holidays, but in the meantime, here's what we came up with > around sorting: > > #sortBlock: is defined by ANSI on SortedCollection as an accessor and > an instance creation method. That's what it sounds like and shouldn't > be implemented on non-sorted collections. > > > #asSortedCollection is defined by ANSI on Collection and returns an > instance of SortedCollection. > > > #sort and #sort: -- Squeak/Pharo have it on ArrayedCollection, VW has > it on SequenceableCollection, and VASt will now add it. This sorts the > instance in place. > > > #sorted, #sorted: -- VW already has this. VA is adding it. > Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It > returns a sorted copy of SequenceableCollections and a sorted Array of > all other collections. > Oh, that's exactly the one I would have chosen :) We should go for it, both Squeak and Pharo. > > #sortBy: is silly, as you mention and not supported on any other > platform. We're adding it to our lint rules as a "do not use" method. > And in the future, change semantic as a filter before sorting like proposed here... > > We didn't notice #asSortedArray but I think that's a terrible name -- > the pattern with #as* methods is that the thing after the "as" should > be a class. That behaviour could be easily achieved with "aCollection > sorted asArray" or "aCollection asArray sort" if really needed. > > > So that's what VASt/Seaside/Grease are doing... I encourage you to > follow our lead. :) > > Julian > > _______________________________________________ > 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] SUnit forked, gofer it

by StÃ©phane Ducasse

Adrian I know that in GNUSMalltalk paolo long time ago added logging facilities (I never looked at it so may be this is just the description: but joseph once talked about that when he presented toothpick at Bern). Stef On Dec 23, 2009, at 7:20 PM, Adrian Kuhn wrote: > Mariano Martinez Peck <marianopeck@...> writes: > >> Can I add something to my dear santa list ??Many times, I have tests that >> freeze the image. And I don't known what test was the "guilty". I always hack >> the runCase to show in Transcript the test selector. Maybe adding a >> configurable logging option (enable/disable) may help. > > Good point. > > I plan to add a TestListener that can be used to do this. > > --AA > > > > -- > 4th Workshop on Dynamic Languages and Applications > Submit papers by March 31, 2010. http://bit.ly/dyla2010 > > > _______________________________________________ > 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: sort: and sortBlock:

by StÃ©phane Ducasse

Let me know if we can integrate them and we will. Stef >> > > Don't open a new issue. There is > http://code.google.com/p/pharo/issues/detail?id=1214 > http://code.google.com/p/pharo/issues/detail?id=1346 >

Dec. 23, 2009

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

by StÃ©phane Ducasse

> > That's probably why Stephane proposed a UniqueOrderedCollection: he > must have the expectation that this collection can be indexed in O(1) Not really :) I was more looking at the user perspective. You often want an orderedCollection (add:) vs Array at: but which deals with duplicate as a Set. I will rename it because OrderedSet is not a good name because this is not a Set. Now this is boring because this is not an OrderedCollection (or you do not have to be forced to implement insert:after:..... I really see that the collection classes suffers from single inheritance and sometimes are too fat. A Nilish collection would be a fun exercise. May be we should start and get a cool OOPSLA paper out of that. Stef

Dec. 23, 2009

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

by Nicolas Cellier

2009/12/23 Levente Uzonyi <leves(a)elte.hu>: > On Wed, 23 Dec 2009, StÃ©phane Ducasse wrote: > >>>> >>> >>> What bugs me is that #sortBy: does not what it says. I would expect that >>> >>> Â aCollection sortBy: [ :each | each name ] >>> >>> does the same as >>> >>> Â aCollection sort: [ :a :b | a name <= b name ] >>> >>> if you want that, I can provide a fast implementation of #sortBy: >>> >>> >>> Not all collections are sortable and #sort: is sorting in-place, so it's >>> hardly doable. >> >> But it would be nice to have sort: and sortBlock: polymorph. >> Because right now we cannot have OrderedCollection and Array or >> SortedCollection interchanged. > > SortedCollection should be used as rarely as possible. In the past it was > used for sorting which is a misuse of this data structure (I wonder why such > data strucure exists at all, it's almost never useful). > The only case should be to keep collection automatically sorted when its contents further evolves... Of course, using repeated #add: is inefficient (#addAll: has a rule for sorting once or at every #add:). > If you pick the changes from squeak trunk, Array and OrderedCollection (and > SortedCollection) will understand #sort and #sort: and will have the same > semantics: sort in place (by a stable sorting algorithm). > Don't open a new issue. There is http://code.google.com/p/pharo/issues/detail?id=1214 http://code.google.com/p/pharo/issues/detail?id=1346 Nicolas > > Levente > >> >> Stef >> _______________________________________________ >> 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 >

Dec. 23, 2009

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

by Eliot Miranda

On Wed, Dec 23, 2009 at 4:15 AM, Lukas Renggli <renggli(a)gmail.com> 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 > > That is not that simple, because packages can be unloaded in a > different order they are installed. I think a better strategy is to > allow methods to be defined in multiple packages. > Right. Maintain a global package load order. Maintain a dictionary from method reference to set of package/method pairs for each method that is overridden. When a package is removed search overrides and compute the overridden methods to be reinstalled, computing the uppermost method depending on the new package order. A package could mean for example an MC package and loading a new version of a package is an unload of the old version and a load of the new version. This is important to avoid overrides building up. The system must effectively GC overrides for unloaded packages so that the overridden methods only correspond to loaded packages. When I first tried this in VW with parcels I got the data structure badly wrong and chose a stack per override, ad had no global load order, because I hadn't thought through the arbitrary load/unload order properly. But I think sets of overrides plus a global load order will work. > 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] SUnit forked, gofer it

by Mariano Martinez Peck

On Wed, Dec 23, 2009 at 7:20 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > > Can I add something to my dear santa list ??Many times, I have tests that > > freeze the image. And I don't known what test was the "guilty". I always > hack > > the runCase to show in Transcript the test selector. Maybe adding a > > configurable logging option (enable/disable) may help. > > Good point. > > I plan to add a TestListener that can be used to do this. > > You have already thought in everything ;) Excellent then!!! Thank you :) Mariano > --AA > > > > -- > 4th Workshop on Dynamic Languages and Applications > Submit papers by March 31, 2010. http://bit.ly/dyla2010 > > > _______________________________________________ > 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