June 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Broken tests

by Adrian Lienhard

I've fixed the following 7 tests (see inbox: SLICE-test-fixes.al.1.mcz): testRootsOfTheWorld -- test removed testLocalMethodWithSameCodeInTrait -- removed duplicated method ClassDescription>>fileOutCategory: testFinalizationOfEquals -- test fixed testHash -- remove all assertions/tests that have hardcoded hash values DateAndTimeEpochTest>>#testHash DateAndTimeLeapTest>>#testHash TimeTest>>#testHash TimespanTest>>#testHash Now 8 tests are still failing. We are getting there... Cheers, Adrian On Jun 11, 2008, at 19:07 , StÃ©phane Ducasse wrote: > excellent! > > Stef > > On Jun 11, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > >> >> Just for phun, I ran all the tests in the Pharo image. There are >> only 13 failures, 2 expected failures, and no errors! >> >> I have started a page to give an overview: >> >> http://code.google.com/p/pharo/wiki/BrokenTests >> >> Please update this page with an appropriate comment if you are >> working on any of these (or if you fix them). >> >> - on >> >> _______________________________________________ >> 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

June 12, 2008

[Pharo-project] Improving the general quality of package

by StÃ©phane Ducasse

Hi all I would really like to see if it make sense to run SmallLint on packages. Of course we should not naively apply the proposed refactoring (some blind applications of them in the past went against speed in Graphics), still identifying and building a process to produce a bit better code quality would be great. If any of you want to give a try it would be great. I'm also thinking about having a manifesto to each package or group of package so that we can attach information and metainformation to package such as documentation... So far I'm not happy with what I did (cf DrDoc but this is one step in that direction). Stef

June 12, 2008

Re: [Pharo-project] Strange bug in TraitsTest

by Adrian Lienhard

On Jun 12, 2008, at 15:49 , Norbert Hartl wrote: > On Thu, 2008-06-12 at 15:28 +0200, Adrian Lienhard wrote: >> I don't see what could testRootsOfTheWorld be useful for. Anyway, the >> reason why this fails is because for the traits tests I use test >> resources and they are set up before all tests are run and >> testRootsOfTheWorld asserts that there are exactly 3 classes in the >> system that do not have a superclass. >> > I don't think that the test does harm. And I don't really care > about the test. What I don't understand is the "side effect". The > classes are created in TraitsTestCase. The failing test is in > ClassTest. As far as I can see the created classes are removed on > tearDown time. Well, this is how the test runner works... It first sets up all test resources (which in this case creates the offending classes), then it runs all tests, and then it releases the resources. That is, resource allocation and deallocation is "global", therefore ClassTest is affected. Hope that explains it better. Adrian > > > > Norbert > >> There are two simple solutions for this. Either remove >> testRootsOfTheWorld or change the test classes created in >> TraitsRescource to inherit from Object instead of ProtoObject. I >> would >> do the former unless somebody has a convincing argument for keeping >> that test in the image. >> >> Adrian >> >> NB: I'll also fix #testLocalMethodWithSameCodeInTrait when I'm at it >> (this tests that there do not exist duplicated methods between a >> trait >> and a class using the trait) >> >> On Jun 11, 2008, at 19:24 , Norbert Hartl wrote: >> >>> If you open a test runner and select only KernelTests-ClassTest and >>> TraitsTests-TraitsTestCase you may find a failure >>> >>> ClassTest>>testRootsOfTheWorld >>> >>> But I don't understand fully why it appears. I had once >>> the chance to get a debugger on the failure (which does >>> usually not work on this failure) and so I know that the >>> rootsOfTheWorld (which is usually 3) is 6 in size containing >>> additionally classes C3 C4 and C6. The ones which are created >>> by TraitsTestCase (see my last mail "Bug for harvest"). >>> >>> They all have a superclass of nil but they aren't included >>> in the SystemNavigation. (conditions for being included in >>> the rootsOfTheWorld) >>> >>> If you press "Run selected" again the same error occurrs >>> while pressing "Run failures" gives you all green (ok, it >>> is this way in my case) >>> >>> And I can't reproduce the same in a 3.10 image. >>> >>> It seems that there is a timing problem involved. Selecting >>> only the two test cases I get the failure every time (or nearly). >>> Selecting all tests it appears only at random. >>> >>> Any hints? >>> >>> Norbert >>> >>> >>> >>> >>> _______________________________________________ >>> 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

June 12, 2008

Re: [Pharo-project] Strange bug in TraitsTest

by StÃ©phane Ducasse

