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

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

> I don't think that growing a Set is faster than growing an Array, then >>> converting it to a Set, but let's see the numbers: >>> >>> "Prepare an array with 10000 elements, each element is an array with one >>> integer. 10% is duplicate." >> >> This is something I can understand. So we will fix that. > > This is rather a matter of memory. The use case in Moose back then used to be > closer to 10 million objects with a set of eventual size of 100 element. So > the intend is to avoid allocating 40 MB of memory when all you need is a set > of 100 elements. So at least in Moose, you should keep it :) Context :) Thanks. I will add a comment to flatCollectAsSet: going in that direction. Stef

Dec. 28, 2009

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

by Alexandre Bergel

This is really cool that you work on SUnit. This is really needed. Cheers, Alexandre On 28 Dec 2009, at 18:47, Alexandre Bergel wrote: >>>> 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? >> >> The stored history is compiled into a method on the class side. So >> you get the >> exact benefit of #expectedFailures/#expectedError. It is persistent >> across >> source control and will mark your failures/errors as expected. So >> you dont >> need #expectedError at all. > > Yep, I know this, I pair programmed the history mechanism with > Simon :-) > But I still do not understand how do you distinguish a method that > always fails from an expectedFailure (i.e., a method that I know will > fail, but I do not want it to make my unit test red)? > If we need expectedFailure, we will probably need expectedError no? > > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2009

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

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > Adrian I would love to see a videos of the new features you did :) A blog post is in work... --AA -- 2nd Workshop on Source Code Search etc. Submit papers by January 19, 2010. http://bit.ly/suite2010

Dec. 28, 2009

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

by Alexandre Bergel

>>> 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? > > The stored history is compiled into a method on the class side. So > you get the > exact benefit of #expectedFailures/#expectedError. It is persistent > across > source control and will mark your failures/errors as expected. So > you dont > need #expectedError at all. Yep, I know this, I pair programmed the history mechanism with Simon :-) But I still do not understand how do you distinguish a method that always fails from an expectedFailure (i.e., a method that I know will fail, but I do not want it to make my unit test red)? If we need expectedFailure, we will probably need expectedError no? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2009

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

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 6:42 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > > Hi Adrian! Thanks for trying to fix this. However, I can still reproduce > the > > problem. I put a halt in my expectedFailures method and it is being > called > > [..] The iteration throught the do: seems to be ok, but I don't know why, > > the tests are still considered as error (red) instead of expectedFailures > in > > green. Is correct to put "outcome: TestFinished failures;" ??? I > guess > > it would be something like "outcome: TestFinished expectedFailures" but I > > look in the class side methods of TestFinished and I only see passed, > failure > > and error. Let me know if I can test something more. > > I see, you got the same case as Alex. > > You declared an expected *error* in #expectedFailures. That used to work > with > the old SUnit but the new SUnit takes you literally and expects it to be a > failure and a failure only. I will work on a solution for that. > Ahhh yes, sorry. I just discovered that. Wait...I will suggest this: It is true what you said about expectedFailure is expected failure and not expected error. I just did it like that because I thought it was like that. But now that I see it, that is probably wrong. So, what I would do is to "fix" it but (I don't know) put is as deprecated so that all the tests of the people are still green and give them time to change it to expectedErrors or similar. After a second release you can remove this fix :) What do you think ? Cheers Mariano > > --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] akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > Hi Adrian! Thanks for trying to fix this. However, I can still reproduce the > problem. I put a halt in my expectedFailures method and it is being called > [..] The iteration throught the do: seems to be ok, but I don't know why, > the tests are still considered as error (red) instead of expectedFailures in > green. Is correct to put "outcome: TestFinished failures;" ??? I guess > it would be something like "outcome: TestFinished expectedFailures" but I > look in the class side methods of TestFinished and I only see passed, failure > and error. Let me know if I can test something more. I see, you got the same case as Alex. You declared an expected *error* in #expectedFailures. That used to work with the old SUnit but the new SUnit takes you literally and expects it to be a failure and a failure only. I will work on a solution for that. --AA

