From: Updike, C. <Cla...@jh...> - 2005-05-23 13:24:22
|
> -----Original Message----- > From: On Behalf Of Samuele Pedroni >=20 > Brian Zimmer wrote: >=20 > > As we're moving closer to an alpha we've been trying to get a handle > > on what tests should and should not be passing (because of CPython=20 > > differences primarily or now unsupported features such as > subclassing > > a Java class and a new-style Jython class). > > > > Part of the difficulty has been up until now the build did not copy=20 > > all the necessary files from Lib/test into the > dist/Lib/test directory > > so depending on which directory from which you ran regrtest > you would > > get different results. This has caused some confusion. > > >=20 > well, one thing is that some tests in jython/Lib/test are > obsolete, they are just a older version of a corresponding=20 > CPython test and should be removed, at one point I started=20 > doing that but did not finish. This is related to the fact=20 > that because in the deployment setup test are going to be=20 > mixed no tests in jython/Lib/test should have the > same name of a CPython test unless it is meant to completely=20 > override it. Right now regrtests with --broad option execute both=20 > tests sharing a name in jython/Lib/test and a subsquent Lib/test=20 > dir on sys.path (typically the CPython one), but ideally in the=20 > absence of spurious clashes it should need to execute only the=20 > first test encountered along sys.path with a given name. I'm not sure it works like you describe any longer. As I've said a couple times, nothing would get the jython/Lib/test tests to run. Inside regrtest.py, --broad is treated the same as -a, AFAICT. On the collections-integration branch, I modified build.xml to=20 overwrite any python tests with jython tests of the same name (and of course now the jython tests run). If we keep it this way, I'll=20 need to go through the jython tests and clean them up (make sure they are still needed and have the required python 2.2 tests if=20 they are needed). =20 > > I for one can't seem to figure out how to add a new test to the > > regrtest framework that prints to stdout such as test_sets which I=20 > > copied from the Python 2.3 test set. I had to explictly set the=20 > > test_support.verbose attribute to False otherwise the=20 > variances in the > > time taken to run the test caused the output to always diff. > > > > Another area is the bugtests respository which as far as I > can tell is > > the only real source of jythonc tests. This has yet another test > > framework. > > > > Also, testing the code from Java (not through jython) is rather > > cumbersome but Clark Updike did just add some tests for such work. > > > > Does anyone have a full handle on this stuff? Anyone want to help > > consolidate the testing frameworks? > > > > thanks, > > > > brian |
From: Updike, C. <Cla...@jh...> - 2005-05-23 15:22:19
|
> -----Original Message----- > From: Samuele Pedroni [mailto:ped...@st...]=20 > > Updike, Clark wrote: >=20 snip... > >>well, one thing is that some tests in jython/Lib/test are obsolete,=20 > >>they are just a older version of a corresponding CPython test and=20 > >>should be removed, at one point I started doing that but did not=20 > >>finish. This is related to the fact that because in the deployment=20 > >>setup test are going to be mixed no tests in jython/Lib/test should=20 > >>have the same name of a CPython test unless it is meant to=20 > completely > >>override it. Right now regrtests with --broad option execute both=20 > >>tests sharing a name in jython/Lib/test and a subsquent Lib/test=20 > >>dir on sys.path (typically the CPython one), but ideally in the=20 > >>absence of spurious clashes it should need to execute only the=20 > >>first test encountered along sys.path with a given name. > >> =20 > >> > > > >I'm not sure it works like you describe any longer. As I've said a=20 > >couple times, nothing would get the jython/Lib/test tests to run.=20 > >Inside regrtest.py, --broad is treated the same as -a, AFAICT. > > =20 > > > well, I was not able to reproduce that problem, for me=20 > regrtest with -a=20 > or --broad > run jython/Lib/test tests too. I'm basing my comments specifically on test_types.py, which exists both in the jython test dir and the cpython test dir. When I forced an exception in the jython test_types.py, I saw no change in the test output. build.xml was leaving the cpython test_types.py in=20 the dist test directory and not overwriting it with jython's=20 test_types.py until I made the above-mentioned change. snip |
From: Samuele P. <ped...@st...> - 2005-05-23 15:36:24
|
Updike, Clark wrote: > > >>-----Original Message----- >>From: Samuele Pedroni [mailto:ped...@st...] >> >>Updike, Clark wrote: >> >> >> >snip... > > >>>>well, one thing is that some tests in jython/Lib/test are obsolete, >>>>they are just a older version of a corresponding CPython test and >>>>should be removed, at one point I started doing that but did not >>>>finish. This is related to the fact that because in the deployment >>>>setup test are going to be mixed no tests in jython/Lib/test should >>>>have the same name of a CPython test unless it is meant to >>>> >>>> >>completely >> >> >>>>override it. Right now regrtests with --broad option execute both >>>>tests sharing a name in jython/Lib/test and a subsquent Lib/test >>>>dir on sys.path (typically the CPython one), but ideally in the >>>>absence of spurious clashes it should need to execute only the >>>>first test encountered along sys.path with a given name. >>>> >>>> >>>> >>>> >>>I'm not sure it works like you describe any longer. As I've said a >>>couple times, nothing would get the jython/Lib/test tests to run. >>>Inside regrtest.py, --broad is treated the same as -a, AFAICT. >>> >>> >>> >>> >>well, I was not able to reproduce that problem, for me >>regrtest with -a >>or --broad >>run jython/Lib/test tests too. >> >> > >I'm basing my comments specifically on test_types.py, which exists >both in the jython test dir and the cpython test dir. When I forced >an exception in the jython test_types.py, I saw no change in the >test output. build.xml was leaving the cpython test_types.py in >the dist test directory and not overwriting it with jython's >test_types.py until I made the above-mentioned change. > > well, build is doing the right thing anyway now, -a and --broad are meant for when one is developing and keeping jython Lib and cpython Lib separated, I will check again. jython Lib preceding cpython Lib on sys.path. |
From: Brian Z. <bz...@zi...> - 2005-05-23 16:09:18
|
Samuele Pedroni wrote: > well, build is doing the right thing anyway now, -a and --broad are > meant for when one is developing > and keeping jython Lib and cpython Lib separated, I will check again. > jython Lib preceding > cpython Lib on sys.path. > The way I generally run is to 'ant dist' and run the tests out of 'dist/Lib/test' so I don't include the stdlib of CPython in my sys.path. I think this is more in the flavor of how the actual deployment will occur through a standard installation. I like Clark expect the build.xml to copy the tests from CPython and then have Jython overwrite any modifications. brian |
From: Samuele P. <ped...@st...> - 2005-05-23 16:39:08
|
> > I like Clark expect the build.xml to copy the tests from CPython and > then have Jython overwrite any modifications. > yes, that's what my "now" was referring to, but the obsolete tests need to be cleaned up to make it completely effective. > brian > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Samuele P. <ped...@st...> - 2005-05-23 13:31:05
|
Updike, Clark wrote: >>-----Original Message----- >>From: On Behalf Of Samuele Pedroni >> >>Brian Zimmer wrote: >> >> >> >>>As we're moving closer to an alpha we've been trying to get a handle >>> >>> > > > >>>on what tests should and should not be passing (because of CPython >>>differences primarily or now unsupported features such as >>> >>> >>subclassing >> >> >>>a Java class and a new-style Jython class). >>> >>>Part of the difficulty has been up until now the build did not copy >>>all the necessary files from Lib/test into the >>> >>> >>dist/Lib/test directory >> >> >>>so depending on which directory from which you ran regrtest >>> >>> >>you would >> >> >>>get different results. This has caused some confusion. >>> >>> >>> >>well, one thing is that some tests in jython/Lib/test are >>obsolete, they are just a older version of a corresponding >>CPython test and should be removed, at one point I started >>doing that but did not finish. This is related to the fact >>that because in the deployment setup test are going to be >>mixed no tests in jython/Lib/test should have the >>same name of a CPython test unless it is meant to completely >>override it. Right now regrtests with --broad option execute both >>tests sharing a name in jython/Lib/test and a subsquent Lib/test >>dir on sys.path (typically the CPython one), but ideally in the >>absence of spurious clashes it should need to execute only the >>first test encountered along sys.path with a given name. >> >> > >I'm not sure it works like you describe any longer. As I've said >a couple times, nothing would get the jython/Lib/test tests to run. >Inside regrtest.py, --broad is treated the same as -a, AFAICT. > > well, I was not able to reproduce that problem, for me regrtest with -a or --broad run jython/Lib/test tests too. >On the collections-integration branch, I modified build.xml to >overwrite any python tests with jython tests of the same name (and >of course now the jython tests run). If we keep it this way, I'll >need to go through the jython tests and clean them up (make sure >they are still needed and have the required python 2.2 tests if >they are needed). > > > >>>I for one can't seem to figure out how to add a new test to the >>>regrtest framework that prints to stdout such as test_sets which I >>>copied from the Python 2.3 test set. I had to explictly set the >>>test_support.verbose attribute to False otherwise the >>> >>> >>variances in the >> >> >>>time taken to run the test caused the output to always diff. >>> >>>Another area is the bugtests respository which as far as I >>> >>> >>can tell is >> >> >>>the only real source of jythonc tests. This has yet another test >>>framework. >>> >>>Also, testing the code from Java (not through jython) is rather >>>cumbersome but Clark Updike did just add some tests for such work. >>> >>>Does anyone have a full handle on this stuff? Anyone want to help >>>consolidate the testing frameworks? >>> >>>thanks, >>> >>>brian >>> >>> |