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

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

by StÃ©phane Ducasse

On Dec 23, 2009, at 5:17 PM, Adrian Kuhn wrote: > Yanni Chiu <yanni@...> writes: > >>> Gofer it >>> squeaksource: 'akuhn'; >>> package: 'SUnit'; >>> package: 'SUnitGUI'; >>> load >> >> Is it too late to call it SUnit2, SUnit3, whatever? > > Too early in my opinion :) > > I follow the github style of forking, ie "fork early, fork often". The name of > a fork is qualified by prefixing it with the name of the forker, so my fork is > qualified "akuhn/SUnit". IMHO it is early enough to think about a new name > when it is (ever?) merged back into Pharo. Phunit might be nice. > > @stef that might make a nice feature for new package system: to tell in an > immediately visible way from which repo a package/class is coming. The problem is that you can have multiple repos. Now RPackage is disconnect orthogonal to MC and repo it is just a couple of classes to replace packageInfo. >> What happens is that people start writing test cases assuming the newer >> version. Then at some point there's a conflict, and you either have to >> re-write your old or your new test cases. Maybe it's okay to be forced >> to update your old test cases, but it would be good know which version >> of the "SUnit API" is available or required. > > Good point, I share your concern. Maybe something like > > self assumeSUnitIsAkuhnFork > > might help. This will fail with DNU on all version except my fork. > > --AA > > > > _______________________________________________ > 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

>> I started to implement OrderedSet (OrderedCollection no duplicate) >> but I think that I want probably UniqueOrdered. >> I will publish what I have done and ask for feedback and that other can >> improve. I like the idea of using the TraitsTest to have coherent sets of >> behavior. > > Oh yeah, TreeSet ftw, missed that already sometime! what is TreeSet? >>>>> asSortedArray >>> asSortedCollection >>> asSortedCollection: >>> sortBy: > > 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 ] Is it not that sortBy: should be used like that aCollection sortBy: [ :a :b | a name <= b name ] ? > if you want that, I can provide a fast implementation of #sortBy: Now what would be good is to have sort: for all the collections so that we can use them polymorphically. I do not really see the use of sortBy: except as a replacement/unification between sortBlock: and sort:. I really think that we should polish the collections. They are the foundation. We should probably have a look at the moose collection extensions you did and we ported to squeak (not all of them). They are published in Moose/CollectionExtensions Stef > > --AA > > > _______________________________________________ > 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

by Adrian Kuhn

Denis Kudriashov <dionisiydk@...> writes: > VisualWorks has interesting framework Assessments > http://blogten.blogspot.com/2009/07/what-is-assessments.html Cool, I'll look at that. Thanks --AA

Dec. 23, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

Martin McClure <martin@...> writes: > Some months ago Niall Ross took over maintainership of SUnit. IIRC he > had the blessing of the previous maintainers, who hadn't been able to > actually do much with it in recent years. At ESUG in Brest, Niall was > actively working on SUnit and talking to folks from various Smalltalk > implementations to try to get stuff into the next "official" release > that would make everyone happy. > > So there is work going on to attempt to make the situation better. I'd > think you'd want to at least discuss this with Niall and look at what > he's done before starting over from scratch. If what's there doesn't > meet Pharo's needs, starting from scratch might be appropriate. But if > there can be "one true SUnit" for all Smalltalk, that seems like a > better answer. Sure thing, I'll contact Niall. --AA -- Follow me http://twitter.com/akuhn Follow me http://twitter.com/codemap Follow me http://twitter.com/jexample Follow me http://twitter.com/suite2010 Follow me http://twitter.com/dyla2010 -- new!

Dec. 23, 2009

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

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > Ok so why don't you use a better name > > SingleTestResult > > because Token does not talk to me. Consider all names tentative for the moment. Suggestion are indeed welcome. --AA

Dec. 23, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by StÃ©phane Ducasse

