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

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

Lukas I know that you also have a cool lib of other highorder function. Where can we find it? Stef On Dec 27, 2009, at 5:26 PM, StÃ©phane Ducasse wrote: > hi > > here are the collection extensions we use in Moose. > I copied them to PharoTaskForces so that we can discuss and tweak the code if wanted. > > My favorite is > flatCollect:/flatCollectAsSet: > groupedBy: > > There are really useful. > > Stef > > > testFlatCollectArray > "self debug: #testFlatCollectArray" > > self assert: ((#((1 2) (3 4) (5 3)) flatCollect: [ :each ]) = #(1 2 3 4 5 3)). > self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each]) = #(1 2 2 3 1 3 4)). > > self assert: ((#((1 2) (2 3) () ()) flatCollect: [:each]) = #(1 2 2 3)). > > self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each| Array with: each]) > = #(#(1 2) #(2 3) #(1 3 4))). > > self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each| Set with: each]) > = #(#(1 2) #(2 3) #(1 3 4))). > > > testFlatCollectSet > "self debug: #testFlatCollectSet" > > self assert: ((#((1 2) (1 2) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). > self assert: ((#() asSet flatCollect: [:each]) = #() asSet). > > self assert: ((#((1 2) () (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). > self assert: ((#((1 2) #((99)) (1 3 4)) asSet flatCollect: [:each]) > = #(1 1 2 3 4 (99)) asSet). > self assert: ((#((1 2) #(()) (1 3 4)) asSet flatCollect: [:each]) > = #(1 1 2 3 4 ()) asSet). > > testCollectAsSet > "self debug: #testCollectAsSet" > > self assert: ((#() collectAsSet: [:each | each odd]) = Set new). > self assert: (#(1 2 3 4 5 6) collectAsSet: [:each | each odd]) > = (Set with: true with: false). > self assert: (#(1 3 5 7 9 11) collectAsSet: [:each | each odd]) > = (Set with: true). > > self assert: (#(1 2 3 4 5 4 3 2 1) collectAsSet: [:each | each]) = (1 to: 5) asSet. > > > testGroupedByArray > "self debug: #testGroupedByArray" > > | res | > res := #(1 2 3 4 5) groupedBy: [:each | each odd]. > self assert: (res at: true) = #(1 3 5). > self assert: (res at: false) = #(2 4) > > > > Set>>flatCollect: aBlock > > > ^self flatCollectAsSet: aBlock > > > Symbol>>value > "Allow this object to act as a ValueHolder on itself." > > ^self > > OrderedCollection>>removeAtIndex: anIndex > "Remove the element of the collection at position anIndex. Answer the object removed." > > | obj | > obj := self at: anIndex. > self removeIndex: anIndex + firstIndex - 1. > ^obj > > Collection > ============================== > > collectAsSet: aBlock > "Evaluates aBlock for each element of the receiver and collects > the resulting values into a Set." > > "This is an efficient shorthand for [ (self collect: aBlock) asSet ]." > "originally developed by a. kuhn and released under MIT." > > ^self inject: Set new into: [ :set :each | > set add: (aBlock value: each); yourself ]. > > > copyEmpty: aSize > "Answer a copy of the receiver that contains no elements. > > This method should be redefined in subclasses that add > instance variables, so that the state of those variables > is preserved" > > ^self class new: aSize > > > flatCollect: aBlock > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock returns some kind > of collection for each element. Equivalent to the lisp's mapcan" > "original written by a. Kuhn and released under MIT" > > | stream | > self isEmpty ifTrue: [ ^ self copy ]. > stream := (self species new: 0) nsWriteStream. > self do: [ :each | stream nextPutAll: (aBlock value: each) ]. > ^ stream contents > > flatCollectAsSet: aBlock > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock returns some kind > of collection for each element. Equivalent to the lisp's mapcan" > > "original written by a. Kuhn and released under MIT" > > | set | > self isEmpty ifTrue: [^self copy ]. > set := Set new. > self do: [ :each | > set addAll: (aBlock value: each) ]. > ^set > > > flatten > "Recursively collect each non-collection element of the receiver and its descendant > collections. Please note, this implementation assumes that strings are to be treated > as objects rather than as collection." > > ^self gather: [ :each ] > > groupedBy: aBlock > "Return a dictionary whose keys are the result of evaluating aBlock for all elements in > the collection, and the value for each key is the collection of elements that evaluated > to that key. e.g. > #(1 2 3 4 5) groupedBy: [:each | each odd] > a Dictionary > true ---> #( 1 3 5) > false --> #(2 4) > originally developed by a. kuhn and released under MIT." > > | result | > result := Dictionary new. > self do: > [:each | | key collection | > key := aBlock value: each. > collection := result at: key ifAbsentPut: [OrderedCollection new]. > collection add: each]. > self species ~~ OrderedCollection ifTrue: > ["Convert the result collections to be the right type. > Note that it should be safe to modify the dictionary > while iterating because we only replace values for existing keys" > result keysAndValuesDo: > [:key :value | result at: key put: (self species withAll: value)]]. > > ^result > > includesAll: aCollection > "Answer true if the receiver includes all elements of aCollection with at > least as many occurrences as in aCollection. For a less strict comparison > please refer to supersetOf: and its inverse subsetOf:." > > > ^(aCollection isCollection) and: [ > aCollection size <= self size and: [ > aCollection allSatisfy: [ :each | > (aCollection occurrencesOf: each) <= (self occurrencesOf: each) ]]] > > nilSafeGroupedBy: aBlock > ^ self groupedBy: [ :each | > | value | > value := aBlock value: each. > value ifNil: [ UndefinedObject ]. > ] > > selectAsSet: aBlock > "Evaluate aBlock with each of the receiver's elements as the argument. > Collect into a new set, only those elements for which > aBlock evaluates to true. Answer the new collection." > > | newSet | > newSet := Set new. > self do: [:each | (aBlock value: each) ifTrue: [newSet add: each]]. > ^newSet > > shuffle > "Swaps the receiver's elements at random." > > self shuffle: (self size * self size log) asInteger > > sum: aSymbolOrBlock > > ^self > inject: 0 > into: [:sum :each | sum + (aSymbolOrBlock value: each)] > > shuffle: times > "Swaps random elements of the receiver." > > | size random | > size := self size. > random := Random new. > times timesRepeat: [ > self swap: (random next * size) floor + 1 with: (random next * size) floor + 1 > ]. > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

> Levente Uzonyi <leves@...> writes: >> >>> #equalsTo: >>> misleading name, #containsSameElementsAs: would be better IMO >>> #(1 1 2) equalsTo: #(2 1 1) ===> true >> >> There is a #sameElements: in roel typer package. I think #sameElementsAs: and >> #sameSequenceAs: would be nice method names for methods that test for same >> elements and same elements in same order. See the other thread I would like to have sameSequenceOfElements: and sameElements: >> >>> #flatCollect: -> #gather: >>> #flatCollectAsSet: -> #gather: + #asSet >> >> NB: #gather always returns an array, should use species. > > Arrays are cool, they can contain any object. And I guess #gather: + > #asSet is faster than #flatCollectAsSet:. No Array are not cool. They are useful in specific ocassion. flatCollect: and other should work on OrderedCollection, Set, SortedCollection In Moose we have special collection like entities and they should work also on them, and returns the same kind of collection. > >> >>> #groupBy: -> #groupBy:having: >> >> Does not have the same behavior! #groupBy:having: requires that "keyBlock >> should return an Integer" whereas #groupedBy: works with any values (except >> nil) returned from the the block. >> > > keyBlock can return whatever it wants (and it doesn't have to be a block > at all), PluggableDictionary >> #integerDictionary is just a dictionary > that has better hash properties with integers from a small range than a > normal Dictionary, but the keys don't have to be integers. Example: > > 'abcdefgh' groupBy: #isVowel having: [ :e | true ] > >>> #sum: -> #detectSum: >> >> Short names and readability, anyone? Also the name is misleading, #detect: >> returns an element of the collection, #detectSum not. For maximum it makes >> sense to have both #detectMax: (which returns the element with the max value) >> and #max: (which returns the max value). > > I agree that the name is wrong, but it's in the base image. > >> >>> SequenceableCollection >> >>> #shuffle -> #shuffled >> >> NB: #shuffledBy: should use `i atRandom:` rather than `(1 to: i) atRandom:` >> to avoid creating an interval object for each element of the collection. > > I fixed that in squeak in october and I found the fix in my 1.1 pharo > image, though further improvement is possible (even ~85% speedup can > be achieved :)). > > > Levente > >> >>> OrderedCollection >> >>> #removeAtIndex: -> #removeAt: >> >> Shorter name, nice! :) >> >> --AA >> >> >> _______________________________________________ >> 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. 28, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

>>>> #flatCollect: -> #gather: >>>> #flatCollectAsSet: -> #gather: + #asSet >>> >>> NB: #gather always returns an array, should use species. >> >> Arrays are cool, they can contain any object. And I guess #gather: + >> #asSet is faster than #flatCollectAsSet:. > > #collect: uses species, so should #flatCollect:. This is not an issue of sets > alone. When you work with your own custom collections (eg NodeList) you want > all enumerations to return collections of *your* type. YES!!! > > For the #*asSet: methods, I really do love the #*:as: solution. Adrian if you want publish a new version of the package in the tasksForces. Now this is really central to moose so all the tests should pass. >> keyBlock can return whatever it wants (and it doesn't have to be a block >> at all), PluggableDictionary >> #integerDictionary is just a dictionary >> that has better hash properties with integers from a small range than a >> normal Dictionary, but the keys don't have to be integers. Example: >> >> 'abcdefgh' groupBy: #isVowel having: [ :e | true ] > > Then someone *please* fix the comment and provide #group(ed)By: without having > clause. Also, again, the generated collection should be of species. When I > group a node list I want node lists. I agree. Publish code :) > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

Levente you should realize that these methods have been defined and used more than a couple of years ago. They are used by a cool group of programmer and the infrastructure of Moose since also a couple of years so I would not call them useless misleading but thanks for you analysis :) It is time to rewrite them. But flatCollect: and flatCollectAsSet: names are more important than their implementation. >> I just checked these and most of them are useless misleading or duplicate, like: > > Collection >> > #collectAsSet: -> #collect:as: (ok, it's new in pharo) > #equalsTo: > misleading name, #containsSameElementsAs: would be better IMO > #(1 1 2) equalsTo: #(2 1 1) ===> true Yes I do not really like it > #flatCollect: -> #gather: the problem is that gather: does not convey its intention. flatCollect: is much much better. > #flatCollectAsSet: -> #gather: + #asSet Is it not faster? > #flatten -- > misleading name, since it doesn't change the object, but returns > a new array and it's only flattening one level which is what #gather: > does. Tthere's a proper #flattened implementation in squeak treated > inbox if you're interested. (guess why it's not in the trunk) > #groupBy: -> #groupBy:having: > #sum: -> #detectSum: > > Symbol >> > #value (same as super) > > SequenceableCollection >> > #shuffle -> #shuffled > > OrderedCollection >> > #removeAtIndex: -> #removeAt: > > (-> means that the extension on the left is the same as or worse than > the already existing method(s) on the right) > > I guess you should shrink this package. :) > > > Levente_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] Fwd: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use))

by StÃ©phane Ducasse

Yes :) Marcus would like to have code inside the image... since a couple of years :) Stef On Dec 27, 2009, at 11:32 PM, David T. Lewis wrote: > FYI Marcus provided a solution to this problem back in 2006, see > http://bugs.squeak.org/view.php?id=4369 (but the original author > may be Klaus Witzel). So Marcus will understand the issue well :) > > Dave > > On Sun, Dec 27, 2009 at 09:20:20PM +0100, St?phane Ducasse wrote: >> Thanks David. >> I will look at the methodTrailer fixes soon. Now my knowledge is limited >> in this area and I would prefer to have marcus have a look. >> I will at least check the code and see if it looks ok. >> >> Stef >> >> On Dec 27, 2009, at 8:25 PM, David T. Lewis wrote: >> >>> Note, the change sets for this update are also on Mantis >>> http://bugs.squeak.org/view.php?id=5205 >>> along with discussion of other approaches to the problem. >>> >>> These changes are now in Squeak trunk. >>> >>> Dave >>> >>> On Sun, Dec 27, 2009 at 09:19:46PM +0200, Igor Stasenko wrote: >>>> ---------- Forwarded message ---------- >>>> From: David T. Lewis <lewis(a)mail.msen.com> >>>> Date: 2009/12/27 >>>> Subject: Re: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR >>>> (Re: CompiledMethodTrailers ready for use)) >>>> To: The general-purpose Squeak developers list >>>> <squeak-dev(a)lists.squeakfoundation.org> >>>> >>>> >>>> I have put the updates for large changes and sources files into the >>>> inbox. I would appreciate if someone can review this before moving >>>> into trunk. >>>> >>>> There are three mcz updates: >>>> ??Files-dtl.62 >>>> ??System-dtl.205 >>>> ??Kernel-dtl.347 >>>> >>>> Important: The changes *must* be loaded in the order listed above. >>>> This will require a configuration map update when the changes are >>>> moved to trunk. >>>> >>>> The use of ExpandedSourceFileArray takes effect after the first >>>> image restart. To change back to using the StandardSourceFileArray, >>>> the procedure is as follows: >>>> >>>> ??1) Evaluate 'StandardSourceFileArray install' >>>> ??2) Edit SourceFileArray class>>concreteClass to answer >>>> ?? ??StandardSourceFileArray rather than ExpandedSourceFileArray. >>>> >>>> Thanks, >>>> Dave >>>> >>>> -- >>>> 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 >> >> >> _______________________________________________ >> 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. 28, 2009

