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

Re: [Pharo-project] TestRunner ENH

by Mariano Martinez Peck

On Wed, Nov 4, 2009 at 10:34 PM, keith <keith_hodges(a)yahoo.co.uk> wrote: > > > > > > Why would I want to run my tests faster or slower ? I would always > > choose fast ahahahha > > > > Of course, there is something I am missing. > > > > Kind regards, > > > > Mariano > > > > > In SUnit-improved TestRunner the time taken to run each test was > recorded. > > Then there is an option to automatically categorize tests as (slow) , > (long) or (net), where you can configure what time span is considered > "slow", or "long" > > Then on subsequent runs you can organize to run the quick tests first, > and you get something like 90%+ coverage in the first minute, with the > slow and long tests to follow. > > Thanks Keith! That makes sense. So, it would be something like "run only the faster ones" than "run them fast" As the button says "run fast" I understood the second intention. Thanks! Mariano > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 6, 2009

[Pharo-project] [update] #10494

by Adrian Lienhard

10494 ----- - Issue 1408: SharedQueue2 doesNotUnderstand: #flushAllSuchThat: - Issue 1409: update gofer - Issue 1379: Sometimes my author names ends up being "TestRunner" ---- Now the list of pending issues for 1.0 is empty again. If you know of any remaining problems, please report them. Adrian ___________________ http://www.adrian-lienhard.ch/

Nov. 6, 2009

Re: [Pharo-project] Shadowed Variables

by StÃ©phane Ducasse

>> Yes, but... > > ...then the author of the trait must know all of the IV names of all > of > the classes to which the trait might be applied, including ones not > yet > written. Since traits aren't allowed to reference any IV, this does > seem > like an unreasonable burden for the trait author. but this is not that way. As a composer I have to pay attention. > Or, conversely, the author of a new class that wants to apply one or > more existing traits to the new class must know all of the temp > variable > names used by the trait, which also seems an unreasonable burden. > > > The interaction between traits and classes should be defined solely by > trait messages provided and required; the variable names used should > not > enter into it. Exact. > I'd think that the desirable path would be to have arg and temp names > shadow instvars, and that the tools would warn of this condition > except > in traits, where the shadowing would be silently accepted. Yes. > Also desirable is for the tools to consider any access to an IV > within a > trait as an error. (Maybe the tools already do this?) funnily I did not try :)

Nov. 6, 2009

Re: [Pharo-project] Shadowed Variables

by Martin McClure

StÃ©phane Ducasse wrote: >> Well, with the presence of traits, i don't see how we could avoid >> that nicely. > > May be I missed something but I do not see why? > If I do not use in a trait a local variable that are the same name as > an iv then I have no problem. > So just using a different local or iv solve it. Yes, but... ...then the author of the trait must know all of the IV names of all of the classes to which the trait might be applied, including ones not yet written. Since traits aren't allowed to reference any IV, this does seem like an unreasonable burden for the trait author. Or, conversely, the author of a new class that wants to apply one or more existing traits to the new class must know all of the temp variable names used by the trait, which also seems an unreasonable burden. The interaction between traits and classes should be defined solely by trait messages provided and required; the variable names used should not enter into it. I'd think that the desirable path would be to have arg and temp names shadow instvars, and that the tools would warn of this condition except in traits, where the shadowing would be silently accepted. Also desirable is for the tools to consider any access to an IV within a trait as an error. (Maybe the tools already do this?) Regards, -Martin

Nov. 6, 2009

[Pharo-project] New Pharo based on core 10493 - Win32 Installer

by Torsten Bergmann

... you may already know, is up on the download page. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Nov. 6, 2009

[Pharo-project] Phexample moved to new account on Squeaksource

by Adrian Kuhn

Dear list, in the future please use the script to load Phexample Gofer new squeaksource: 'phexample'; addPackage: 'Phexample-Core'; load. we renamed the URL to be all lower case. PS, as a goodie you will find a glamour browser in the package 'Phexample-Glamour', critical feedback welcome! cheers, AA

Nov. 6, 2009

Re: [Pharo-project] chasing AnObsoleteFlaps

by StÃ©phane Ducasse

On Nov 6, 2009, at 7:21 PM, Nicolas Cellier wrote: > Yes, but given all the Weak* things used, shouldn't they auto-flush ? Yes I saw that too :) stef

Nov. 6, 2009

Re: [Pharo-project] chasing AnObsoleteFlaps

by Nicolas Cellier

Yes, but given all the Weak* things used, shouldn't they auto-flush ? 2009/11/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I imagine that we can flush the caches. > > Stef > > On Nov 5, 2009, at 10:36 PM, Nicolas Cellier wrote: > >> I tried this to get rid of AnObsoleteFlaps >> >> Preferences dictionaryOfPreferences: (Preferences >> dictionaryOfPreferences reject: [:e | e value isObsolete]). >> >> Unfortunately, RequiredSelectors still has some references... Just >> too bad. >> >> _______________________________________________ >> 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 >

Nov. 6, 2009

Re: [Pharo-project] Shadowed Variables

by Igor Stasenko

2009/11/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Well, with the presence of traits, i don't see how we could avoid >> that nicely. > > May be I missed something but I do not see why? > If I do not use in a trait a local variable that are the same name as > an iv then I have no problem. > So just using a different local or iv solve it. > Consider uses of traits over a large time span and by multiple developers. One may change an already existing trait (and introduce/change temps names), which already used by multiple projects. But since author is physically unable to check all uses of this trait, then at some point, shadowing may occur. Of course, the maintainer of code who using the trait can react and change the names of ivars, or ask the author of trait to not use some names for temps vars. But since it doesn't affects the code semantics, nothing bad could happen (class vars is different story). And i don't agree that shadowing is considered evil. > Stef > > _______________________________________________ > 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.

Nov. 6, 2009

Re: [Pharo-project] chasing AnObsoleteFlaps

by StÃ©phane Ducasse

I imagine that we can flush the caches. Stef On Nov 5, 2009, at 10:36 PM, Nicolas Cellier wrote: > I tried this to get rid of AnObsoleteFlaps > > Preferences dictionaryOfPreferences: (Preferences > dictionaryOfPreferences reject: [:e | e value isObsolete]). > > Unfortunately, RequiredSelectors still has some references... Just > too bad. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 6, 2009