From pearu at scipy.org Sun Jan 4 06:23:21 2004 From: pearu at scipy.org (Pearu Peterson) Date: Sun, 4 Jan 2004 05:23:21 -0600 (CST) Subject: [SciPy-dev] weave moved to scipy_core in CVS Message-ID: Hi, weave module is now moved to scipy_core. This simplifies building scipy/chaco modules that need weave (that might not be installed when first checking out scipy/chaco modules). So, when updating scipy or chaco_all or any other CVS module that contained weave then you'll probably see the following message: cvs server: cannot open directory /home/cvsroot/world/scipy/Lib/weave: \ No such file or directory In that case you should remove your local copy of weave (or if you have made changes to local weave then make a backup) and re-run 'cvs update' or 'cvs co weave'. Regards, Pearu From arnd.baecker at web.de Mon Jan 5 04:51:43 2004 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 5 Jan 2004 10:51:43 +0100 (CET) Subject: [SciPy-dev] band matrices in scipy In-Reply-To: References: Message-ID: Hi, I continued working on the wrapper for dsbev, dsbevd and dsbevx. The present status can be obtained from http://www.physik.tu-dresden.de/~baecker/python/Band.zip Before I continue with the last changes so that it could be included in scipy it would be nice if someone (Pearu ?;-) with more knowledge of f2py has a quick look at it. Concerning dsbevx I have the following questions: a) abstol parameter: from dsbev.f: "Eigenvalues will be computed most accurately when ABSTOL is set to twice the underflow threshold 2*DLAMCH('S'), not zero." Maybe the easiest (best?) is to wrap DLAMCH as well (easy) and let the user provide the value, if necessary? ((Even nicer would be to compute this value internally - is this possible with f2py ? If not, I am not sure if adding this is worth the effort...)) b) Presently I suppress the array q Q (output) DOUBLE PRECISION array, dimension (LDQ, N) If JOBZ = 'V', the N-by-N orthogonal matrix used in the reduction to tridiagonal form. If JOBZ = 'N', the array Q is not referenced. Should one better return this as well and therefore replace double precision dimension(ldq,ldq),intent(hide),depend(ldq) :: q by double precision dimension(ldq,ldq),intent(out),depend(ldq) :: q ? c) Should one make vl,vu,il,iu, optional as well ? Background: dsbevx allows to compute range: 0 = 'A': all eigenvalues will be found; 1 = 'V': all eigenvalues in the half-open interval (vl,vu] will be found; 2 = 'I': the il-th through iu-th eigenvalues will be found. so we may have that either vl,vu or il,iu or neither of the two pairs are used. If one makes all vl,vu,il,iu, optional, one could set set the defaults to il=0 iu=10 vl=0.0 vu=20.0 # this of course absolutely # dependent on the problem, # i.e in general nonsense... And one more remark/question concerning the copying of arrays when using f2py - sorry if I re-state things already said before, but I just want to make sure that I understand things correctly here. First the option -DF2PY_REPORT_ON_ARRAY_COPY=1 is very helpful (thanks Pearu for pointing this out). With this I get the following picture (please correct me if I am wrong!): If one allocates a matrix in python with mat=zeros( (N,M)) this is not Fortran contiguous, so a copy is done. However, declaring mat=transpose(zeros(M,N)) one obtains a Fortran contiguous array and no copy is done. If this is correct, would you say that the second variant is a good way or is there a better one? Many thanks, Arnd From bgoli at sun.ac.za Mon Jan 12 08:23:22 2004 From: bgoli at sun.ac.za (Brett G. Olivier) Date: Mon, 12 Jan 2004 15:23:22 +0200 (SAST) Subject: [SciPy-dev] Windows build, possible problem with scipy_distutils MinGW support Message-ID: <1142.146.232.210.120.1073913802.squirrel@glue.jjj.sun.ac.za> Hi I have been trying to build scipy on win2k (Python 2.3, scipy cvs ver. '0.2.1_252.4501') using MinGW. One problem in the build process is a strange call to a program "g" when building the cluster module (the other is a problem building the specfun library), a possible solution can be found by making a change in scipy_distutils: mingw32_support.py As far as the cluster build problem is concerned: compiling scipy with "python setup.py build --compiler=mingw32" results in the following error: "g -shared build\temp.win32-2.3\Release\lib\cluster\src\vq_wrap.o -Lc:\python23\libs -Lc:\python23\PCBuild -Lbuild\temp.win32-2.3 -lpython23 -lrootfind -lc_misc-lcephes -o build\lib.win32-2.3\scipy\cluster\_vq.pyd error: command 'g' failed: No such file or directory" I have tracked down the probable source of this problem in mingw32_support.py: Line 96: self.compiler_cxx = 'g++' If I understand it correctly MinGW uses python distutils UnixCCompiler which in unixccompiler.py has: Line 174: if target_lang == "c++" and self.compiler_cxx: Line 175: linker[0] = self.compiler_cxx[0] I think this is the source of the phantom "g" call. In mingw32_support.py altering Line 96: Line 96: self.compiler_cxx = 'g++' Line 96: self.compiler_cxx = ['g++'] seems to sort this problem out. I'm not at all sure if this is a proper solution to this problem or not, any comments or questions are more than welcome. Best regards Brett -- Brett G. Olivier (bgoli at sun ac za) Biochemistry Dept, Stellenbosch University Tel: +27-21-8085871 Fax: +27-218085863 From pearu at scipy.org Mon Jan 12 08:47:11 2004 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 12 Jan 2004 07:47:11 -0600 (CST) Subject: [SciPy-dev] Windows build, possible problem with scipy_distutils MinGW support In-Reply-To: <1142.146.232.210.120.1073913802.squirrel@glue.jjj.sun.ac.za> Message-ID: On Mon, 12 Jan 2004, Brett G. Olivier wrote: > I have been trying to build scipy on win2k (Python 2.3, scipy cvs ver. > '0.2.1_252.4501') using MinGW. One problem in the build process is a > strange call to a program "g" when building the cluster module (the other > is a problem building the specfun library), a possible solution can be > found by making a change in scipy_distutils: mingw32_support.py > > As far as the cluster build problem is concerned: compiling scipy with > "python setup.py build --compiler=mingw32" > > results in the following error: > > "g -shared build\temp.win32-2.3\Release\lib\cluster\src\vq_wrap.o > -Lc:\python23\libs -Lc:\python23\PCBuild -Lbuild\temp.win32-2.3 -lpython23 > -lrootfind -lc_misc-lcephes -o build\lib.win32-2.3\scipy\cluster\_vq.pyd > error: command 'g' failed: No such file or directory" > > I have tracked down the probable source of this problem in > mingw32_support.py: > > Line 96: self.compiler_cxx = 'g++' > > If I understand it correctly MinGW uses python distutils UnixCCompiler > which in unixccompiler.py has: > > Line 174: if target_lang == "c++" and self.compiler_cxx: > Line 175: linker[0] = self.compiler_cxx[0] > > I think this is the source of the phantom "g" call. In mingw32_support.py > altering Line 96: > > Line 96: self.compiler_cxx = 'g++' > Line 96: self.compiler_cxx = ['g++'] > > seems to sort this problem out. > > I'm not at all sure if this is a proper solution to this problem or not, > any comments or questions are more than welcome. Thanks for tracking this down. I have applied your patch to CVS. It shouldn't affect pre 2.3 Python versions as their distutils are not using compiler_cxx. Thanks, Pearu From travis at enthought.com Mon Jan 19 14:53:01 2004 From: travis at enthought.com (Travis N. Vaught) Date: Mon, 19 Jan 2004 13:53:01 -0600 Subject: [SciPy-dev] specfun compile errors on windows Message-ID: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> Greetings, I finally have taken the time to look at our nightly builds of scipy for win32 and noticed that specfun is not compiling--as some have reported here: http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002 457.html and a link to the threaded discussion is here: http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/thr ead.html Specifically you get an 'internal compiler error' when you have -O3 set (using no optimization setting seems to work). I've tried it with gcc ~3.2 and it compiles fine but 3.2.3 and a 3.3.1 (that comes with cygwin) were not able to compile it. Since specfun.f is a rather large file it would be impossible for me to reduce this to a simple case for reporting to the g77 folks or finding a workaround. Does anyone (Travis O.?) want to take a stab at this? (It would stink to have to specify gcc 3.2 or below as a build requirement on windows.) Thanks, Travis BTW Here's what I get with gcc 3.3.1: ....... Lib\special\specfun\specfun.f: In subroutine `cgama': Lib\special\specfun\specfun.f:7786: warning: `y1' might be used uninitialized in this function Lib\special\specfun\specfun.f:7794: warning: `na' might be used uninitialized in this function Lib\special\specfun\specfun.f: In subroutine `aswfb': Lib\special\specfun\specfun.f:7871: warning: `sw' might be used uninitialized in this function Lib\special\specfun\specfun.f:7881: Internal compiler error in emit_swap_insn, a t reg-stack.c:990 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. warning: build_py: package init file 'Lib\tests\__init__.py' not found (or not a regular file) warning: build_py: package init file 'c:\temp\2.1\scipy\Lib\cluster\tests\__init __.py' not found (or not a regular file) warning: build_py: package init file 'c:\temp\2.1\scipy\Lib\fftpack\tests\__init __.py' not found (or not a regular file) ...... ........................ Travis N. Vaught Enthought, Inc. (512)536-1057 http://www.enthought.com ........................ From oliphant at ee.byu.edu Mon Jan 19 14:04:15 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 19 Jan 2004 13:04:15 -0600 Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> References: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> Message-ID: <400C2A2F.10400@ee.byu.edu> Travis N. Vaught wrote: >Greetings, > >I finally have taken the time to look at our nightly builds of scipy for >win32 and noticed that specfun is not compiling--as some have reported >here: > >http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002 >457.html > >and a link to the threaded discussion is here: > >http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/thr >ead.html > >Specifically you get an 'internal compiler error' when you have -O3 set >(using no optimization setting seems to work). > >I've tried it with gcc ~3.2 and it compiles fine but 3.2.3 and a 3.3.1 >(that comes with cygwin) were not able to compile it. > > > I went through this same process and discovered it as well. I will try to localize the error to one subroutine and submit it as a bug-report to the g77 people. I agree that it is a pain to have to eliminate -O3 for one file. From pearu at scipy.org Mon Jan 19 15:20:46 2004 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 19 Jan 2004 14:20:46 -0600 (CST) Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> Message-ID: On Mon, 19 Jan 2004, Travis N. Vaught wrote: > Greetings, > > I finally have taken the time to look at our nightly builds of scipy for > win32 and noticed that specfun is not compiling--as some have reported > here: > > http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002 > 457.html > > and a link to the threaded discussion is here: > > http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/thr > ead.html > > Specifically you get an 'internal compiler error' when you have -O3 set > (using no optimization setting seems to work). > > I've tried it with gcc ~3.2 and it compiles fine but 3.2.3 and a 3.3.1 > (that comes with cygwin) were not able to compile it. > > Since specfun.f is a rather large file it would be impossible for me to > reduce this to a simple case for reporting to the g77 folks or finding a > workaround. Does anyone (Travis O.?) want to take a stab at this? (It > would stink to have to specify gcc 3.2 or below as a build requirement > on windows.) One possible workaround that might be worth to try is to separate the two offending functions (RMN2L and ASWFB) in specfun.f to two different files (rmn2l.f and aswfb.f). Hopefully, g77 will compile them with -O3. If not, then at least the sizes of files are much smaller in order to find a workaround. Note that I am currently working on scipy_distutils and there might be a simple way to use different compiler flags for different sources. But in order to keep it simple, the sources should reside in different directories (that should contain setup.cfg files where it is possible to enable/disable optimization flags). So, this gives another solution if nothing else will work. Pearu From bgoli at sun.ac.za Mon Jan 19 15:27:11 2004 From: bgoli at sun.ac.za (Brett G. Olivier) Date: Mon, 19 Jan 2004 22:27:11 +0200 (SAST) Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: References: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> Message-ID: <1068.196.30.179.72.1074544031.squirrel@glue.jjj.sun.ac.za> Hi I have been looking into this problem and submitted it as a bug to the MinGW people (I'll put the bug report at the end of this email). The reply I got from them was: ======================================================= Comment By: Danny Smith (dannysmith) Date: 2004-01-10 09:45 This is a gcc bug that is fixed in gcc 3.3.3 and trunck sources. Danny ======================================================= I was hoping that mingw + gcc 3.3.3 would arrive soon enough and make this go away? Best regards Brett ============================ Original bug report to mingw Category: gcc Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Olivier (bgoli) Assigned to: Danny Smith (dannysmith) Summary: g77 (gcc 3.3.1) emit_swap_insn internal compiler error Initial Comment: A specific combination (-O3 -funroll-loops - march=pentium3) of compiler flags causes g77 to fail with an internal compiler error with the attached routines Compile command: g77 -Wall -fno-second-underscore -O3 -funroll-loops - march=pentium3 -malign-double -fomit-frame-pointer -c specfun_error_func.f -o specfun_error_func.o Output: specfun_error_func.f: In subroutine `rmn2l': specfun_error_func.f:32: warning: `sw' might be used uninitialized in this funct ion specfun_error_func.f:38: warning: `lg' might be used uninitialized in this funct ion specfun_error_func.f:45: warning: `np' might be used uninitialized in this funct ion specfun_error_func.f:47: warning: `eps1' might be used uninitialized in this fun ction specfun_error_func.f:69: warning: `eps2' might be used uninitialized in this fun ction specfun_error_func.f:75: internal compiler error: in emit_swap_insn, at reg-stac k.c:987 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. After playing around a bit I found the following two workarounds that allow me to compile these two functions. Current workaround (1) remove flag: -O3 ================= Compile command: g77 -Wall -fno-second-underscore -funroll-loops - march=pentium3 -malign-double -fomit-frame-pointer -c specfun_error_func.f -o specfun_error_func.o Output: compiles OK Current workaround (2) remove flags: -funroll-loops -march=pentium3 ================= Compile command: g77 -Wall -fno-second-underscore -O3 -malign-double - fomit-frame-pointer -c specfun_error_func.f -o specfun_error_func.o Output: compiles OK Environment ========= OS == Windows 2000 SP 4 gcc -v ====== Reading specs from c:/mingw/bin/../lib/gcc- lib/mingw32/3.3.1/specs Configured with: ../gcc/configure --with-gcc --with-gnu- ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable- threads --disable-nls --enable -languages=c,c++,f77,objc,ada,java --disable-win32- registry --disable-shared --e nable-sjlj-exceptions --enable-libgcj --disable-java-awt - -without-x --enable-ja va-gc=boehm --disable-libgcj-debug --enable- interpreter --enable-hash-synchroniz ation Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1) ld -v ==== GNU ld version 2.13.90 20030111 MinGW installer + updates =================== MinGW-3.1.0-1.exe binutils-2.13.90-20030111-1.tar.gz gcc-core-3.3.1-20030804-1.tar.gz gcc-g++-3.3.1-20030804-1.tar.gz gcc-g77-3.3.1-20030804-1.tar.gz mingw-runtime-3.2.tar.gz w32api-2.4.tar.gz ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2004-01-10 09:45 Message: Logged In: YES user_id=11494 This is a gcc bug that is fixed in gcc 3.3.3 and trunck sources. Danny ---------------------------------------------------------------------- > > > On Mon, 19 Jan 2004, Travis N. Vaught wrote: > >> Greetings, >> >> I finally have taken the time to look at our nightly builds of scipy for >> win32 and noticed that specfun is not compiling--as some have reported >> here: >> > Note that I am currently working on scipy_distutils and there might be > a simple way to use different compiler flags for different sources. > But in order to keep it simple, the sources should reside in different > directories (that should contain setup.cfg files where it is possible > to enable/disable optimization flags). So, this gives another solution > if nothing else will work. > > Pearu > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > -- Brett G. Olivier (bgoli at sun . ac . za) Biochemistry Dept, Stellenbosch University Tel: +27-21-8085871 Fax: +27-218085863 From oliphant at ee.byu.edu Mon Jan 19 14:55:46 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 19 Jan 2004 13:55:46 -0600 Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: References: Message-ID: <400C3642.7020303@ee.byu.edu> Pearu Peterson wrote: >One possible workaround that might be worth to try is to separate the two >offending functions (RMN2L and ASWFB) in specfun.f to two different >files (rmn2l.f and aswfb.f). Hopefully, g77 will compile them with -O3. >If not, then at least the sizes of files are much smaller in order >to find a workaround. > > > I have taken aswfb out of the specfun file and now the rest of the specfun.f file compiles normally. The extracted subroutine still gives the error which I will submit to the gcc bug database. It would appear that it is -O3 and -funroll-loops flags together that give the problem (any other combination of the flags does not seem to reproduce the error for me). What error are you getting on rmn21.f ? I don't see any error there. -Travis O. > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > > From pearu at scipy.org Mon Jan 19 16:25:59 2004 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 19 Jan 2004 15:25:59 -0600 (CST) Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: <400C3642.7020303@ee.byu.edu> Message-ID: On Mon, 19 Jan 2004, Travis Oliphant wrote: > Pearu Peterson wrote: > > >One possible workaround that might be worth to try is to separate the two > >offending functions (RMN2L and ASWFB) in specfun.f to two different > >files (rmn2l.f and aswfb.f). Hopefully, g77 will compile them with -O3. > >If not, then at least the sizes of files are much smaller in order > >to find a workaround. > > > I have taken aswfb out of the specfun file and now the rest of the > specfun.f file compiles normally. The extracted subroutine still gives > the error which I will submit to the gcc bug database. Have you played with the loops and the code of this function? May be recoding with a different style might cause g77 to succeed? > It would appear that it is -O3 and -funroll-loops flags together that > give the problem (any other combination of the flags does not seem to > reproduce the error for me). If that is the case then we can disable -funroll-loops instead of -O3 for bugy gcc versions, -O3 should be more useful than unrolling loops. This is very simple in build_flib.py. Could you sum up under which conditions the compiler bug appears? The following information should be enough: os.name os.uname sys.platform g77 --version # only the version numbers when there is a failure # and when not. Then I can make a patch to build_flib.py to resolve this issue. > What error are you getting on rmn21.f ? I took this information from http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002459.html > I don't see any error there. Good. Pearu From oliphant at ee.byu.edu Mon Jan 19 16:41:39 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 19 Jan 2004 15:41:39 -0600 Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> References: <0f1001c3dec5$dbae4260$af01a8c0@tvlaptop> Message-ID: <400C4F13.3040201@ee.byu.edu> It looks like several people are working on this at once. I have heard that this bug in gcc 3.3.1 is fixed in later versions of gcc. I altered the fortran file so that an uniitialized variable is now initialized prior to a loop and this seems to avoid the compiler bug. Please check the new specfun.f file to see if it works right without any other compiler tweaking... It seems to for me. -Travis O. From oliphant at ee.byu.edu Mon Jan 19 16:49:59 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 19 Jan 2004 15:49:59 -0600 Subject: [SciPy-dev] Strang error on cygwin Message-ID: <400C5107.8000907@ee.byu.edu> I periodically get this strange error which is probably due to the way I am using cygwin. I'm wondering if someone with more experience on cygwin could help me. Say I'm using the cygwin bash shell and I set my Path to grab the enthought Python binary first but the cygwin copy of gcc PATH=/cygdrive/c/Python23:/usr/bin:/bin Now, when I run python setup.py build --compiler=mingw32 install I get the following error: building 'scipy.cluster._vq' extension cygiwn_output_dir: build\temp.win32-2.3\Release here build\temp.win32-2.3\Release\lib\cluster\src\vq_wrap.o ...: build\temp.win32-2.3\Release lib\cluster\src\vq_wrap.o C:\cygwin\bin\gcc.exe -O2 -w -Wstrict-prototypes -Ic:\Python23\include -Ic:\Pyth on23\PC -c Lib\cluster\src/vq_wrap.cpp -o build\temp.win32-2.3\Release\lib\clust er\src\vq_wrap.o In file included from c:/Python23/include/Python.h:75, from Lib/cluster/src/vq_wrap.cpp:176: c:/Python23/include/intobject.h:41: error: syntax error before `(' token In file included from c:/Python23/include/Python.h:77, from Lib/cluster/src/vq_wrap.cpp:176: c:/Python23/include/longobject.h:37: error: `__int64' was not declared in this scope c:/Python23/include/longobject.h:39: error: syntax error before `*' token c:/Python23/include/longobject.h:40: error: syntax error before `(' token c:/Python23/include/longobject.h:41: error: syntax error before `(' token error: command 'gcc' failed with exit status 1 I'm wondering if this is somehow due to path issues, but it seems tied up in distutils. Am I being foolish to try and use the Enthought Python2.3 windows binary with the cygwin gcc compiler (the -mno-cygwin option that distutils provides ensures that the dll won't link against cygwin).? Thanks for any insight. -Travis O. From pearu at scipy.org Mon Jan 19 19:13:33 2004 From: pearu at scipy.org (Pearu Peterson) Date: Mon, 19 Jan 2004 18:13:33 -0600 (CST) Subject: [SciPy-dev] specfun compile errors on windows In-Reply-To: <400C4F13.3040201@ee.byu.edu> Message-ID: On Mon, 19 Jan 2004, Travis Oliphant wrote: > It looks like several people are working on this at once. > > I have heard that this bug in gcc 3.3.1 is fixed in later versions of gcc. > > I altered the fortran file so that an uniitialized variable is now > initialized prior to a loop and this seems to avoid the compiler > bug. > > Please check the new specfun.f file to see if it works right without > any other compiler tweaking... > > It seems to for me. I think this is just great! Such a small change will make recent scipy available to a large number of Windows users after so long time.. Thanks, Pearu From oliphant at ee.byu.edu Mon Jan 19 22:12:02 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Mon, 19 Jan 2004 21:12:02 -0600 Subject: [SciPy-dev] Error on Linux Compile Message-ID: <400C9C82.5040805@ee.byu.edu> Pearu, I checked out a recent version of SciPy and installed on my Mandrake 9.2 Linux box (hard-drive choked) After a clean build and install (no fftw or djbfft) I am getting the following error. undefined symbol: fftr8_scale1024 in _fftpack.so I will try and track this down, but wondered if you recognized this call and why I suddenly wouldn't have it on my system. -Travis O. From pearu at scipy.org Tue Jan 20 04:02:01 2004 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 20 Jan 2004 03:02:01 -0600 (CST) Subject: [SciPy-dev] Error on Linux Compile In-Reply-To: <400C9C82.5040805@ee.byu.edu> Message-ID: On Mon, 19 Jan 2004, Travis Oliphant wrote: > Pearu, > > I checked out a recent version of SciPy and installed on my Mandrake 9.2 > Linux box (hard-drive choked) > > After a clean build and install (no fftw or djbfft) I am getting the > following error. > > undefined symbol: fftr8_scale1024 in _fftpack.so > > I will try and track this down, but wondered if you recognized this call > and why I suddenly wouldn't have it on my system. This symbol is defined in the djbfft library and scipy uses it only in fftpack/src/drfft.c. But only when WITH_DJBFFT is defined. Are you sure that your build is absolutely clean? 'rm -rf build' might help. I tried fftpack build without fftw and djbfft support, everything looks ok here. Pearu From nwagner at mecha.uni-stuttgart.de Tue Jan 20 04:36:39 2004 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 20 Jan 2004 10:36:39 +0100 Subject: [SciPy-dev] Error on Linux Compile References: Message-ID: <400CF6A7.42A8EFE0@mecha.uni-stuttgart.de> Pearu Peterson schrieb: > > On Mon, 19 Jan 2004, Travis Oliphant wrote: > > > Pearu, > > > > I checked out a recent version of SciPy and installed on my Mandrake 9.2 > > Linux box (hard-drive choked) > > > > After a clean build and install (no fftw or djbfft) I am getting the > > following error. > > > > undefined symbol: fftr8_scale1024 in _fftpack.so > > > > I will try and track this down, but wondered if you recognized this call > > and why I suddenly wouldn't have it on my system. > > This symbol is defined in the djbfft library and scipy uses it only > in fftpack/src/drfft.c. But only when WITH_DJBFFT is defined. > Are you sure that your build is absolutely clean? 'rm -rf build' might > help. I tried fftpack build without fftw and djbfft support, everything > looks ok here. > > Pearu > BTW, a make in djbfft-0.76 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] Error 1 Any idea ? Nils > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From cookedm at physics.mcmaster.ca Tue Jan 20 13:09:32 2004 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Tue, 20 Jan 2004 13:09:32 -0500 Subject: [SciPy-dev] Error on Linux Compile In-Reply-To: <400CF6A7.42A8EFE0@mecha.uni-stuttgart.de> References: <400CF6A7.42A8EFE0@mecha.uni-stuttgart.de> Message-ID: <20040120180932.GA7850@arbutus.physics.mcmaster.ca> On Tue, Jan 20, 2004 at 10:36:39AM +0100, Nils Wagner wrote: > Pearu Peterson schrieb: > BTW, a make in djbfft-0.76 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] Error 1 Just ran into this a few days ago. Apply the following patch. New versions of glibc require errno.h to be included everywhere errno is used (it does something funky to work around that errno is global when using threads, I think.) --- djbfft-0.76/error.h 1999-09-30 16:25:58.000000000 -0400 +++ djbfft-0.76.new/error.h 2004-01-15 19:30:33.000000000 -0500 @@ -1,6 +1,8 @@ #ifndef ERROR_H #define ERROR_H +#include + extern int errno; extern int error_intr; -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From prabhu at aero.iitm.ernet.in Wed Jan 28 00:50:45 2004 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 28 Jan 2004 11:20:45 +0530 Subject: [SciPy-dev] Re: [vtkusers] c api and python and vtk - with SWIG In-Reply-To: <9A9D4EFC-5109-11D8-9FAB-000393449862@post.rwth-aachen.de> References: <313ca49.8db9fd7.8163900@expms1.cites.uiuc.edu> <9A9D4EFC-5109-11D8-9FAB-000393449862@post.rwth-aachen.de> Message-ID: <16407.19893.661122.950461@monster.linux.in> >>>>> "MA" == Mark Asbach writes: >> I have a set of C codes that manipulate a data structure, one >> component of which is an array of doubles. I've managed to >> wrap the C codes with SWIG so I have access to the structure >> with the typical SWIG accessor functions, >> i.e. Sp4Array_data_get() What do I have to do to get this data >> array into vtk? MA> The way I took for my code is to just write the conversion to MA> vtk data structures in C, wrap them with SWIG and mix that MA> with the vtk python stuff. There is a bug in the current SWIG MA> adaptor code of VTK though, and I don't know, if David MA> committed my fix to the repository already (David?). In general and especially when you have Numeric arrays, this is much easier to do if you use Weave. I completely forgot about it and never posted about it, sorry! My apologies also for the cross-posting. Here are some details. http://www.scipy.org/site_content/weave Weave is a neat tool that lets you write C++ code straight inside your Python code. The first time the Python script is run, the C++ code is compiled to a module, and stored in a special place (all done automatically). The next time the script runs, the script will use the compiled module. Weave generates all the standard boiler plate code to convert the objects, return values etc. I've not played with generic SWIG pointers, but it should be possible to use too. A long while ago I wrote a small component that makes it trivial to embed VTK C++ code inside a VTK-Python script. If you use weave from CVS this is available. I am not sure if the tarball at the Weave web site has this part and if it does not please ask on the scipy-dev list that I've CC'd for clarifications etc. I've also not tested this under MSVC. Only under Linux with g++. YMMV. Anyway, here is a trivial example that I used to test with. I convert a reasonably large Numeric array to a vtkFloatArray. # ------------ try: from scipy import weave except ImportError: import weave import vtk import sys import Numeric import time # change these to suit your needs. inc_dirs=['/cvs/VTK/','/cvs/VTK/Common'] lib_dirs=['/cvs/VTK/bin'] def simple_test(): a = vtk.vtkStructuredPoints() # Your C++ code code=""" printf("Inline a->ClassName() == %s\n", a->GetClassName()); printf("Inline a->GetReferenceCount() == %d\n", a->GetReferenceCount()); """ # Now execute this. weave.inline(code, ['a'], include_dirs=inc_dirs, library_dirs=lib_dirs) def test(): arr = Numeric.arange(0, 10, 0.0001) print "Number of elements in array = ", arr.shape[0] v_arr = vtk.vtkFloatArray() ts = time.time() for i in range(arr.shape[0]): v_arr.InsertNextValue(arr[i]) print "Time taken to do it in pure Python =", time.time() - ts v_arr = vtk.vtkFloatArray() # Your C++ code code = """ int size = Narr[0]; for (int i=0; iInsertNextValue(arr[i]); """ ts = time.time() # Execute it. weave.inline(code, ['arr', 'v_arr'], include_dirs=inc_dirs, library_dirs=lib_dirs) # Note, if you need special headers for compilation, add them via # an extra keyword arg., headers=["vtkFoo.h"] print "Time taken to do it using Weave =", time.time() - ts print "Checking data." for i in range(v_arr.GetNumberOfTuples()): val = (v_arr.GetValue(i) -arr[i] ) assert (val < 1e-6), "i = %d, val= %f"%(i, val) print "OK." if __name__ == "__main__": simple_test() test() # ------------ The example is certainly trivial, but shows you how it works. This is also old code and I am not sure how things have changed recently. For more details check the weave docs. On my machine I get these results: Inline a->ClassName() == vtkStructuredPoints Inline a->GetReferenceCount() == 2 Number of elements in array = 100000 Time taken to do it in pure Python = 0.800973892212 Time taken to do it using Weave = 0.0328440666199 Checking data. OK. Which is an ~25 fold speed increase. Its been a while since I used/wrote this so I'm most probably not the right person to ask questions. I just wanted to let you folks know of this option. You might be better served asking questions on scipy-dev. cheers, prabhu