Ok this is in the image I did not remember (getting old) :) but the vm pay attention not to crash totally when you put nil in a methodDict. Now what I know is that a while back when we activate Smalltalk at: #MDFaultDict put: Dictionary new. We kind of either crashed or got all the classes of the system in. I have the impression that this is just a hack and I would remove it from the system because we can do with MW or reflectivity (even if we probably cannot trace the tracing code). Also the granularity is really the class so as soon as one method is invoked you get all the class back. So with mathieu we simply something could not understand why all the classes would be touched may be browser was scanning all the image. No idea. but at the end it was not useful. Stef On Dec 23, 2009, at 4:51 PM, Adrian Kuhn wrote: > Mariano Martinez Peck <marianopeck@...> writes: > >> So, it seems to HACK (it forces a fault) this MD fault recover to discover >> inactive classes and other things. Ok, forget that hack for a moment. >> >> What questions is, what are these faults? Why a method dictionary can be in >> nil ? How is this produced ? And how is it fixed? >> >> I saw for example this: >> >> Behaviour>>methodDict >> methodDict == nil ifTrue: [self recoverFromMDFaultWithTrace]. >> ^ methodDict >> >> But again...how can that be nil ??? > > I guess your missing link is > > ProtoObject >> #cannotInterpret: > > which is executed by the VM whenever you try to send a message to an object > whose class does not have a method dictionary. Further methods that you should > look at are > > ClassDescription >> #induceMDFault > ClassDescription >> #recoverFromMDFault > ClassDescription >> #recoverFromMDFaultWithTrace > > and their senders. Except for the call to #cannotInterpret by the VM, all the > rest is done in the image (stef got that wrong) and you can go and read the > code. All in all, it is a highly sophisticated (read *ugly*) hack and I'd say > an evil use of superpowers. > > --AA > > > > > > > _______________________________________________ > 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 Adrian Kuhn

Yanni Chiu <yanni@...> writes: > > Gofer it > > squeaksource: 'akuhn'; > > package: 'SUnit'; > > package: 'SUnitGUI'; > > load > > Is it too late to call it SUnit2, SUnit3, whatever? Too early in my opinion :) I follow the github style of forking, ie "fork early, fork often". The name of a fork is qualified by prefixing it with the name of the forker, so my fork is qualified "akuhn/SUnit". IMHO it is early enough to think about a new name when it is (ever?) merged back into Pharo. Phunit might be nice. @stef that might make a nice feature for new package system: to tell in an immediately visible way from which repo a package/class is coming. > What happens is that people start writing test cases assuming the newer > version. Then at some point there's a conflict, and you either have to > re-write your old or your new test cases. Maybe it's okay to be forced > to update your old test cases, but it would be good know which version > of the "SUnit API" is available or required. Good point, I share your concern. Maybe something like self assumeSUnitIsAkuhnFork might help. This will fail with DNU on all version except my fork. --AA

Dec. 23, 2009

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

by merlyn＠stonehenge.com

>>>>> "Adrian" == Adrian Kuhn <akuhn(a)iam.unibe.ch> writes: Adrian> What bugs me is that #sortBy: does not what it says. I would expect that Adrian> aCollection sortBy: [ :each | each name ] Adrian> does the same as Adrian> aCollection sort: [ :a :b | a name <= b name ] And if you could make "aCollection sortBy: #name" also do the same, bonus points! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Dec. 23, 2009

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

by Mariano Martinez Peck

On Wed, Dec 23, 2009 at 4:58 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > > > I started to implement OrderedSet (OrderedCollection no duplicate) > > but I think that I want probably UniqueOrdered. > > I will publish what I have done and ask for feedback and that other can > > improve. I like the idea of using the TraitsTest to have coherent sets of > > behavior. > > Oh yeah, TreeSet ftw, missed that already sometime! > > > > >> asSortedArray > > > asSortedCollection > > > asSortedCollection: > > > sortBy: > > 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: > > In those cases will be cool to write first all the tests than make the things to fail and then write the code to fix them :) But ok...not everybody have that time. > --AA > > > _______________________________________________ > 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: All mailinglist messages on gmane are dublicated

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > I don't see them duplicated.Â only comments view is affected, eg http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/17858 --AA

Dec. 23, 2009