[Pharo-project] Fwd: Is mac hostmenu cleanup ready for inclusion?

by StÃ©phane Ducasse

Hi mike today: no fun no smalltalk -> just project writing. so this evening I will do an update. Stef Begin forwarded message: > From: Michael Rueger <m.rueger(a)acm.org> > Date: December 28, 2009 10:07:38 AM GMT+01:00 > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: Re: Is mac hostmenu cleanup ready for inclusion? > > Michael Rueger wrote: >> not yet, a couple of fixes missing. > > there is now a new test and HostMenu package in the inbox. > You need to save and quit the image after the update. > > People should also test if the double paste is gone, otherwise I need to come up with new test scripts... > > Michael >

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Alexandre Bergel

>> Apparently, expectedFailure has a different behavior from the >> original >> SUnit. > > Yes, now as you mention errors. In the original it has the > (undocumented) > behavior of declaring expected failures *and* errors. I'll see how I > can fix > that. Maybe introducing a method expectedErrors would do the thing. >> I have a test method declared in a expectedFailures method. However, >> this test method does not fail, but it triggers a MNU. Running the >> unit test tells me there is 1 error, the method that I declared as >> expectedFailure. I guess this behavior is the right one. >> >> How can I fix this? There is no sender or implementer of >> expectedErrors. > > The preferred way is to store your results into the stored history. > You can > store the history with the context menu in the test runner. To do > so, right > click in the colored status field and choose `store history`. The > stored > results are treated as the expected results then. Yes, but... how is this related to the expectedError? >> By the way, why TestCase>>expectedFailures is in the protocol >> 'history >> management'? There is also two empty method categories in TestCase. > > The empty protocols are left overs of the old implementations. I > dont know > how to tell gofer/monticello to delete them. Do you know how? No idea. But this looks like to be a bug in Monticello no? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2009