Dec. 28, 2009

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

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > > 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? The stored history is compiled into a method on the class side. So you get the exact benefit of #expectedFailures/#expectedError. It is persistent across source control and will mark your failures/errors as expected. So you dont need #expectedError at all. The history system has two levels - "history" is put in a class variable on the class side. This information is used for the browser icons by OB and O2, such that you can see the result of the latest test run. This information is local to your image. - "stored history" is put into a compiled method on the class side. This information is used by the test runner to mark unexpected passes and expected defects (failures, errors *and* any custom defects). This information is global and persists together with your source code. Programatically they are accessible with `testClass history` and `testClass storedHistory`, and `testClass storeHistoryIntoCompiledMethod` will put the current history into stored history. Marking of unexpected results can be done between *any* two test results with `testResult markUnexpectedResults: anotherTestResult`, so other tools builders are free to compare any two results. Also you can define your very own test results (eg `aTestFinished outcome: #ignored`) and they will be processed by result marking. --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > > I don't think that growing a Set is faster than growing an Array, then > > converting it to a Set, but let's see the numbers: > > > > "Prepare an array with 10000 elements, each element is an array with one > > integer. 10% is duplicate." > > This is something I can understand. So we will fix that. This is rather a matter of memory. The use case in Moose back then used to be closer to 10 million objects with a set of eventual size of 100 element. So the intend is to avoid allocating 40 MB of memory when all you need is a set of 100 elements. So at least in Moose, you should keep it :) --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Lukas Renggli

Attached is #foldLeft: and #foldRight: from PetitParser. These are generalized #fold: operators that I use for years in Magritte already. Lukas 2009/12/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 28, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 4:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes > > I'm losing my time trying to rescue a proposal we should sent and I wonder > what I'm doing because the acceptance rate are null. > the proposal is in Java or SQL ? hahahah NILLLLLLLLLLLLL :) > > Stef > > On Dec 28, 2009, at 4:20 PM, Dale Henrichs wrote: > > > Stef, > > > > The moving sands are one of the costs of advancement ... I'm more upset > that _I_ don't have time to solve the dang problems than I am that the > problems are appearing ... all of the changes have been for good reasons and > over time I have been removing code from Metacello as Gofer has expanded > it's functionality... > > > > Gotta love the holidays:) > > > > Dale > > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > > > | On Dec 27, 2009, at 11:38 PM, Dale Henrichs wrote: > > | > > | > Gofer-dkh.105 or whichever later version predates the move of the > > | instance variable would get Metacello back into a bootable form for > > | all versions of Pharo. > > | > > > | > I agree that for 1.0 a stable version of Gofer be chosen ... I'm > > | trying to restrict the current Metacello changes to avoid significant > > | API changes, but every time Gofer moves out from under me, I'm forced > > | into making fundamental changes. > > | > > | Yes! > > | I would like to have gofer stable in 1.0 and the same in 1.1 > > | Sorry for the moving sands ;( > > | Stef > > | > > | > Dale > > | > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: > > | > > > | > | >> | | >> After proceeding these warnings, I have a rollback: MNU > > | > | >> | | >> GoferPackageReference class>>name:repository: > > | > | >> | | > > > | > | >> | | > Can you evaluate > > | > | >> | | > > > | > | >> | | > [ Gofer gofer load ] > > | > | >> | | > on: Error > > | > | >> | | > do: [ :err | err retry ]. > > | > | >> | | > Gofer gofer recompile. > > | > | >> | | > > > | > | >> | | > ? I don't have any senders of #name:repository: to > > | > | >> | | > GoferPackageReference. > > | > | > > | > | We can remove the deprecated warnings, but that will not solve > > | the > > | > | real problem. Metacello is using some internal parts of Gofer > > | that > > | > | had > > | > | to be changed to properly support fetch/push operations on > > | multiple > > | > | repositories. > > | > | > > | > | People have to stick with an old version of Gofer/Monticello. > > | That's > > | > | the same as with Pharo 1.1: Do not use the latest one. > > | > | > > | > | 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 > > | > > > | > _______________________________________________ > > | > 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