Hi adrian go for it :) Stef On Jun 12, 2008, at 3:28 PM, Adrian Lienhard wrote: > I don't see what could testRootsOfTheWorld be useful for. Anyway, > the reason why this fails is because for the traits tests I use test > resources and they are set up before all tests are run and > testRootsOfTheWorld asserts that there are exactly 3 classes in the > system that do not have a superclass. > > There are two simple solutions for this. Either remove > testRootsOfTheWorld or change the test classes created in > TraitsRescource to inherit from Object instead of ProtoObject. I > would do the former unless somebody has a convincing argument for > keeping that test in the image. > > Adrian > > NB: I'll also fix #testLocalMethodWithSameCodeInTrait when I'm at it > (this tests that there do not exist duplicated methods between a > trait and a class using the trait) > > On Jun 11, 2008, at 19:24 , Norbert Hartl wrote: > >> If you open a test runner and select only KernelTests-ClassTest and >> TraitsTests-TraitsTestCase you may find a failure >> >> ClassTest>>testRootsOfTheWorld >> >> But I don't understand fully why it appears. I had once >> the chance to get a debugger on the failure (which does >> usually not work on this failure) and so I know that the >> rootsOfTheWorld (which is usually 3) is 6 in size containing >> additionally classes C3 C4 and C6. The ones which are created >> by TraitsTestCase (see my last mail "Bug for harvest"). >> >> They all have a superclass of nil but they aren't included >> in the SystemNavigation. (conditions for being included in >> the rootsOfTheWorld) >> >> If you press "Run selected" again the same error occurrs >> while pressing "Run failures" gives you all green (ok, it >> is this way in my case) >> >> And I can't reproduce the same in a 3.10 image. >> >> It seems that there is a timing problem involved. Selecting >> only the two test cases I get the failure every time (or nearly). >> Selecting all tests it appears only at random. >> >> Any hints? >> >> Norbert >> >> >> >> >> _______________________________________________ >> 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 >

June 12, 2008

[Pharo-project] Fwd: Comment on BrokenTests in pharo

by Pharo Smalltalk

---------- Forwarded message ---------- From: <codesite-noreply(a)google.com> Date: Thu, Jun 12, 2008 at 3:16 AM Subject: Comment on BrokenTests in pharo To: pharo.smalltalk(a)gmail.com Comment by andreas.raab: 3.9 has a different manifest bit pattern for NaN than Pharo. Try this: Float nan hex "<print it>" 3.9: '7FF8000000000000' Pharo: 'FFF8000000000000' It looks like 3.9 was initialized on PPC, Pharo on Intel. Since there is an infinite number of NaN bit patterns the real solution is to use a manifest binary constant in Float initialization, i.e, Float class>>initialize "..." NaN := Float with: 16rFFF80000 with: 0. instead of the computation that is in there today. For more information: http://code.google.com/p/pharo/wiki/BrokenTests

June 12, 2008

[Pharo-project] Which tests broken in Phrao are also broken in 3.9 and 3.10

by Oscar Nierstrasz

I checked all the broken tests. It seems that there are some fixes that we should be able to harvest from 3.10. http://code.google.com/p/pharo/wiki/BrokenTests - on

June 12, 2008

Re: [Pharo-project] Strange bug in TraitsTest

by Norbert Hartl

On Thu, 2008-06-12 at 15:28 +0200, Adrian Lienhard wrote: > I don't see what could testRootsOfTheWorld be useful for. Anyway, the > reason why this fails is because for the traits tests I use test > resources and they are set up before all tests are run and > testRootsOfTheWorld asserts that there are exactly 3 classes in the > system that do not have a superclass. > I don't think that the test does harm. And I don't really care about the test. What I don't understand is the "side effect". The classes are created in TraitsTestCase. The failing test is in ClassTest. As far as I can see the created classes are removed on tearDown time. Norbert > There are two simple solutions for this. Either remove > testRootsOfTheWorld or change the test classes created in > TraitsRescource to inherit from Object instead of ProtoObject. I would > do the former unless somebody has a convincing argument for keeping > that test in the image. > > Adrian > > NB: I'll also fix #testLocalMethodWithSameCodeInTrait when I'm at it > (this tests that there do not exist duplicated methods between a trait > and a class using the trait) > > On Jun 11, 2008, at 19:24 , Norbert Hartl wrote: > > > If you open a test runner and select only KernelTests-ClassTest and > > TraitsTests-TraitsTestCase you may find a failure > > > > ClassTest>>testRootsOfTheWorld > > > > But I don't understand fully why it appears. I had once > > the chance to get a debugger on the failure (which does > > usually not work on this failure) and so I know that the > > rootsOfTheWorld (which is usually 3) is 6 in size containing > > additionally classes C3 C4 and C6. The ones which are created > > by TraitsTestCase (see my last mail "Bug for harvest"). > > > > They all have a superclass of nil but they aren't included > > in the SystemNavigation. (conditions for being included in > > the rootsOfTheWorld) > > > > If you press "Run selected" again the same error occurrs > > while pressing "Run failures" gives you all green (ok, it > > is this way in my case) > > > > And I can't reproduce the same in a 3.10 image. > > > > It seems that there is a timing problem involved. Selecting > > only the two test cases I get the failure every time (or nearly). > > Selecting all tests it appears only at random. > > > > Any hints? > > > > Norbert > > > > > > > > > > _______________________________________________ > > 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