Re: [Pharo-project] Refactoring Browser depenences

by Lukas Renggli

> Another question, do you know whatÂ Refactoring-SpellingÂ Â is Yes, I wrote it :-) It reactors your spell errors away :-P > and who > depends on it ? See attached PDFs. This is what Package-Dependencies produces in a few second: highlighted cyclic dependencies, it removes transitive dependencies, and it creates a simple graph that carries all information to load. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > Apparently, expectedFailure has a different behavior from the original > SUnit. Yes, now as you mention errors. In the original it has the (undocumented) behavior of declaring expected failures *and* errors. I'll see how I can fix that. > I have a test method declared in a expectedFailures method. However, > this test method does not fail, but it triggers a MNU. Running the > unit test tells me there is 1 error, the method that I declared as > expectedFailure. I guess this behavior is the right one. > > How can I fix this? There is no sender or implementer of expectedErrors. The preferred way is to store your results into the stored history. You can store the history with the context menu in the test runner. To do so, right click in the colored status field and choose `store history`. The stored results are treated as the expected results then. > By the way, why TestCase>>expectedFailures is in the protocol 'history > management'? There is also two empty method categories in TestCase. The empty protocols are left overs of the old implementations. I dont know how to tell gofer/monticello to delete them. Do you know how? --AA

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Alexandre Bergel

Hi! Apparently, expectedFailure has a different behavior from the original SUnit. I have a test method declared in a expectedFailures method. However, this test method does not fail, but it triggers a MNU. Running the unit test tells me there is 1 error, the method that I declared as expectedFailure. I guess this behavior is the right one. How can I fix this? There is no sender or implementer of expectedErrors. By the way, why TestCase>>expectedFailures is in the protocol 'history management'? There is also two empty method categories in TestCase. Cheers, Alexandre On 28 Dec 2009, at 02:27, Adrian Kuhn wrote: > Name: SUnit-AdrianKuhn.115 > Author: AdrianKuhn > Time: 28 December 2009, 2:22:16 am > UUID: 21af8078-0c75-4323-89aa-5f0142fa09d4 > Ancestors: SUnit-AdrianKuhn.114 > > Takes #expectedFailure into account. > > As required by Mariano Martinez Peck on the mailing list. He > uses the #expectedFailure method to dynamically create > expected failures, rather than a fixed set of failures as is > stored in stored history. > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2009