Hi, I think we are ready to make the release: with the recent Scipy from CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, and a WinNT box. If you think that there are some important bugs to be fixed, you still got about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian time), create tar-balls, etc. See http://www.scipy.org/development/releasescipy.txt for relevant tasks. Please, let me know if there is any reason that I should hold on for tagging CVS tree. I can also make binaries for Linux system but it would be create if someone could create RPMs (Joe?) and Win32 installers (Travis?) after tar-balls are available. Thanks, Pearu
On Wed, 6 Oct 2004 14:04:50 -0500 (CDT) Pearu Peterson <pearu@scipy.org> wrote:
Hi,
I think we are ready to make the release: with the recent Scipy from CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, and a WinNT box.
If you think that there are some important bugs to be fixed, you still got about 12 hours.
Pearu, I still have problems with from scipy.xplt import * see my previous e-mail. It works quite well a few weeks ago. Following Travis, I have upgraded Numeric to 23.5 but nothing happened. I am also using the latest scipy from cvs. Any pointer would be appreciated. Thanks Nils I plan to tag Scipy CVS tree tomorrow
morning (Estonian time), create tar-balls, etc. See
http://www.scipy.org/development/releasescipy.txt
for relevant tasks.
Please, let me know if there is any reason that I should hold on for tagging CVS tree.
I can also make binaries for Linux system but it would be create if someone could create RPMs (Joe?) and Win32 installers (Travis?) after tar-balls are available.
Thanks, Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
Pearu Peterson wrote:
Hi,
I think we are ready to make the release: with the recent Scipy from CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, and a WinNT box.
If you think that there are some important bugs to be fixed, you still got about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian time), create tar-balls, etc. See
http://www.scipy.org/development/releasescipy.txt
for relevant tasks.
Please, let me know if there is any reason that I should hold on for tagging CVS tree.
I can also make binaries for Linux system but it would be create if someone could create RPMs (Joe?) and Win32 installers (Travis?) after tar-balls are available.
I can make Win32 installers appropriate for my system (i.e. the ATLAS I use) --- later in coming would be generic-type Win32 installers. I can make RPMS appropriate for Mandrake 10.0 as well. -Travis
Travis Oliphant schrieb:
Pearu Peterson wrote:
Hi,
I think we are ready to make the release: with the recent Scipy from CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, and a WinNT box.
If you think that there are some important bugs to be fixed, you still got about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian time), create tar-balls, etc. See
http://www.scipy.org/development/releasescipy.txt
for relevant tasks.
Please, let me know if there is any reason that I should hold on for tagging CVS tree.
I worry that gui_thread is really not ready for public consumption: planck[pylab]> cd /usr/share/doc/wxPythonGTK2-2.4.2.4/demo/ planck[demo]> ip Python 2.3.3 (#1, May 7 2004, 10:31:40) Type "copyright", "credits" or "license" for more information. IPython 0.6.4.rc1 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: import gui_thread In [2]: gui_thread.start() In [3]: import Main In [4]: d = Main.wxPythonDemo(None,-1, 'a') Segmentation fault Prabhu is getting very good results with wxpython 2.5, but it seems that for 2.4 there are serious problems still. I've been running several small tests which he has suggested, but with no positive results yet. Considering that this is on an up-to-date Fedora 2 install, perhaps gui_thread should be disabled for WxPython 2.4. Printing a warning and telling users that gui_thread only supports 2.5 would be better than segfaulting :) Best, f
On Wed, 6 Oct 2004, Fernando Perez wrote:
I worry that gui_thread is really not ready for public consumption:
planck[pylab]> cd /usr/share/doc/wxPythonGTK2-2.4.2.4/demo/ planck[demo]> ip Python 2.3.3 (#1, May 7 2004, 10:31:40) Type "copyright", "credits" or "license" for more information.
IPython 0.6.4.rc1 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import gui_thread
In [2]: gui_thread.start()
In [3]: import Main
In [4]: d = Main.wxPythonDemo(None,-1, 'a') Segmentation fault
Prabhu is getting very good results with wxpython 2.5, but it seems that for 2.4 there are serious problems still. I've been running several small tests which he has suggested, but with no positive results yet.
Considering that this is on an up-to-date Fedora 2 install, perhaps gui_thread should be disabled for WxPython 2.4. Printing a warning and telling users that gui_thread only supports 2.5 would be better than segfaulting :)
I have no problems with using gui_thread on a Debian system with wxPythonSrc-2.4.2.4. So, I wouldn't disable gui_thread for myself;) My environment: Python 2.3.4, LANG is unset, Numeric 23.5. Could you try to use libwadpy or some other tool to find out which part of wxPython is segfaulting? Pearu
Pearu Peterson schrieb:
I have no problems with using gui_thread on a Debian system with wxPythonSrc-2.4.2.4. So, I wouldn't disable gui_thread for myself;) My environment: Python 2.3.4, LANG is unset, Numeric 23.5.
Ok, here's a bit more useful info: if I set LANG to C, it all looks pretty good. If I leave one of the fedora defaults, even an english one: planck[demo]> echo $LANG en_US.UTF-8 I get guaranteed segfaults. I'm going to guess it's a bug related to UTF-8 handling deep in the bowels of wx and/or GTK.
Could you try to use libwadpy or some other tool to find out which part of wxPython is segfaulting?
Unfortunately I can't really commit to deeply debugging this problem at the library level (WX) right now. That kind of bug hunting in C libs is very time consuming, and at the moment I can only spend short bursts of time on this performing small tests. Hopefully the LANG info proves useful, since that's the most I'm likely to be able to provide. Can you see if you get similar problems with UTF-8 settings? Perhaps doing a hard LANG=C inside gui_thread is a viable option also. Not ideal, but better than a segfault :) Cheers, f
On Wed, 6 Oct 2004, Fernando Perez wrote:
Pearu Peterson schrieb:
I have no problems with using gui_thread on a Debian system with wxPythonSrc-2.4.2.4. So, I wouldn't disable gui_thread for myself;) My environment: Python 2.3.4, LANG is unset, Numeric 23.5.
Ok, here's a bit more useful info: if I set LANG to C, it all looks pretty good. If I leave one of the fedora defaults, even an english one:
planck[demo]> echo $LANG en_US.UTF-8
I get guaranteed segfaults. I'm going to guess it's a bug related to UTF-8 handling deep in the bowels of wx and/or GTK.
Could you try to use libwadpy or some other tool to find out which part of wxPython is segfaulting?
Unfortunately I can't really commit to deeply debugging this problem at the library level (WX) right now. That kind of bug hunting in C libs is very time consuming, and at the moment I can only spend short bursts of time on this performing small tests. Hopefully the LANG info proves useful, since that's the most I'm likely to be able to provide. Can you see if you get similar problems with UTF-8 settings?
No. Using `LANG=en_US.UTF-8 python` does not cause any problems here on Debian box: I can even run multiple wxPython demo instances.
Perhaps doing a hard LANG=C inside gui_thread is a viable option also. Not ideal, but better than a segfault :)
I agree. But have you tested that adding 'os.environ["LANG"]="C"' to gui_thread will fix the problem? If so, then we should use it in 0.3.2. Pearu
Pearu Peterson schrieb:
Perhaps doing a hard LANG=C inside gui_thread is a viable option also. Not ideal, but better than a segfault :)
I agree. But have you tested that adding 'os.environ["LANG"]="C"' to gui_thread will fix the problem? If so, then we should use it in 0.3.2.
Well, it's worse. Even though I got the previous time things to work with LANG=C, it's actually kind of random. Sometimes it works, sometimes it segfaults. And setting it from python (os.environ) or from the shell doesn't really seem to matter (at least not in a useful way). Sorry if I can't be of more help on this. Tracking down a problem like this one can be hell. I guess I just worry in case it's not just something with my box, as Fedora2 is a fairly popular platform. But it would be useful to have feedback from other Fedora2 users: if it's just a misconfig on my system, then we don't have to worry about it. But if it's a problem likely to bite all Fedora2 users, then I'd say it's a bigger worry. Cheers, f
Pearu Peterson schrieb:
Hi,
I think we are ready to make the release: with the recent Scipy from CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, and a WinNT box.
If you think that there are some important bugs to be fixed, you still got about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian time), create tar-balls, etc. See
http://www.scipy.org/development/releasescipy.txt
for relevant tasks.
Please, let me know if there is any reason that I should hold on for tagging CVS tree.
Just for the record, on my Fedora core 2 box, with CVS scipy from a moment ago: planck[~/misc]> python Python 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 ... In [1]: import scipy In [2]: scipy.__version__ Out[2]: '0.3.1_287.4334' In [3]: scipy.test(level=10) !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from '...-packages/scipy/xplt/Mplot.pyc'> !! No test file 'test_lena.py' found for <module 'scipy.plt.lena' from '...te-packages/scipy/plt/lena.pyc'> ... A bunch more of these, I don't know if they matter. I can post the full list if it matters. Then, after a while: .Testing weibull_max .Testing weibull_min ..... ---------------------------------------------------------------------- Ran 986 tests in 115.357s OK So here, things are looking pretty good (except for the gui_thread thingie elsewhere in this thread). Best, f
On Wed, 6 Oct 2004, Fernando Perez wrote:
Just for the record, on my Fedora core 2 box, with CVS scipy from a moment ago:
planck[~/misc]> python Python 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
...
In [1]: import scipy
In [2]: scipy.__version__ Out[2]: '0.3.1_287.4334'
In [3]: scipy.test(level=10) !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from '...-packages/scipy/xplt/Mplot.pyc'> !! No test file 'test_lena.py' found for <module 'scipy.plt.lena' from '...te-packages/scipy/plt/lena.pyc'>
... A bunch more of these, I don't know if they matter. I can post the full list if it matters.
These messages are reminders to implement more tests to scipy. Once we will have a good coverage of scipy with tests in some nice day, we can disable these annoying messages;) Pearu
"FP" == Fernando Perez <Fernando.Perez@colorado.edu> writes:
FP> Pearu Peterson schrieb: FP> Just for the record, on my Fedora core 2 box, with CVS scipy FP> from a moment ago: [...] FP> So here, things are looking pretty good (except for the FP> gui_thread thingie elsewhere in this thread). Well, I can't devote any more time to this either. Perhaps the only thing to do would be to run python under gdb and see where it dies. gdb python (gdb) r
import gui_thread ... SEGFAULT (gdb) bt
Even if you did that there is no guarantee that we'll be able to fix it. I think we'll just have to leave it at that. gui_thread works nicely for me under both 2.4 and 2.5. cheers, prabhu
Prabhu Ramachandran wrote:
Even if you did that there is no guarantee that we'll be able to fix it. I think we'll just have to leave it at that. gui_thread works nicely for me under both 2.4 and 2.5.
Well, I'll leave the decision up to you guys. Hopefully it's something funky with my system and we won't get failures on all Fedora2 boxes out there. Without hearing from other FC2 users, it's really hard to tell right now. Fedora3 is due for release in a few weeks, and I assume it will have wx 2.5. Perhaps that will fix things. Cheers, f
SciPy CVS passes all tests on Mac OSX 10.3.5 with ATLAS. Even gui_thread with wxPython 2.5.2.7 works. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
"RK" == Robert Kern <rkern@ucsd.edu> writes:
RK> SciPy CVS passes all tests on Mac OSX 10.3.5 with ATLAS. Even RK> gui_thread with wxPython 2.5.2.7 works. Thanks, that gui_thread works on the Mac is good news. So far no reports from the Windows users. :( cheers, prabhu
On Thu, 7 Oct 2004, Prabhu Ramachandran wrote:
"RK" == Robert Kern <rkern@ucsd.edu> writes:
RK> SciPy CVS passes all tests on Mac OSX 10.3.5 with ATLAS. Even RK> gui_thread with wxPython 2.5.2.7 works.
Thanks, that gui_thread works on the Mac is good news. So far no reports from the Windows users. :(
Just tried under Windows: import gui_thread gui_thread.start() from scipy.plt import * plot([1,2]) works fine. However, running wxPython demo did not quite work. There appeared a Tip-window already before `d.Show()` but that freezed. But Python prompt was interactive. The main window of the demo program did not show up at all. Pearu
participants (6)
-
Fernando Perez -
Nils Wagner -
Pearu Peterson -
Prabhu Ramachandran -
Robert Kern -
Travis Oliphant