June 12, 2008

Re: [Pharo-project] Bug for harvesting

by Adrian Lienhard

Fix looks ok. Not sure why setting the superclass to nil is actually needed, but else the test is not green (note, the "requires algorithm" was introduced by David Vainsencher and was originally implemented by Nathanael; does somebody use it? maybe in the Squeak-dev image?). Adrian On Jun 11, 2008, at 20:50 , Victor Rodriguez wrote: > On Wed, Jun 11, 2008 at 1:12 PM, Norbert Hartl <norbert(a)hartl.name> > wrote: >> Hi, >> >> I opened a bug a few minutes ago which you may find interesting >> for harvest. >> >> http://bugs.squeak.org/view.php?id=7090 > > I have filed this as Issue 13. I left the state as NEW. > > Saludos, > > Victor. > >> Norbert >> >> >> _______________________________________________ >> 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

June 12, 2008

Re: [Pharo-project] Strange bug in TraitsTest

by Adrian Lienhard

I don't see what could testRootsOfTheWorld be useful for. Anyway, the reason why this fails is because for the traits tests I use test resources and they are set up before all tests are run and testRootsOfTheWorld asserts that there are exactly 3 classes in the system that do not have a superclass. There are two simple solutions for this. Either remove testRootsOfTheWorld or change the test classes created in TraitsRescource to inherit from Object instead of ProtoObject. I would do the former unless somebody has a convincing argument for keeping that test in the image. Adrian NB: I'll also fix #testLocalMethodWithSameCodeInTrait when I'm at it (this tests that there do not exist duplicated methods between a trait and a class using the trait) On Jun 11, 2008, at 19:24 , Norbert Hartl wrote: > If you open a test runner and select only KernelTests-ClassTest and > TraitsTests-TraitsTestCase you may find a failure > > ClassTest>>testRootsOfTheWorld > > But I don't understand fully why it appears. I had once > the chance to get a debugger on the failure (which does > usually not work on this failure) and so I know that the > rootsOfTheWorld (which is usually 3) is 6 in size containing > additionally classes C3 C4 and C6. The ones which are created > by TraitsTestCase (see my last mail "Bug for harvest"). > > They all have a superclass of nil but they aren't included > in the SystemNavigation. (conditions for being included in > the rootsOfTheWorld) > > If you press "Run selected" again the same error occurrs > while pressing "Run failures" gives you all green (ok, it > is this way in my case) > > And I can't reproduce the same in a 3.10 image. > > It seems that there is a timing problem involved. Selecting > only the two test cases I get the failure every time (or nearly). > Selecting all tests it appears only at random. > > Any hints? > > Norbert > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 12, 2008

Re: [Pharo-project] [ANN] New release

by Victor Rodriguez

Replaying to two messages: On Thu, Jun 12, 2008 at 2:47 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > On Wed, 2008-06-11 at 21:22 -0400, Victor Rodriguez wrote: [snip] >> BTW, PharoReady.cs is not available. Stephane, could you please add it? >> > I added it. I've put it into the svn and linked it from there. I don't > think the initial cs has be add inria. > > Norbert On Thu, Jun 12, 2008 at 5:07 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > It is there. > > http://pharo.gforge.inria.fr/PharoReady.cs I would say put the PharoReady.cs on the files section of the INRIA gforge. I would put it right under "Squeak / 3.9.1-7075" so that all the files needed to build Pharo from scratch are together. If we are going to use INRIA gforge for files, lets put *all* the files there, specially "published" files such as this one. If we ever really need to revision something, then we can use the SVN repository. Saludos, Victor Rodriguez. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2008