From kern at caltech.edu Sun Sep 2 22:59:26 2001 From: kern at caltech.edu (Robert Kern) Date: Sun, 2 Sep 2001 19:59:26 -0700 Subject: [SciPy-dev] LAPACK is not thread-safe (AFAICT) Message-ID: <20010902195926.A20656@myrddin.caltech.edu> Disclaimer: I'm not a FORTRAN programmer or a thread expert. In linalg/docs/more_notes, Eric says he knows of no reason that any of the LAPACK functions wouldn't be thread-safe. However, I have run across a USENET discussion saying that some are not thread-safe. Some of the Netlib LAPACK's functions use FORTRAN's SAVE statement to preserve variable values across invocations, and this makes them thread-unsafe (AFAICT). C.f. http://groups.google.com/groups?q=LAPACK+thread&hl=en&safe=off&rnum=1&selm=ceee3b79.0108241520.57157bb6%40posting.google.com The affected routines are dlacon, dlaed6, dlamch, dlartg, dlasq3, dlasq4, zlacon, zlargv, zlartg, and their single-precision equivalents. Also, any function calling one of these functions is not thread-safe either. ATLAS is thread-safe, but of course, not all of the LAPACK routines have been integrated. Some vendor LAPACK libraries appear to be threadsafe. I don't know how useful this information is; I just wanted to throw it out there before someone adds the Py_BEGIN_ALLOW_THREADS to the wrappers. -- Robert Kern kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From europax at home.com Mon Sep 3 12:39:38 2001 From: europax at home.com (Rob) Date: Mon, 03 Sep 2001 09:39:38 -0700 Subject: [SciPy-dev] documentation Message-ID: <3B93B249.A3E8B37D@home.com> Is there a non-html version of the documentation. Like the Numpy manual, I like to print out the whole thing and keep it as a reference. Plain text would be wonderful. Thanks, Rob. ps. I still can't get the package to compile on FreeBSD, even setting X11=0. It can't find my Fortran compiler f77, even though it exists. -- The Numeric Python EM Project www.members.home.net/europax From kern at caltech.edu Thu Sep 6 16:36:10 2001 From: kern at caltech.edu (Robert Kern) Date: Thu, 6 Sep 2001 13:36:10 -0700 Subject: [SciPy-dev] scipy.linalg and LAPACK 3.0 Message-ID: <20010906133610.A18337@myrddin.caltech.edu> Hi, Some of the routines wrapped in generic_lapack.pyf seem to be deprecated in LAPACK 3.0, notably _GESVD, which is rather slower than the new _GESDD. Is there a reason for this (e.g. compatibility for people who haven't upgraded their LAPACK, yet), or has simply no-one done the work, yet? If the latter, I'll see what I can come up with and contribute. -- Robert Kern kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From eric at scipy.org Thu Sep 6 16:03:13 2001 From: eric at scipy.org (eric jones) Date: Thu, 6 Sep 2001 16:03:13 -0400 Subject: [SciPy-dev] scipy.linalg and LAPACK 3.0 References: <20010906133610.A18337@myrddin.caltech.edu> Message-ID: <00c101c1370e$f6758010$c100a8c0@ericlaptop> I'd say the latter of the two. I started linalg months ago, and Travis O. put a lot of effort into over the last several weeks. I'm not really familiar with 3.0 -- we are really focusing on ATLAS cause it is so dang fast on most platforms. It doesn't provide a full LAPACK though, so you have to merge it with another LAPACK to get everything. If you can figure out how to write a generic interface (not to hard, but only partially documented in /linalg/docs/more_notes), then have at it. The actual f2py interfaces are generated from a python script. The more interfaces the merrier, but the compatibility issue has to be addressed. On Unix, we could use 'nm' to check if the function is there. On windows it ain't so easy. Maybe it should just be an optional function for now (i.e. defaults to being commented out) for the widest compatibility. eric ----- Original Message ----- From: "Robert Kern" To: Sent: Thursday, September 06, 2001 4:36 PM Subject: [SciPy-dev] scipy.linalg and LAPACK 3.0 > Hi, > > Some of the routines wrapped in generic_lapack.pyf seem to be deprecated in > LAPACK 3.0, notably _GESVD, which is rather slower than the new _GESDD. Is there > a reason for this (e.g. compatibility for people who haven't upgraded their > LAPACK, yet), or has simply no-one done the work, yet? > > If the latter, I'll see what I can come up with and contribute. > > -- > Robert Kern > kern at caltech.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From jochen at unc.edu Thu Sep 27 10:26:13 2001 From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=) Date: 27 Sep 2001 10:26:13 -0400 Subject: [SciPy-dev] SciPy on Cygwin Message-ID: <86d74cr9q2.fsf@bock.chem.unc.edu> I am trying to compile SciPy (cvs) on latest Cygwin (all packages besides postgresql, irc installed). Anybody got that going? - gcc version 2.95.3-5 (cygwin special) - Python 2.1.1 (#2, Sep 26 2001, 09:32:53) [GCC 2.95.3-5 (cygwin special)] on cygwin - NumPy from cvs as of today The problem I am running into in linalg is that I get compile errors in flapackmodule.c: ,---- | linalg/flapackmodule.c:447: initializer element is not constant | linalg/flapackmodule.c:502: initializer element is not constant | linalg/flapackmodule.c:557: initializer element is not constant | linalg/flapackmodule.c:616: initializer element is not constant `---- The respective code is ,----[flapackmodule.c: 447] | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; `---- I am not sure what to do about that? To get so far I had to do the following changes: a) Add /usr/local/lib to ATLAS search-path: Index: setup.py =================================================================== RCS file: /home/cvsroot/world/scipy/setup.py,v retrieving revision 1.56 diff -u -r1.56 setup.py --- setup.py 2001/09/21 08:29:55 1.56 +++ setup.py 2001/09/27 14:23:14 @@ -96,7 +96,7 @@ local_atlas1 = os.path.join(path,platform[:-1],'atlas') # first look for a system defined atlas directory - dir_search = ['/usr/local/lib/atlas','/usr/lib/atlas', + dir_search = ['/usr/local/lib/atlas','/usr/lib/atlas', '/usr/local/lib', local_atlas0, local_atlas1] for directory in dir_search: if os.path.exists(directory): b) In the cephes module I had to undefine the log2 macro from /usr/include/math.h to make it compile: Index: special/cephes.h =================================================================== RCS file: /home/cvsroot/world/scipy/special/cephes.h,v retrieving revision 1.1 diff -u -r1.1 cephes.h --- special/cephes.h 2001/06/20 05:29:41 1.1 +++ special/cephes.h 2001/09/27 14:19:50 @@ -102,6 +102,9 @@ /* extern int levnsn ( int n, double r[], double a[], double e[], double refl[] ); */ +#ifdef log2 /* some systems have log2 as a macro */ +# undef log2 +#endif extern double log2 ( double x ); /* extern long lrand ( void ); Index: special/cephes/protos.h =================================================================== RCS file: /home/cvsroot/world/scipy/special/cephes/protos.h,v retrieving revision 1.2 diff -u -r1.2 protos.h --- special/cephes/protos.h 2001/07/03 08:32:00 1.2 +++ special/cephes/protos.h 2001/09/27 14:19:50 @@ -101,6 +101,9 @@ extern int levnsn ( int n, double r[], double a[], double e[], double refl[] ); extern double log ( double x ); extern double log10 ( double x ); +#ifdef log2 /* some systems have log2 as a macro */ +# undef log2 +#endif extern double log2 ( double x ); extern long lrand ( void ); extern long lsqrt ( long x ); Any help appreciated... Greetings, Jochen -- University of North Carolina phone: 919-962-4403 Department of Chemistry phone: 919-962-1579 Venable Hall CB#3290 fax: 919-843-6041 Chapel Hill, NC 27599, USA GnuPG key: 44BCCD8E From oliphant at ee.byu.edu Thu Sep 27 13:19:26 2001 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 27 Sep 2001 11:19:26 -0600 (MDT) Subject: [SciPy-dev] Re: Scipy-dev digest, Vol 1 #11 - 1 msg In-Reply-To: <200109271700.f8RH02U04182@scipy.org> Message-ID: > 1. SciPy on Cygwin (Jochen =?iso-8859-1?q?K=FCpper?=) > > --__--__-- > > Message: 1 > To: scipy-dev at scipy.net > Cc: Cygwin > From: "Jochen =?iso-8859-1?q?K=FCpper?=" > Organization: University of North Carolina > Date: 27 Sep 2001 10:26:13 -0400 > Subject: [SciPy-dev] SciPy on Cygwin > Reply-To: scipy-dev at scipy.net > > I am trying to compile SciPy (cvs) on latest Cygwin (all packages > besides postgresql, irc installed). Anybody got that going? > > - gcc version 2.95.3-5 (cygwin special) > - Python 2.1.1 (#2, Sep 26 2001, 09:32:53) > [GCC 2.95.3-5 (cygwin special)] on cygwin > - NumPy from cvs as of today > > The problem I am running into in linalg is that I get compile errors > in flapackmodule.c: > ,---- > | linalg/flapackmodule.c:447: initializer element is not constant > | linalg/flapackmodule.c:502: initializer element is not constant > | linalg/flapackmodule.c:557: initializer element is not constant > | linalg/flapackmodule.c:616: initializer element is not constant > `---- > > The respective code is > ,----[flapackmodule.c: 447] > | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; > `---- Well it looks like some more ifdefs are needed. I think there is some DL_EXPORT macro that needs to be used somewhere for it to work on CYGWIN. Because this is an f2py generated file, I'm not sure what to do. Does f2py support Cygwin? -Travis From pearu at cens.ioc.ee Thu Sep 27 14:10:57 2001 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 27 Sep 2001 20:10:57 +0200 (EET) Subject: [SciPy-dev] Re: Scipy-dev digest, Vol 1 #11 - 1 msg In-Reply-To: Message-ID: On Thu, 27 Sep 2001, Travis Oliphant wrote: > > The problem I am running into in linalg is that I get compile errors > > in flapackmodule.c: > > ,---- > > | linalg/flapackmodule.c:447: initializer element is not constant > > | linalg/flapackmodule.c:502: initializer element is not constant > > | linalg/flapackmodule.c:557: initializer element is not constant > > | linalg/flapackmodule.c:616: initializer element is not constant > > `---- > > > > The respective code is > > ,----[flapackmodule.c: 447] > > | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; > > `---- > > > Well it looks like some more ifdefs are needed. > > I think there is some DL_EXPORT macro that needs to be used somewhere for > it to work on CYGWIN. Because this is an f2py generated file, I'm not > sure what to do. Does f2py support Cygwin? I have never tried cygwin but it is basically gcc (right?) and therefore I did not see any reasons why f2py generated code would fail on cygwin. However, it seems that I need to let f2py to put lines like 477 above to init () block. But if there is a way to use macros please let me know - the fix will be certainly simpler for me. Meanwhile I suggest manually moving the initializations with Py_None to the function flapackmodule(). (I am not sure when I am able to fix f2py as it will not be trivial). Regards, Pearu From pearu at cens.ioc.ee Thu Sep 27 14:16:32 2001 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 27 Sep 2001 20:16:32 +0200 (EET) Subject: [SciPy-dev] Re: Scipy-dev digest, Vol 1 #11 - 1 msg In-Reply-To: Message-ID: On Thu, 27 Sep 2001, Pearu Peterson wrote: > Meanwhile I suggest manually moving the initializations with Py_None to > the function flapackmodule(). I meant to the function initflapack(). Pearu From kern at caltech.edu Thu Sep 27 15:48:52 2001 From: kern at caltech.edu (Robert Kern) Date: Thu, 27 Sep 2001 12:48:52 -0700 Subject: [SciPy-dev] Re: Scipy-dev digest, Vol 1 #11 - 1 msg In-Reply-To: References:

Message-ID: <20010927124852.A18567@myrddin.caltech.edu> On Thu, Sep 27, 2001 at 08:10:57PM +0200, Pearu Peterson wrote: > > > On Thu, 27 Sep 2001, Travis Oliphant wrote: > > > > The problem I am running into in linalg is that I get compile errors > > > in flapackmodule.c: > > > ,---- > > > | linalg/flapackmodule.c:447: initializer element is not constant > > > | linalg/flapackmodule.c:502: initializer element is not constant > > > | linalg/flapackmodule.c:557: initializer element is not constant > > > | linalg/flapackmodule.c:616: initializer element is not constant > > > `---- > > > > > > The respective code is > > > ,----[flapackmodule.c: 447] > > > | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; > > > `---- > > > > > > Well it looks like some more ifdefs are needed. > > > > I think there is some DL_EXPORT macro that needs to be used somewhere for > > it to work on CYGWIN. Because this is an f2py generated file, I'm not > > sure what to do. Does f2py support Cygwin? > > I have never tried cygwin but it is basically gcc (right?) and therefore > I did not see any reasons why f2py generated code would fail on > cygwin. However, it seems that I need to let f2py to put lines like 477 > above to init () block. It's a silly Windows DLL-linking limitation. I don't know the technical details of why one can't initialize pointers like that, but putting the assignment in the init() block will work. Also, if you compile with g++, it should work (don't ask me why it works, but it does). -- Robert Kern kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jason at tishler.net Thu Sep 27 16:48:48 2001 From: jason at tishler.net (Jason Tishler) Date: Thu, 27 Sep 2001 16:48:48 -0400 Subject: [SciPy-dev] Re: SciPy on Cygwin In-Reply-To: <86d74cr9q2.fsf@bock.chem.unc.edu> Message-ID: <20010927164848.Q1356@dothill.com> Jochen, On Thu, Sep 27, 2001 at 10:26:13AM -0400, Jochen K?pper wrote: > The problem I am running into in linalg is that I get compile errors > in flapackmodule.c: > ,---- > | linalg/flapackmodule.c:447: initializer element is not constant > | linalg/flapackmodule.c:502: initializer element is not constant > | linalg/flapackmodule.c:557: initializer element is not constant > | linalg/flapackmodule.c:616: initializer element is not constant > `---- The usually solution to the above kind of errors is the following: http://www.python.org/doc/FAQ.html#3.24 > The respective code is > ,----[flapackmodule.c: 447] > | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; > `---- Unfortunately, the above line does *not* seem to jib with this solution. Jason From jochen at jochen-kuepper.de Fri Sep 28 10:48:13 2001 From: jochen at jochen-kuepper.de (Jochen =?iso-8859-1?q?K=FCpper?=) Date: 28 Sep 2001 10:48:13 -0400 Subject: [SciPy-dev] SciPy on Cygwin In-Reply-To: <86d74cr9q2.fsf@bock.chem.unc.edu> References: <86d74cr9q2.fsf@bock.chem.unc.edu> Message-ID: <86g097pgqt.fsf@bock.chem.unc.edu> A little further, but now I am having linking problems. See end of message for current problem: Since I apparently couldn't subscribe to scipy-dev yet send me a cc, please. >>>>> Jochen K?pper wrote on 27 Sep 2001 10:26:13 -0400: [SciPy on Cygwin...] Jochen> ,----[flapackmodule.c: 447] Jochen> | PyObject *cb_cselect_in_cgees__user__routines_capi = Py_None; Jochen> `---- Jochen> I am not sure what to do about that? >>>>> Jason Tishler wrote on Thu, 27 Sep 2001 16:48:48 -0400: Jason> The usually solution to the above kind of errors is the Jason> following: Jason> http://www.python.org/doc/FAQ.html#3.24 Jason> Unfortunately, the above line does *not* seem to jib with this solution. Right. And compiling with g++ reveals a ton of other errors. >>>>> Travis Oliphant wrote on Thu, 27 Sep 2001 11:19:26 -0600 (MDT): Travis> Well it looks like some more ifdefs are needed. Travis> I think there is some DL_EXPORT macro that needs to be used somewhere for Travis> it to work on CYGWIN. Because this is an f2py generated file, I'm not Travis> sure what to do. Does f2py support Cygwin? I actually tried to put DL_EXPORT macros at different position, but since I pretty clueless about both Cygwin and python C-extensions I don't have too much of an understanding where it has to go:( >>>>> Pearu Peterson wrote on Thu, 27 Sep 2001 20:10:57 +0200 (EET): Pearu> I have never tried cygwin but it is basically gcc (right?) and therefore Pearu> I did not see any reasons why f2py generated code would fail on Pearu> cygwin. However, it seems that I need to let f2py to put lines like 477 Pearu> above to init () block. But if there is a way to use macros please Pearu> let me know - the fix will be certainly simpler for me. Pearu> Meanwhile I suggest manually moving the initializations with Py_None to Pearu> the function flapackmodule(). (I am not sure when I am able to fix f2py Pearu> as it will not be trivial). >>>>> Pearu Peterson wrote on Thu, 27 Sep 2001 20:16:32 +0200 (EET): Pearu> I meant to the function initflapack(). Well, that could be a solution for me since it isn't too much work, a appropriate putch could probable even be applied by setup.py? Running into the next problem is the definition of PyFortran_Type in fortranmodule.h, I changed in the following way: - no global initialization: PyTypeObject PyFortran_Type; - created this function in fortranmodule.c, added declaration to fortranmodule.h and call it from initflapack: void fortranobject_init(void) { PyFortran_Type = (PyTypeObject){ PyObject_HEAD_INIT(&PyType_Type) 0, /*ob_size*/ "fortran", /*tp_name*/ sizeof(PyFortranObject), /*tp_basicsize*/ 0, /*tp_itemsize*/ /* methods */ (destructor)fortran_dealloc, /*tp_dealloc*/ 0, /*tp_print*/ (getattrfunc)fortran_getattr, /*tp_getattr*/ (setattrfunc)fortran_setattr, /*tp_setattr*/ 0, /*tp_compare*/ 0, /*tp_repr*/ 0, /*tp_as_number*/ 0, /*tp_as_sequence*/ 0, /*tp_as_mapping*/ 0, /*tp_hash*/ (ternaryfunc)fortran_call, /*tp_call*/ }; } Does this look like a reasonable idea? Well, it compiles, but I get undefined references on linking. > gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.3-i686-2.1/flapackmodule.o build/temp.cygwin-1.3.3-i686-2.1/fortranobject.o -L/usr/local/lib -L/usr/lib/python2.1/config -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 -Lbuild/temp.cygwin-1.3.3-i686-2.1 -Lbuild/temp.cygwin-1.3.3-i686-2.1 -llapack -lcblas -lf77blas -latlas -lpython2.1 -lamos -ltoms -lfitpack -lminpack -lquadpack -lodepack -llinpack_lite -lmach -lg2c -lgcc -lc_misc -lcephes -o build/lib.cygwin-1.3.3-i686-2.1/scipy/linalg/flapack.dll build/temp.cygwin-1.3.3-i686-2.1/flapackmodule.o: In function `initflapack': /home/software/scipy/linalg/flapackmodule.c:7855: undefined reference to `_imp__PyFortranObject_NewAsAttr' build/temp.cygwin-1.3.3-i686-2.1/fortranobject.o: In function `PyFortranObject_New': /home/software/scipy/linalg/fortranobject.c:138: undefined reference to `_imp__PyFortran_Type' /home/software/scipy/linalg/fortranobject.c:146: undefined reference to `_imp__PyFortranObject_NewAsAttr' build/temp.cygwin-1.3.3-i686-2.1/fortranobject.o: In function `PyFortranObject_NewAsAttr': /home/software/scipy/linalg/fortranobject.c:168: undefined reference to `_imp__PyFortran_Type' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 As I said above I tried playing with DL_EXPORTS, to no avail. Thank you for your help, hope you guys have some more ideas...:)) Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: 44BCCD8E Sex, drugs and rock-n-roll From jason at tishler.net Fri Sep 28 13:57:00 2001 From: jason at tishler.net (Jason Tishler) Date: Fri, 28 Sep 2001 13:57:00 -0400 Subject: [SciPy-dev] SciPy on Cygwin In-Reply-To: <86g097pgqt.fsf@bock.chem.unc.edu> Message-ID: <20010928135700.X1356@dothill.com> Jochen, On Fri, Sep 28, 2001 at 10:48:13AM -0400, Jochen K?pper wrote: > A little further, but now I am having linking problems. See end of > message for current problem: Note that you never really gave enough context (at least on the Cygwin list) for people to help you. So the following is my best WAG... > >>>>> Jason Tishler wrote on Thu, 27 Sep 2001 16:48:48 -0400: > > Jason> The usually solution to the above kind of errors is the > Jason> following: > > Jason> http://www.python.org/doc/FAQ.html#3.24 > > Jason> Unfortunately, the above line does *not* seem to jib with this solution. > > Right. And compiling with g++ reveals a ton of other errors. No, I meant change the code as explained by the above URL not compile with g++. > >>>>> Travis Oliphant wrote on Thu, 27 Sep 2001 11:19:26 -0600 (MDT): > > Travis> Well it looks like some more ifdefs are needed. > > Travis> I think there is some DL_EXPORT macro that needs to be used somewhere for > Travis> it to work on CYGWIN. Because this is an f2py generated file, I'm not > Travis> sure what to do. Does f2py support Cygwin? > > I actually tried to put DL_EXPORT macros at different position, but > since I pretty clueless about both Cygwin and python C-extensions I > don't have too much of an understanding where it has to go:( The following are the "tricks" for building Cygwin Python extensions: o DL_EXPORT is typically only need for the extension's init function o -DUSE_DL_IMPORT needs to be supplied during compilation o Cygwin Python's import library (e.g. libpython2.1.dll.a) needs to be supplied during linking > >>>>> Pearu Peterson wrote on Thu, 27 Sep 2001 20:10:57 +0200 (EET): > > Pearu> I have never tried cygwin but it is basically gcc (right?) and therefore > Pearu> I did not see any reasons why f2py generated code would fail on > Pearu> cygwin. However, it seems that I need to let f2py to put lines like 477 > Pearu> above to init () block. But if there is a way to use macros please > Pearu> let me know - the fix will be certainly simpler for me. > > Pearu> Meanwhile I suggest manually moving the initializations with Py_None to > Pearu> the function flapackmodule(). (I am not sure when I am able to fix f2py > Pearu> as it will not be trivial). > > >>>>> Pearu Peterson wrote on Thu, 27 Sep 2001 20:16:32 +0200 (EET): > Pearu> I meant to the function initflapack(). The above seems to be congruent with the above mentioned Python FAQ URL. > Well, that could be a solution for me since it isn't too much work, Agreed. > a appropriate putch could probable even be applied by setup.py? Huh? > Running into the next problem is the definition of PyFortran_Type in > fortranmodule.h, I changed in the following way: > > - no global initialization: > > PyTypeObject PyFortran_Type; > > - created this function in fortranmodule.c, added declaration to > fortranmodule.h and call it from initflapack: > > void fortranobject_init(void) { > PyFortran_Type = (PyTypeObject){ > PyObject_HEAD_INIT(&PyType_Type) > 0, /*ob_size*/ > [snip] > (ternaryfunc)fortran_call, /*tp_call*/ > }; > } > > Does this look like a reasonable idea? No, I would structure the code as suggested by the above mentioned Python FAQ URL. You can also look at the standard Python extensions in Modules directory of the Python source tree for examples. > Well, it compiles, but I get undefined references on linking. > > > gcc -shared -Wl,--enable-auto-image-base > build/temp.cygwin-1.3.3-i686-2.1/flapackmodule.o > build/temp.cygwin-1.3.3-i686-2.1/fortranobject.o -L/usr/local/lib > -L/usr/lib/python2.1/config -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 > -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 > -Lbuild/temp.cygwin-1.3.3-i686-2.1 -Lbuild/temp.cygwin-1.3.3-i686-2.1 > -llapack -lcblas -lf77blas -latlas -lpython2.1 -lamos -ltoms -lfitpack > -lminpack -lquadpack -lodepack -llinpack_lite -lmach -lg2c -lgcc > -lc_misc -lcephes -o > build/lib.cygwin-1.3.3-i686-2.1/scipy/linalg/flapack.dll > > build/temp.cygwin-1.3.3-i686-2.1/flapackmodule.o: In function `initflapack': > /home/software/scipy/linalg/flapackmodule.c:7855: undefined reference to `_imp__PyFortranObject_NewAsAttr' > build/temp.cygwin-1.3.3-i686-2.1/fortranobject.o: In function `PyFortranObject_New': > [snip] > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > As I said above I tried playing with DL_EXPORTS, to no avail. Did you compile with -DUSE_DL_IMPORT? If not, then the above unresolved link errors are to be expected. > Thank you for your help, hope you guys have some more ideas...:)) You may have better luck on the Distutils mailing list: distutils-sig at python.org The only other suggestion that I have is to start with a simple Cygwin Python extension so you can really understand what is going on before trying something significantly more complicated like a f2py generated extension. For example, try the Demo/extend in the Python source tree -- all you need to do is execute "make_shared". Jason From pearu at cens.ioc.ee Fri Sep 28 14:03:10 2001 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 28 Sep 2001 20:03:10 +0200 (EET) Subject: [SciPy-dev] SciPy on Cygwin In-Reply-To: <86g097pgqt.fsf@bock.chem.unc.edu> Message-ID: On 28 Sep 2001, Jochen K?pper wrote: > Running into the next problem is the definition of PyFortran_Type in > fortranmodule.h, What is this problem? Try moving all PyFortran_Type stuff from fortranobject.h to fortranobject.c. When I look at some of my f2py generated *.c files, I don't see it used nowhere. So, it is possible that it is not needed at all. Though, it is not probably releated to the linking problem below. > Well, it compiles, but I get undefined references on linking. > build/temp.cygwin-1.3.3-i686-2.1/flapackmodule.o: In function `initflapack': > /home/software/scipy/linalg/flapackmodule.c:7855: undefined reference to `_imp__PyFortranObject_NewAsAttr' ^ \___ does anyone have idea how _imp__ got here? Regards, Pearu From pearu at cens.ioc.ee Fri Sep 28 14:03:10 2001 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 28 Sep 2001 20:03:10 +0200 (EET) Subject: [SciPy-dev] SciPy on Cygwin In-Reply-To: <86g097pgqt.fsf@bock.chem.unc.edu> Message-ID: On 28 Sep 2001, Jochen K?pper wrote: > Running into the next problem is the definition of PyFortran_Type in > fortranmodule.h, What is this problem? Try moving all PyFortran_Type stuff from fortranobject.h to fortranobject.c. When I look at some of my f2py generated *.c files, I don't see it used nowhere. So, it is possible that it is not needed at all. Though, it is not probably releated to the linking problem below. > Well, it compiles, but I get undefined references on linking. > build/temp.cygwin-1.3.3-i686-2.1/flapackmodule.o: In function `initflapack': > /home/software/scipy/linalg/flapackmodule.c:7855: undefined reference to `_imp__PyFortranObject_NewAsAttr' ^ \___ does anyone have idea how _imp__ got here? Regards, Pearu From jhauser at ifm.uni-kiel.de Sun Sep 30 10:21:18 2001 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sun, 30 Sep 2001 16:21:18 +0200 (CEST) Subject: [SciPy-dev] Documentation and then some Message-ID: <20010930142118.16379.qmail@lisboa.ifm.uni-kiel.de> Hi, I saw the notice for the new documentation and figured that this is automatically generated stuff (HappyDoc?!). May I ask, if there is also interest in a type of documentation like the standard python library reference? As some of you may know, I had once started something like this for NumPy. I'm willing to revamp this and build at least a start. I would start with the documentation for the functions which are the base of scipy (numeric+handy+misc+basic) and then some of the other modules (I think I have special, signal, stats and fft already covered). Interest? Then I noticed that min(),max() are part of basic. This collides with the standard min and max of python. Is this a possible problem? Also I have coded amin(),amax() that if an axis=None is provided a complete minimum/maximum of the array is calculated. Then I would like to have a function which combines a.flat() and ravel() in such a way that where ever possible flat is returned, as ravel makes a copy of the array. To say the truth I have this function :-). def flatten(a): """Returns a rank 1 view of the array a. Does not create a copy if a.iscontiguous() == 1. """ # XXXIMPLEMENTATION: Should perhaps be a special case of ravel, # like ravel(a, savespace=1). if a.iscontiguous() == 1: return a.flat else: return ravel(a) Another question: Seeing scipy placed against Matlab, is there also the idea of a toolbox concept? And a last one: What help regarding the Zope-site is needed? Let me say, that I'm very happy, that scipy looks more and more like the fullfillment of an old idea. With regards, __Janko From wsryu at fas.harvard.edu Sun Sep 30 13:25:03 2001 From: wsryu at fas.harvard.edu (William Ryu) Date: Sun, 30 Sep 2001 13:25:03 -0400 Subject: [SciPy-dev] Re: Scipy-dev digest, Vol 1 #14 - 1 msg In-Reply-To: <200109301701.f8UH11U00314@scipy.org> Message-ID: <5.1.0.14.2.20010930132153.00a7beb8@pop.fas.harvard.edu> At 12:01 PM 9/30/2001 -0500, you wrote: >From: Janko Hauser >Date: Sun, 30 Sep 2001 16:21:18 +0200 (CEST) >To: scipy-dev at scipy.net >Subject: [SciPy-dev] Documentation and then some >Reply-To: scipy-dev at scipy.net > >Hi, I saw the notice for the new documentation and figured that this >is automatically generated stuff (HappyDoc?!). May I ask, if there is >also interest in a type of documentation like the standard python >library reference? Well as an scipy end users, I would love to see such documentation. More documentation the better. :) >As some of you may know, I had once started >something like this for NumPy. I'm willing to revamp this and build at >least a start. I would start with the documentation for the functions >which are the base of scipy (numeric+handy+misc+basic) and then some >of the other modules (I think I have special, signal, stats and fft >already covered). Is the preliminary document you started for NumPy available for download? Regards, -willryu From jhauser at ifm.uni-kiel.de Sun Sep 30 17:45:31 2001 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sun, 30 Sep 2001 23:45:31 +0200 (CEST) Subject: [SciPy-dev] Re: Scipy-dev digest, Vol 1 #14 - 1 msg In-Reply-To: <5.1.0.14.2.20010930132153.00a7beb8@pop.fas.harvard.edu> References: <200109301701.f8UH11U00314@scipy.org> <5.1.0.14.2.20010930132153.00a7beb8@pop.fas.harvard.edu> Message-ID: <20010930214531.16525.qmail@lisboa.ifm.uni-kiel.de> Sorry for the last mail if it actually came through, I wanted this to send to William directly and not bother everyone with this. My apologies and promise to be more careful in the future. __Janko