- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

Adrian I would love to see a videos of the new features you did :) Stef (back writing and closing mail) On Dec 28, 2009, at 1:57 AM, Adrian Kuhn wrote: > Mariano Martinez Peck <marianopeck@...> writes: > >> Adrian: Can I still bother you with new requirements ? jajaja > > Your welcome :) > >> First of all, thank you very much for putting a context menu when you press >> "right button" over a failing or error test. I really hate when it was run >> again instead of opening a context menu. Now, I noticed that you open a menu >> with the options "History" "Store..." and "Show progress". > > The history menu should *only* show up when you right-click in the colored > status bar, but not on failure and error list. Can you conform that? > >> I really love one item more called "browse it" and that opens a System >> Browser with that class, with that test method selected. What do you think? > > Awesome idea, I'll add that. > > PS, I was also thinking about a 'step through test' option that open a debugger > at the start of the test, rather than at the failing assertions. Will add that > to the same menu... > > --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] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

>> >> >> Package Classes Methods >> Traits 59 873 >> Traits-Kernel 22 343 >> Traits-Kernel-Traits 17 215 >> Traits-Composition 7 127 >> NanoTraits-Kernel 9 190 >> NanoTraits-Tests 9 122 >> > > oh, that's quite a big difference. > I am curious, is it because of simpler implementation or because of > smaller feature set? First two remarks -we should remove the old infrasturcture for requirements computation that has not much with traits. - second counting number of classes is not a good measure. Do you think that this is better to have one Refactoring class or 18 Refactoring classes? >> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing >> NanoTraits there will be many other methods removed in Behavior and friends >> which are only the result of unnecessary complexity in Berned traits. It >> will be *significantly* simpler by any measures and unloadable. This is probably true. This is why I want to see the result of nano traits. >>> >> (Installer repository: 'http://www.squeaksource.com/NanoTraits') >> install: 'NanoTraits-Kernel'; >> install: 'NanoTraits-Tests'. >> >> then install it using: >> >> NanoTrait install. >> >> (WARNING: Be prepared to throw the image away if something goes wrong) >> >>> I just have some concerns about common protocols, so developers could >>> use traits in both pharo & squeak without need of refactoring. >> >> Fair enough. I don't think there's much difficulty as far as extending the >> existing protocols go. We could even add compatibility traits >> (TCompilingBehavior etc) that model the old structure if people want to add >> extension methods to those. >> > > And hey, my code is always MIT, so if the Pharo folks are interested, tell >> them they're more than welcome to use and enhance it. The squeaksource >> repository is world-writable. I'm really interested in a cleaner/smaller/less intrusive trait implementations. Contrary to what some not so clever guys thought it was always the case. ;D Just no time right now. shit..... back project wirting > Aye, i CC this conversation to pharo list. > Personally, amount of code is the major criteria for me to choose > from. Especially for things in Kernel. > And especially, if it doesn't having heavy tradeoffs. Igor please rephrase your thoughts! :) amount of complexity !!! not amount of code!!! Come on number of classes is not a decent measure in presence of late binding! Stef

Dec. 28, 2009

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