- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit forked, gofer it

by Tudor Girba

In the current OB browser(s), if you press Command+T on a selected test method runs only that test. Cheers, Doru On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote: > > > On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> > wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > > Sorry for go a bit offtopic, but is it possible to run only ONE > test from the > > browser??? I would like to right click on a test method and be > execute. > > Just like the "run tests" option but only for THAT test and not > all the tests > > of that class. Is that possible ? > > Fixed in my image. > > If you file a bug report, I'll attach the fix :) > > Excellent!!!! > > http://code.google.com/p/pharo/issues/detail?id=1665 > > Let me say that I really like all the little improvements that are > being done. > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Dec. 24, 2009

[Pharo-project] Vote for Kernel test: (Array allSubclasses size) = 0 [ Was: Re: FixedIdentitySet ... ]

by Igor Stasenko

2009/12/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/12/23 Martin McClure <martin(a)hand2mouse.com>: >> Nicolas Cellier wrote: >>> >>> While looking at it, FixedIdentitySet asArray ^ self, is this really expected ? >> >> FixedIdentitySet is a very odd beast. I'm afraid I don't see the value >> of it at all, but I haven't looked at the code that uses it. >> >> Regards, >> >> -Martin >> > > Yes, very bad example, only used in traits implementation and should > be considered as private, so who ever use it should learn to not send > asArray, nor any other inherited message but a few. > I suspect inheriting basicAt: basicAt:put: and basicSize: should be > enough, which completely disqualify the choice of superclass, but I > won't bother more. > Anyway, I'm impressed by (Array allSubclasses size), I would expect > zero as a good number. > +1 why its subclassing Array, why not Collection? I propose to vote for putting SUnit test, in Kernel tests: self assert: [ Array allSubclasses size = 0 ]. -- Best regards, Igor Stasenko AKA sig.

Dec. 23, 2009

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

by Nicolas Cellier

2009/12/23 Martin McClure <martin(a)hand2mouse.com>: > Nicolas Cellier wrote: >> >> While looking at it, FixedIdentitySet asArray ^ self, is this really expected ? > > FixedIdentitySet is a very odd beast. I'm afraid I don't see the value > of it at all, but I haven't looked at the code that uses it. > > Regards, > > -Martin > Yes, very bad example, only used in traits implementation and should be considered as private, so who ever use it should learn to not send asArray, nor any other inherited message but a few. I suspect inheriting basicAt: basicAt:put: and basicSize: should be enough, which completely disqualify the choice of superclass, but I won't bother more. Anyway, I'm impressed by (Array allSubclasses size), I would expect zero as a good number. 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] ClassFactoryForTestCase

by Adrian Kuhn

Follow up. Why is #compile: not silent? The method is only ever used in tests, where (as I would expect) logging of compilations is not what you want. --AA PS: I know there is #compileSilently:classified:notifying:, but if we know that compilation *without* classification and notification is only ever used in tests, why not pick the shortest possible name fro that so our tests are more readable?

Dec. 23, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Igor Stasenko

Eliot is right: the argument of isSameSequenceAs: should be already of SequenceableCollection kind , otherwise there is no sense asking , whether some collection has same sequence as another one, which probably not sequencable. By analogy, asking 'isSameColor: anObject' , we already stating, that an argument - anObject having a #color property. Otherwise, if its not, this should lead to error, but not returning 'false'. 2009/12/23 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Wed, Dec 23, 2009 at 10:41 AM, <csrabak(a)bol.com.br> wrote: >> >> 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 > > We're talking about the argument otherCollection not the receiver. Â i.e. > leaving out isKindOf: in > 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 | > Â Â Â Â Â (otherCollection isKindOf: SequenceableCollection) ifFalse: > [^false]. "this is a horrible wart" > Â Â Â Â Â (size := self size) = otherCollection size ifFalse: [^false]. > Â Â Â Â Â 1 to: size do: [:index | > Â Â Â Â Â Â Â Â Â (self at: index) = (otherCollection at: index) ifFalse: > [^false]]. > Â Â Â Â Â ^true > You could use double dispatching: > SequenceableCollection>>isSameSequenceAs: otherThing > Â Â Â ^otherThing isSameSequenceAsSequence: self > SequenceableCollection>>Â isSameSequenceAsSequence: aSequenceableCollection > Â Â Â aSequenceableCollection size ~= self size ifTrue: [^false]. > Â Â Â etc > ObjectÂ isSameSequenceAsSequence:Â aSequenceableCollection > Â Â Â ^false > but I think in this case it's overkill. >> >> -- >> Cesar Rabak >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Dec. 23, 2009

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

