From: David F. <da...@sj...> - 2003-07-22 10:44:47
|
Hi I was just wondering if the imminent release of 1.1 mentioned on the web site is about to happen ... how long is it likely to take, what needs to be done? Thanks for inspiring software :-) David |
From: Armin R. <ar...@tu...> - 2003-07-23 10:50:05
|
Hello David, On Tue, Jul 22, 2003 at 12:44:14PM +0200, David Fraser wrote: > I was just wondering if the imminent release of 1.1 mentioned on the web > site is about to happen ... how long is it likely to take, what needs to > be done? Not much, mainly only compiling and testing in depth on Windows (which is always a bit complicated for me to do). Armin |
From: David F. <da...@sj...> - 2003-07-23 11:01:37
|
Armin Rigo wrote: >Hello David, > >On Tue, Jul 22, 2003 at 12:44:14PM +0200, David Fraser wrote: > > >>I was just wondering if the imminent release of 1.1 mentioned on the web >>site is about to happen ... how long is it likely to take, what needs to >>be done? >> >> > >Not much, mainly only compiling and testing in depth on Windows (which is >always a bit complicated for me to do). > > >Armin > OK, If you have any specific tests you want to run, you can let me know and I'll run them (I don't know if you have a test suite for this kind of thing but it might be a nice addition anyway, for demo/testing purposes) David |
From: Armin R. <ar...@tu...> - 2003-07-23 13:27:39
|
Hello David, On Wed, Jul 23, 2003 at 01:00:37PM +0200, David Fraser wrote: > >Not much, mainly only compiling and testing in depth on Windows (which is > >always a bit complicated for me to do). > > OK, If you have any specific tests you want to run, you can let me know > and I'll run them I am using my own test suite in 'test/fulltester.py'. It runs all tests with different versions of Python. The path to the Python executables must be put in a file 'test/fulltester.local'. I am not entierely sure it works under Windows, however, as it is a recent addition. If you want to have a look at it you're welcome. If possible, I need the tests to run with four versions of Python: Python 2.1.X Python 2.2.0 or 2.2.1 Python 2.2.2 or 2.2.3 Python 2.3cX A bientot, Armin. |
From: David F. <da...@sj...> - 2003-07-25 08:28:51
|
Armin Rigo wrote: >Hello David, > >On Wed, Jul 23, 2003 at 01:00:37PM +0200, David Fraser wrote: > > >>>Not much, mainly only compiling and testing in depth on Windows (which is >>>always a bit complicated for me to do). >>> >>> >>OK, If you have any specific tests you want to run, you can let me know >>and I'll run them >> >> > >I am using my own test suite in 'test/fulltester.py'. It runs all tests with >different versions of Python. The path to the Python executables must be put >in a file 'test/fulltester.local'. I am not entierely sure it works under >Windows, however, as it is a recent addition. > >If you want to have a look at it you're welcome. If possible, I need the tests >to run with four versions of Python: > > Python 2.1.X > Python 2.2.0 or 2.2.1 > Python 2.2.2 or 2.2.3 > Python 2.3cX > > >A bientot, > >Armin. > > > Thanks, Armin I have installed Python 2.1, 2.2.0, 2.2.1, 2.2.2, 2.2.3 and 2.3c1. I am now going to look at adapting fulltester.py so it works properly under Windows - at the moment it just runs all the tests in the same interpeter for some reason, and the compiling doesn't seem to work... David |
From: Armin R. <ar...@tu...> - 2003-07-25 09:57:37
|
Hello David, On Fri, Jul 25, 2003 at 10:27:59AM +0200, David Fraser wrote: > I have installed Python 2.1, 2.2.0, 2.2.1, 2.2.2, 2.2.3 and 2.3c1. I am > now going to look at adapting fulltester.py so it works properly under > Windows - at the moment it just runs all the tests in the same > interpeter for some reason, and the compiling doesn't seem to work... The tests are really supposed to be all run in the same interpreter (more precisely, the tests are divided into 3 blocks and run in 3 successive interpreters to avoid too high memory usages). If compiling doesn't work it is more suspicious... Armin |
From: David F. <da...@sj...> - 2003-07-25 10:18:43
|
Armin Rigo wrote: >Hello David, > >On Fri, Jul 25, 2003 at 10:27:59AM +0200, David Fraser wrote: > > >>I have installed Python 2.1, 2.2.0, 2.2.1, 2.2.2, 2.2.3 and 2.3c1. I am >>now going to look at adapting fulltester.py so it works properly under >>Windows - at the moment it just runs all the tests in the same >>interpeter for some reason, and the compiling doesn't seem to work... >> >> > >The tests are really supposed to be all run in the same interpreter (more >precisely, the tests are divided into 3 blocks and run in 3 successive >interpreters to avoid too high memory usages). > OK, I got confused by the thing about fulltester.local having a list of Python executables. So I should basically just change fulltester.local each time I run it on a different interpreter. I've written a shell script to do this for all versions so it should be easy to repeat >If compiling doesn't work it is more suspicious... > I suspect the compiling wasn't working because of being in the wrong interpreter because of the above issue. I've set it up to fix these and will post the results of the tests when done. David |
From: David F. <da...@sj...> - 2003-07-25 12:06:47
Attachments:
fulltester.sh
psyco-test-logs-win2000-20030725.zip
|
Hi These are the results of running fulltester.py on Python 2.1, 2.2, 2.2.1, 2.2.2, 2.2.3, 2.3c1 on Windows 2000 (using Visual C++ 6.0 SP5 to build the module) The version used was the latest CVS (using anonymous CVS from the shell.sourceforge.net server - would it be possible to be made a developer so I can use ssh access for CVS?) - the last update was rev 1.7 of c/Modules/parray.c I wrote a (Cygwin bash) shell script that runs from the CVS directory, and installs and then runs the tests on each version, which I have attached. It expects a file called fulltester.homes which is a list of the Python Homes (in Windows path format) It outputs the results into two files, Pythonx.x.log and Pythonx.x.dlog containing stdout and stderr. I have attached these for each version, all zipped. There seem to be similar problems with all the Python2.2.x. Python2.3c1 crashed! But others probably know better what the logs mean, so let me know if I need to change anything. Please also let me know if there is a better way to produce/send these results... they're quite large, so I could zip them... David |
From: Armin R. <ar...@tu...> - 2003-07-25 16:15:12
|
Hello David, On Fri, Jul 25, 2003 at 12:17:31PM +0200, David Fraser wrote: > OK, I got confused by the thing about fulltester.local having a list of > Python executables. Yes, this is right, it should be a list of Python executables. Here is what should occur: for interpreter in fulltester.local: for mode in (debug, optimized): compile Psyco for 'mode' and 'interpreter' for testset in testset_list: start 'interpreter' running 'testset' The testset_list is called RUNNING_MODES in fulltester.py, and has the following entries: basetests.py -- run elementary tests regrtester2.py 0/3 -- 1st third of all regr tests in psyco.full() regrtester2.py 1/3 -- 2nd third of all regr tests in psyco.full() regrtester2.py 2/3 -- 3rd third of all regr tests in psyco.full() (idem) -- the same, in psyco.profile() Now I remember about the compiler: the script runs it with 'make' in the 'psyco/c' directory, and this Makefile has a syntax which I guess differs from what Windows compilers typically expect. The fulltester.py file should be changed to actually use the top-level setup.py file (although it might be a bit hacky because we want two different compilation modes at different times, debug and optimized). A bientôt, Armin. |
From: David F. <da...@sj...> - 2003-07-28 06:03:28
|
Armin Rigo wrote: >Hello David, > >[snip] > >Now I remember about the compiler: the script runs it with 'make' in the >'psyco/c' directory, and this Makefile has a syntax which I guess differs from >what Windows compilers typically expect. The fulltester.py file should be >changed to actually use the top-level setup.py file (although it might be a >bit hacky because we want two different compilation modes at different times, >debug and optimized). > This makes me think the previous results I sent were inaccurate, I didn't realise it was recompiling in different ways and I'm not sure it would work. I'll have a look into this David |
From: Jesus C. A. <jc...@ar...> - 2003-07-23 14:01:23
|
I'd like to insist again in the convenience of having a psyco version running in *not* x86 CPUs, like old versions did, using a virtual machine :) How can I help?. -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jc...@ar... http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/_/_/_/ PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz |
From: David F. <da...@sj...> - 2003-07-25 10:36:35
|
Jesus Cea Avion wrote: >I'd like to insist again in the convenience of having a psyco version >running in *not* x86 CPUs, like old versions did, using a virtual >machine :) > >How can I help?. > > > On a not-entirely-unrelated note, what about using the SF.net compile farm to test psyco on an Opteron? This should be able to run x86-32 code anyway and might be interesting. From the latest sourceforge newsletter: >AMD Quad Opteron System on Compile Farm >--------------------------------------------- >Are you curious how your latest code runs on a 4-way 64bit Opteron >system? Now you can find out using the latest addition to >Sourceforge.net's compile Farm. AMD has been kind enough to provide >SF.net hardware for the community to use. Running SuSE Linux Enterprise >Server 8 this new system is now available for you to use. Enjoy! The >SF.net team would like to give a big thank you to AMD for their support. > >To find out more about the compile farm: >http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1 David |