From oliphant at ee.byu.edu Wed Oct 1 03:03:50 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 01 Oct 2003 01:03:50 -0600 Subject: [SciPy-dev] SciPy 0.2.0 tagged in CVS Message-ID: <3F7A7C56.3000009@ee.byu.edu> Pearu, I have tagged the CVS tree as "v0_2_0" Now, I'm not sure what to do about the auto-cvs-version business as well as the release_level flag. Do, we make source-distributions and binary rpms that have those bits on them as well? I think SciPy-0.2.0.tar.gz would be a better file name than what it currently is using sdist command of distutils. What do you think? I'd like to start distributing the files and place announcements out. I tried testing this on Windows but my Windows 98 under WinLin kept bombing out during compilation (something about an illegal instruction under and MS DOS prompt). If someone can test the Windows build that would be great. -Travis From eric at enthought.com Wed Oct 1 04:23:49 2003 From: eric at enthought.com (eric jones) Date: Wed, 01 Oct 2003 02:23:49 -0600 Subject: [SciPy-dev] SciPy 0.2.0 tagged in CVS In-Reply-To: <3F7A7C56.3000009@ee.byu.edu> References: <3F7A7C56.3000009@ee.byu.edu> Message-ID: <3F7A8F15.8030408@enthought.com> Hey Travis, Very cool. I will do this tomorrow, late morning. eric Travis Oliphant wrote: > > Pearu, > > I have tagged the CVS tree as "v0_2_0" > > Now, I'm not sure what to do about the auto-cvs-version business as > well as the release_level flag. > > Do, we make source-distributions and binary rpms that have those bits > on them as well? > > I think SciPy-0.2.0.tar.gz would be a better file name than what it > currently is using sdist command of distutils. > > What do you think? > > I'd like to start distributing the files and place announcements out. > > I tried testing this on Windows but my Windows 98 under WinLin kept > bombing out during compilation (something about an illegal instruction > under and MS DOS prompt). > > If someone can test the Windows build that would be great. > > > -Travis > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From oliphant at ee.byu.edu Wed Oct 1 04:02:40 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 01 Oct 2003 02:02:40 -0600 Subject: [SciPy-dev] agg/graphics_context.py and agg/graphics_context.swig.py from agg/swig_src In-Reply-To: <3F7A8F15.8030408@enthought.com> References: <3F7A7C56.3000009@ee.byu.edu> <3F7A8F15.8030408@enthought.com> Message-ID: <3F7A8A20.1030209@ee.byu.edu> Eric, Could you explain what is going on with these .py files? It looks like distutils tries to compile everything with a *.py extension but these files won't compile because of some stuff at the front of the file. For example, the error shows up during RPM building right now as RPM build errors: File not found: /var/tmp/SciPy-buildroot/usr/lib/python2.2/site-packages/kiva/agg/graphics_context.pyc File not found: /var/tmp/SciPy-buildroot/usr/lib/python2.2/site-packages/kiva/agg/graphics_context.swig.pyc The files are probably not found due to compilation issues earlier: byte-compiling /usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.py to graphics_context.pyc File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.py", line 1 %pythoncode { ^ SyntaxError: invalid syntax byte-compiling /usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py to graphics_context.swig.pyc File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py", line 1 %pythoncode { ^ SyntaxError: invalid syntax -Travis O. From pearu at scipy.org Wed Oct 1 04:10:11 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Oct 2003 03:10:11 -0500 (CDT) Subject: [SciPy-dev] SciPy 0.2.0 tagged in CVS In-Reply-To: <3F7A7C56.3000009@ee.byu.edu> Message-ID: On Wed, 1 Oct 2003, Travis Oliphant wrote: > I have tagged the CVS tree as "v0_2_0" > > Now, I'm not sure what to do about the auto-cvs-version business as well > as the release_level flag. > > Do, we make source-distributions and binary rpms that have those bits on > them as well? > > I think SciPy-0.2.0.tar.gz would be a better file name than what it > currently is using sdist command of distutils. > > What do you think? I agree with you, SciPy-0.2.0.tar.gz looks better, also people who will package scipy will be happier. Hmm, we could start the following convention: when the minor version number is odd, then this corresponds to CVS version of scipy. If it is even, then to tar-ball version of scipy. So, scipy_version.py should contain: if micro % 2: scipy_version = '%(major)d.%(minor)d.%(micro)d_%(release_level)s'\ '_%(cvs_minor)d.%(cvs_serial)d' % (locals ()) else: scipy_version = '%(major)d.%(minor)d.%(micro)d' % (locals ()) Pearu From pearu at scipy.org Wed Oct 1 04:22:58 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Oct 2003 03:22:58 -0500 (CDT) Subject: [SciPy-dev] SciPy 0.2.0 tagged in CVS In-Reply-To: <3F7A7C56.3000009@ee.byu.edu> Message-ID: On Wed, 1 Oct 2003, Travis Oliphant wrote: > I'd like to start distributing the files and place announcements out. While doing this, could you keep a record on your commands so that a 'How to release Scipy' section could be added to Scipy developer docs. Thanks, Pearu From bhoel at web.de Wed Oct 1 16:03:41 2003 From: bhoel at web.de (=?iso-8859-1?q?Berthold_H=F6llmann?=) Date: Wed, 01 Oct 2003 22:03:41 +0200 Subject: [SciPy-dev] Failures in current CVS version Message-ID: Hello, Building the current CVS version of SciPy and running > python -c "import scipy ; scipy.test(2)" I get . ====================================================================== ERROR: check_integer (test_array_import.test_read_array) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/site-packages/scipy/io/tests/test_array_import.py", line 61, in check_integer a = stats.randint(1,20,size=(3,4)) AttributeError: 'module' object has no attribute 'randint' ====================================================================== FAIL: check_pro_ang1_cv (test_basic.test_cephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 357, in check_pro_ang1_cv assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0)) File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 332, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: DESIRED: (1.0, 0.0) ACTUAL: (0.99999999999999989, 0.0) ---------------------------------------------------------------------- on my SuSE 8.2 system with gcc 3.3 on a AMD Athlon(tm) XP 2000+. on install I found the messages: ... File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py", line 1 %pythoncode { ^ SyntaxError: invalid syntax ... File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.py", line 1 %pythoncode { ^ SyntaxError: invalid syntax ... /usr/local/lib/python2.3/site-packages/kiva/wxfast.py:149: SyntaxWarning: import * only allowed at module level def calc_points(self): ... Regards, Berthold -- bhoel at web.de / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad. From pearu at scipy.org Wed Oct 1 16:23:05 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Oct 2003 15:23:05 -0500 (CDT) Subject: [SciPy-dev] Failures in current CVS version In-Reply-To: Message-ID: On Wed, 1 Oct 2003, Berthold H?llmann wrote: > Building the current CVS version of SciPy and running > > > python -c "import scipy ; scipy.test(2)" > . > ====================================================================== > ERROR: check_integer (test_array_import.test_read_array) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/local/lib/python2.3/site-packages/scipy/io/tests/test_array_import.py", line 61, in check_integer > a = stats.randint(1,20,size=(3,4)) > AttributeError: 'module' object has no attribute 'randint' Hmm, I fixed this about 50min ago in CVS. > ====================================================================== > FAIL: check_pro_ang1_cv (test_basic.test_cephes) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/local/lib/python2.3/site-packages/scipy/special/tests/test_basic.py", line 357, in check_pro_ang1_cv > assert_equal(cephes.pro_ang1_cv(1,1,1,1,0),(1.0,0.0)) > File "/usr/local/lib/python2.3/site-packages/scipy_test/testing.py", line 332, in assert_equal > assert desired == actual, msg > AssertionError: > Items are not equal: > DESIRED: (1.0, 0.0) > ACTUAL: (0.99999999999999989, 0.0) What ATLAS version are you using? > on install I found the messages: > > ... > File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py", line 1 > %pythoncode { > ^ > SyntaxError: invalid syntax That's a known issue but has no harm on using scipy. Btw, I just run build scipy under Python 2.1 and there I get only one failure: ====================================================================== FAIL: check_arange (test_basic.test_arange) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py", line 474, in check_arange assert_array_equal(numstringa, array([3.,3.3,3.6,3.9])) File "/usr/lib/python2.1/site-packages/scipy_test/testing.py", line 390, in assert_array_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not equal: Pearu From pearu at scipy.org Wed Oct 1 16:39:45 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Oct 2003 15:39:45 -0500 (CDT) Subject: [SciPy-dev] Failures in current CVS version In-Reply-To: Message-ID: On Wed, 1 Oct 2003, Pearu Peterson wrote: > Btw, I just run build scipy under Python 2.1 and there I get only one > failure: > ====================================================================== > FAIL: check_arange (test_basic.test_arange) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py", > line 474, in check_arange > assert_array_equal(numstringa, array([3.,3.3,3.6,3.9])) > File "/usr/lib/python2.1/site-packages/scipy_test/testing.py", line 390, > in assert_array_equal > assert alltrue(ravel(reduced)),\ > AssertionError: > Arrays are not equal: I investigated this a bit futher.. The problem was in Numeric.arange that have different implementations in versions 21.0 (that I have under Python 2.1) and 23.1 (Python 2.3.1) and return a tiny bit different (but noticable to above tests) results: Python 2.1.3+ (#1, Jul 5 2003, 00:42:30) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Numeric >>> Numeric.__version__ '21.0' >>> Numeric.arange(3,4,.3)[-1] 3.8999999999999995 Python 2.3.1 (#2, Sep 27 2003, 12:44:22) [GCC 3.3.2 20030908 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> Numeric.__version__ '23.1' >>> Numeric.arange(3,4,.3)[-1] 3.8999999999999999 On the other hand, why Numeric.arange is tested under scipy.special anyway? I'd remove it from special/test_basic.py. Any objections? Pearu From bhoel at web.de Wed Oct 1 17:06:21 2003 From: bhoel at web.de (=?iso-8859-1?q?Berthold_H=F6llmann?=) Date: Wed, 01 Oct 2003 23:06:21 +0200 Subject: [SciPy-dev] Re: Failures in current CVS version In-Reply-To: (Pearu Peterson's message of "Wed, 1 Oct 2003 15:23:05 -0500 (CDT)") References: Message-ID: Pearu Peterson writes: > On Wed, 1 Oct 2003, Berthold H?llmann wrote: > ... >> Items are not equal: >> DESIRED: (1.0, 0.0) >> ACTUAL: (0.99999999999999989, 0.0) > > What ATLAS version are you using? > /usr/local/bin/python -c "import atlas_version" ATLAS version 3.4.1 >> on install I found the messages: >> >> ... >> File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py", line 1 >> %pythoncode { >> ^ >> SyntaxError: invalid syntax > > That's a known issue but has no harm on using scipy. But when you try to upgrade Python with the same minor version number (e.g. 2.3->2.3.1) the installation processes fails because it tries to compile all .py files and the it fails on these. The problem is hard to find because the compilation process does not abort immidiately but only after all pending file are handeled, so you have to scroll through lots of output > ... Regards, Berthold -- bhoel at web.de / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad. From oliphant at ee.byu.edu Wed Oct 1 17:17:00 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Wed, 01 Oct 2003 15:17:00 -0600 Subject: [SciPy-dev] Failures in current CVS version In-Reply-To: References: Message-ID: <3F7B444C.2020800@ee.byu.edu> Pearu Peterson wrote: > > On Wed, 1 Oct 2003, Pearu Peterson wrote: > > >>Btw, I just run build scipy under Python 2.1 and there I get only one >>failure: >>====================================================================== >>FAIL: check_arange (test_basic.test_arange) >>---------------------------------------------------------------------- >>Traceback (most recent call last): >> File >>"/usr/local/lib/python2.1/site-packages/scipy/special/tests/test_basic.py", >>line 474, in check_arange >> assert_array_equal(numstringa, array([3.,3.3,3.6,3.9])) >> File "/usr/lib/python2.1/site-packages/scipy_test/testing.py", line 390, >>in assert_array_equal >> assert alltrue(ravel(reduced)),\ >>AssertionError: >>Arrays are not equal: > > > I investigated this a bit futher.. The problem was in Numeric.arange that > have different implementations in versions 21.0 (that I have under Python > 2.1) and 23.1 (Python 2.3.1) and return a tiny bit different (but > noticable to above tests) results: Stragely enough, I saw this error too and couldn't account for it because the implementation of arange hasn't changed between 21.0 and 23.1 --- it shows that you shouldn't count on arange ending on exactly the float you expect if you are relying on float equality e,g, 1/10.0 is not necessarily the same as 0.1 down to the last bit. -Travis From pearu at scipy.org Thu Oct 2 00:51:46 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Oct 2003 23:51:46 -0500 (CDT) Subject: [SciPy-dev] Failures in current CVS version In-Reply-To: <3F7B444C.2020800@ee.byu.edu> Message-ID: On Wed, 1 Oct 2003, Travis E. Oliphant wrote: > > I investigated this a bit futher.. The problem was in Numeric.arange that > > have different implementations in versions 21.0 (that I have under Python > > 2.1) and 23.1 (Python 2.3.1) and return a tiny bit different (but > > noticable to above tests) results: > > Stragely enough, I saw this error too and couldn't account for it > because the implementation of arange hasn't changed between 21.0 and > 23.1 Numeric 21.0 was released 12Feb2002 but the arange implementation changed between multiarraymodule.c revisions 1.28 and 1.29,1.30 dated around 25Mar2002. See http://cvs.sourceforge.net/viewcvs.py/numpy/Numerical/Src/multiarraymodule.c That was Travis O. who commited these changes;-) > --- it shows that you shouldn't count on arange ending on exactly > the float you expect if you are relying on float equality I think the new arange implementation fixed this, or at least, as well as possible. > e,g, 1/10.0 is not necessarily the same as 0.1 down to the last bit. This is not completely true, 0.1 and 1/10.0 happen to be exactly the same floats:-) >>> '%.24e' % (1/10.0) '1.000000000000000055511151e-01' >>> '%.24e' % (0.1) '1.000000000000000055511151e-01' but in general I agree that different ways to compute a floating point number may have a bit different results. Pearu From eric at enthought.com Thu Oct 2 02:27:53 2003 From: eric at enthought.com (eric jones) Date: Thu, 02 Oct 2003 00:27:53 -0600 Subject: [SciPy-dev] test results on windows Message-ID: <3F7BC569.7070406@enthought.com> Hey guys, I've had a chance to test the CVS scipy on windows this evening. I'm using Python 2.3 - Enthought Edition and mingw32 with gcc 3.2. I did have to make a few small changes to CVS to get things to build here (checked in). I also fixed the "%pythoncode" problem in the build process that has been reported. I currently get 8 errors. It sounds like I'm seeing more failures than on the Linux side of things, although I've seen a few of these role by in other peoples posts. I haven't looked to deeply into the nature of them yet. eric >>> scipy.test() ====================================================================== FAIL: check_nrdtrimn (test_basic.test_cephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 3 17, in check_nrdtrimn assert_equal(cephes.nrdtrimn(0.5,1,1),1.0) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 332, in asser t_equal assert desired == actual, msg AssertionError: Items are not equal: DESIRED: 1.0 ACTUAL: 0.99999999999999989 ====================================================================== FAIL: check_bei_zeros (test_basic.test_bei_zeros) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 5 53, in check_bei_zeros -7.940178689168587]),11) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 405, in asser t_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ====================================================================== FAIL: check_chebyc (test_basic.test_chebyc) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 6 58, in check_chebyc assert_array_almost_equal(C4.c,[1,0,-4,0,2],13) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 405, in asser t_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ====================================================================== FAIL: check_fresnel_zeros (test_basic.test_fresnel_zeros) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 9 21, in check_fresnel_zeros 4.4742+0.1877j]),3) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 405, in asser t_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ====================================================================== FAIL: check_fresnels_zeros (test_basic.test_fresnel_zeros) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 9 41, in check_fresnels_zeros assert_array_almost_equal(frs,szo,12) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 405, in asser t_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ====================================================================== FAIL: check_round (test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 1 770, in check_round assert_array_equal(rnd,rndrl) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 390, in asser t_array_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not equal: ====================================================================== FAIL: check_y0_zeros (test_basic.test_y0_zeros) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 2 002, in check_y0_zeros assert_array_almost_equal(abs(yv(0.0,all)),0.0,11) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 405, in asser t_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ====================================================================== FAIL: check_y1p_zeros (test_basic.test_y1p_zeros) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy\special\tests\test_basic.py", line 2 016, in check_y1p_zeros assert_array_almost_equal(y1p,(array([ 0.5768+0.904j]), array([-0.7635+0.589 2j])),3) File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 405, in asser t_array_almost_equal assert alltrue(ravel(reduced)),\ AssertionError: Arrays are not almost equal: ---------------------------------------------------------------------- Ran 967 tests in 4.476s FAILED (failures=8) From mkuemmel at eso.org Thu Oct 2 03:32:35 2003 From: mkuemmel at eso.org (Martin Kuemmel) Date: Thu, 2 Oct 2003 09:32:35 +0200 (MEST) Subject: [SciPy-dev] Saving plots Message-ID: Hi everybody! I am working since a month now with python, and I have to say that I am impressed about its capabilities. Now I encountered a problem, and hope there will be a solution in scientific python. I have to make plots in a noninteractive way, and I have to store them in a html-compatible format like gif, or jpeg, or png or whatsever. The help of the plotting package says that plots can be saved, but the format is not specified. So, is the a way to get gif's, jpg'or similar?? Yours, Martin From j_r_fonseca at yahoo.co.uk Thu Oct 2 20:51:05 2003 From: j_r_fonseca at yahoo.co.uk (=?iso-8859-15?Q?Jos=E9?= Fonseca) Date: Fri, 3 Oct 2003 01:51:05 +0100 Subject: [SciPy-dev] Updated Debian packages of scipy and f2py In-Reply-To: References: <20030714225737.GB1869@prometeu> Message-ID: <20031003005105.GA17513@mefriss1.swan.ac.uk> I've made new debian packages of scipy and f2py that follow the Pearu Peterson's packaging guidelines . I.e., they're made from CVS and they can all hapilly cohabitate in your debian machine. Thanks to Pearu for such detailed document. Scipy tests went fine but I didn't do any testing on chaco yet. Please report issues (that you think are caused by the packaging) directly to me. The next step in the packaging will be making them debian policy complaint, in order to have them in debian proper. Regards, Jose Fonseca On Thu, Aug 07, 2003 at 11:47:32AM +0300, Pearu Peterson wrote: > > On Mon, 14 Jul 2003, [iso-8859-15] Jos? Fonseca wrote: > > > I've make Debian packages of scipy and f2py. They are available from my > > apt-get repository at: > > > > http://jrfonseca.dyndns.org/debian/ > > > > I referred to Joe Reinhardt's packages http://people.debian.org/~jmr/ > > but have done these packages from scratch. These come for all python > > versions in debian unstable (2.1, 2.2 and 2.3). > > Great! > > > I've run the standard tests successfully but I'd appreciate that > > problems with these packages to be reported to me [privately] as I'd > > like to have these on Debian proper at some time. > > > > One tricky issue I'd like to address with the scipy and f2py maintainers > > is the the scipy_distutils. Both scipy and f2py attempt to install to > > /usr/lib/python*/site-packages/scipy_distutils and at least on Debian > > this is not admissible so the packages conflict with each other and are > > mutually exclusive. This is particularly even more annoying for me, > > since for building scipy f2py is needed, so I need to install and > > uninstall them as a maniac. Is there any solution that allow both these > > packages to happily co-exist in a tree without overlapping? > > This is a long lasting issue and several solutions have been proposed, see > scipy mailing archives. > > The current solution for package installation of scipy,f2py,etc > would be the following: > [...] > > Let us know if such an approach is acceptable for debianizing scipy,f2py > then we can consider simplifying steps 1-3). > Other suggestions are welcome. From pearu at scipy.org Sun Oct 5 03:59:37 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sun, 5 Oct 2003 02:59:37 -0500 (CDT) Subject: [SciPy-dev] Scipy roundup anonymnous user behaves strangely Message-ID: Hi, During last weeks I have resolved several roundup issues and set them "resolved". However, I have noticed that some anonymous user is setting them "chatting" again and without adding any comments why it is doing so. So, would it be possible to discard those roundup issue editing attempts that leave "Change note" empty? Thanks, Pearu From joe at enthought.com Sun Oct 5 05:00:18 2003 From: joe at enthought.com (Joe Cooper) Date: Sun, 05 Oct 2003 04:00:18 -0500 Subject: [SciPy-dev] Re: Scipy roundup anonymnous user behaves strangely In-Reply-To: References: Message-ID: <3F7FDDA2.8020007@enthought.com> Hi Pearu, Most things are possible...Some are easier than others. I'll look into it. It has been decreed (by Eric, I seem to recall) in the past that anonymous reports are welcome, so we can't turn those off, but it looks like it is next-to-trivial to enforce filling in certain fields. Anyone object to forcing the user to fill in the change note every time an item is changed? Note that this will require a note when you close the issue, or otherwise change status. If everyone is already making a note when changing status, then it won't even be a noticeable change except for those anonymous lurkers who like to ruin your good times. Pearu Peterson wrote: > Hi, > > During last weeks I have resolved several roundup issues and set them > "resolved". However, I have noticed that some anonymous user is setting > them "chatting" again and without adding any comments why it is doing so. > > So, would it be possible to discard those roundup issue editing attempts > that leave "Change note" empty? > > Thanks, > Pearu From pearu at scipy.org Mon Oct 6 10:34:33 2003 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 6 Oct 2003 09:34:33 -0500 (CDT) Subject: [SciPy-dev] gui_thread and chaco under Linux Message-ID: Hi, I have struggling with getting chaco to work under Linux. Currently the following happens: >>> import gui_thread >>> gui_thread.start() >>> >>> from chaco.wxplt import * Xlib: unexpected async reply (sequence 0x68)! After some research I found that the above failure occurs because wx functions are not called from the same thread that imported wxPython, first this happens in traits/wxtrait_sheet.py. When importing chaco.wxplt from the same thread that imported wxPython (by inserting `import chaco.wxplt` just after wxPython import in gui_thread/gui_thread_guts.py), then we have this: >>> import gui_thread >>> gui_thread.start() >>> >>> from chaco.wxplt import * >>> but now trying to make a simple plot fails with python hang: >>> plot([1,2]) Xlib: unexpected async reply (sequence 0x7a)! Again, the reason for this failure is that the above plot function was called from the main but wrong thread. For example, inserting also `chaco.wxplt.plot([1,2])` to gui_thread/gui_thread_guts.py will result a working wx plot window as well as working python prompt. This example worked because the plot function was called from the right (secondary) thread. While having chaco imports in gui_thread/gui_thread_guts.py can be acceptable but I have failed to figure out how to force calling plot function from the prompt (that runs under the main thread) so that it will be executed in the second thread (that imported wxPython and chaco). Somehow I am getting a feeling that the gui_thread concept is just not working under Linux (or any Unixes that run under X) because X is not thread safe and therefore there is a condition that wxPython must be imported and used strictly within the same thread. Please, correct me if I am wrong on this! The following solutions come into my head: 1) Introduce a wrapper around wxPython module that transforms all accesses to wxPython data from the main thread to the secondary thread (that imports wxPython). I think this can be achieved without touching chaco at all through similar hooks that are used in ppimport. 2) Import wxPython from the main thread and create an interactive prompt thread from wxPython app. This would require implementing a prompt very similar to PyCrust but that would have I/O from the terminal. Both solutions would require a lot of work and I would hope that there would be a simpler solution. For example, getting gui_thread to work correctly under X. Other thoughts? Regards, Pearu From fperez at colorado.edu Mon Oct 6 12:09:18 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 06 Oct 2003 10:09:18 -0600 Subject: [SciPy-dev] Re: Scipy roundup anonymnous user behaves strangely In-Reply-To: <3F7FDDA2.8020007@enthought.com> References: <3F7FDDA2.8020007@enthought.com> Message-ID: <3F8193AE.4050901@colorado.edu> Joe Cooper wrote: > Hi Pearu, > > Most things are possible...Some are easier than others. I'll look into > it. It has been decreed (by Eric, I seem to recall) in the past that > anonymous reports are welcome, so we can't turn those off, but it looks > like it is next-to-trivial to enforce filling in certain fields. > > Anyone object to forcing the user to fill in the change note every time > an item is changed? Note that this will require a note when you close > the issue, or otherwise change status. If everyone is already making a > note when changing status, then it won't even be a noticeable change > except for those anonymous lurkers who like to ruin your good times. Seems like a good idea to me. People doing 'real' work probably won't even notice (since they already comment what they do), and it will prevent silly changes like what Pearu saw by some random idiot out there. Cheers, f From pearu at scipy.org Mon Oct 6 16:20:40 2003 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 6 Oct 2003 15:20:40 -0500 (CDT) Subject: [SciPy-dev] gui_thread and chaco under Linux In-Reply-To: Message-ID: Hi, Ok, now I have made some progress with calling chaco from Python prompt under Linux. What follows is work-in-progress but shows that the idea works: from parallel_exec import ParallelExec # the code of parallel_exec is given below pexec = ParallelExec() pexec("""\ import wxPython.wx from chaco.wxplt import * class MyApp(wxPython.wx.wxApp): def OnInit(self): return True def show(): MyApp().MainLoop() """) plot([1,2,4]);pexec('show()') # shows a graph of [1,2,4] # you can enter Python commands from the prompt plot([1,2,5,4]);pexec('show()') # replaces previous graph with [1,2,5,4] Note that show() must be called using pexec (that executes command in the so-called parallel thread) otherwise Python prompt hangs until a plot window is closed. A way how to open multiple plot windows must be figured out. Ideas are welcome. Pearu #-------------- parallel_exec.py ----------- # Author: Pearu Peteson # Created: Oct 6, 2003 import sys import threading import Queue import traceback class ParallelExec(threading.Thread): """ Create a thread of parallel execution. """ def __init__(self,frame_level=0): self.__queue = Queue.Queue(0) self.__frame = sys._getframe(frame_level+1) threading.Thread.__init__(self) self.setDaemon(1) self.start() def __call__(self,code): self.__queue.put(code) def shutdown(self): self.__queue.put(None) def run(self): while 1: code = self.__queue.get() if code is None: break frame = self.__frame try: exec (code, frame.f_globals,frame.f_locals) except Exception: traceback.print_exc() #------------- EOF parallel_exec.py ----------- From prabhu at aero.iitm.ernet.in Tue Oct 7 10:25:44 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Tue, 7 Oct 2003 19:55:44 +0530 Subject: [SciPy-dev] gui_thread and chaco under Linux In-Reply-To: References: Message-ID: <16258.52456.915532.349943@monster.linux.in> Hi Pearu, >>>>> "PP" == Pearu Peterson writes: PP> I have struggling with getting chaco to work under Linux. PP> Currently the following happens: >>>> import gui_thread gui_thread.start() PP> >>>> >>>> from chaco.wxplt import * PP> Xlib: unexpected async reply (sequence 0x68)! PP> After some research I found that the above failure occurs PP> because wx functions are not called from the same thread that PP> imported wxPython, first this happens in PP> traits/wxtrait_sheet.py. [snip] PP> Somehow I am getting a feeling that the gui_thread concept is PP> just not working under Linux (or any Unixes that run under X) PP> because X is not thread safe and therefore there is a PP> condition that wxPython must be imported and used strictly PP> within the same thread. Please, correct me if I am wrong on PP> this! Well, gui_thread does work under Linux. For example, this works for me: In [1]: import gui_thread In [2]: gui_thread.start() >>> In [3]: import scipy.plt as plt In [4]: p = plt.plot([1,4,9]) I think its just that wxplt is not using gui_thread and is currently pure wxPython code. As you have rightly discovered the way to chaco-on-interpreter-heaven is to call all wxPython related functions from another thread and this thread must be the first to import wxPython. To use gui_thread you need to 'register' a class with it. gui_thread then returns a massaged class wraps around the actual class that the actual functions are called in the right thread. It also tries to handle attribute access safely. However, this is from memory having hacked on gui_thread about two years ago and a few things might have changed. Anyway, the way to register a class with gui_thread is to do the following: wrapped_class = gui_thread.register(some_wx_python_class) Then you create wrapped_class instances as you would create some_wx_python_class and it should work (in theory). I can't test this because I cannot run chaco anymore. kiva no longer builds under gcc 2.95.4. :( Admittedly, the gui_thread approach is a hack and has limitations but it used to work pretty OK. Eric was talking about a better approach that IIRC is similar to your approach (1). As you notice its a non-trivial job and AFAIK no one has yet had a stab at it. cheers, prabhu From derek at physast.uga.edu Tue Oct 7 19:52:41 2003 From: derek at physast.uga.edu (Derek Homeier) Date: Tue, 7 Oct 2003 19:52:41 -0400 Subject: [SciPy-dev] Saving plots In-Reply-To: Message-ID: <56880B9C-F921-11D7-ADF3-003065EF8FD0@physast.uga.edu> On Thursday, October 2, 2003, at 03:32 AM, Martin Kuemmel wrote: > I am working since a month now with python, > and I have to say that I am impressed about its > capabilities. Now I encountered a problem, and > hope there will be a solution in scientific > python. I have to make plots in a noninteractive > way, and I have to store them in a html-compatible > format like gif, or jpeg, or png or whatsever. > The help of the plotting package says that > plots can be saved, but the format is not > specified. So, is the a way to get gif's, jpg'or > similar?? > I haven't worked with scipy's gnuplot module for some time, and have not yet switched to employ chaco for major work, but since no one else has responded yet, maybe I can help you out. There are a number of different interfaces to use gnuplot from python, and gnuplot, as you might know, has numerous drivers to plot to at least 20 output formats. I am currently using the python's Gnuplot module, which is independent of scipy. That supports basically output to various terminal drivers (x11 etc.) and output to postscript with the "hardcopy" function. Unfortunately I am not aware of an easy way to directly hardcopy to other formats. But I think scipy's gplt package might do this, if you check out the plotting documentation on the scipy site (as I said, I haven't used this in a while). Another way would be to first create postscript output from Gnuplot or gplt and then convert it externally, e.g. with the Imagemagick package, which is readily scriptable and available for most Unix systems, just do "convert plot.ps plot.png". This actually has the advantage of getting the much superior layout that gnuplot provides with the postscript driver compared to other output formats, e.g. Greek letters and other symbols, better axis labelling etc. HTH, Derek From pearu at scipy.org Wed Oct 8 07:56:07 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 8 Oct 2003 06:56:07 -0500 (CDT) Subject: [SciPy-dev] gui_thread and chaco under Linux In-Reply-To: <16258.52456.915532.349943@monster.linux.in> Message-ID: Hi Prabhu, On Tue, 7 Oct 2003, Prabhu Ramachandran wrote: > Well, gui_thread does work under Linux. For example, this works for > me: > > In [1]: import gui_thread > In [2]: gui_thread.start() > > >>> > In [3]: import scipy.plt as plt > In [4]: p = plt.plot([1,4,9]) > > I think its just that wxplt is not using gui_thread and is currently > pure wxPython code. Thank you for the clarification! I must admit that at first I really didn't understand the code in gui_thread (now I do, after re-implementing it almost from a scratch;-). > As you have rightly discovered the way to > chaco-on-interpreter-heaven is to call all wxPython related functions > from another thread and this thread must be the first to import > wxPython. To use gui_thread you need to 'register' a class with it. > gui_thread then returns a massaged class wraps around the actual class > that the actual functions are called in the right thread. It also > tries to handle attribute access safely. However, this is from memory > having hacked on gui_thread about two years ago and a few things might > have changed. Anyway, the way to register a class with gui_thread is > to do the following: > > wrapped_class = gui_thread.register(some_wx_python_class) > > Then you create wrapped_class instances as you would create > some_wx_python_class and it should work (in theory). This will not work for chaco anymore because chaco executes wxPython functions during chaco.wxplt import. > I can't test this because I cannot run chaco anymore. kiva no longer > builds under gcc 2.95.4. :( Yes. In fact, this triggered me to upgrade gcc on my debian system. It turned out to be quite painless, now I have gcc-2.95 gcc-3.2 gcc-3.3 nicely co-existing on my system. You could try the same ^K ;-) > Admittedly, the gui_thread approach is a hack and has limitations but > it used to work pretty OK. Eric was talking about a better approach > that IIRC is similar to your approach (1). As you notice its a > non-trivial job and AFAIK no one has yet had a stab at it. I took this challenge and here are intermediate results: >>> from parallel_exec import ParallelExec >>> pexec=ParallelExec() # create wxPython thread >>> pexec('import wxPython.wx') >>> pexec('from wrap_wx import ParallelExec_wxApp;app=ParallelExec_wxApp()') >>> pexec('app.run()') # Now calling app will execute commands in wxPython thread: >>> app('from chaco.wxplt import *') >>> app('plot([1,2])') # creates a plot [1,2] >>> app('figure()') # opens new empty window >>> app('plot([5,2])') # creates a plot [5,2] in new window >>> app.shutdown() that is, I can already use chaco from my Linux prompt! And I have made no changes to chaco for that. The next step is to make >>> from chaco.wxplt import * >>> plot([1,2]) safe... Pearu From prabhu at aero.iitm.ernet.in Wed Oct 8 13:49:05 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 8 Oct 2003 23:19:05 +0530 Subject: [SciPy-dev] gui_thread and chaco under Linux In-Reply-To: References: <16258.52456.915532.349943@monster.linux.in> Message-ID: <16260.19985.719444.297190@monster.linux.in> >>>>> "PP" == Pearu Peterson writes: [snip] >> wrapped_class = gui_thread.register(some_wx_python_class) >> >> Then you create wrapped_class instances as you would create >> some_wx_python_class and it should work (in theory). PP> This will not work for chaco anymore because chaco executes PP> wxPython functions during chaco.wxplt import. OK. :( >> I can't test this because I cannot run chaco anymore. kiva no >> longer builds under gcc 2.95.4. :( PP> Yes. In fact, this triggered me to upgrade gcc on my debian PP> system. It turned out to be quite painless, now I have PP> gcc-2.95 gcc-3.2 gcc-3.3 PP> nicely co-existing on my system. You could try the same ^K PP> ;-) Well, I'm running Woody (stable) so all I have is gcc-3.0 which I've heard has bugs. testing and unstable are too unstable for me at the moment. >> Admittedly, the gui_thread approach is a hack and has >> limitations but it used to work pretty OK. Eric was talking >> about a better approach that IIRC is similar to your approach >> (1). As you notice its a non-trivial job and AFAIK no one has >> yet had a stab at it. PP> I took this challenge and here are intermediate results: >>>> from parallel_exec import ParallelExec pexec=ParallelExec() # [snip] >>>> app.shutdown() PP> that is, I can already use chaco from my Linux prompt! And I PP> have made no changes to chaco for that. The next step is to PP> make Nice. This looks to be similar to the code written for Gtk by someone. IIRC it was available on ASPN. >>>> from chaco.wxplt import * plot([1,2]) PP> safe... I'd think you'd need to modify or wrap around wxPython itself to get this to work that transparently or you'd need to do something similar to gui_thread. Actually it looks like this could be easy to hack into wxPython. Most of wxPython's work is done inside of a call to apply. So if we quietly replace apply inside wxPython's namespace with a massaged apply that calls the real apply in the right thread, I think we should be all set. This is a hack but if its this easy I guess Robin could be convinced to add cleaner support for it. orig_apply = apply def apply(o, *args, **kwargs): pexec('orig_apply(o, *args, **kwargs)') I don't know if this will work with pexec the way its implemented currently but I think you get what I'm trying to say here. cheers, prabhu From pearu at scipy.org Thu Oct 9 05:10:31 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 9 Oct 2003 04:10:31 -0500 (CDT) Subject: [SciPy-dev] gui_thread and chaco under Linux In-Reply-To: <16260.19985.719444.297190@monster.linux.in> Message-ID: Hi, ------------------------------------------------------------------ Those who have not followed this thread or are not interested in details, can skip until the end of this message where instructions for how to use chaco.wxplt from Python prompt under Linux (also Win32 should work but I haven't tested) are given. ------------------------------------------------------------------ On Wed, 8 Oct 2003, Prabhu Ramachandran wrote: > >>>>> "PP" == Pearu Peterson writes: > PP> I took this challenge and here are intermediate results: > > >>>> from parallel_exec import ParallelExec pexec=ParallelExec() # > [snip] > >>>> app.shutdown() > > PP> that is, I can already use chaco from my Linux prompt! And I > PP> have made no changes to chaco for that. The next step is to > PP> make > > Nice. This looks to be similar to the code written for Gtk by > someone. IIRC it was available on ASPN. You probably mean http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109 that indeed has very similar basic idea. The main difference with ParallelExec is that ParallelExec implementation is more generic and can be used also in non-GUI applications. > >>>> from chaco.wxplt import * plot([1,2]) > > PP> safe... > > I'd think you'd need to modify or wrap around wxPython itself to get > this to work that transparently or you'd need to do something similar > to gui_thread. I have tried both ways, well, more or less. And they have different pros and cons, but the main difficulty in both cases is that both are too complex to be absolutely robust. IMHO, if the gui_thread module is not robust then we'll struggle with Xlib: unexpected async reply type of crashes forever... > Actually it looks like this could be easy to hack into wxPython. Most > of wxPython's work is done inside of a call to apply. So if we > quietly replace apply inside wxPython's namespace with a massaged > apply that calls the real apply in the right thread, I think we should > be all set. This is a hack but if its this easy I guess Robin could > be convinced to add cleaner support for it. > > orig_apply = apply > def apply(o, *args, **kwargs): > pexec('orig_apply(o, *args, **kwargs)') > > > I don't know if this will work with pexec the way its implemented > currently but I think you get what I'm trying to say here. Yes, I think it is a very good idea to try out. If there are not calls to wxPython functions during wxPython import then this should work just fine. And using ParallelExec here should give no problems. I'll check it.. In the mean time, scipy Linux users can already use chaco.wxplt functions from Python prompt (just update scipy from CVS) as follows: >>> import gui_thread >>> execfile(gui_thread.__path__[0]+'/chaco_wxplt.py') >>> f1=figure() >>> p1=plot([1,2]) >>> f2=figure() >>> p2=plot([3,4]) Pearu From prabhu at aero.iitm.ernet.in Thu Oct 9 10:02:51 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Thu, 9 Oct 2003 19:32:51 +0530 Subject: [SciPy-dev] gui_thread and chaco under Linux In-Reply-To: References: <16260.19985.719444.297190@monster.linux.in> Message-ID: <16261.27275.924686.578196@monster.linux.in> Hi, >>>>> "PP" == Pearu Peterson writes: >> Nice. This looks to be similar to the code written for Gtk by >> someone. IIRC it was available on ASPN. PP> You probably mean PP> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109 Yes thats it. PP> that indeed has very similar basic idea. The main difference PP> with ParallelExec is that ParallelExec implementation is more PP> generic and can be used also in non-GUI applications. Yeah. The Gtk version also provides an interpreter etc. which is not what we want here but as you say the basic idea is similar. >> orig_apply = apply def apply(o, *args, **kwargs): >> pexec('orig_apply(o, *args, **kwargs)') >> >> I don't know if this will work with pexec the way its >> implemented currently but I think you get what I'm trying to >> say here. PP> Yes, I think it is a very good idea to try out. If there are PP> not calls to wxPython functions during wxPython import then PP> this should work just fine. And using ParallelExec here PP> should give no problems. I'll check it.. Looking forward to seeing your results! Good luck! cheers, prabhu From pearu at scipy.org Thu Oct 9 21:39:05 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 9 Oct 2003 20:39:05 -0500 (CDT) Subject: [SciPy-dev] New implementation for gui_thread In-Reply-To: <16261.27275.924686.578196@monster.linux.in> Message-ID: Hi, I have succesfully finished implementing new hooks for importing wxPython to its own thread. The working idea is that all wxPython extension modules (that contain only low-level functions) are transparently replaced with wrappers that direct wx execution to a different thread so that Python prompt will be available for interactive work even when a wxPython application is running. As an example, here follows how to use chaco from Python prompt: # update scipy from CVS >>> from gui_thread import wxPython_thread; wxPython_thread() >>> from chaco.wxplt import * >>> f=figure() >>> p=plot([1,2]) >>> close() etc. Also scipy.plt works: >>> from gui_thread import wxPython_thread; wxPython_thread() >>> from scipy.plt import * >>> f=figure() >>> p=plot([1,2]) etc. If there will be no serious problems then I'll replace wxPython_thread function with start so that the above examples become: >>> import gui_thread; gui_thread.start() >>> ... It would be great if someone could test the above also on Windows. Enjoy, Pearu From prabhu at aero.iitm.ernet.in Fri Oct 10 02:58:06 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Fri, 10 Oct 2003 12:28:06 +0530 Subject: [SciPy-dev] New implementation for gui_thread In-Reply-To: References: <16261.27275.924686.578196@monster.linux.in> Message-ID: <16262.22654.373840.444208@monster.linux.in> Hi, >>>>> "PP" == Pearu Peterson writes: PP> I have succesfully finished implementing new hooks for PP> importing wxPython to its own thread. The working idea is that PP> all wxPython extension modules (that contain only low-level PP> functions) are transparently replaced with wrappers that PP> direct wx execution to a different thread so that Python PP> prompt will be available for interactive work even when a PP> wxPython application is running. Nice! I briefly looked at the code and from what I can see you transparently wrap the builtin functions used inside all the wxPython functions. This means apply is wrapped and therefore everything works correctly? I've managed to work around the kiva_agg build problem by building the offending code with gcc-3.0. How does one specify to python setup.py to choose gcc-3.0 instead of vanilla gcc? Setting the environment variable CC does not appear to help. Anyway, the new gui_thread works really nicely. I like the fact that you don't have to wait before you run the next statement since you wait while importing wxPython. However, the new gui_thread appears to have trouble when quitting the interpreter: In [1]: from gui_thread import wxPython_thread; wxPython_thread() In [2]: from chaco.wxplt import * In [3]: p=plot([1,2]) In [4]: close() In [5]: Do you really want to exit ([y]/n)? Exception in thread Thread-221: Traceback (most recent call last): File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap self.run() File "/usr/local/stow/scipy/lib/python2.2/site-packages/gui_thread/wxBackgroundApp.py", line 65, in run exec self.cmd in self.globs,self.locs File "", line 1, in ? AttributeError: wxBackgroundApp instance has no attribute 'event_catcher' cheers, prabhu From pearu at scipy.org Fri Oct 10 04:18:26 2003 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 10 Oct 2003 03:18:26 -0500 (CDT) Subject: [SciPy-dev] New implementation for gui_thread In-Reply-To: <16262.22654.373840.444208@monster.linux.in> Message-ID: Hi, On Fri, 10 Oct 2003, Prabhu Ramachandran wrote: > >>>>> "PP" == Pearu Peterson writes: > > PP> I have succesfully finished implementing new hooks for > PP> importing wxPython to its own thread. The working idea is that > PP> all wxPython extension modules (that contain only low-level > PP> functions) are transparently replaced with wrappers that > PP> direct wx execution to a different thread so that Python > PP> prompt will be available for interactive work even when a > PP> wxPython application is running. > > Nice! I briefly looked at the code and from what I can see you > transparently wrap the builtin functions used inside all the wxPython > functions. This means apply is wrapped and therefore everything works > correctly? Note that apply is not depreciated in Python and, I guess, because of this there were no apply usages in my installation of wxPython (Debian, unstable, Python 2.3). So, your idea simply replacing apply function could not work, at least literally. But your observations what wxPython_thread does are correct. Wrapping built-in functions are *much* simpler and robust than wrapping Python classes (as it was done in old gui_thread) with all its methods and implementation changes between various versions of Python etc. At first I worried that there will be a performance hit for another function layer between Python and wxWindows but it turned out to be not too bad. Btw, a nice way to see how all these wx built-in functions are called is to add the following line print 'In %(func_name)s [THREAD=',get_ident(),']' just after def %(func_name)s(*args,**kws): in wxPython_thread.py ;-) > I've managed to work around the kiva_agg build problem by building the > offending code with gcc-3.0. How does one specify to python setup.py > to choose gcc-3.0 instead of vanilla gcc? Setting the environment > variable CC does not appear to help. I am using debian colorgcc hooks to achieve switching compilers: I have the following files in my home directory: # .colorgccrc-2.95.4 g++: /usr/bin/g++-2.95 gcc: /usr/bin/gcc-2.95 c++: /usr/bin/g++-2.95 cc: /usr/bin/gcc-2.95 # ..colorgccrc-3.2 g++: /usr/bin/g++-3.2 gcc: /usr/bin/gcc-3.2 c++: /usr/bin/g++-3.2 cc: /usr/bin/gcc-3.2 # .colorgccrc-3.3 g++: /usr/bin/g++-3.3 gcc: /usr/bin/gcc-3.3 c++: /usr/bin/g++-3.3 cc: /usr/bin/gcc-3.3 and a link .colorgccrc to one of these files. Switching a compiler means just changing this link. > Anyway, the new gui_thread works really nicely. I like the fact that > you don't have to wait before you run the next statement since you > wait while importing wxPython. Glad to here. I always considered this waiting part as a TODO item in gui_thread.. > However, the new gui_thread appears to have trouble when quitting the > interpreter: > In [1]: from gui_thread import wxPython_thread; wxPython_thread() > In [2]: from chaco.wxplt import * > In [3]: p=plot([1,2]) > In [4]: close() > In [5]: > Do you really want to exit ([y]/n)? > Exception in thread Thread-221: > Traceback (most recent call last): > File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap > self.run() > File "/usr/local/stow/scipy/lib/python2.2/site-packages/gui_thread/wxBackgroundApp.py", line 65, in run > exec self.cmd in self.globs,self.locs > File "", line 1, in ? > AttributeError: wxBackgroundApp instance has no attribute 'event_catcher' This does not happen here with Python-2.3 (also tried ipython), so it could be due to Python-2.2.. I hope you can live with this until I get a moment to rebuild scipy under Python-2.2 (and 2.1) and fix it. Regards, Pearu From prabhu at aero.iitm.ernet.in Fri Oct 10 11:17:07 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Fri, 10 Oct 2003 20:47:07 +0530 Subject: [SciPy-dev] New implementation for gui_thread In-Reply-To: References: <16262.22654.373840.444208@monster.linux.in> Message-ID: <16262.52595.49814.387515@monster.linux.in> >>>>> "PP" == Pearu Peterson writes: [...] PP> I am using debian colorgcc hooks to achieve switching PP> compilers: I have the following files in my home directory: PP> # .colorgccrc-2.95.4 PP> g++: /usr/bin/g++-2.95 gcc: /usr/bin/gcc-2.95 c++: PP> /usr/bin/g++-2.95 cc: /usr/bin/gcc-2.95 [...] PP> and a link .colorgccrc to one of these files. Switching a PP> compiler means just changing this link. Thanks for the tip! [...] PP> This does not happen here with Python-2.3 (also tried PP> ipython), so it could be due to Python-2.2.. I hope you can PP> live with this until I get a moment to rebuild scipy under PP> Python-2.2 (and 2.1) and fix it. Sure, that would be great. I am in absolutely no big hurry. I just wanted to see how it all worked since I did spend quite a bit of time on gui_thread a couple of years back and was interested in the new solution. I think a similar solution should work nicely for pyGTK also since both pyGTK and wxPythonuse SWIG to generate the wrappers. cheers, prabhu From nwagner at mecha.uni-stuttgart.de Tue Oct 14 05:28:28 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 14 Oct 2003 11:28:28 +0200 Subject: [SciPy-dev] io.loadmat Message-ID: <3F8BC1BC.85CED77F@mecha.uni-stuttgart.de> Dear experts, I need some advice concerning loadmat loadmat -- read a MATLAB (version <= 4) style mat file loadmat(name, dict=None, appendmat=1) Load the MATLAB mat file saved in level 1.0 format. If name is a full path name load it in. Otherwise search for the file on the sys.path list and load the first one found (the current directory is searched first). Only Level 1.0 MAT files are supported so far. Inputs: name -- name of the mat file (don't need .mat extension) dict -- the dictionary to insert into. If none the variables will be returned in a dictionary. appendmat -- non-zero to append the .mat extension to the end of the given filename. Outputs: If dict is None, then a dictionary of names and objects representing the stored arrays is returned. What is meaning of level 1.0 format ? Afaik, the current version of Matlab is 6.5. However loadmat seems to be restricted to version <=4. Is there any progress in upgrading this feature ? from scipy import * file=open("matrizen_red.mat",'r') io.loadmat(file,appendmat=0) raceback (most recent call last): File "matlab.py", line 3, in ? io.loadmat(file,appendmat=0) File "/usr/local/lib/python2.1/site-packages/scipy/io/mio.py", line 348, in loadmat if os.sep in name: TypeError: 'in' or 'not in' needs sequence right argument Any suggestion ? Nils From heiko at hhenkelmann.de Wed Oct 15 18:15:57 2003 From: heiko at hhenkelmann.de (Heiko Henkelmann) Date: Thu, 16 Oct 2003 00:15:57 +0200 Subject: [SciPy-dev] matFile module Message-ID: <00d601c39369$e89d54e0$9bdb9e3e@arrow> Dear All, due to popular demand on this list I'm giving you the chance to look at a module which I'm currently developing. I'm not done with it but I figured in terms of avoiding duplicated efforts it would be a good point to show it to you. It is a pure python implementation and enables users to read ML Version 5 compatible files. At this point it is able to read anything but sparse matrices. Not having looked at Nigel Wades matfile I can't tell you what the differences to my implementation are. Feedback, especially on cross platform compatibility and every kind of test results would be very welcome. Thanx Heiko -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: matFile.py URL: From oliphant at ee.byu.edu Wed Oct 15 18:25:02 2003 From: oliphant at ee.byu.edu (Travis E. Oliphant) Date: Wed, 15 Oct 2003 16:25:02 -0600 Subject: [SciPy-dev] matFile module In-Reply-To: <00d601c39369$e89d54e0$9bdb9e3e@arrow> References: <00d601c39369$e89d54e0$9bdb9e3e@arrow> Message-ID: <3F8DC93E.8020801@ee.byu.edu> Heiko Henkelmann wrote: > Dear All, > > due to popular demand on this list I'm giving you the chance to look at a > module which I'm currently developing. I'm not done with it but I figured in > terms of avoiding duplicated efforts it would be a good point to show it to > you. It is a pure python implementation and enables users to read ML Version > 5 compatible files. At this point it is able to read anything but sparse > matrices. > > Not having looked at Nigel Wades matfile I can't tell you what the > differences to my implementation are. > > Feedback, especially on cross platform compatibility and every kind of test > results would be very welcome. I'm very much in favor of this kind of approach over a C-written approach. I'm not sure what speed issues there may be. But, this looks like it could be dropped into SciPy pretty easily if enough people agree. -Travis O. From oliphant at ee.byu.edu Thu Oct 16 21:11:40 2003 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 16 Oct 2003 19:11:40 -0600 Subject: [SciPy-dev] Added Matlab version 5.0 file reading support Message-ID: <3F8F41CC.8@ee.byu.edu> Thanks to the good start provided by Heinko, I have completed addition of read support for MATLAB(tm) version 5.0 mat files. Sparse matrices are also read and converted to SciPy sparse matrices if you have compiled the sparse package (turned off by default). The changes are in CVS and are part of the io.loadmat function (it now recognized v5 files). Matlab(tm) Structures and objects are handled as (arrays of) dummy classes and are also supported. Cell arrays are handled as an Object array. -Travis O. From anthony.seward at ieee.org Fri Oct 17 14:50:03 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Fri, 17 Oct 2003 12:50:03 -0600 Subject: [SciPy-dev] building RPMs Message-ID: <1066416603.5979.46.camel@sonylap1> I'm trying to streamline and simplify the building of my SciPy RPMs. It would greatly help if the MANIFEST.in and setup.cfg files that I've attached are included in the scipy_core/scipy_distutils directory. Comments? Tony -- Anthony Joseph Seward -------------- next part -------------- recursive-include command *.py include *.py include sample_site.cfg -------------- next part -------------- [bdist_rpm] doc_files = sample_site.cfg From fperez at colorado.edu Fri Oct 17 20:38:01 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri, 17 Oct 2003 18:38:01 -0600 Subject: [SciPy-dev] Found fix for a long-standing bug in weave.catalog Message-ID: <3F908B69.5070209@colorado.edu> Hi all, on and off I've been seeing very strange behavior from weave.inline(). Basically it would rebuild functions which it had already seen before, in a rather erratic manner. Today I finally dove in to try and fix, and after a _lot_ of print statements all over weave, I think I got it. In catalog.py, the add_function_persistent() method NEEDS as its final line: cat.close() This closes the shelve catalog object, which guarantees that the changes are actually committed to disk. From the shelve docs: Dependent on the implementation, closing a persistent dictionary may or may not be necessary to flush changes to disk. It's quite possible that others haven't seen this because they are on different platforms, or stress weave in different ways. I've actually beeen using inline() for a long time, and only with one particular library I have, do I see this problem. But when it hits you, it's extremely annoying, since you end up paying the compilation time overhead on _every_ function call. Kind of defeats the purpose of weave :) Eric, this is the bug I told you about at SciPy'03, which I was seeing on and off. Quite tricky to track down, but now that I had to understand most of how weave.inline() & friends work, my hat is off to you. That's one beautiful piece of code (messy, but amazing :) It would be great if someone could double check that this is ineed ok (I'm pretty sure it is) and apply that single line change to the sources. I tested it against my library, and now it behaves reliably as it should (which it neveer had before). Many thanks, Fernando. From pearu at scipy.org Sun Oct 19 12:40:03 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sun, 19 Oct 2003 11:40:03 -0500 (CDT) Subject: [SciPy-dev] building RPMs In-Reply-To: <1066416603.5979.46.camel@sonylap1> Message-ID: On Fri, 17 Oct 2003, Anthony Joseph Seward wrote: > I'm trying to streamline and simplify the building of my SciPy RPMs. It > would greatly help if the MANIFEST.in and setup.cfg files that I've > attached are included in the scipy_core/scipy_distutils directory. > > Comments? Could you elaborate why do you want these files included to scipy_distutils and not to scipy_core? Scipy_distutils is not meant to be packaged standalone. See PACKAGERS.txt. Pearu From anthony.seward at ieee.org Mon Oct 20 14:35:47 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Mon, 20 Oct 2003 12:35:47 -0600 Subject: [SciPy-dev] building RPMs In-Reply-To: References: Message-ID: <1066674946.5979.98.camel@sonylap1> On Sun, 2003-10-19 at 10:40, Pearu Peterson wrote: > On Fri, 17 Oct 2003, Anthony Joseph Seward wrote: > > > I'm trying to streamline and simplify the building of my SciPy RPMs. It > > would greatly help if the MANIFEST.in and setup.cfg files that I've > > attached are included in the scipy_core/scipy_distutils directory. > > > > Comments? > > Could you elaborate why do you want these files included to > scipy_distutils and not to scipy_core? Scipy_distutils is not meant to > be packaged standalone. See PACKAGERS.txt. > > Pearu > If scipy_distutils is not installed before f2py, then f2py installs a version of scipy_distutils which will then conflict with the one installed by scipy. I was installing a scipy_distutils RPM before making f2py. Why is scipy_distutils not meant to be distributed standalone? Tony -- Anthony Joseph Seward From anthony.seward at ieee.org Mon Oct 20 14:50:35 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Mon, 20 Oct 2003 12:50:35 -0600 Subject: [SciPy-dev] building RPMs In-Reply-To: <1066674946.5979.98.camel@sonylap1> References: <1066674946.5979.98.camel@sonylap1> Message-ID: <1066675835.5979.101.camel@sonylap1> On Mon, 2003-10-20 at 12:35, Anthony Joseph Seward wrote: > On Sun, 2003-10-19 at 10:40, Pearu Peterson wrote: > > On Fri, 17 Oct 2003, Anthony Joseph Seward wrote: > > > > > I'm trying to streamline and simplify the building of my SciPy RPMs. It > > > would greatly help if the MANIFEST.in and setup.cfg files that I've > > > attached are included in the scipy_core/scipy_distutils directory. > > > > > > Comments? > > > > Could you elaborate why do you want these files included to > > scipy_distutils and not to scipy_core? Scipy_distutils is not meant to > > be packaged standalone. See PACKAGERS.txt. > > Sorry: busy day at work and I'm reading my e-mail too quickly. I'll mull over PACKAGERS.txt and rethink my strategy. > > > Pearu > > > > If scipy_distutils is not installed before f2py, then f2py installs a > version of scipy_distutils which will then conflict with the one > installed by scipy. I was installing a scipy_distutils RPM before > making f2py. > > Why is scipy_distutils not meant to be distributed standalone? > > Tony -- Anthony Joseph Seward From anthony.seward at ieee.org Mon Oct 20 19:39:40 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Mon, 20 Oct 2003 17:39:40 -0600 Subject: [SciPy-dev] building RPMs In-Reply-To: References: Message-ID: <1066693180.31981.8.camel@sonylap1> If you apply the attached scipy_core-MANIFEST.in.diff to scipy_core/MANIFEST.in then the bdist_rpm command works for Scipy_core. If you apply f2py2e-__version__.py.diff to f2py2e/__version__.py then bdist_rpm works for F2PY. Is this better? I have to go. I'll try the full SciPy later. Tony On Sun, 2003-10-19 at 10:40, Pearu Peterson wrote: > On Fri, 17 Oct 2003, Anthony Joseph Seward wrote: > > > I'm trying to streamline and simplify the building of my SciPy RPMs. It > > would greatly help if the MANIFEST.in and setup.cfg files that I've > > attached are included in the scipy_core/scipy_distutils directory. > > > > Comments? > > Could you elaborate why do you want these files included to > scipy_distutils and not to scipy_core? Scipy_distutils is not meant to > be packaged standalone. See PACKAGERS.txt. > > Pearu -- Anthony Joseph Seward -------------- next part -------------- A non-text attachment was scrubbed... Name: scipy_core-MANIFEST.in.diff Type: text/x-patch Size: 559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f2py2e-__version__.py.diff Type: text/x-patch Size: 515 bytes Desc: not available URL: From pearu at scipy.org Tue Oct 21 02:19:25 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 21 Oct 2003 01:19:25 -0500 (CDT) Subject: [SciPy-dev] building RPMs In-Reply-To: <1066693180.31981.8.camel@sonylap1> Message-ID: On Mon, 20 Oct 2003, Anthony Joseph Seward wrote: > If you apply the attached scipy_core-MANIFEST.in.diff to > scipy_core/MANIFEST.in then the bdist_rpm command works for Scipy_core. > > If you apply f2py2e-__version__.py.diff to f2py2e/__version__.py then > bdist_rpm works for F2PY. > > Is this better? Yes. The diffs are applied to CVS repositories. Thanks, Pearu From anthony.seward at ieee.org Tue Oct 21 12:47:47 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Tue, 21 Oct 2003 10:47:47 -0600 Subject: [SciPy-dev] building RPMs In-Reply-To: References: Message-ID: <1066754866.7489.5.camel@sonylap1> Applying the attached scipy-MANIFEST.in.diff to scipy/MANIFEST.in allows bdist_rpm to work for scipy proper. Tony -- Anthony Joseph Seward -------------- next part -------------- A non-text attachment was scrubbed... Name: scipy-MANIFEST.in.diff Type: text/x-patch Size: 772 bytes Desc: not available URL: From fperez at colorado.edu Fri Oct 24 14:22:19 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri, 24 Oct 2003 12:22:19 -0600 Subject: [SciPy-dev] Patch for pilutils Message-ID: <3F996DDB.9040501@colorado.edu> Hi all, here's a simple patch for pilutil which adds a simple 'flatten' option to the image reading functions imread. Here are the resulting definition and docstrings: In [2]: scipy.fromimage? Definition: scipy.fromimage(im, flatten=0) Docstring: Takes a PIL image and returns a copy of the image in a Numeric container. If the image is RGB returns a 3-dimensional array: arr[:,:,n] is each channel Optional arguments: - flatten (0): if true, the image is flattened by calling convert('F') on the image object before extracting the numerical data. This flattens the color layers into a single grayscale layer. Note that the supplied image object is NOT modified. In [3]: scipy.imread? Definition: scipy.imread(name, flatten=0) Docstring: Read an image file from a filename. Optional arguments: - flatten (0): if true, the image is flattened by calling convert('F') on the resulting image object. This flattens the color layers into a single grayscale layer. This is useful in case you want to load straight from an image file (jpeg, tiff, ...) but you want a single grayscale array to do numerics on. The change is fully backwards compatible. I did it because we needed here to easily read images for testing some numerical transformations without dealing with the color channels. It was easier to patch scipy than to tell my coworkers to remember to convert every image first :) Comments? I think I can commit to CVS, but I don't want to without some feedback first on whether people like/dislike the idea. Especially because it's not a bugfix, it's a new feature (albeit a small one). Regards, Fernando. ps. Hey Travis, thanks for committing the weave.catalog fix. I was going to include that today in the patch and I checked the CVS, to find you'd done it. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pilutil.diff URL: From fperez at colorado.edu Fri Oct 24 18:34:35 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri, 24 Oct 2003 16:34:35 -0600 Subject: [SciPy-dev] Very strange interaction between scipy and PIL Message-ID: <3F99A8FB.2010006@colorado.edu> Hi all, I'm seeing an extremely strange behavior. Consider the following: In [1]: import Image In [2]: im=Image.open('slide_img0065_sm.jpg') In [3]: import scipy In [4]: arr=scipy.imread('slide_img0065_sm.jpg') --------------------------------------------------------------------------- IOError Traceback (most recent call last) ? /usr/lib/python2.2/site-packages/scipy/pilutil.py in imread(name='slide_img0065_sm.jpg', flatten=0) 39 grayscale layer. 40 """ ---> 41 im = Image.open(name) im = undefined, global Image = , global open = undefined, name = 'slide_img0065_sm.jpg' 42 return fromimage(im,flatten=flatten) 43 /usr/lib/python2.2/site-packages/PIL/Image.py in open(fp=, mode='r') 1572 pass 1573 -> 1574 raise IOError("cannot identify image file") global IOError = undefined 1575 1576 # IOError: cannot identify image file When you realize that the code for imread() does only: def imread(name,flatten=0): """Read an image file from a filename. Optional arguments: - flatten (0): if true, the image is flattened by calling convert('F') on the resulting image object. This flattens the color layers into a single grayscale layer. """ im = Image.open(name) return fromimage(im,flatten=flatten) it makes no sense whatsoever! Somehow, the fact of importing scipy seems to mess something internally in whatever it is that Image.open does, if Image was imported first. If you ONLY use scipy, it works fine: In [1]: import scipy In [2]: arr=scipy.imread('slide_img0065_sm.jpg') In [3]: arr.shape Out[3]: (387, 577, 3) And here's an even better one. Compare these two scenarios: In [1]: import Image,scipy In [2]: im=Image.open('slide_img0065_sm.jpg') --------------------------------------------------------------------------- IOError Traceback (most recent call last) ? /usr/lib/python2.2/site-packages/PIL/Image.py in open(fp=, mode='r') 1572 pass 1573 -> 1574 raise IOError("cannot identify image file") global IOError = undefined 1575 1576 # IOError: cannot identify image file In [3]: VS: In [1]: import scipy,Image In [2]: im=Image.open('slide_img0065_sm.jpg') In [3]: This means that importing scipy AFTER Image breaks something, but importing it before does not. If anyone can crack this one, I'd love to hear. I tried for a while already, but didn't get very far. Best, f. From pearu at scipy.org Sat Oct 25 04:47:26 2003 From: pearu at scipy.org (Pearu Peterson) Date: Sat, 25 Oct 2003 03:47:26 -0500 (CDT) Subject: [SciPy-dev] Very strange interaction between scipy and PIL In-Reply-To: <3F99A8FB.2010006@colorado.edu> Message-ID: On Fri, 24 Oct 2003, Fernando Perez wrote: > I'm seeing an extremely strange behavior. Consider the following: > If anyone can crack this one, I'd love to hear. I tried for a while already, > but didn't get very far. This behavior was due to incomplete implementation of ppimport function and now it is fixed in CVS. Thanks for reporting it, Pearu From wagner.nils at vdi.de Mon Oct 27 10:16:01 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Mon, 27 Oct 2003 16:16:01 +0100 Subject: [SciPy-dev] problems with latest cvs Message-ID: <20031027151904.A190B3EB1B@www.scipy.com> Dear experts, A build from latest cvs failed Traceback (most recent call last): File "setup.py", line 163, in ? setup_package(ignore_packages) File "setup.py", line 153, in setup_package url = "http://www.scipy.org", File "scipy_core/scipy_distutils/core.py", line 42, in setup return old_setup(**new_attr) File "/usr/lib/python2.3/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.3/distutils/dist.py", line 907, in run_commands self.run_command(cmd) File "/usr/lib/python2.3/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/usr/lib/python2.3/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/usr/lib/python2.3/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.3/distutils/dist.py", line 927, in run_command cmd_obj.run() File "scipy_core/scipy_distutils/command/run_f2py.py", line 70, in run ext.sources = self.f2py_sources(ext.sources,ext) File "scipy_core/scipy_distutils/command/run_f2py.py", line 118, in f2py_sources (base, source_ext) = os.path.splitext(source) File "/usr/lib/python2.3/posixpath.py", line 92, in splitext i = p.rfind('.') AttributeError: SourceFilter instance has no attribute 'rfind' Nils From pearu at scipy.org Mon Oct 27 10:37:35 2003 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 27 Oct 2003 17:37:35 +0200 (EET) Subject: [SciPy-dev] problems with latest cvs In-Reply-To: <20031027151904.A190B3EB1B@www.scipy.com> Message-ID: On Mon, 27 Oct 2003, Nils Wagner wrote: > Dear experts, > > A build from latest cvs failed > > Traceback (most recent call last): ... > AttributeError: SourceFilter instance has no attribute 'rfind' That's me. I'll fix it within an hour. Pearu From pearu at scipy.org Mon Oct 27 11:52:51 2003 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 27 Oct 2003 18:52:51 +0200 (EET) Subject: [SciPy-dev] problems with latest cvs In-Reply-To: Message-ID: On Mon, 27 Oct 2003, Pearu Peterson wrote: > > > On Mon, 27 Oct 2003, Nils Wagner wrote: > > > A build from latest cvs failed > > > > Traceback (most recent call last): > ... > > AttributeError: SourceFilter instance has no attribute 'rfind' > > That's me. I'll fix it within an hour. Fixed. Pearu From fperez at colorado.edu Mon Oct 27 12:49:15 2003 From: fperez at colorado.edu (Fernando Perez) Date: Mon, 27 Oct 2003 10:49:15 -0700 Subject: [SciPy-dev] Very strange interaction between scipy and PIL In-Reply-To: References: Message-ID: <3F9D5A9B.705@colorado.edu> Pearu Peterson wrote: > This behavior was due to incomplete implementation of ppimport function > and now it is fixed in CVS. > > Thanks for reporting it, No prob. Thanks for fixing it! This was really weird, I'm glad you were able to track it so quickly. Best, f From wagner.nils at vdi.de Mon Oct 27 15:13:20 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Mon, 27 Oct 2003 21:13:20 +0100 Subject: [SciPy-dev] More matrix functions Message-ID: <20031027201624.DE3AA3EB1B@www.scipy.com> Dear experts, Please find enclosed two algorithms for the computation of the matrix square root. It would be great to have this function in scipy. Any comments ? Nils Reference Nick Higham How and how not to compute the matrix square root Numerical Algorithms 15(2) 227--242 (1997) -------------- next part -------------- A non-text attachment was scrubbed... Name: db.py Type: application/octet-stream Size: 1223 bytes Desc: not available URL: From wagner.nils at vdi.de Mon Oct 27 15:40:34 2003 From: wagner.nils at vdi.de (Nils Wagner) Date: Mon, 27 Oct 2003 21:40:34 +0100 Subject: [SciPy-dev] sqrtm Message-ID: <20031027204338.BF8F63EB33@www.scipy.com> Hi all, Just another sqrtm implementation based on Pade iteration... def sqrtm2(A,p): # # Pade Iteration # m,n = shape(A) i=arange(1,p+1) xi = 0.5*(1.+cos(0.5*(2*i-1)*pi/p)) ai2 = 1.0/xi-1. Y0 = A Z0 = identity(n) maxiter = 5 for k in arange(0,maxiter): sum1= zeros((n,n),Complex) sum2= zeros((n,n),Complex) for j in arange(0,p): sum1 = sum1 + linalg.inv(dot(Z0,Y0)+ai2[j]*identity(n))/xi[j] sum2 = sum2 + linalg.inv(dot(Y0,Z0)+ai2[j]*identity(n))/xi[j] Y1 = dot(Y0,sum1)/p Z1 = dot(Z0,sum1)/p Y0 = Y1 Z0 = Z1 return Y1,Z1 # # test matrix # A=rand(5,5) # # Modify the spectrum # A = dot(A,A)/25.0+identity(5) # Y2,Z2 = sqrtm2(A,4) print linalg.norm(dot(Y2,Y2)-A) print linalg.norm(dot(Z2,Z2)-linalg.inv(A)) Any suggestions ? Nils From ijliao at csie.nctu.edu.tw Tue Oct 28 00:38:55 2003 From: ijliao at csie.nctu.edu.tw (Ying-Chieh Liao) Date: Tue, 28 Oct 2003 13:38:55 +0800 Subject: [SciPy-dev] build scipy on freebsd Message-ID: <20031028053855.GA31421@freebsd.csie.nctu.edu.tw> I'm trying to make a port for scipy, but there's a problem I cannot solve... error messages like this : running build_ext building 'scipy_base.fastumath' extension cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentium4 -D_THREAD_SAFE -DTHREAD_STACK_SIZE=0x20000 -O -pipe -march=pentium4 -fPIC -I/usr/local/include/python2.3 -c /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.c -o build/temp.freebsd-5.1-CURRENT-i386-2.3/tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.o In file included from /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.c:27: /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumath_unsigned.inc:2785: error: `acosh' undeclared here (not in a function) /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumath_unsigned.inc:2785: error: initializer element is not constant btw, I've installed djbfft (in /usr/local/{include/lib}) but scipy cannot detect it... -- KISS : Keep It Simple, Stupid. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From pearu at scipy.org Tue Oct 28 01:03:52 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 00:03:52 -0600 (CST) Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: <20031028053855.GA31421@freebsd.csie.nctu.edu.tw> Message-ID: On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > I'm trying to make a port for scipy, Great! But you should certainly use the CVS version of scipy for that as recent changes in CVS have made packaging scipy much easier. See also PACKAGERS.txt (that I'll soon update again). > but there's a problem I cannot solve... > error messages like this : > > running build_ext > building 'scipy_base.fastumath' extension > cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentium4 -D_THREAD_SAFE -DTHREAD_STACK_SIZE=0x20000 -O -pipe -march=pentium4 -fPIC -I/usr/local/include/python2.3 -c /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.c -o build/temp.freebsd-5.1-CURRENT-i386-2.3/tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.o > In file included from /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.c:27: > /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumath_unsigned.inc:2785: error: `acosh' undeclared here (not in a function) > /tmp/py-SciPy/work/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumath_unsigned.inc:2785: error: initializer element is not constant > That is weird as acosh is defined in fastumath_unsigned.inc. Try using -UHAVE_INVERSE_HYPERBOLIC. Let us know if it works or you found another solution for freebsd. > btw, I've installed djbfft (in /usr/local/{include/lib}) > but scipy cannot detect it... You have to follow installation instructions in http://cr.yp.to/djbfft/install.html Yes, they are a bit braindead but "fixing" djbfft installation process is not so simple. Pearu From ijliao at csie.nctu.edu.tw Tue Oct 28 01:20:07 2003 From: ijliao at csie.nctu.edu.tw (Ying-Chieh Liao) Date: Tue, 28 Oct 2003 14:20:07 +0800 Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: References: <20031028053855.GA31421@freebsd.csie.nctu.edu.tw> Message-ID: <20031028062007.GB32147@freebsd.csie.nctu.edu.tw> On Tue, Oct 28, 2003 at 00:03:52 -0600, Pearu Peterson wrote: > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > I'm trying to make a port for scipy, > Great! > But you should certainly use the CVS version of scipy for that > as recent changes in CVS have made packaging scipy much easier. > See also PACKAGERS.txt (that I'll soon update again). too bad ... do you have any release plan recently ? :) > That is weird as acosh is defined in fastumath_unsigned.inc. > Try using -UHAVE_INVERSE_HYPERBOLIC. > Let us know if it works or you found another solution for freebsd. ok I'll try it > > btw, I've installed djbfft (in /usr/local/{include/lib}) > > but scipy cannot detect it... > You have to follow installation instructions in > http://cr.yp.to/djbfft/install.html > Yes, they are a bit braindead but "fixing" djbfft installation process > is not so simple. hmmm... In the FreeBSD ports system, djbfft is installed into /usr/local/include/djbfft/*.h /usr/local/lib/libdjbfft.a how can I adjust scipy source (or configure) to find it ? -- Allocate four digits for the year part of a date : a new millennium is coming. --- David Huber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From pearu at scipy.org Tue Oct 28 01:47:18 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 00:47:18 -0600 (CST) Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: <20031028062007.GB32147@freebsd.csie.nctu.edu.tw> Message-ID: On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > On Tue, Oct 28, 2003 at 00:03:52 -0600, Pearu Peterson wrote: > > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > > I'm trying to make a port for scipy, > > Great! > > But you should certainly use the CVS version of scipy for that > > as recent changes in CVS have made packaging scipy much easier. > > See also PACKAGERS.txt (that I'll soon update again). > > too bad ... do you have any release plan recently ? :) If you are interested in freebsd binary port then you are probably on your own as, if I am not mistaken, no scipy developer uses freebsd. But getting scipy from CVS is not so complicated. See http://www.scipy.org/site_content/tutorials/CVSInstruct I guess that freebsd has cvs software installed. > > That is weird as acosh is defined in fastumath_unsigned.inc. > > Try using -UHAVE_INVERSE_HYPERBOLIC. > > Let us know if it works or you found another solution for freebsd. > > ok I'll try it > > > > btw, I've installed djbfft (in /usr/local/{include/lib}) > > > but scipy cannot detect it... > > You have to follow installation instructions in > > http://cr.yp.to/djbfft/install.html > > Yes, they are a bit braindead but "fixing" djbfft installation process > > is not so simple. > > hmmm... > > In the FreeBSD ports system, djbfft is installed into > /usr/local/include/djbfft/*.h > /usr/local/lib/libdjbfft.a > > how can I adjust scipy source (or configure) to find it ? You should have seen the following message """ DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [djbfft]) or by setting the DJBFFT environment variable.""" when building scipy but unfortunately this will not work as scipy_distutils/system_info.py is still looking for a file djbfft.a (not libdjbfft.a). You can try fixing this in system_info.py yourself, I'll later fix it also in CVS. Pearu From ijliao at csie.nctu.edu.tw Tue Oct 28 01:51:24 2003 From: ijliao at csie.nctu.edu.tw (Ying-Chieh Liao) Date: Tue, 28 Oct 2003 14:51:24 +0800 Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: References: <20031028062007.GB32147@freebsd.csie.nctu.edu.tw> Message-ID: <20031028065124.GA34582@freebsd.csie.nctu.edu.tw> On Tue, Oct 28, 2003 at 00:47:18 -0600, Pearu Peterson wrote: > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > On Tue, Oct 28, 2003 at 00:03:52 -0600, Pearu Peterson wrote: > > > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > > > I'm trying to make a port for scipy, > > > Great! > > > But you should certainly use the CVS version of scipy for that > > > as recent changes in CVS have made packaging scipy much easier. > > > See also PACKAGERS.txt (that I'll soon update again). > > too bad ... do you have any release plan recently ? :) > If you are interested in freebsd binary port then you are probably > on your own as, if I am not mistaken, no scipy developer uses freebsd. > But getting scipy from CVS is not so complicated. See > http://www.scipy.org/site_content/tutorials/CVSInstruct > I guess that freebsd has cvs software installed. yeah, FreeBSD uses cvs, too but I want to build a "port", something like rpm/srpm so that every FreeBSD user around the world can use this package by simply a "pkg_add" or "make install" that's why I need a source tarball instead of cvs checkout :) > when building scipy but unfortunately this will not work as > scipy_distutils/system_info.py is still looking for a file > djbfft.a (not libdjbfft.a). You can try fixing this in system_info.py > yourself, I'll later fix it also in CVS. hmmm... ok -- Allocate four digits for the year part of a date : a new millennium is coming. --- David Huber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From pearu at scipy.org Tue Oct 28 01:59:27 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 00:59:27 -0600 (CST) Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: <20031028065124.GA34582@freebsd.csie.nctu.edu.tw> Message-ID: On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > but I want to build a "port", something like rpm/srpm > so that every FreeBSD user around the world can use this package by simply > a "pkg_add" or "make install" > > that's why I need a source tarball instead of cvs checkout :) But it is easy to create a source tarball also from cvs checkout: #checkout scipy to cvs/ cd cvs/scipy python setup.py sdist -f -t blah that will create a source tarball into dist/ directory. Pearu From ijliao at csie.nctu.edu.tw Tue Oct 28 02:01:01 2003 From: ijliao at csie.nctu.edu.tw (Ying-Chieh Liao) Date: Tue, 28 Oct 2003 15:01:01 +0800 Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: References: <20031028065124.GA34582@freebsd.csie.nctu.edu.tw> Message-ID: <20031028070101.GA35139@freebsd.csie.nctu.edu.tw> On Tue, Oct 28, 2003 at 00:59:27 -0600, Pearu Peterson wrote: > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > but I want to build a "port", something like rpm/srpm > > so that every FreeBSD user around the world can use this package by simply > > a "pkg_add" or "make install" > > that's why I need a source tarball instead of cvs checkout :) > But it is easy to create a source tarball also from cvs checkout: > #checkout scipy to cvs/ > cd cvs/scipy > python setup.py sdist -f -t blah > that will create a source tarball into dist/ directory. I mean, an official one :) -- Allocate four digits for the year part of a date : a new millennium is coming. --- David Huber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From pearu at scipy.org Tue Oct 28 02:57:29 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 01:57:29 -0600 (CST) Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: <20031028070101.GA35139@freebsd.csie.nctu.edu.tw> Message-ID: On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > On Tue, Oct 28, 2003 at 00:59:27 -0600, Pearu Peterson wrote: > > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > > but I want to build a "port", something like rpm/srpm > > > so that every FreeBSD user around the world can use this package by simply > > > a "pkg_add" or "make install" > > > that's why I need a source tarball instead of cvs checkout :) > > But it is easy to create a source tarball also from cvs checkout: > > #checkout scipy to cvs/ > > cd cvs/scipy > > python setup.py sdist -f -t blah > > that will create a source tarball into dist/ directory. > > I mean, an official one :) Yes, we are all looking forward to it:) On the other hand, note that if we would make the tarball now that should work perfectly under Linux (and may be on other platforms as well) then under freebsd it might not be as smooth as you just discovered. So, to support freebsd in offical tarball someone has to test CVS scipy first and together solve any merging issues. Regards, Pearu From nwagner at mecha.uni-stuttgart.de Tue Oct 28 04:22:33 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 28 Oct 2003 10:22:33 +0100 Subject: [SciPy-dev] errors in scipy.test() Message-ID: <3F9E3558.E9C0BC1A@mecha.uni-stuttgart.de> Dear experts, scipy.test() from latest cvs results in 4 errors and several failures >>> scipy.__version__ '0.2.1_249.4423' >>> import Numeric >>> Numeric.__version__ '23.0' >>> Python 2.1.2 (#1, Feb 25 2002, 18:04:21) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "copyright", "credits" or "license" for more information. ====================================================================== ERROR: check_basic (scipy.stats.stats.test_stats.test_mode) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/stats/tests/test_stats.py", line 680, in check_basic assert_almost_equal(vals[0],6) File "/usr/local/lib/python2.1/site-packages/scipy_test/testing.py", line 536, in assert_almost_equal assert round(abs(desired - actual),decimal) == 0, msg TypeError: only rank-0 arrays can be converted to Python scalars. ====================================================================== ERROR: check_linear_constant (scipy.interpolate.fitpack.test_fitpack.test_LSQBivariateSpline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py", line 52, in check_linear_constant lut = LSQBivariateSpline(x,y,z,tx,ty,kx=1,ky=1) File "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py", line 399, in __init__ kx,ky,eps,lwrk2=1) error: (len(y)==m) failed for 3rd argument z ====================================================================== ERROR: check_linear_1d (scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py", line 72, in check_linear_1d lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1) File "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py", line 356, in __init__ kx,ky,s=s,eps=eps,lwrk2=1) error: (len(y)==m) failed for 3rd argument z ====================================================================== ERROR: check_linear_constant (scipy.interpolate.fitpack.test_fitpack.test_SmoothBivariateSpline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.1/site-packages/scipy/interpolate/tests/test_fitpack.py", line 62, in check_linear_constant lut = SmoothBivariateSpline(x,y,z,kx=1,ky=1) File "/usr/local/lib/python2.1/site-packages/scipy/interpolate/fitpack2.py", line 356, in __init__ kx,ky,s=s,eps=eps,lwrk2=1) error: (len(y)==m) failed for 3rd argument z Nils From pearu at scipy.org Tue Oct 28 03:48:14 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 02:48:14 -0600 (CST) Subject: [SciPy-dev] build scipy on freebsd In-Reply-To: <20031028065124.GA34582@freebsd.csie.nctu.edu.tw> Message-ID: On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > when building scipy but unfortunately this will not work as > > scipy_distutils/system_info.py is still looking for a file > > djbfft.a (not libdjbfft.a). You can try fixing this in system_info.py > > yourself, I'll later fix it also in CVS. > > hmmm... ok This issue should be now fixed in CVS. Pearu From nwagner at mecha.uni-stuttgart.de Tue Oct 28 05:52:44 2003 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 28 Oct 2003 11:52:44 +0100 Subject: [SciPy-dev] build scipy on freebsd References: Message-ID: <3F9E4A7C.6A2E326@mecha.uni-stuttgart.de> Pearu Peterson schrieb: > > On Tue, 28 Oct 2003, Ying-Chieh Liao wrote: > > > > when building scipy but unfortunately this will not work as > > > scipy_distutils/system_info.py is still looking for a file > > > djbfft.a (not libdjbfft.a). You can try fixing this in system_info.py > > > yourself, I'll later fix it also in CVS. > > > > hmmm... ok > > This issue should be now fixed in CVS. > > Pearu > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev Hi all, I tried to install djbfft-0.76 Hoever make failed ./makelib str.a byte_copy.o byte_cr.o str_len.o ./load auto-str substdio.a error.a str.a substdio.a(substdo.o)(.text+0x31): In function `allwrite': : undefined reference to `errno' collect2: ld returned 1 exit status make: *** [auto-str] Fehler 1 Any idea ? Nils From hoel at gl-group.com Tue Oct 28 10:14:59 2003 From: hoel at gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=) Date: Tue, 28 Oct 2003 16:14:59 +0100 Subject: [SciPy-dev] building libraries using scipy distutils on WinXP Message-ID: Hello, The path to my Visual Studio executables contains spaces. This leads to an error when "lib.exe" is called from scipy distutils. The attached patch to command/build_flib.py fixes this problem for me. cvs server: Diffing scipy_core/scipy_distutils/command Index: scipy_core/scipy_distutils/command/build_flib.py =================================================================== RCS file: /home/cvsroot/world/scipy_core/scipy_distutils/command/build_flib.py,v retrieving revision 1.82 diff -r1.82 build_flib.py 1290c1290 < self.lib_ar = MSVCCompiler().lib + ' /OUT:' --- > self.lib_ar = '"%s" /OUT:' % MSVCCompiler().lib 1535c1535 < self.lib_ar = MSVCCompiler().lib + ' /OUT:' --- > self.lib_ar = '"%s" /OUT:' % MSVCCompiler().lib cvs server: Diffing scipy_core/scipy_test Kind regards Berthold H?llmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel at gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark at germanlloyd.org will be replaced by shortmark at gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc. From pearu at scipy.org Tue Oct 28 10:43:22 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 09:43:22 -0600 (CST) Subject: [SciPy-dev] building libraries using scipy distutils on WinXP In-Reply-To: Message-ID: On Tue, 28 Oct 2003, [iso-8859-15] Berthold H?llmann wrote: > The path to my Visual Studio executables contains spaces. This leads > to an error when "lib.exe" is called from scipy distutils. The > attached patch to command/build_flib.py fixes this problem for me. The patch is applied to CVS. Thanks, Pearu From hoel at gl-group.com Tue Oct 28 10:57:25 2003 From: hoel at gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=) Date: Tue, 28 Oct 2003 16:57:25 +0100 Subject: [SciPy-dev] build_flib.py again Message-ID: Hello, May I ask, what is the rationale for the changes for the swithches in the 'compaq_visual_fortran_compiler' class between CVS version 1.80 and today's head. The old ones (working for me were) (line 1527): switches = ' /nologo /MD /W1 /iface:cref /iface=nomixed_str_len_arg ' in current head I find (not working for me) (line 1537-1539): switches = ' /nologo /nodebug /MD /WX '\ ' /iface=(cref,nomixed_str_len_arg) /names:lowercase '\ ' /assume:underscore /threads ' shouldn't /nodebug only be set if not in debug mode? The main problems I have with the /iface and /names settings that break some code by me, ie my carefully compiled Atlas/lapack libraries under WinXP. Kind regards Berthold H?llmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel at gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark at germanlloyd.org will be replaced by shortmark at gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc. From pearu at scipy.org Tue Oct 28 11:33:27 2003 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 28 Oct 2003 10:33:27 -0600 (CST) Subject: [SciPy-dev] build_flib.py again In-Reply-To: Message-ID: On Tue, 28 Oct 2003, [iso-8859-15] Berthold H?llmann wrote: > Hello, > > May I ask, what is the rationale for the changes for the swithches in > the 'compaq_visual_fortran_compiler' class between CVS version 1.80 > and today's head. The old ones (working for me were) (line 1527): > > switches = ' /nologo /MD /W1 /iface:cref /iface=nomixed_str_len_arg ' > > in current head I find (not working for me) (line 1537-1539): > > switches = ' /nologo /nodebug /MD /WX '\ > ' /iface=(cref,nomixed_str_len_arg) /names:lowercase '\ > ' /assume:underscore /threads ' > > shouldn't /nodebug only be set if not in debug mode? I agree. > The main problems > I have with the /iface and /names settings that break some code by me, > ie my carefully compiled Atlas/lapack libraries under WinXP. The rationale is that all supported compilers should behave in the same way, that is, lower cases and append underscore to fortran symbols. Different compilers may behave differently in this respect and with additional switches one can "tune" a compiler as needed. Earlier compaq_visual_fortran_compiler did not follow this convention and hence the changes. Sorry that it broke some of your codes and I hope it is not too much trouble for you to fix them. Pearu From prabhu at aero.iitm.ernet.in Tue Oct 28 13:24:43 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Tue, 28 Oct 2003 23:54:43 +0530 Subject: [SciPy-dev] VTK-Python-CVS binaries for Win32. Message-ID: <16286.46187.105323.377304@monster.linux.in> Hi, I just built VTK for Win32 and Python2.3.2. The binaries along with installation instructions are available here: http://av.stanford.edu/~prabhu/download/vtk/win32/ This was built from VTK cvs (2003-10-27) and built against Python-2.3.2-1. It supports GL2PS-1.0 (with PDF output support). The binaries *should* work well with MayaVi. The VTK documentation is not provided here, only the binaries. I've also posted instructions on how to build VTK from source over here. http://mayavi.sourceforge.net/cgi-bin/moin.cgi/BuildingVTKOnWin32 My thanks to Badri Narayanan of the CFD center, IIT-Madras for providing the resources for building VTK and for his help. Enjoy! cheers, prabhu p.s. sorry about the cross-posting! From hoel at gl-group.com Wed Oct 29 04:25:25 2003 From: hoel at gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=) Date: Wed, 29 Oct 2003 10:25:25 +0100 Subject: [SciPy-dev] Re: build_flib.py again In-Reply-To: (Pearu Peterson's message of "Tue, 28 Oct 2003 10:33:27 -0600 (CST)") References: Message-ID: Pearu Peterson writes: > On Tue, 28 Oct 2003, [iso-8859-15] Berthold H?llmann wrote: > >> Hello, >> >> May I ask, what is the rationale for the changes for the swithches in >> the 'compaq_visual_fortran_compiler' class between CVS version 1.80 >> and today's head. The old ones (working for me were) (line 1527): >> >> switches = ' /nologo /MD /W1 > /iface:cref /iface=nomixed_str_len_arg ' >> >> in current head I find (not working for me) (line 1537-1539): >> >> switches = ' /nologo /nodebug /MD /WX '\ >> ' /iface=(cref,nomixed_str_len_arg) /names:lowercase '\ >> ' /assume:underscore /threads ' >> >> shouldn't /nodebug only be set if not in debug mode? > > I agree. > >> The main problems >> I have with the /iface and /names settings that break some code by me, >> ie my carefully compiled Atlas/lapack libraries under WinXP. > > The rationale is that all supported compilers should behave in > the same way, that is, lower cases and append underscore to fortran > symbols. Different compilers may behave differently in this respect and > with additional switches one can "tune" a compiler as needed. > Earlier compaq_visual_fortran_compiler did not follow this > convention and hence the changes. Sorry that it broke some of your > codes and I hope it is not too much trouble for you to fix them. But do you do with Third party delivered libraries you want to wrap. We have a set of huge libraries where we can't compile of our own. From time to time we need/have fortran wrapper around these libraries that then need to be wrapped for python. These Fortran wrapper are only needed for the Python wrapper and as such are compiled as library unsing distutils. Would it be possible to provide a mechanism to allow user defined settings for the "switches" to make the libraries work? Kind regards Berthold H?llmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel at gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark at germanlloyd.org will be replaced by shortmark at gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc. From pearu at scipy.org Wed Oct 29 04:37:09 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 29 Oct 2003 03:37:09 -0600 (CST) Subject: [SciPy-dev] Re: build_flib.py again In-Reply-To: Message-ID: On Wed, 29 Oct 2003, [iso-8859-15] Berthold H?llmann wrote: > > The rationale is that all supported compilers should behave in > > the same way, that is, lower cases and append underscore to fortran > > symbols. Different compilers may behave differently in this respect and > > with additional switches one can "tune" a compiler as needed. > > Earlier compaq_visual_fortran_compiler did not follow this > > convention and hence the changes. Sorry that it broke some of your > > codes and I hope it is not too much trouble for you to fix them. > > But do you do with Third party delivered libraries you want to > wrap. We have a set of huge libraries where we can't compile of our > own. From time to time we need/have fortran wrapper around these > libraries that then need to be wrapped for python. These Fortran > wrapper are only needed for the Python wrapper and as such are > compiled as library unsing distutils. Would it be possible to provide > a mechanism to allow user defined settings for the "switches" to make > the libraries work? Could you give a more detailed example of the fortran wrapper and how do you wrap it to Python? If these wrappers can be modified e.g. by inserting f2py directives, then `fortranname` .pyf file command might be what you need. Pearu From hoel at gl-group.com Wed Oct 29 05:01:21 2003 From: hoel at gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=) Date: Wed, 29 Oct 2003 11:01:21 +0100 Subject: [SciPy-dev] Re: build_flib.py again In-Reply-To: (Pearu Peterson's message of "Wed, 29 Oct 2003 03:37:09 -0600 (CST)") References: Message-ID: Pearu Peterson writes: > On Wed, 29 Oct 2003, [iso-8859-15] Berthold H?llmann wrote: > >> > The rationale is that all supported compilers should behave in >> > the same way, that is, lower cases and append underscore to fortran >> > symbols. Different compilers may behave differently in this respect and >> > with additional switches one can "tune" a compiler as needed. >> > Earlier compaq_visual_fortran_compiler did not follow this >> > convention and hence the changes. Sorry that it broke some of your >> > codes and I hope it is not too much trouble for you to fix them. >> >> But do you do with Third party delivered libraries you want to >> wrap. We have a set of huge libraries where we can't compile of our >> own. From time to time we need/have fortran wrapper around these >> libraries that then need to be wrapped for python. These Fortran >> wrapper are only needed for the Python wrapper and as such are >> compiled as library unsing distutils. Would it be possible to provide >> a mechanism to allow user defined settings for the "switches" to make >> the libraries work? > > Could you give a more detailed example of the fortran wrapper and how do > you wrap it to Python? If these wrappers can be modified e.g. by inserting > f2py directives, then `fortranname` .pyf file command might be what you > need. Now i have a binary Fortran library named 'provided'. 'provided' provides a function 'subroutine foo()' which leads to a symol '_FOO at 0' in the library. Now i want to write a function that makes intensive use of 'foo', so I write a Fortran routine 'subroutine usefoo()' that is specific to python ant I wrap it unsing f2py. Because 'usefoo' is only usefull for my Python extension library I include it's sourcecode in my Python Project and build it as 'fortran_libraries' using scipy distutils. With the switches' settings as they are now this does not work, because the linker looks for '_foo_' instead of '_FOO' or '_FOO at 0'. Kind regards Berthold H?llmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel at gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark at germanlloyd.org will be replaced by shortmark at gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc. From pearu at scipy.org Wed Oct 29 15:38:47 2003 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 29 Oct 2003 14:38:47 -0600 (CST) Subject: [SciPy-dev] Re: build_flib.py again In-Reply-To: Message-ID: On Wed, 29 Oct 2003, [iso-8859-15] Berthold H?llmann wrote: > Pearu Peterson writes: > > > Could you give a more detailed example of the fortran wrapper and how do > > you wrap it to Python? If these wrappers can be modified e.g. by inserting > > f2py directives, then `fortranname` .pyf file command might be what you > > need. > > Now i have a binary Fortran library named 'provided'. 'provided' > provides a function 'subroutine foo()' which leads to a symol '_FOO at 0' > in the library. Now i want to write a function that makes intensive > use of 'foo', so I write a Fortran routine 'subroutine usefoo()' that > is specific to python ant I wrap it unsing f2py. Because 'usefoo' is > only usefull for my Python extension library I include it's sourcecode > in my Python Project and build it as 'fortran_libraries' using scipy > distutils. With the switches' settings as they are now this does not > work, because the linker looks for '_foo_' instead of '_FOO' or > '_FOO at 0'. Thanks for the explanation. So, you must be also using -DUPPERCASE_FORTRAN and -DPREPEND_FORTRAN cpp options. In fact, there are two possible ways for resolving Fortran symbols in f2py generated modules: + One is to uses compiler options to force certian convention that I explained earlier. + And the other is to use certain combinations of the CPP variables UPPERCASE_FORTRAN, PREPEND_FORTRAN, NO_APPEND_FORTRAN. In scipy_distutils we are using the first way because of two reasons: (i) this avoids issues with symbols containing characters like @ or ! that certain Fortran compilers may add to the initial names; namely, these characters in names will cause C compiler to complain as they are not allowed characters for C names. (ii) we haven't worked out a way how to define CPP macros for a C compiler depending on the Fortran compiler, and all that within the framework of distutils. But to resolve your case, there should be a way to define Fortran compiler options for scipy_distutils, but this feature is not implemented yet because we haven't needed it earlier. Meanwhile, you can use the following workaround in the setup.py file: from scipy_distutils.command import build_flib class my_fortran_compiler(build_flib.compaq_visual_fortran_compiler): def __init__(self, fc=None, f90c=None, verbose=0): build_flib.compaq_visual_fortran_compiler.__init__(self,fc,f90c,verbose) s = self.f77_switches s = s.replace('/names:lowercase','') s = s.replace('/assume:underscore','') # ... self.f77_switches = s # similarly can be self.f90_switches fixed. i = build_flib.all_compilers.index(build_flib.compaq_visual_fortran_compiler) build_flib.all_compilers[i] = my_fortran_compiler Note that I have not tested this code but it should work after fixing any possible typos that I might have been made here. Pearu From anthony.seward at ieee.org Thu Oct 30 13:08:03 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Thu, 30 Oct 2003 11:08:03 -0700 Subject: [SciPy-dev] RPM build problem Message-ID: <1067537283.28684.5.camel@sonylap1> Lines 19 and 20 of scipy/setup.py are causing problems with the bdist_rpm command. I commented them out and the build works fine as instructed in PACKAGERS.txt The offending lines: assert 'scipy_core'==os.path.basename(os.path.dirname(\ scipy_distutils.__path__[0])), scipy_distutils.__path__[0] What was the intention of these lines? Tony -- Anthony Joseph Seward From anthony.seward at ieee.org Thu Oct 30 13:17:26 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Thu, 30 Oct 2003 11:17:26 -0700 Subject: [SciPy-dev] Windows endlines in CVS Message-ID: <1067537846.28684.16.camel@sonylap1> There are some Windows endlines in the CVS repository. Is this considered a bug? It goofs with my scripts and so I was wondering if it could be fixed. I can make a patch. Tony -- Anthony Joseph Seward From pearu at scipy.org Thu Oct 30 13:21:47 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 30 Oct 2003 12:21:47 -0600 (CST) Subject: [SciPy-dev] RPM build problem In-Reply-To: <1067537283.28684.5.camel@sonylap1> Message-ID: On Thu, 30 Oct 2003, Anthony Joseph Seward wrote: > Lines 19 and 20 of scipy/setup.py are causing problems with the > bdist_rpm command. I commented them out and the build works fine as > instructed in PACKAGERS.txt > > The offending lines: > assert 'scipy_core'==os.path.basename(os.path.dirname(\ > scipy_distutils.__path__[0])), scipy_distutils.__path__[0] > > What was the intention of these lines? The intention was to ensure that setup.py imports scipy_core packages from the CVS tree, not from the installation tree (where they might not be updated). When running bdist_rpm command, the situation is a bit different and it is OK to remove the offending assert statement. I'll fix setup.py and complete other TODO tasks (applying import hooks to chaco packages, clean ups, updating PACKAGERS.txt, etc) related to new importing hooks in the next couple of days. Pearu From pearu at scipy.org Thu Oct 30 13:47:37 2003 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 30 Oct 2003 12:47:37 -0600 (CST) Subject: [SciPy-dev] Windows endlines in CVS In-Reply-To: <1067537846.28684.16.camel@sonylap1> Message-ID: On Thu, 30 Oct 2003, Anthony Joseph Seward wrote: > There are some Windows endlines in the CVS repository. Is this > considered a bug? It goofs with my scripts and so I was wondering if it > could be fixed. I can make a patch. Yeah, this seems to be a constant problem and I am not sure that applying patches will fix it. As soon as a developer under windows commits new changes to CVS repository, the problem is there again. This is my guess and I might be wrong. So, if you can send just the file names that contain Windows endlines, that would be great. Then we can apply flip command ourself to these files. Pearu From anthony.seward at ieee.org Thu Oct 30 15:18:03 2003 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Thu, 30 Oct 2003 13:18:03 -0700 Subject: [SciPy-dev] Windows endlines in CVS In-Reply-To: References: Message-ID: <1067545082.28684.18.camel@sonylap1> Lib/weave/examples/object.py Lib/weave/tests/scxx_timings.py Lib_chaco/agg2/examples/linux_sdl/gradients/Makefile Lib_chaco/agg2/examples/linux_sdl/images1/Makefile Lib_chaco/agg2/examples/linux_sdl/lion/Makefile Lib_chaco/agg2/examples/win32_api/conv_dash_marker/conv_dash_marker.dsp Lib_chaco/agg2/examples/win32_api/conv_dash_marker/conv_dash_marker.dsw Lib_chaco/agg2/examples/win32_api/conv_stroke/conv_stroke.dsp Lib_chaco/agg2/examples/win32_api/conv_stroke/conv_stroke.dsw Lib_chaco/agg2/examples/win32_api/conv_stroke/conv_stroke.plg Lib_chaco/agg2/examples/win32_api/images1/image1.dsp Lib_chaco/agg2/examples/win32_api/images1/image1.dsw Lib_chaco/agg2/examples/win32_mfc/CustomRasterizer/res/CustomRasterizer.rc2 Lib_chaco/agg2/examples/win32_mfc/CustomRenderer/res/CustomRenderer.rc2 Lib_chaco/chaco/fill.py Lib_chaco/chaco/demo/__init__.py Lib_chaco/chaco/demo/scripts/group_test.co Lib_chaco/chaco/demo/scripts/simple.co Lib_chaco/chaco/extras/plot_list.py Lib_chaco/freetype/__init__.py Lib_chaco/freetype/docs/notes.html Lib_chaco/freetype/docs/notes.txt Lib_chaco/freetype/freetype2/src/base/ftglyph.c.bak Lib_chaco/freetype/src/build_ft.py Lib_chaco/freetype/src/ft_spec.py Lib_chaco/freetype/tests/test_freetype.py Lib_chaco/kiva/__init__.py Lib_chaco/kiva/colormap.py Lib_chaco/kiva/geometry.py Lib_chaco/kiva/macexample.py Lib_chaco/traits/standard.py Lib_chaco/traits/trait_errors.py Lib_chaco/traits/tests/test_timing.py On Thu, 2003-10-30 at 11:47, Pearu Peterson wrote: > On Thu, 30 Oct 2003, Anthony Joseph Seward wrote: > > > There are some Windows endlines in the CVS repository. Is this > > considered a bug? It goofs with my scripts and so I was wondering if it > > could be fixed. I can make a patch. > > Yeah, this seems to be a constant problem and I am not sure that applying > patches will fix it. As soon as a developer under windows commits new > changes to CVS repository, the problem is there again. This is my guess > and I might be wrong. So, if you can send just the file names that contain > Windows endlines, that would be great. Then we can apply flip command > ourself to these files. > > Pearu > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev -- Anthony Joseph Seward