by Levente Uzonyi

On Wed, 23 Dec 2009, Martin McClure wrote: > Levente Uzonyi wrote: >>>> >>> I'd think that a hashtable of elements that are linked into a tree >>> structure would also be an attractive implementation of a sorted set. >>> Insert and delete time would be O(log n) but lookup time would be O(1). >> >> I don't see the point here. Without a tree structure (just a list) it's >> O(1) for both. > > How do you get O(1) for sorted inserts into a list? That's usually > considered an O(n) operation. Or am I misunderstanding what you mean by > list? Well, just realized that you are thinking about a sorted set. The original idea was to create an ordered set. Levente > > Regards, > > -Martin > > _______________________________________________ > 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 Martin McClure

Levente Uzonyi wrote: >>> >> I'd think that a hashtable of elements that are linked into a tree >> structure would also be an attractive implementation of a sorted set. >> Insert and delete time would be O(log n) but lookup time would be O(1). > > I don't see the point here. Without a tree structure (just a list) it's > O(1) for both. How do you get O(1) for sorted inserts into a list? That's usually considered an O(n) operation. Or am I misunderstanding what you mean by list? Regards, -Martin

Dec. 23, 2009

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

by Martin McClure

Nicolas Cellier wrote: > > While looking at it, FixedIdentitySet asArray ^ self, is this really expected ? FixedIdentitySet is a very odd beast. I'm afraid I don't see the value of it at all, but I haven't looked at the code that uses it. Regards, -Martin

Dec. 23, 2009

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

by Martin McClure

Nicolas Cellier wrote: >>> >> I'd like a selector that I can apply to any collection like a Set too. >> For example, in some implementations keys are a Set (original st80) in >> others keys are an Array (Squeak trunk/Pharo). >> So, in order to have more portable pieces of code I ended up with >> (self keys asArray sort). >> Maybe the most simple thing would be to define >> Collection>>sort >> ^self asArray sort > > Arg, I pressed tab, then (oops) space and sent the message too soon... > I wanted to add this comment: > "Sort the collection in place if possible, otherwise answer a sorted Array. > Subclasses that can sort in place should override this message." > Interesting. Possibly good. But what would you do when you knew you wanted a *copy* that was sorted? "myCollection copy sort" would work, but might or might not create two copies, depending on whether the original class was one that could be sorted in place. I'm now leaning toward defining #copySorted or some such on Collection for this purpose. And *maybe* also doing what you propose with #sort. Regards, -Martin

Dec. 23, 2009

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

by Nicolas Cellier

2009/12/23 Adrian Kuhn <akuhn(a)iam.unibe.ch>: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> 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. > > A simple method should do that job > > Â Â Collection >> #addIfAbsent: element > Â Â Â Â (self includes: element) ifFalse: [ self add: element ] > > usage > > Â Â coll := OrderedCollection new. > Â Â coll addIfAbsent: #foo. > Â Â coll addIfAbsent: #bar. > Â Â coll addIfAbsent: #qux. > Â Â coll addIfAbsent: #bar. > Â Â self assert: coll asArray = #(foo bar qux). > > --AA > Yes in O(n)... The challenge was to provide a fast implementation. > > _______________________________________________ > 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