From stoudtc at yahoo.com  Wed May  1 11:36:36 2002
From: stoudtc at yahoo.com (Craig Stoudt)
Date: Wed, 1 May 2002 08:36:36 -0700 (PDT)
Subject: [SciPy-user] Installation Problem
Message-ID: <20020501153636.62447.qmail@web10503.mail.yahoo.com>

Greetings,

After what appeared to be a successful install (from
the tarball) I tried to import scipy and got the
following:

Python 2.2 (#1, Apr 30 2002, 18:20:55)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import scipy
Traceback (most recent call last):
File "<stdin>", line 1, in ?
  File
"/usr/local/lib/python2.2/site-packages/scipy/__init__.py",
line 41, in ? from handy import *
File
"/usr/local/lib/python2.2/site-packages/scipy/handy.py",
line 1, in ?    import Numeric
File
"/usr/local/lib/python2.2/site-packages/Numeric/Numeric.py",
line 124, in ?
arrayrange = multiarray.arange
AttributeError: 'module' object has no attribute
'arange'
>>>

Could someone help me figure out the problem?

Thanks!

Craig Stoudt
Annandale, VA

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com


From eric at scipy.org  Wed May  1 10:44:53 2002
From: eric at scipy.org (eric)
Date: Wed, 1 May 2002 10:44:53 -0400
Subject: [SciPy-user] Installation Problem
References: <20020501153636.62447.qmail@web10503.mail.yahoo.com>
Message-ID: <034f01c1f11e$c1323310$6b01a8c0@ericlaptop>

Hey Craig,

Try upgrading to the latest Numeric (21.0 or so).  Versions prior to 20.3 or so
declared arange in Python instead of in the multiarray C extension module.  This
looks like it is causing the problem (though I'm not sure why it manifest itself
here).

eric

----- Original Message -----
From: "Craig Stoudt" <stoudtc at yahoo.com>
To: <scipy-user at scipy.net>
Sent: Wednesday, May 01, 2002 11:36 AM
Subject: [SciPy-user] Installation Problem


> Greetings,
>
> After what appeared to be a successful install (from
> the tarball) I tried to import scipy and got the
> following:
>
> Python 2.2 (#1, Apr 30 2002, 18:20:55)
> [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
> linux2
> Type "help", "copyright", "credits" or "license" for
> more information.
> >>> import scipy
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
>   File
> "/usr/local/lib/python2.2/site-packages/scipy/__init__.py",
> line 41, in ? from handy import *
> File
> "/usr/local/lib/python2.2/site-packages/scipy/handy.py",
> line 1, in ?    import Numeric
> File
> "/usr/local/lib/python2.2/site-packages/Numeric/Numeric.py",
> line 124, in ?
> arrayrange = multiarray.arange
> AttributeError: 'module' object has no attribute
> 'arange'
> >>>
>
> Could someone help me figure out the problem?
>
> Thanks!
>
> Craig Stoudt
> Annandale, VA
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From stoudtc at yahoo.com  Wed May  1 16:48:44 2002
From: stoudtc at yahoo.com (Craig Stoudt)
Date: Wed, 1 May 2002 13:48:44 -0700 (PDT)
Subject: [SciPy-user] Installation Problem
Message-ID: <20020501204844.20225.qmail@web10502.mail.yahoo.com>

Thanks, Eric.  However, I'm already using Numeric-21.0

As an experiment, I installed python2.1.3 and then
Numeric-21.0.  So far so good:

[root at localhost Numeric-21.0]# python2.1
Python 2.1.3 (#2, May  1 2002, 16:09:35)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "copyright", "credits" or "license" for more
information.
>>> import Numeric 
>>>

Then I installed SciPy-0.1.  Now, when I try to import
Numeric, I get:

[root at localhost SciPy-0.1]# python2.1
Python 2.1.3 (#2, May  1 2002, 16:09:35)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "copyright", "credits" or "license" for more
information.
>>> import Numeric
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/lib/python2.1/site-packages/Numeric/Numeric.p
    arrayrange = multiarray.arange
AttributeError: 'multiarray' module has no attribute
'arange'

Apparently, the SciPy install is doing something to my
Numeric module.  Does anyone know what is going on
here?

Craig Stoudt
Annandale, VA

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com


From steven.robbins at videotron.ca  Wed May  1 16:57:41 2002
From: steven.robbins at videotron.ca (Steve M. Robbins)
Date: Wed, 1 May 2002 16:57:41 -0400
Subject: [SciPy-user] Installation Problem
In-Reply-To: <20020501204844.20225.qmail@web10502.mail.yahoo.com>
References: <20020501204844.20225.qmail@web10502.mail.yahoo.com>
Message-ID: <20020501205741.GB17484@nyongwa.montreal.qc.ca>

On Wed, May 01, 2002 at 01:48:44PM -0700, Craig Stoudt wrote:

> Apparently, the SciPy install is doing something to my
> Numeric module.  Does anyone know what is going on
> here?

Where did SciPy come from -- source?  RPM?

IIRC, the debian package of a couple of months ago for scipy would
overwrite bits of Numeric.  Did you check to see whether Numeric has
changed after installing scipy?


-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants



From eric at scipy.org  Wed May  1 17:17:39 2002
From: eric at scipy.org (eric)
Date: Wed, 1 May 2002 17:17:39 -0400
Subject: [SciPy-user] Installation Problem
References: <20020501204844.20225.qmail@web10502.mail.yahoo.com>
Message-ID: <001901c1f155$a008f3e0$6b01a8c0@ericlaptop>

Hey Craig,

> Thanks, Eric.  However, I'm already using Numeric-21.0
<snip>
> Then I installed SciPy-0.1.  Now, when I try to import

Ah.  I've been using the CVS version so long, I didn't even think about 0.1. :-|
This explains it. SciPy-0.1 does overwrite some of Numeric -- and with a much
older version than you are using.  I expect you have some sort of mixture of the
old and the new in Numeric, and they don't play well together.

I think there are two possibilities.  If you want to stick with the 0.1 release,
I would first remove the Numeric directory from site-packages.  *Do not*
reinstall Numeric-21.0.  Reinstall SciPy 0.1.  SciPy will install an old version
of Numeric, but this will hopefully fix your problem.

The other alternative is to try your hand at installing the (forever) upcoming
0.2 release from the nightly CVS snapshot.  It has many improvements and is
probably more stable than 0.1.  It will take more effort to install though
because it depends on several other packages.  Some notes on installation are
here:

http://www.scipy.net/pipermail/scipy-user/2002-April/000269.html

I'd recommend trying 0.2 if you have the time to build it.  I think you'll be
happier with the package.

good luck,
eric




From stoudtc at yahoo.com  Thu May  2 10:31:30 2002
From: stoudtc at yahoo.com (Craig Stoudt)
Date: Thu, 2 May 2002 07:31:30 -0700 (PDT)
Subject: [SciPy-user] Installation Problem - Follow-up
Message-ID: <20020502143130.35164.qmail@web10502.mail.yahoo.com>

Thanks, Eric.

Following your instructions, I successfully installed
scipy-0.1 under python2.1, and scipy-0.2 ("snapshot")
under python2.2.

When I run scipy.test (both 0.1 and 0.2) I do get the
following:

<unittest.TextTestRunner instance at 0x845f8ac> 

Don't know if this is a problem or not.  Otherwise, it
seems to be working fine.

Thanks for your help.  This mailing list is much more
"newbie-friendly" than some others I have encountered.

Best regards,

Craig Stoudt
Annandale, VA

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com


From arnd.baecker at physik.uni-ulm.de  Thu May  2 10:40:16 2002
From: arnd.baecker at physik.uni-ulm.de (arnd.baecker at physik.uni-ulm.de)
Date: Thu, 2 May 2002 16:40:16 +0200 (MEST)
Subject: [SciPy-user] Installation Problem - Follow-up
In-Reply-To: <20020502143130.35164.qmail@web10502.mail.yahoo.com>
Message-ID: <Pine.SOL.4.44.0205021638140.12180-100000@wega.rz.uni-ulm.de>

Hi Craig,

just use
  scipy.test()
or
  scipy.test(10)
for the basic test or the full test at level 10.
(you need the brackets to call the test function,
without them you just the information about the object ...)

Arnd

On Thu, 2 May 2002, Craig Stoudt wrote:

> Thanks, Eric.
>
> Following your instructions, I successfully installed
> scipy-0.1 under python2.1, and scipy-0.2 ("snapshot")
> under python2.2.
>
> When I run scipy.test (both 0.1 and 0.2) I do get the
> following:
>
> <unittest.TextTestRunner instance at 0x845f8ac>
>
> Don't know if this is a problem or not.  Otherwise, it
> seems to be working fine.
>
> Thanks for your help.  This mailing list is much more
> "newbie-friendly" than some others I have encountered.
>
> Best regards,
>
> Craig Stoudt
> Annandale, VA
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>
>
>



From arnd.baecker at physik.uni-ulm.de  Thu May  2 10:40:16 2002
From: arnd.baecker at physik.uni-ulm.de (arnd.baecker at physik.uni-ulm.de)
Date: Thu, 2 May 2002 16:40:16 +0200 (MEST)
Subject: [SciPy-user] Installation Problem - Follow-up
In-Reply-To: <20020502143130.35164.qmail@web10502.mail.yahoo.com>
Message-ID: <Pine.SOL.4.44.0205021638140.12180-100000@wega.rz.uni-ulm.de>

Hi Craig,

just use
  scipy.test()
or
  scipy.test(10)
for the basic test or the full test at level 10.
(you need the brackets to call the test function,
without them you just the information about the object ...)

Arnd

On Thu, 2 May 2002, Craig Stoudt wrote:

> Thanks, Eric.
>
> Following your instructions, I successfully installed
> scipy-0.1 under python2.1, and scipy-0.2 ("snapshot")
> under python2.2.
>
> When I run scipy.test (both 0.1 and 0.2) I do get the
> following:
>
> <unittest.TextTestRunner instance at 0x845f8ac>
>
> Don't know if this is a problem or not.  Otherwise, it
> seems to be working fine.
>
> Thanks for your help.  This mailing list is much more
> "newbie-friendly" than some others I have encountered.
>
> Best regards,
>
> Craig Stoudt
> Annandale, VA
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>
>
>



From tim.carlson at pnl.gov  Thu May  2 14:19:03 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Thu, 02 May 2002 11:19:03 -0700 (PDT)
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs scipy)
Message-ID: <Pine.LNX.4.44.0205021107360.17434-100000@roach.emsl.pnl.gov>

I checked out the cvs version of scipy this morning and I am running into
the following problem when doing the installation on an IRIX 6.5.15m
Origin 2000 box.

Some useful info.
---------------------------
>python -c 'import os,sys;print os.name,sys.platform'
posix irix646

>python -c 'import Numeric;print Numeric.__version__'
21.0

>f2py -v
2.13.175-1250

>python scipy_distutils/system_info.py
atlas_info:
  FOUND:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/atlas', '/usr/local/atlas']
    include_dirs = ['/usr/include']

fftw_info:
  NOT AVAILABLE

x11_info:
  NOT AVAILABLE

> uname -a
IRIX64 mulliken 6.5 01091821 IP27

> gcc -v
Reading specs from
/afs/msrc.pnl.gov/files/apps/gcc-2.95.3/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/specs
gcc version 2.95.3 20010315 (release)
---------------------------

I checked out scipy and started the installation with

python setuy.py install

All goes well until I hit the bug in optimize/Zeros/zeros.h which I fix
and happily continue on. My problem comes at

---snip---

ranlib build/temp.irix64-6.5-2.2/librootfind.a
running run_f2py
running build_flib
scipy_distutils.command.build_flib.gnu_fortran_compiler
error: Fortran compiler not available: None

---snip---

It looks to me like setup can't find fortran. Now there are various
fortran's to choose from

> which f77
/usr/bin/f77
> which g77
/msrc/apps/gcc-2.95.3/bin/g77

Both of which should work fine. I compiled ATLAS and LAPACK with SGI's f77

> f77 -version
MIPSpro Compilers: Version 7.3.1.2m


I did use "-n32" for ATLAS/LAPACK because I want to be able to run this on
a variety of SGI boxes.

Any ideas?

PS.. I'm trying out the CVS version because the released version seems to
have a bug (at least how I installed it).

------
from scipy import *

x= arange(0,1,.1)
y=x**2
print y
--------

y reports lots of NaN's. I can do y=x*x and get the correct results, but
y=x**2 seems broken.

TIA

Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support




From eric at scipy.org  Thu May  2 14:57:44 2002
From: eric at scipy.org (eric)
Date: Thu, 2 May 2002 14:57:44 -0400
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs scipy)
References: <Pine.LNX.4.44.0205021107360.17434-100000@roach.emsl.pnl.gov>
Message-ID: <019f01c1f20b$3e350a30$6b01a8c0@ericlaptop>

Hey Tim,


> I checked out the cvs version of scipy this morning and I am running into
> the following problem when doing the installation on an IRIX 6.5.15m
> Origin 2000 box.

Very good.  I'd like to make sure this platform is working also.

>
> <snip>
> All goes well until I hit the bug in optimize/Zeros/zeros.h which I fix
> and happily continue on.

What problem are you running into on zeros.h?  Can you send a patch?

> My problem comes at
>
> ---snip---
>
> ranlib build/temp.irix64-6.5-2.2/librootfind.a
> running run_f2py
> running build_flib
> scipy_distutils.command.build_flib.gnu_fortran_compiler
> error: Fortran compiler not available: None
>
> ---snip---
>
> It looks to me like setup can't find fortran. Now there are various
> fortran's to choose from
>
> > which f77
> /usr/bin/f77
> > which g77
> /msrc/apps/gcc-2.95.3/bin/g77
>
> Both of which should work fine. I compiled ATLAS and LAPACK with SGI's f77

It sounds like the Fortran compiler detection stuff is failing on your machine.
The way to check this is:

>>> import scipy_distutils.command.build_flib
>>> scipy_distutils.command.build_flib.show_compilers()
Absoft 4.6
Gnu 2.95.2

You should get MIPS and g77.

I'm surprised the g77 compiler isn't detected -- I wouldn't have expected this
to fail.  The MIPS compiler doesn't surprise me since SciPy isn't currently
tested on IRIX.

>
> > f77 -version
> MIPSpro Compilers: Version 7.3.1.2m
>

The place to check on why the compiler isn't detected is in the:

    modules:
      scipy_distutils.command.build_flib

    classes:
      fortran_compiler_base
      mips_fortran_compiler

Basically, the way we figure out which compiler is installed is by doing exactly
what you did -- running g77 -v or f77 -version or whatever and then running a
regular expression on the output.  The regular expression for MIPS is specified
in the mips_fortran_compiler class.  The regular expression is run by the:

    fortran_compiler_base.get_version()

method.  There are some commented out print statements in this method:

        #print 'command:', self.ver_cmd
        exit_status, out_text = run_command(self.ver_cmd)
        #print exit_status, out_text

that you might enable and then run the show_compilers() command mentioned above.
Hopefully that will help figure out why the compiler isn't found.  If you go to
the scipy_distutils/command directory, you can just run the module after you
edit it:

    python build_flib.py
    <output stuff>

If you can figure out how to fix things, great -- send the patch.  If not, post
the output and hopefully someone else can pitch in.

>
> I did use "-n32" for ATLAS/LAPACK because I want to be able to run this on
> a variety of SGI boxes.

This should be fine.  Looking through the flags for the mips compiler, I see

    self.f77_switches = ' -n32 -KPIC '

so that is what SciPy expects also.  I'm sure the 032 n32 n64 ABI stuff is a
good solution to a difficult problem, but man is it a headache...

>
> Any ideas?
>
> PS.. I'm trying out the CVS version because the released version seems to
> have a bug (at least how I installed it).

Very good plan.  The CVS is more stable and has a lot more features.

>
> ------
> from scipy import *
>
> x= arange(0,1,.1)
> y=x**2
> print y
> --------
>
> y reports lots of NaN's. I can do y=x*x and get the correct results, but
> y=x**2 seems broken.

I seem to remember that sqrt in Numeric doesn't work on IRIX correctly either.
You might check anyway.

Thanks for the info.  I'd like to see IRIX support cleaned up.

eric





From tim.carlson at pnl.gov  Thu May  2 19:38:01 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Thu, 02 May 2002 16:38:01 -0700 (PDT)
Subject: [SciPy-user] install problem can't find fortran
 (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <019f01c1f20b$3e350a30$6b01a8c0@ericlaptop>
Message-ID: <Pine.GSO.4.44.0205021625470.18212-100000@poincare.emsl.pnl.gov>

On Thu, 2 May 2002, eric wrote:

> > All goes well until I hit the bug in optimize/Zeros/zeros.h which I fix
> > and happily continue on.
>
> What problem are you running into on zeros.h?  Can you send a patch?

Here is "diff -c". I think the problem was that the backslash was escaping
the ^M's that are all over this file. So I took it out and just put
everything on one line. Hey.. I'm a sysadmin, not a programmer :)

*** zeros.h	Thu May  2 08:41:44 2002
--- /msrc/dist/scipy-cvs/scipy/optimize/Zeros/zeros.h	Mon Apr 15 13:40:58 2002
***************
*** 14,20 ****
  } default_parameters;

  static double dminarg1,dminarg2;
! #define DMIN(a,b) (dminarg1=(a),dminarg2=(b),(dminarg1) < (dminarg2) ?(dminarg1) : (dminarg2))

  #define SIGN(a)   ((a) > 0.0 ? 1.0 : -1.0)
  #define ERROR(params,num,val) (params)->error_num=(num); return (val)
--- 14,21 ----
  } default_parameters;

  static double dminarg1,dminarg2;
! #define DMIN(a,b) (dminarg1=(a),dminarg2=(b),(dminarg1) < (dminarg2) ?\
!         (dminarg1) : (dminarg2))

  #define SIGN(a)   ((a) > 0.0 ? 1.0 : -1.0)
  #define ERROR(params,num,val) (params)->error_num=(num); return (val)


> >>> import scipy_distutils.command.build_flib
> >>> scipy_distutils.command.build_flib.show_compilers()
> Absoft 4.6
> Gnu 2.95.2
>
> You should get MIPS and g77.


Python 2.2.1 (#1, May  1 2002, 11:48:54)
[GCC 2.95.3 20010315 (release)] on irix646
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy_distutils.command.build_flib
>>> scipy_distutils.command.build_flib.show_compilers()
SGI 7.3.1.2m

Looks like it misses g77 (which is in my path)

Something could be broken with by g77 build. g77 -v reports a mess of info
and then

g77: installation problem, cannot exec `/var/tmp/ccaTe91N': Permission
denied

A bit odd because I am able to use it to compile things. I'll do
more checking on that.

I'll whack on it a bit more and post any interesting results :)

Thanks for the advice.

I'll get this problem fixed and then post problems with HPUX. I really
hate HPUX.

Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From steven.robbins at videotron.ca  Thu May  2 19:45:14 2002
From: steven.robbins at videotron.ca (Steve M. Robbins)
Date: Thu, 2 May 2002 19:45:14 -0400
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <019f01c1f20b$3e350a30$6b01a8c0@ericlaptop>
References: <Pine.LNX.4.44.0205021107360.17434-100000@roach.emsl.pnl.gov> <019f01c1f20b$3e350a30$6b01a8c0@ericlaptop>
Message-ID: <20020502234513.GC7328@nyongwa.montreal.qc.ca>

Hi,

I've also been trying to install scipy on an IRIX64 machine.
I got 


On Thu, May 02, 2002 at 02:57:44PM -0400, eric wrote:

> > My problem comes at
> >
> > ---snip---
> >
> > ranlib build/temp.irix64-6.5-2.2/librootfind.a
> > running run_f2py
> > running build_flib
> > scipy_distutils.command.build_flib.gnu_fortran_compiler
> > error: Fortran compiler not available: None
> >
> > ---snip---
> >
> > It looks to me like setup can't find fortran. Now there are various
> > fortran's to choose from
> >
> > > which f77
> > /usr/bin/f77
> > > which g77
> > /msrc/apps/gcc-2.95.3/bin/g77
> >
> > Both of which should work fine. 

However, scipy's setup.py says ...

	# force g77 for now
	from scipy_distutils.command import build_flib
	build_flib.all_compilers = [build_flib.gnu_fortran_compiler]

... so you have to get g77 support working.



> It sounds like the Fortran compiler detection stuff is failing on
> your machine.  [ ... ]

> Basically, the way we figure out which compiler is installed is by
> doing exactly what you did -- running g77 -v or f77 -version or
> whatever and then running a regular expression on the output.

The problem lies in that "g77 -v" returns exit status 1 on IRIX.

At least that is my experience (though I have GCC 3.0.4 installed
there).  Curiously, "gcc -v" returns status 0.  Also, both "gcc -v"
and "g77 -v" return status 0 on my linux machine, for both 2.9x and
3.x versions.

Anyway, the "-v" option is documented to print out the commands
executed during compilation, not to give version info.  Thus, I
hacked the script to run "g77 --version" instead, and modified the
regex suitably.  This suffices to detect g77 (from GCC 3.0.4) on
IRIX.  It looks like it should work with g77 from GCC 2.9x too.

Index: scipy_distutils/command/build_flib.py
===================================================================
RCS file: /home/cvsroot/world/scipy/scipy_distutils/command/build_flib.py,v
retrieving revision 1.17
diff -u -b -B -r1.17 build_flib.py
--- scipy_distutils/command/build_flib.py       2002/03/26 13:08:06     1.17
+++ scipy_distutils/command/build_flib.py       2002/05/02 23:24:49
@@ -636,7 +636,7 @@
 
     vendor = 'Gnu'
-    ver_match = r'g77 version (?P<version>[^\s*]*)'
+    ver_match = r'GNU Fortran (?P<version>[^\s*]*)'
 
     def __init__(self, fc = None, f90c = None):
         fortran_compiler_base.__init__(self)
@@ -660,7 +660,7 @@
             switches = switches + ' -fpic '
 
         self.f77_switches = switches
-        self.ver_cmd = self.f77_compiler + ' -v '
+        self.ver_cmd = self.f77_compiler + ' --version '
 
         self.f77_opt = self.get_opt()



With this change, I built scipy up to the point where it tried to
link the n32 object with the 64-bit ATLAS libs ... 


> > I did use "-n32" for ATLAS/LAPACK because I want to be able to run this on
> > a variety of SGI boxes.

This is what I have to do, eventually.  Did you have to do anything
special to get n32 libs?


> > ------
> > from scipy import *
> >
> > x= arange(0,1,.1)
> > y=x**2
> > print y
> > --------
> >
> > y reports lots of NaN's. I can do y=x*x and get the correct results, but
> > y=x**2 seems broken.

Really?  But isn't arange() from Numeric?  I've just tried this on my
irix system (importing Numeric rather than scipy) and it looks
fine -- the correct answer, no NaNs.

Did you compile python with the MIPS compiler?  Did you know that 
python tickles compiler bugs and you have to build some of it
without optimization?  [It's something I just learned last week :-(]


> I seem to remember that sqrt in Numeric doesn't work on IRIX correctly either.
> You might check anyway.

Uh, oh.  

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants



From tim.carlson at pnl.gov  Thu May  2 20:27:07 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Thu, 02 May 2002 17:27:07 -0700 (PDT)
Subject: [SciPy-user] install problem can't find fortran
 (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <20020502234513.GC7328@nyongwa.montreal.qc.ca>
Message-ID: <Pine.GSO.4.44.0205021710550.18212-100000@poincare.emsl.pnl.gov>

On Thu, 2 May 2002, Steve M. Robbins wrote:

> The problem lies in that "g77 -v" returns exit status 1 on IRIX.
>

Applied your patch (replacing -v with --version and changing the ver_match
line and it is happily building having found g77

> > > I did use "-n32" for ATLAS/LAPACK because I want to be able to run this on
> > > a variety of SGI boxes.
>
> This is what I have to do, eventually.  Did you have to do anything
> special to get n32 libs?

I downloaded the latest atlast and ran the the make. Instead of taking the
default vaules for the compilers, I replaced -64 with -n32. Same thing
with LAPACK, copy the correct make.inc and replaced the -64 with -n32

> Really?  But isn't arange() from Numeric?  I've just tried this on my
> irix system (importing Numeric rather than scipy) and it looks
> fine -- the correct answer, no NaNs.

True. Importing Numeric (20.3, or 21.0) does not produce incorrect
results.  It is specific to scipy.

> Did you compile python with the MIPS compiler?  Did you know that
> python tickles compiler bugs and you have to build some of it
> without optimization?  [It's something I just learned last week :-(]

I compile apps on various platforms (Solaris 2.6/8, IRIX 6.5, HPUX, Redhat
Linux, AIX 4.x, and soon on our bazillion dollar IA64 Linux cluster). I
use gcc for everything if possible. Not quite the performance as some of
the native compilers, but it saves me lots of headaches.

ok.. during all of that I finally got down to the next error. I fixed this
by going to g77 from gcc-3.0.4



g77 -shared build/temp.irix64-6.5-2.2/fortranobject.o
build/temp.irix64-6.5-2.2/vodemodule.o -L/usr/local/atlas/
-L/usr/local/atlas/ -Lbuild/temp.irix64-6.5-2.2
-Lbuild/temp.irix64-6.5-2.2 -Lbuild/temp.irix64-6.5-2.2
-Lbuild/temp.irix64-6.5-2.2 -Lbuild/temp.irix64-6.5-2.2
-Lbuild/temp.irix64-6.5-2.2 -L/usr/local/atlas/ -L/usr/local/atlas/
-Lbuild/temp.irix64-6.5-2.2 -Lbuild/temp.irix64-6.5-2.2
-Lbuild/temp.irix64-6.5-2.2 -Lbuild/temp.irix64-6.5-2.2
-Lbuild/temp.irix64-6.5-2.2 -Lbuild/temp.irix64-6.5-2.2
-Lbuild/temp.irix64-6.5-2.2 -lodepack -llinpack_lite -llapack -lf77blas
-lcblas -latlas -lg2c -o build/lib.irix64-6.5-2.2/scipy/integrate/vode.so
ld32: WARNING 84 : /usr/local/atlas/liblapack.a is not used for resolving
any symbol.
ld32: WARNING 84 : /usr/local/atlas/libcblas.a is not used for resolving
any symbol.
ld32: Segmentation fault.  Removing output file...
collect2: ld returned 1 exit status


So the beast is compiled. I'll see if I can run it and do some testing.


Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From eric at scipy.org  Thu May  2 21:03:43 2002
From: eric at scipy.org (eric)
Date: Thu, 2 May 2002 21:03:43 -0400
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs scipy)
References: <Pine.GSO.4.44.0205021625470.18212-100000@poincare.emsl.pnl.gov>
Message-ID: <02a901c1f23e$5f503270$6b01a8c0@ericlaptop>


> On Thu, 2 May 2002, eric wrote:
>
> > > All goes well until I hit the bug in optimize/Zeros/zeros.h which I fix
> > > and happily continue on.
> >
> > What problem are you running into on zeros.h?  Can you send a patch?
>
> Here is "diff -c". I think the problem was that the backslash was escaping
> the ^M's that are all over this file. So I took it out and just put
> everything on one line. Hey.. I'm a sysadmin, not a programmer :)

I fixed the line ending issue.  They are all Unix style now.  That should fix
this issue without removing the line break.

eric





From eric at scipy.org  Thu May  2 21:28:07 2002
From: eric at scipy.org (eric)
Date: Thu, 2 May 2002 21:28:07 -0400
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs scipy)
References: <Pine.LNX.4.44.0205021107360.17434-100000@roach.emsl.pnl.gov> <019f01c1f20b$3e350a30$6b01a8c0@ericlaptop> <20020502234513.GC7328@nyongwa.montreal.qc.ca>
Message-ID: <02b901c1f241$c7629fd0$6b01a8c0@ericlaptop>

----- Original Message -----
From: "Steve M. Robbins" <steven.robbins at videotron.ca>
>
> Hi,
>
> I've also been trying to install scipy on an IRIX64 machine.
> I got
>
>
> On Thu, May 02, 2002 at 02:57:44PM -0400, eric wrote:
>
> > > My problem comes at
> > >
> > > ---snip---
> > >
> > > ranlib build/temp.irix64-6.5-2.2/librootfind.a
> > > running run_f2py
> > > running build_flib
> > > scipy_distutils.command.build_flib.gnu_fortran_compiler
> > > error: Fortran compiler not available: None
> > >
> > > ---snip---
> > >
> > > It looks to me like setup can't find fortran. Now there are various
> > > fortran's to choose from
> > >
> > > > which f77
> > > /usr/bin/f77
> > > > which g77
> > > /msrc/apps/gcc-2.95.3/bin/g77
> > >
> > > Both of which should work fine.
>
> However, scipy's setup.py says ...
>
> # force g77 for now
> from scipy_distutils.command import build_flib
> build_flib.all_compilers = [build_flib.gnu_fortran_compiler]
>
> ... so you have to get g77 support working.

Hmmm. Yes.  I had forgotten about that.  I'm not sure it is strictly necessary,
but I've never tried to build with anything else.  Seems like Pearu has though
with some success.  g77 is certainly easiest, especially if your compiler is gcc
because there aren't as many chances for linking issues (incompatible IO
functions, missing libraries, etc.)  If you built everything with the MIPS or
Sun tool chain though, I expect it should all work.  All of the code should be
portable.  If someone comments this out on these machines and has success, let
us know.

> > It sounds like the Fortran compiler detection stuff is failing on
> > your machine.  [ ... ]
>
> > Basically, the way we figure out which compiler is installed is by
> > doing exactly what you did -- running g77 -v or f77 -version or
> > whatever and then running a regular expression on the output.
>
> The problem lies in that "g77 -v" returns exit status 1 on IRIX.
>
> At least that is my experience (though I have GCC 3.0.4 installed
> there).  Curiously, "gcc -v" returns status 0.  Also, both "gcc -v"
> and "g77 -v" return status 0 on my linux machine, for both 2.9x and
> 3.x versions.
>
> Anyway, the "-v" option is documented to print out the commands
> executed during compilation, not to give version info.  Thus, I
> hacked the script to run "g77 --version" instead, and modified the
> regex suitably.  This suffices to detect g77 (from GCC 3.0.4) on
> IRIX.  It looks like it should work with g77 from GCC 2.9x too.
>
> <snip patch>

I've applied the patch.  The only issue with it is that now the get_opt() method
doesn't check for the better optimization flags that Pearu added for Athlon and
Intel processors because it gets the "wrong" version number.  Can someone with
g77 3.x.x tell me what g77 --version returns for this string so that we can
detect it compared to g77 2.95.x.

>
>
> With this change, I built scipy up to the point where it tried to
> link the n32 object with the 64-bit ATLAS libs ...
>
>
> > > I did use "-n32" for ATLAS/LAPACK because I want to be able to run this on
> > > a variety of SGI boxes.
>
> This is what I have to do, eventually.  Did you have to do anything
> special to get n32 libs?
>
>
> > > ------
> > > from scipy import *
> > >
> > > x= arange(0,1,.1)
> > > y=x**2
> > > print y
> > > --------
> > >
> > > y reports lots of NaN's. I can do y=x*x and get the correct results, but
> > > y=x**2 seems broken.
>
> Really?  But isn't arange() from Numeric?  I've just tried this on my
> irix system (importing Numeric rather than scipy) and it looks
> fine -- the correct answer, no NaNs.

Sounds like something is going unhealthy is going on in fastumath.c.

>
> Did you compile python with the MIPS compiler?  Did you know that
> python tickles compiler bugs and you have to build some of it
> without optimization?  [It's something I just learned last week :-(]
>
>
> > I seem to remember that sqrt in Numeric doesn't work on IRIX correctly
either.
> > You might check anyway.
>
> Uh, oh.
>
> -S

eric




From steven.robbins at videotron.ca  Thu May  2 22:45:55 2002
From: steven.robbins at videotron.ca (Steve M. Robbins)
Date: Thu, 2 May 2002 22:45:55 -0400
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <02b901c1f241$c7629fd0$6b01a8c0@ericlaptop>
References: <Pine.LNX.4.44.0205021107360.17434-100000@roach.emsl.pnl.gov> <019f01c1f20b$3e350a30$6b01a8c0@ericlaptop> <20020502234513.GC7328@nyongwa.montreal.qc.ca> <02b901c1f241$c7629fd0$6b01a8c0@ericlaptop>
Message-ID: <20020503024554.GD7328@nyongwa.montreal.qc.ca>

On Thu, May 02, 2002 at 09:28:07PM -0400, eric wrote:

 
> I've applied the patch.  The only issue with it is that now the
> get_opt() method doesn't check for the better optimization flags
> that Pearu added for Athlon and Intel processors because it gets the
> "wrong" version number.  Can someone with g77 3.x.x tell me what g77
> --version returns for this string so that we can detect it compared
> to g77 2.95.x.

It looks like 0.5.25 versus 0.5.26.

On my Debian/linux box:

	steve at riemann{steve}g77-2.95 --version |head -1
	GNU Fortran 0.5.25 20010319 (prerelease)
	steve at riemann{steve}g77-3.0 --version |head -1
	GNU Fortran 0.5.26 20020220 (release)
	steve at riemann{steve}

On the IRIX, g77 (from 3.0.4):

	swmgr at wart{scipy-cvs}g77 --version |head -1
	GNU Fortran 0.5.26 20020220 (release)


-S


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants



From F.L.Burton at udcf.gla.ac.uk  Mon May  6 07:33:15 2002
From: F.L.Burton at udcf.gla.ac.uk (Francis Burton)
Date: Mon, 06 May 2002 12:33:15 +0100
Subject: [SciPy-user] Installing onto Python 2.2.1 (windows)
Message-ID: <3.0.3.32.20020506123315.00839750@lenzie.cent.gla.ac.uk>

Hi!

Total newbie here, but very enthusiastic about the
potential for python and SciPy.

I have already installed on my Win95 system:

Python-2.2.1.exe
ActiveTcl8.3.4.2-1-win32-ix86.exe
Numeric-21.0.win32-py2.2.exe
wxPython-2.3.2.1-Py22-hybrid.exe

and have had python and IDLE running. (Trying to run
the wxPython demo gives "PYTHON caused an exception
c06d007eH in module WXMSW232H.DLL at 0157:00bf59aa."
but I guess that's OT for this mailing list.)

My problem is that when I run SciPy-0.1.win32-py2.1.exe
the "Select python installation to use" box is blank.

Is that because this version was meant to be installed
with python2.1?

I read a message in the archive where someone suggested
getting 0.2 from CVS. I'm not sure how to do this - it
all looks rather complicated and I would much prefer to
run a single Windows executable! :-) Is there a copy of
SciPy-0.2.win32-py2.2.exe available somewhere?

Thanks!

Francis



From jjl at pobox.com  Mon May  6 11:01:38 2002
From: jjl at pobox.com (John J. Lee)
Date: Mon, 6 May 2002 16:01:38 +0100 (BST)
Subject: [SciPy-user] Installing onto Python 2.2.1 (windows)
In-Reply-To: <3.0.3.32.20020506123315.00839750@lenzie.cent.gla.ac.uk>
Message-ID: <Pine.SOL.4.30.0205061554330.15612-100000@mimosa.csv.warwick.ac.uk>

On Mon, 6 May 2002, Francis Burton wrote:
[...]
> My problem is that when I run SciPy-0.1.win32-py2.1.exe
> the "Select python installation to use" box is blank.
>
> Is that because this version was meant to be installed
> with python2.1?

Generally, python extensions (in C, Fortran, or whatever) only work with
the Python version for which they were compiled.  Or at least, they're
only supposed to work for that version (though they do sometimes work
across versions if you're prepared to ignore the warnings).  I guess the
installer is a generic distutils one, so the reason the box is there is
that for pure-Python packages this would be useful.

> I read a message in the archive where someone suggested
> getting 0.2 from CVS. I'm not sure how to do this - it
> all looks rather complicated and I would much prefer to
> run a single Windows executable! :-) Is there a copy of
> SciPy-0.2.win32-py2.2.exe available somewhere?

Will be released soon, apparently.  It's easy to download a CVS version
though, you just follow the generic instructions -- no need to understand
CVS.  Certainly better to use 0.2 ATM, unless you have trouble installing
it.


John



From F.L.Burton at udcf.gla.ac.uk  Mon May  6 12:22:03 2002
From: F.L.Burton at udcf.gla.ac.uk (Francis Burton)
Date: Mon, 06 May 2002 17:22:03 +0100
Subject: [SciPy-user] Installing onto Python 2.2.1 (windows)
In-Reply-To: <Pine.SOL.4.30.0205061554330.15612-100000@mimosa.csv.warwic
 k.ac.uk>
References: <3.0.3.32.20020506123315.00839750@lenzie.cent.gla.ac.uk>
Message-ID: <3.0.3.32.20020506172203.00843a40@lenzie.cent.gla.ac.uk>

Thanks for that, John. I decided meanwhile to take a step
back to python 2.1 and compatible addons (including SciPy).
That works very nicely on my NT machine.

(Unfortunately, wxPython still crashes on Win 95, even
with compatible versions of everything. But I can start
development work on the other computer.)

Francis

At 16:01 06/05/02 +0100, John J. Lee wrote:
>[...]
>Will be released soon, apparently.  It's easy to download a CVS version
>though, you just follow the generic instructions -- no need to understand
>CVS.  Certainly better to use 0.2 ATM, unless you have trouble installing
>it.



From tim.carlson at pnl.gov  Mon May  6 14:00:06 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Mon, 06 May 2002 11:00:06 -0700 (PDT)
Subject: [SciPy-user] install problem can't find fortran
 (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <Pine.GSO.4.44.0205021710550.18212-100000@poincare.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.44.0205060951090.18762-100000@roach.emsl.pnl.gov>

On Thu, 2 May 2002, Tim Carlson wrote:

> So the beast is compiled. I'll see if I can run it and do some testing.

Getting back to this. It seems I can't load the fastumath module. The
shared object does exist.

% python
Python 2.2.1 (#1, May  1 2002, 11:48:54)
[GCC 2.95.3 20010315 (release)] on irix646
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/gen1_scr/tim/python/lib/python2.2/site-packages/scipy/__init__.py", line
29, in ?
    from scipy_base import *
  File "scipy_base/__init__.py", line 4, in ?
    import scipy_base.fastumath
ImportError: No module named fastumath
>>> ^D

I compiled scipy with gcc/g77 from the 3.0.4 distribution. I've also
recompiled python 2.2.1 with gcc-3.0.4 and I get the same error. I've
set my LD_LIBRARY_PATH to the directory where my gcc-3.x libraries are
in the event there was some shared library loading problem. There is a
fastumath.so file in the correct place.

% ls -l site-packages/scipy_base/fastumath.so
-rwxr-xr-x   1 tim      user       463076 May  6 09:42 site-packages/scipy_base/fastumath.so

Any thoughts on this one?

I can import other .so files.

>>> from Numeric import mutliarray
>>>

Thanks

Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From pearu at cens.ioc.ee  Mon May  6 14:25:02 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 6 May 2002 21:25:02 +0300 (EEST)
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs
 scipy)
In-Reply-To: <Pine.LNX.4.44.0205060951090.18762-100000@roach.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.21.0205062120030.19292-100000@cens.ioc.ee>

> On Thu, 2 May 2002, Tim Carlson wrote:
> 
> > So the beast is compiled. I'll see if I can run it and do some testing.
> 
> Getting back to this. It seems I can't load the fastumath module. The
> shared object does exist.
> 
> % python
> Python 2.2.1 (#1, May  1 2002, 11:48:54)
> [GCC 2.95.3 20010315 (release)] on irix646
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from scipy import *
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File
> "/gen1_scr/tim/python/lib/python2.2/site-packages/scipy/__init__.py", line
> 29, in ?
>     from scipy_base import *
>   File "scipy_base/__init__.py", line 4, in ?

          ^^^^^^^^^^^^^^^^^^^^^^

>     import scipy_base.fastumath
> ImportError: No module named fastumath

> Any thoughts on this one?

You are trying to import scipy within the  scipy source directory and
when importing scipy, it picks up scipy_base from the scipy source
directory (that happens to be the current directory), not from the scipy
installation directory. So, you need to go out from the scipy source
directory and try again.

Pearu



From tim.carlson at pnl.gov  Mon May  6 16:33:50 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Mon, 06 May 2002 13:33:50 -0700 (PDT)
Subject: [SciPy-user] install problem can't find fortran
 (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <Pine.LNX.4.21.0205062120030.19292-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.44.0205061154000.18168-100000@roach.emsl.pnl.gov>

On Mon, 6 May 2002, Pearu Peterson wrote:

> You are trying to import scipy within the  scipy source directory and
> when importing scipy, it picks up scipy_base from the scipy source
> directory (that happens to be the current directory), not from the scipy
> installation directory. So, you need to go out from the scipy source
> directory and try again.

oops :-)

Thanks!

Closing in on it.  I enabled the zlib module and rebuilt python. Looks
like this is required although the INSTALL.txt file doesn't mention this.

Here are some more errors to report that will be specific to IRIX.

python 2.2.1 (#4, May  6 2002, 11:49:02)
[GCC 3.0.4] on irix646
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy import *
exceptions.ImportError: 2924328:python: rld: Fatal Error: unresolvable
symbol in /gen1_scr/tim/python/lib/python2.2/site-packages/scipy/linalg/flapack.so: __powdi
exceptions.ImportError: 2924328:python: rld: Fatal Error: unresolvable symbol in
/gen1_scr/tim/python/lib/python2.2/site-packages/scipy/linalg/_flinalg.so: s_wsfe64
exceptions.ImportError: 2924328:python: rld: Fatal Error: unresolvable symbol in
/gen1_scr/tim/python/lib/python2.2/site-packages/scipy/linalg/fblas.so: s_wsfe64


A quick look through the ATLAS libs

nm *.a | grep s_wsfe64

shows

[4]     |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
[14]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
[14]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
[4]     |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64

A look through the libs in /usr/lib32 shows the missing function
lives in /usr/lib32/libftn.so

So I relinked the above shared objects with libftn.so and python now seems
happy to import scipy.

I'll call this an error in the ATLAS build and leave it at that.

Thanks for everybody's help.

Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From pearu at cens.ioc.ee  Mon May  6 17:28:35 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 7 May 2002 00:28:35 +0300 (EEST)
Subject: [SciPy-user] install problem can't find fortran (IRIX/python2.2.1/cvs
 scipy)
In-Reply-To: <Pine.LNX.4.44.0205061154000.18168-100000@roach.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.21.0205070003540.19292-100000@cens.ioc.ee>

On Mon, 6 May 2002, Tim Carlson wrote:

> Closing in on it.  I enabled the zlib module and rebuilt python. Looks
> like this is required although the INSTALL.txt file doesn't mention this.

Fixed. Thanks.

> Here are some more errors to report that will be specific to IRIX.
> 
> python 2.2.1 (#4, May  6 2002, 11:49:02)
> [GCC 3.0.4] on irix646
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from scipy import *
> exceptions.ImportError: 2924328:python: rld: Fatal Error: unresolvable
> symbol in /gen1_scr/tim/python/lib/python2.2/site-packages/scipy/linalg/flapack.so: __powdi
> exceptions.ImportError: 2924328:python: rld: Fatal Error: unresolvable symbol in
> /gen1_scr/tim/python/lib/python2.2/site-packages/scipy/linalg/_flinalg.so: s_wsfe64
> exceptions.ImportError: 2924328:python: rld: Fatal Error: unresolvable symbol in
> /gen1_scr/tim/python/lib/python2.2/site-packages/scipy/linalg/fblas.so: s_wsfe64
> 
> 
> A quick look through the ATLAS libs
> 
> nm *.a | grep s_wsfe64
> 
> shows
> 
> [4]     |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
> [14]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
> [14]    |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
> [4]     |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |s_wsfe64
> 
> A look through the libs in /usr/lib32 shows the missing function
> lives in /usr/lib32/libftn.so
> 
> So I relinked the above shared objects with libftn.so and python now seems
> happy to import scipy.

What Fortran compiler did you used? g77 or SGI? 
For SGI, build_flib.py seems to already define ftn in the list of
libraries and I find it strange (may be a bug in scipy_distutils) that you
needed to relink ftn yourself.
If you used g77 then how was atlas compiled? With g77 or with the SGI
compiler?
If with g77 then I find it very strange that ftn was needed at all
(scipy_distutils might then need some IRIX specific hooks).
But if atlas was compiled with the SGI compiler then it seems to be a
local issue as scipy_distutils can do very little if local libraries are
built with different compilers. Anyway, in the latter case the proper
place to supply ftn (and its location) to the linker would be in
  scipy_distutils/site.cfg

BTW, did you need to modify scipy_distutils in any way, especially the SGI
compiler part in build_flib.py? It would be interesting to know if it
actually works.

Thanks,
	Pearu



From tim.carlson at pnl.gov  Mon May  6 17:56:29 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Mon, 06 May 2002 14:56:29 -0700 (PDT)
Subject: [SciPy-user] install problem can't find fortran
 (IRIX/python2.2.1/cvs scipy)
In-Reply-To: <Pine.LNX.4.21.0205070003540.19292-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.44.0205061453190.18168-100000@roach.emsl.pnl.gov>

On Tue, 7 May 2002, Pearu Peterson wrote:

> What Fortran compiler did you used? g77 or SGI?

I used whatever setup detected. In this case, it got g77.

> If you used g77 then how was atlas compiled? With g77 or with the SGI
> compiler?

I used f77. So here is where I probably got into trouble. f77 probably
pulls that library in to any binaries that get built.

> BTW, did you need to modify scipy_distutils in any way, especially the SGI
> compiler part in build_flib.py? It would be interesting to know if it
> actually works.

I didn't do any modifications to the current cvs tree. I only had to hand
edit the Modules/Setup file to add zlib.

When I find that elusive free time, I'll give it a go with the SGI
compiler and report back.

Now I'm headed to HPUX :(

Tim



From F.L.Burton at udcf.gla.ac.uk  Tue May  7 09:07:44 2002
From: F.L.Burton at udcf.gla.ac.uk (Francis Burton)
Date: Tue, 07 May 2002 14:07:44 +0100
Subject: [SciPy-user] reload / auto gui_thread / file striding
Message-ID: <3.0.3.32.20020507140744.00832e50@lenzie.cent.gla.ac.uk>

Now that I have SciPy working with python (under NT not 95),
and am thoroughly enjoying the experience of strolling up the
gentle learning curve, I have a few questions which seasoned
users might be able to help me with. (I hope it's not considered
poor etiquette to ask multiple questions in a single post!) 

1) I have a module which I want to edit and test incrementally
   by invoking functions interactively in IDLE after I have
   typed "from mymodule import *". Do I really have to quit and
   restart IDLE after every change? One of the books mentions
   reload, but this just raises a NameError: name 'mymodule' is
   not defined. What is the correct way to do edit-run cycles?

2) Is there any way I can get IDLE (or plain python) to execute
   "import gui_thread/from scipy import plt/from scipy import *"
   automatically when I start it up? Given the fact I have to
   quit and restart repeatedly, it is a bit of a pain to have
   to retype these statements. (I prefer to use IDLE because the
   syntax coloring and function arg hints are really helpful.)

3) I'm extracting 16 bit integers from a binary data file which
   consists of consecutive frames of 256 digitized channels
   (which follow a fixed sized header). I want to process each
   channel in turn. This means repeatedly seeking forward,
   reading a integer, and appending the value to an array.
   Then I have to write the processed values back to the file.
   The way I am doing it is as follows:

def ReadChannel(chan):
    trace = array('d')
    word = array('H')
    for i in range(nframes):
        offset = ( chan + 256*i + 154 ) * 2
        f.seek(offset)
        word.fromfile(f, 1)
        trace.append(float(word[0]))
        word.pop()
    f.close()
    return trace

def WriteChannel(trace, chan):
    word = array('H', [0])
    f = open(filename, 'r+b')
    for i in range(nframes):
        offset = ( chan + 256*i + 154 ) * 2
        f.seek(offset)
        word[0] = trace[i]   # truncation ok
        word.tofile(f)
    f.close()

   The code for writing is quite intuitive, whereas that for
   reading is not - because it involves an additional call
   to 'pop'. It seems strangely asymmetric to me. But is this
   a good way to handle this situation?

Thanks very much in advance!

Francis



From adamrossbarker at hotmail.com  Tue May  7 11:53:00 2002
From: adamrossbarker at hotmail.com (Adam Barker)
Date: Tue, 07 May 2002 10:53:00 -0500
Subject: [SciPy-user] Please excuse our dust.
Message-ID: <B8FD628C.20%adamrossbarker@hotmail.com>

Hello All,

First, an introduction:

My name is Adam Barker, and I recently started working with Enthought on the
Scipy project.  I'll be taking care of most of the system administration
tasks for the Scipy website and mailing lists, so if you have any questions,
I'll do my best to answer them in a timely manner.

Second, we're doing a bit of work on the websites and the mailing lists.
Specifically, we're moving them to a different set of machines and a
different service provider this week.  Hopefully the move will be
transparent, but there might be a few hiccups this week as everything gets
finished.  We're going to be conservative with the switchover to avoid
interruption of service if possible.

If you have any questions or comments, or if you find something radically
incorrect with the Scipy websites or mailing lists, please feel free to
contact me at:

adam at enthought.com

Thanks!

Adam



From tim.carlson at pnl.gov  Tue May  7 12:31:42 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Tue, 07 May 2002 09:31:42 -0700 (PDT)
Subject: [SciPy-user] forcing compiler other than g77 on HPUX
In-Reply-To: <Pine.LNX.4.21.0205062120030.19292-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.44.0205070922580.21771-100000@roach.emsl.pnl.gov>

So now I am onto HPUX where both g77 from gcc-2.95.3 and gcc-3.0.4 fail
with an internal error when compiling various parts of scipy.  I would
like to use the HP compiler. I used this compiler to build ATLAS and
LAPACK and didn't have any problems.

I dug around and changed all of the places where the GNU fortran compiler
was being force to the following:

build_flib.hpux_fortran_compiler

and added the following bit of code to build_flib.py

--------
class hpux_fortran_compiler(fortran_compiler_base):

    vendor = 'HP'
    ver_match =  r'HP F90 (?P<version>[^\s*,]*)'

    def __init__(self, fc = None, f90c = None):
        fortran_compiler_base.__init__(self)
        if fc is None:
            fc = 'f90'
        if f90c is None:
            f90c = 'f90'

        self.f77_compiler = fc
        self.f77_switches = ' '
        self.f77_opt = ' -O3 '

        self.f90_compiler = f90c
        self.f90_switches = ' '
        self.f90_opt = ' -O3 '

        self.ver_cmd = self.f77_compiler + ' +version'

        self.libraries = ['m']
        self.library_dirs = self.find_lib_dir()



    def build_module_switch(self,module_dirs):
        res = ''
        return res
    def find_lib_dir(self):
        library_dirs = []
        return library_dirs
    def get_runtime_library_dirs(self):
        return self.find_lib_dir()
    def get_extra_link_args(self):
        return []
--------

The HP compiler on this system reports version information with +version
and -O3 seems to be a standard optimization level.  There error I get is I
think due to the return code from  "f90 +version". Here is where it dies

running run_f2py
running build_flib
scipy_distutils.command.build_flib.hpux_fortran_compiler
command: f90 +version
256 HP F90 v2.4
error: Fortran compiler not available: None

I don't know where that "256" is coming from.  I tried some things with
ver_match but nothing seemed to work.

Any ideas on this one?

Thanks

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From pearu at cens.ioc.ee  Tue May  7 13:56:54 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 7 May 2002 20:56:54 +0300 (EEST)
Subject: [SciPy-user] forcing compiler other than g77 on HPUX
In-Reply-To: <Pine.LNX.4.44.0205070922580.21771-100000@roach.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.21.0205072042190.14688-100000@cens.ioc.ee>

On Tue, 7 May 2002, Tim Carlson wrote:

> So now I am onto HPUX where both g77 from gcc-2.95.3 and gcc-3.0.4 fail
> with an internal error when compiling various parts of scipy.

Could you be more specific here? Is it a compiler or scipy issue? And
which parts are failing if the latter?

> --------
> 
> The HP compiler on this system reports version information with +version
> and -O3 seems to be a standard optimization level.  There error I get is I
> think due to the return code from  "f90 +version". Here is where it dies
> 
> running run_f2py
> running build_flib
> scipy_distutils.command.build_flib.hpux_fortran_compiler
> command: f90 +version
> 256 HP F90 v2.4
> error: Fortran compiler not available: None
> 
> I don't know where that "256" is coming from.  I tried some things with
> ver_match but nothing seemed to work.

256 is the return status of the command. If this means success in HP then
you can add some hooks to fortran_compiler_base.get_version method, or
better yet, rewrite it for the hpux_fortran_compiler so that with this
status value it will return the version of the compiler.

BTW, you can try also --fcompiler=HP option to force to look only for this
compiler, eg.

 setup.py build build_flib --fcompiler=HP

Note that build must precede build_flib.

Pearu




From pearu at scipy.org  Tue May  7 15:18:30 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Tue, 7 May 2002 14:18:30 -0500 (CDT)
Subject: [SciPy-user] reload / auto gui_thread / file striding
In-Reply-To: <3.0.3.32.20020507140744.00832e50@lenzie.cent.gla.ac.uk>
Message-ID: <Pine.LNX.4.21.0205071402370.5606-100000@scipy.org>

On Tue, 7 May 2002, Francis Burton wrote:

> Now that I have SciPy working with python (under NT not 95),
> and am thoroughly enjoying the experience of strolling up the
> gentle learning curve, I have a few questions which seasoned
> users might be able to help me with. (I hope it's not considered
> poor etiquette to ask multiple questions in a single post!) 

It is fine to have multiple questions, but your questions are
off-topic. comp.lang.python would be more appropiate place to ask these
questions. Anyway, I can provide few answers below...

> 1) I have a module which I want to edit and test incrementally
>    by invoking functions interactively in IDLE after I have
>    typed "from mymodule import *". Do I really have to quit and
>    restart IDLE after every change? One of the books mentions
>    reload, but this just raises a NameError: name 'mymodule' is
>    not defined. What is the correct way to do edit-run cycles?

reload works for modules that are imported like
  import mymodule
If you do "from mymodule import *" then the modules content is imported to
the current name space but the module itself is not.
You could also try

  import mymodule
  from mymodule import *

  # do stuff, edit mymodule.py

  reload(mymodule)
  from mymodule import *

  # do other stuff

> 
> 2) Is there any way I can get IDLE (or plain python) to execute
>    "import gui_thread/from scipy import plt/from scipy import *"
>    automatically when I start it up? Given the fact I have to
>    quit and restart repeatedly, it is a bit of a pain to have
>    to retype these statements. (I prefer to use IDLE because the
>    syntax coloring and function arg hints are really helpful.)

I have no idea about IDLE but for plain python I have defined

PYTHONSTARTUP=/home/users/pearu/.pythonrc.py

environment variable and the file .pythonrc.py contains stuff that is
executed whenever I start python in interactive mode.


HTH,
	Pearu



From fperez at pizero.colorado.edu  Tue May  7 15:36:24 2002
From: fperez at pizero.colorado.edu (Fernando Perez)
Date: Tue, 7 May 2002 13:36:24 -0600 (MDT)
Subject: [SciPy-user] reload / auto gui_thread / file striding
In-Reply-To: <Pine.LNX.4.21.0205071402370.5606-100000@scipy.org>
Message-ID: <Pine.OSF.3.96.1020507132545.19180B-100000@longs.colorado.edu>

> > 1) I have a module which I want to edit and test incrementally
> >    by invoking functions interactively in IDLE after I have
> >    typed "from mymodule import *". Do I really have to quit and
> >    restart IDLE after every change? One of the books mentions
> >    reload, but this just raises a NameError: name 'mymodule' is
> >    not defined. What is the correct way to do edit-run cycles?
> 
> reload works for modules that are imported like
>   import mymodule
> If you do "from mymodule import *" then the modules content is imported to
> the current name space but the module itself is not.
> You could also try
> 
>   import mymodule
>   from mymodule import *
> 
>   # do stuff, edit mymodule.py
> 
>   reload(mymodule)
>   from mymodule import *
> 
>   # do other stuff

Or you could use IPython ;) Honestly, it's a lot more efficient than the
python shell, even though I'm obviously biased having written most of it.

But with IPython you simply say

run myfile.py

and it gets loaded into the current namespace, with all definitions
re-executed each time (an execfile() under the hood). I never use import
anymore when testing code interactively.

> > 2) Is there any way I can get IDLE (or plain python) to execute
> >    "import gui_thread/from scipy import plt/from scipy import *"
> >    automatically when I start it up? Given the fact I have to
> >    quit and restart repeatedly, it is a bit of a pain to have
> >    to retype these statements. (I prefer to use IDLE because the
> >    syntax coloring and function arg hints are really helpful.)
> 
> I have no idea about IDLE but for plain python I have defined
> 
> PYTHONSTARTUP=/home/users/pearu/.pythonrc.py

IPython supports multiple configuration files, so you can have as many things
loaded as you want and have different 'profiles' for different tasks (since
maybe you don't want to always load scipy/gui_thread, for example).

It doesn't do colors and calltips, but it has functions to retrieve lots of
information about any object. Here's a 'screenshot':

In [1]: list2dict2?
Type:           function
Base Class:     <type 'function'>
String Form:    <function list2dict2 at 0x80e3c04>
Namespace:      User-defined configuration
File:           /usr/local/home/fperez/local/python/IPython/genutils.py
Definition:     list2dict2(lst, default='')
Docstring:
    Takes a list and turns it into a dict.
    Much slower than list2dict, but more versatile. This version can take
    lists with sublists of arbitrary length (including scalars).

In [2]: pdef list2dict2
list2dict2(lst, default='')

In [3]: doc list2dict2
Takes a list and turns it into a dict.
Much slower than list2dict, but more versatile. This version can take
lists with sublists of arbitrary length (including scalars).

In [4]: source list2dict2
def list2dict2(lst,default=''):
    """Takes a list and turns it into a dict.
    Much slower than list2dict, but more versatile. This version can take
    lists with sublists of arbitrary length (including scalars)."""

    dic = {}
    for elem in lst:
        if type(elem) in (types.ListType,types.TupleType):
            size = len(elem)
            if  size == 0:
                pass
[snipped rest...]

If you are interested, you can take a look at more information at
http://www-hep.colorado.edu/~fperez/ipython/

Cheers,

f.



From pearu at scipy.org  Tue May  7 16:10:37 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Tue, 7 May 2002 15:10:37 -0500 (CDT)
Subject: [SciPy-user] reload / auto gui_thread / file striding
In-Reply-To: <Pine.OSF.3.96.1020507132545.19180B-100000@longs.colorado.edu>
Message-ID: <Pine.LNX.4.21.0205071438530.5606-100000@scipy.org>


On Tue, 7 May 2002, Fernando Perez wrote:

> IPython supports <stuff snipped>
>
> It doesn't do colors and calltips, but it has functions to retrieve lots of
> information about any object.

Which gives me an idea that IPython could do colors if you are interested
in. Namely you can send colored (+ bolded + underlined + stroked +
background colored) output to terminal using ANSI color escape
sequences.
I got the idea from
  http://www.livinglogic.de/Python/ansistyle/
but didn't use this ansistyle module because it was to fancy for my apps.
Anyway, try

print '\x1b[1;32m%s\x1b[0m'% ('Hello, I am bold green')
print '\x1b[1;41m%s\x1b[0m'% ('Hello, I am bold white on red background')
print '\x1b[4;31m%s\x1b[0m'% ('Hello, I am underlined red')

to get an idea.

Pearu



From fperez at pizero.colorado.edu  Tue May  7 16:23:55 2002
From: fperez at pizero.colorado.edu (Fernando Perez)
Date: Tue, 7 May 2002 14:23:55 -0600 (MDT)
Subject: [SciPy-user] reload / auto gui_thread / file striding
In-Reply-To: <Pine.LNX.4.21.0205071438530.5606-100000@scipy.org>
Message-ID: <Pine.OSF.3.96.1020507141732.19180G-100000@longs.colorado.edu>

> > It doesn't do colors and calltips, but it has functions to retrieve lots of
> > information about any object.
> 
> Which gives me an idea that IPython could do colors if you are interested
> in. Namely you can send colored (+ bolded + underlined + stroked +
> background colored) output to terminal using ANSI color escape
> sequences.
> I got the idea from
>   http://www.livinglogic.de/Python/ansistyle/
> but didn't use this ansistyle module because it was to fancy for my apps.

[snip]

Thanks Pearu. In fact, it does a lot of coloring for exception tracebacks in
various modes and prompts. I use a simpler scheme than the livinglogic stuff
which is overly heavy. 

The trick is that it doesn't do on-the-fly, as-you-type syntax highlighting.
That would require deeply hacking into the keyboard handling, because you'd
need to modify the line where the user is currently typing, which is under
readline's control. So it's _very_ non-trivial; I'm not trying to rewrite
emacs here ;)

In the future I plan to reorganize it internally (this has been discussed in
the past, mainly in private with Eric and Arnd) so that it can be plugged into
graphical shells like idle and pycrust without losing its stand-alone
functionality in a text terminal. But that will be later...

In the meantime I find it quite useful as it is. I'll soon put out a new
release with some significant enhancements, I can announce it here if there's
interest (it goes to c.l.py anyway). If you go to the above url you can grab
it in current pre-release state (probably what will be the final at this
point).

Cheers,

f.



From tim.carlson at pnl.gov  Tue May  7 19:09:11 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Tue, 07 May 2002 16:09:11 -0700 (PDT)
Subject: [SciPy-user] forcing compiler other than g77 on HPUX
In-Reply-To: <Pine.LNX.4.21.0205072042190.14688-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.44.0205071137430.21808-100000@roach.emsl.pnl.gov>

On Tue, 7 May 2002, Pearu Peterson wrote:

> > So now I am onto HPUX where both g77 from gcc-2.95.3 and gcc-3.0.4 fail
> > with an internal error when compiling various parts of scipy.
>
> Could you be more specific here? Is it a compiler or scipy issue? And
> which parts are failing if the latter?

It is an issue of scipy not being able to find the HP compiler and my
attempt to make scipy use the HP compiler.

I forced build_flib.py to use the compiler by setting the match in the
get_version routine

self.version = "v2.4"

I know that is horrible, but like I've pointed out.. I'm an admin, not a
programmer :)

With that little hack and setting the compiler flags to "-O3 +pic=long"
I got most it going until I ran into linalg/src/calc_lwork.f which
complained about some of the types that were being compared in a
few of the MAX function calls. Apparently comparing a REAL and an INTEGER
is a bad thing with f90 on HPUX. I applied some changes there which you
probably don't want to see.

Now.. everything compiles without too many warnings. I give it a try and I
get the following.

-----
Python 2.2.1 (#1, May  6 2002, 15:20:34)
[GCC 3.0.4] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/__init__.py", line 42, in ?
    import special, io, linalg, stats, fftpack
  File
"/msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/special/__init__.py", line 323, in ?
    from special import *
  File
"/msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/special/special.py", line 10, in ?
    import specfun
ImportError: dynamic module does not define init function (initspecfun)
-----

Running an nm on that shared object shows me that the function is indeed defined.

nm /msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/special/specfun.sl | grep initspecfun
00012590 T initspecfun
000124d0 T initspecfun

And I can load other shared objects into this python, so I don't think the
problem lies entirely with HPUX's implementation of shared objects.

>>> from Numeric import multiarray
>>>


Any ideas

Thanks again

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From pearu at scipy.org  Tue May  7 19:20:51 2002
From: pearu at scipy.org (pearu at scipy.org)
Date: Tue, 7 May 2002 18:20:51 -0500 (CDT)
Subject: [SciPy-user] forcing compiler other than g77 on HPUX
In-Reply-To: <Pine.LNX.4.44.0205071137430.21808-100000@roach.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.21.0205071809150.10423-100000@scipy.org>


On Tue, 7 May 2002, Tim Carlson wrote:

> It is an issue of scipy not being able to find the HP compiler and my
> attempt to make scipy use the HP compiler.
> 
> I forced build_flib.py to use the compiler by setting the match in the
> get_version routine
> 
> self.version = "v2.4"

I'll add HP compiler class (as you send before + doing version stuff
properly) tomorrow. It's rather late here ..

> With that little hack and setting the compiler flags to "-O3 +pic=long"
> I got most it going until I ran into linalg/src/calc_lwork.f which
> complained about some of the types that were being compared in a
> few of the MAX function calls. Apparently comparing a REAL and an INTEGER
> is a bad thing with f90 on HPUX. I applied some changes there which you
> probably don't want to see.

But could you point out which lines are broken? Because calc_lwork.f is
mostly copy-paste of LAPACK routines and they compiled fine as you said
before.

> -----
> Python 2.2.1 (#1, May  6 2002, 15:20:34)
> [GCC 3.0.4] on hp-ux11
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from scipy import *
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File
> "/msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/__init__.py", line 42, in ?
>     import special, io, linalg, stats, fftpack
>   File
> "/msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/special/__init__.py", line 323, in ?
>     from special import *
>   File
> "/msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/special/special.py", line 10, in ?
>     import specfun
> ImportError: dynamic module does not define init function (initspecfun)
> -----
> 
> Running an nm on that shared object shows me that the function is indeed defined.
> 
> nm /msrc/apps/python-2.2/lib/python2.2/site-packages/scipy/special/specfun.sl | grep initspecfun
> 00012590 T initspecfun
> 000124d0 T initspecfun
> 
> And I can load other shared objects into this python, so I don't think the
> problem lies entirely with HPUX's implementation of shared objects.

Strange indeed. Can you import other extension modules that scipy created?
Like linalg/*.sl, optimize/*.sl, signal/*.sl etc.
Are they all failing or just few of them?

Pearu



From tim.carlson at pnl.gov  Tue May  7 19:54:01 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Tue, 07 May 2002 16:54:01 -0700 (PDT)
Subject: [SciPy-user] forcing compiler other than g77 on HPUX
In-Reply-To: <Pine.LNX.4.21.0205071809150.10423-100000@scipy.org>
Message-ID: <Pine.LNX.4.44.0205071637510.23501-100000@roach.emsl.pnl.gov>

On Tue, 7 May 2002 pearu at scipy.org wrote:

> I'll add HP compiler class (as you send before + doing version stuff
> properly) tomorrow. It's rather late here ..

Great! thanks!

> But could you point out which lines are broken? Because calc_lwork.f is
> mostly copy-paste of LAPACK routines and they compiled fine as you said
> before.

I ended up making a temporary variable (either REAL or INTEGER) for the
second argument depending on what it needed to be.

f90 /msrc/tmp/calc_lwork.f
   external subroutine GESDD
               WRKBL = MAX( WRKBL, N+M*ILAENV( 1, prefix // 'ORGQR',
                                    ^
Error 191 at (48:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, 3*N+2*N*
                                      ^
Error 191 at (51:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, 3*N+N*
                                      ^
Error 191 at (54:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, 3*N+N*
                                      ^
Error 191 at (57:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, BDSPAC+2*N )
                                         ^
Error 191 at (60:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               MAXWRK = MAX(WRKBL,BDSPAC + 3*N)
                                         ^
Error 191 at (71:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, M+N*ILAENV( 1, prefix // 'ORGLQ',
                                    ^
Error 191 at (109:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, 3*M+2*M*
                                      ^
Error 191 at (112:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, 3*M+M*
                                      ^
Error 191 at (115:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, 3*M+M*
                                      ^
Error 191 at (118:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               WRKBL = MAX( WRKBL, BDSPAC+2*M )
                                         ^
Error 191 at (121:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
               MAXWRK = MAX(WRKBL,BDSPAC + 3*M)
                                         ^
Error 191 at (130:/msrc/tmp/calc_lwork.f) : This argument has either the
wrong type or no type
   external subroutine GELSS
   external subroutine GETRI
   external subroutine GEEV


> Strange indeed. Can you import other extension modules that scipy created?
> Like linalg/*.sl, optimize/*.sl, signal/*.sl etc.
> Are they all failing or just few of them?

Just a few of them. Here is a non random sample after copying the some .sl
files to my home directory

Python 2.2.1 (#1, May  6 2002, 15:20:34)
[GCC 3.0.4] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> import sigtools
>>> import spline
>>> import _minpack
>>> import _zeros
>>> import flapack
>>> import _flinalg
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (init_flinalg)
>>> import calc_lwork
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (initcalc_lwork)
>>> import cblas
>>> import clapack
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (initclapack)
>>> import fblas
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (initfblas)
>>> import specfun
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (initspecfun)
>>> import fastumath
>>>

Tim



From pearu at cens.ioc.ee  Wed May  8 12:18:09 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 8 May 2002 19:18:09 +0300 (EEST)
Subject: [SciPy-user] forcing compiler other than g77 on HPUX
In-Reply-To: <Pine.LNX.4.44.0205071637510.23501-100000@roach.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.21.0205081905330.23008-100000@cens.ioc.ee>

Hi,

I have commited the support for HP F90 compiler to CVS. Could you check it
out? Also, does HP-UX has a F77 compiler? Or do HP-UX people always use
F90 compiler for Fortran 77 programs as well?

On Tue, 7 May 2002, Tim Carlson wrote:

> I ended up making a temporary variable (either REAL or INTEGER) for the
> second argument depending on what it needed to be.
> 
> f90 /msrc/tmp/calc_lwork.f
>    external subroutine GESDD
>                WRKBL = MAX( WRKBL, N+M*ILAENV( 1, prefix // 'ORGQR',
>                                     ^
> Error 191 at (48:/msrc/tmp/calc_lwork.f) : This argument has either the
> wrong type or no type
<snip>

I think these errors were due to the fact that WRKBL was not declared.
This is fixed now in CVS.

> Just a few of them. Here is a non random sample after copying the some .sl
> files to my home directory
> 
> Python 2.2.1 (#1, May  6 2002, 15:20:34)
> [GCC 3.0.4] on hp-ux11
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sigtools
> >>> import spline
> >>> import _minpack
> >>> import _zeros
> >>> import flapack
> >>> import _flinalg
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dynamic module does not define init function (init_flinalg)
> >>> import calc_lwork
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dynamic module does not define init function (initcalc_lwork)
> >>> import cblas
> >>> import clapack
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dynamic module does not define init function (initclapack)
> >>> import fblas
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dynamic module does not define init function (initfblas)
> >>> import specfun
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dynamic module does not define init function (initspecfun)
> >>> import fastumath
> >>>

Hmm. I have little ideas what could be wrong. Many of these modules have
exactly the same origin but some of them fail and some not. Hmm.
Can anybody else see a pattern here?

If you have a HP F77 compiler could you try re-compiling scipy fortran 
stuff with that?

Pearu



From groma at nucleus.szbk.u-szeged.hu  Tue May 14 05:26:01 2002
From: groma at nucleus.szbk.u-szeged.hu (Geza Groma)
Date: Tue, 14 May 2002 11:26:01 +0200
Subject: [SciPy-user] build problem using cygwin
Message-ID: <3CE0D829.6F929F42@nucleus.szbk.u-szeged.hu>

I tried to build scipy from the latest (MAy 13) CVS on a WindowsNT using
cygwin-1.3.10-1 and gcc-2.95.3-5.
It succesfully built atlas.3.3.15 and created the complete liblapack.a
library from LAPACK 3.0. Building of scipy, however,  is stopped at the
creation of the first dll with the error message below.

Any idea what is wrong?


c:\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s
build\temp.win32-2.2\Release\fortranobject.o build\temp.win32-2.2\Rel
ease\fblasmodule.o build\temp.win32-2.2\Release\fblas.def -LC:\Atlaslib
-LC:\Atlaslib -Lbuild\temp.win32-2.2 -LC:\Python
22\libs -Lbuild\temp.win32-2.2
-Lc:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 -lfblas -llapack
-lf77blas -lcblas -latla
s -lpython22 -lc_misc -lcephes -lrootfind -lgcc -lg2c -o
build\lib.win32-2.2\scipy\linalg\fblas.pyd
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(s_stop.o)(.text+0x2f):s_stop.c:
undefined reference to `_impure_p
tr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(s_stop.o)(.text+0x4d):s_stop.c:
undefined reference to `_impure_p
tr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(s_stop.o)(.text+0x69):s_stop.c:
undefined reference to `_impure_p
tr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(sfe.o)(.text+0x4e):sfe.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(sfe.o)(.text+0xb1):sfe.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(sfe.o)(.text+0xeb):sfe.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(fmt.o)(.text+0x49):fmt.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(fmt.o)(.text+0x95):fmt.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(fmt.o)(.text+0xe54):fmt.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(fmt.o)(.text+0xe76):fmt.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(fmt.o)(.text+0xf2e):fmt.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(fmt.o)(.text+0xf63):fmt.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wsfe.o)(.text+0x1d4):wsfe.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wsfe.o)(.text+0x278):wsfe.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wsfe.o)(.text+0x27f):wsfe.c:
more undefined references to `__errn
o' follow
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x49b):err.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x4bd):err.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x508):err.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x534):err.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x551):err.c:
undefined reference to `_impure_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x577):err.c:
more undefined references to `_impure_
ptr' follow
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x767):err.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x838):err.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(err.o)(.text+0x8a7):err.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(open.o)(.text+0x286):open.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(open.o)(.text+0x424):open.c:
undefined reference to `__errno'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(open.o)(.text+0x577):open.c:
more undefined references to `__errn
o' follow
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(sig_die.o)(.text+0x16):sig_die.c:
undefined reference to `_impure
_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(sig_die.o)(.text+0x30):sig_die.c:
undefined reference to `_impure
_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(sig_die.o)(.text+0x46):sig_die.c:
undefined reference to `_impure
_ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wrtfmt.o)(.text+0x1b0):wrtfmt.c:
undefined reference to `__errno'

c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wrtfmt.o)(.text+0x966):wrtfmt.c:
undefined reference to `_impure_
ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wrtfmt.o)(.text+0xaec):wrtfmt.c:
undefined reference to `_impure_
ptr'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(wref.o)(.text+0x146):wref.c:
undefined reference to `_imp___ctype
_'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(endfile.o)(.text+0x5d):endfile.c:
undefined reference to `__errno
'
c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(endfile.o)(.text+0x374):endfile.c:
undefined reference to `__errn
o'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

--
G?za Groma
Institute of Biophysics,
Biological Research Center of Hungarian Academy of Sciences
Temesv?ri krt.62.
6726 Szeged
Hungary
phone: +36 62 432 232
fax:   +36 62 433 133




From F.L.Burton at udcf.gla.ac.uk  Tue May 14 07:11:32 2002
From: F.L.Burton at udcf.gla.ac.uk (Francis Burton)
Date: Tue, 14 May 2002 12:11:32 +0100
Subject: [SciPy-user] Equivalent of the X Public Access Mechanism
Message-ID: <3.0.3.32.20020514121132.00845490@lenzie.cent.gla.ac.uk>

Has anything like the X Public Access Mechanism been
implemented for/in python?

http://hea-www.harvard.edu/RD/saotng/about_xpa.html

"XPA allows an Xt program to define named public access points
through which data and commands can be exchanged with external
programs."

Basically, GUI programs running as separate processes can be
called as widgets, in much the same way as gnuplot is currently
used within scipy except that XPA allows bidirectional flow of
data. The underlying mechanism is based on sockets and TCP/IP,
so it is networkable.

I think it would be a very nice addition to scipy, facilitating
its extensibility via (and interfacing with) 3rd party programs.

Francis



From pearu at cens.ioc.ee  Tue May 14 08:43:00 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 14 May 2002 15:43:00 +0300 (EEST)
Subject: [SciPy-user] build problem using cygwin
In-Reply-To: <3CE0D829.6F929F42@nucleus.szbk.u-szeged.hu>
Message-ID: <Pine.LNX.4.21.0205141538240.25998-100000@cens.ioc.ee>

On Tue, 14 May 2002, Geza Groma wrote:

> I tried to build scipy from the latest (MAy 13) CVS on a WindowsNT using
> cygwin-1.3.10-1 and gcc-2.95.3-5.
> It succesfully built atlas.3.3.15 and created the complete liblapack.a
> library from LAPACK 3.0. Building of scipy, however,  is stopped at the
> creation of the first dll with the error message below.
> 
> Any idea what is wrong?

No. But google seems to contain lots of messages reporting similar
problems with cygwin. They may be helpful.

> c:\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s
                         ^^^^^^^^^^ - ?
> build\temp.win32-2.2\Release\fortranobject.o build\temp.win32-2.2\Rel
> ease\fblasmodule.o build\temp.win32-2.2\Release\fblas.def -LC:\Atlaslib
> -LC:\Atlaslib -Lbuild\temp.win32-2.2 -LC:\Python
> 22\libs -Lbuild\temp.win32-2.2
> -Lc:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 -lfblas -llapack
> -lf77blas -lcblas -latla
> s -lpython22 -lc_misc -lcephes -lrootfind -lgcc -lg2c -o
> build\lib.win32-2.2\scipy\linalg\fblas.pyd
> c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(s_stop.o)(.text+0x2f):s_stop.c:
> undefined reference to `_impure_ptr'
<snip>

Pearu




From groma at nucleus.szbk.u-szeged.hu  Tue May 14 09:36:02 2002
From: groma at nucleus.szbk.u-szeged.hu (Geza Groma)
Date: Tue, 14 May 2002 15:36:02 +0200
Subject: [SciPy-user] build problem using cygwin
References: <Pine.LNX.4.21.0205141538240.25998-100000@cens.ioc.ee>
Message-ID: <3CE112C2.3A672D71@nucleus.szbk.u-szeged.hu>


Pearu Peterson wrote:

> On Tue, 14 May 2002, Geza Groma wrote:
>
> > I tried to build scipy from the latest (MAy 13) CVS on a WindowsNT using
> > cygwin-1.3.10-1 and gcc-2.95.3-5.
> > It succesfully built atlas.3.3.15 and created the complete liblapack.a
> > library from LAPACK 3.0. Building of scipy, however,  is stopped at the
> > creation of the first dll with the error message below.
> >
> > Any idea what is wrong?
>
> No. But google seems to contain lots of messages reporting similar
> problems with cygwin. They may be helpful.
>

Thanks, I will make a seek. BTW I am not dedicated to use cygwin. First I tried mingw
(gcc-2.95.2-msvcrt.exe), but that failed to build Atlas. Than I changed to cygwin, what was
successful with Atlas, but failed with scipy. So I returned to mingw and built scipy
apparently successfully using the cygwin-built Atlas libs. However, I am a bit worry about
that hybrid. Is there any single tool to build _both_ Atlas and scipy on Windows?

>
> > c:\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s

Well, I did not make any effort to put the -mno-cygwin flag, simply executed 'python
setup.py install'. The flag was created 'automatically'.

--
G?za Groma
Institute of Biophysics,
Biological Research Center of Hungarian Academy of Sciences
Temesv?ri krt.62.
6726 Szeged
Hungary
phone: +36 62 432 232
fax:   +36 62 433 133




From eric at enthought.com  Tue May 14 10:51:34 2002
From: eric at enthought.com (eric)
Date: Tue, 14 May 2002 10:51:34 -0400
Subject: [SciPy-user] Equivalent of the X Public Access Mechanism
References: <3.0.3.32.20020514121132.00845490@lenzie.cent.gla.ac.uk>
Message-ID: <003701c1fb56$d8392ef0$6b01a8c0@ericlaptop>

Hey Francis,

This sounds like something that might be better as a generic Python module, as
others outside of the scipy community would also be interested in it.

You might also look into other methods that are currently available in Python.
You can expose Python functions to separate processes (even over the web)
through xml-rpc, SOAP, http, custom socket servers, etc.  These are all
cross-platforms and often trivial to implement if you just need to expose a
single function.

see ya,
eric

----- Original Message -----
From: "Francis Burton" <F.L.Burton at udcf.gla.ac.uk>
To: <scipy-user at scipy.org>
Sent: Tuesday, May 14, 2002 7:11 AM
Subject: [SciPy-user] Equivalent of the X Public Access Mechanism


> Has anything like the X Public Access Mechanism been
> implemented for/in python?
>
> http://hea-www.harvard.edu/RD/saotng/about_xpa.html
>
> "XPA allows an Xt program to define named public access points
> through which data and commands can be exchanged with external
> programs."
>
> Basically, GUI programs running as separate processes can be
> called as widgets, in much the same way as gnuplot is currently
> used within scipy except that XPA allows bidirectional flow of
> data. The underlying mechanism is based on sockets and TCP/IP,
> so it is networkable.
>
> I think it would be a very nice addition to scipy, facilitating
> its extensibility via (and interfacing with) 3rd party programs.
>
> Francis
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at codetent.com
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From jochen at unc.edu  Tue May 14 11:56:27 2002
From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=)
Date: 14 May 2002 11:56:27 -0400
Subject: [SciPy-user] build problem using cygwin
In-Reply-To: <3CE112C2.3A672D71@nucleus.szbk.u-szeged.hu>
References: <Pine.LNX.4.21.0205141538240.25998-100000@cens.ioc.ee>
	<3CE112C2.3A672D71@nucleus.szbk.u-szeged.hu>
Message-ID: <lyn0v2bucz.fsf@bock.chem.unc.edu>

On Tue, 14 May 2002 15:36:02 +0200 Geza Groma wrote:

Geza> Is there any single tool to build _both_ Atlas and scipy on
Geza> Windows?

Are you using the cygwin python or do you wanna use the Windows
Python?

I use Cygwin:)) Latest cygwin (incl. python and gcc) and scipy cvs...
It didn't work all time, but lately I don't have many problems.

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E



From a.schmolck at gmx.net  Wed May 15 07:57:29 2002
From: a.schmolck at gmx.net (A.Schmolck)
Date: 15 May 2002 12:57:29 +0100
Subject: [SciPy-user] problems building scipy from cvs
Message-ID: <yfsbsbhzkra.fsf@black132.ex.ac.uk>

Hi,

Is scipy meant to work with Atlas 3.4.0? I haven't managed to build
yesterday's CVS version with it successfully (haven't tried the Atlas 3.3.x
versions, 3.4 should do everything those do, is that right?). Anyway after
building , here is what I get  when I do ``import scipy``:

exceptions.ImportError:
/usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: undefined symbol:
clapack_sgetri

> nm /usr/lib/liblapack.a |grep sgetri
sgetri.o:
00000000 T sgetri_

I'm running Linux Mandrake 8.1 on an Athlon and used gcc 2.95.3 to build
atlas, according to the instructions on the atlas pages.


Cheers,

alex


-- 
Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/



From pearu at cens.ioc.ee  Wed May 15 12:37:29 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 15 May 2002 19:37:29 +0300 (EEST)
Subject: [SciPy-user] problems building scipy from cvs
In-Reply-To: <yfsbsbhzkra.fsf@black132.ex.ac.uk>
Message-ID: <Pine.LNX.4.21.0205151926050.2090-100000@cens.ioc.ee>


On 15 May 2002, A.Schmolck wrote:

> Hi,
> 
> Is scipy meant to work with Atlas 3.4.0? 

I think so. From Atlas 3.4.0 announcement:
   <snip>

   3.4.0 is 3.3.15 with some doc changes.

   <snip>

> I haven't managed to build
> yesterday's CVS version with it successfully (haven't tried the Atlas 3.3.x
> versions, 3.4 should do everything those do, is that right?). Anyway after
> building , here is what I get  when I do ``import scipy``:
> 
> exceptions.ImportError:
> /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: undefined symbol:
> clapack_sgetri
> 
> > nm /usr/lib/liblapack.a |grep sgetri
> sgetri.o:
> 00000000 T sgetri_

Where did you install your atlas? What's the output of

  python scipy_distutils/system_info.py

? Are you sure that scipy was built against atlas 3.4.0 and not against
the system atlas?

For example, in my case (Atlas 3.3.14)

nm /path/to/my/atlas/liblapack.a | grep clapack_sgetri
clapack_sgetri.o:
00000000 T clapack_sgetri

HTH,

Pearu



From a.schmolck at gmx.net  Wed May 15 15:06:14 2002
From: a.schmolck at gmx.net (A.Schmolck)
Date: 15 May 2002 20:06:14 +0100
Subject: [SciPy-user] problems building scipy from cvs
In-Reply-To: <Pine.LNX.4.21.0205151926050.2090-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205151926050.2090-100000@cens.ioc.ee>
Message-ID: <yfsy9elxmc9.fsf@black132.ex.ac.uk>

Pearu Peterson <pearu at cens.ioc.ee> writes:

> 
> ? Are you sure that scipy was built against atlas 3.4.0 and not against
> the system atlas?
> 
> For example, in my case (Atlas 3.3.14)
> 
> nm /path/to/my/atlas/liblapack.a | grep clapack_sgetri
> clapack_sgetri.o:
> 00000000 T clapack_sgetri
> 
> HTH,
> 
> Pearu

Yes, that helped indeed, thanks. I must have made some mistake when I ar'ed
the atlas stuff into my lapack library -- I did it again and now it works.

Thanks.

alex


-- 
Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/



From tinu at email.ch  Thu May 16 04:24:45 2002
From: tinu at email.ch (tinu)
Date: 16 May 2002 10:24:45 +0200
Subject: [SciPy-user] NNTP access to scipy-dev and scipy-user
Message-ID: <m3hel8fqk2.fsf@yak.ethz.ch>

Dear list members

There is now NNTP access to the scipy lists at

news://news.gmane.org

The lists scipy-mailing lists are named

gmane.comp.python.scientific.user 
gmane.comp.python.scientific.devel 

If everything works out, this message should be sent 
through the news server at www.gmane.org

Enjoy

Martin

-- 
Martin L?thi              VAW Glaciology, ETH Z?rich, Switzerland
                          mel: luthi at vaw.baug.ethz.ch




From nwagner at mecha.uni-stuttgart.de  Thu May 16 09:43:30 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 16 May 2002 15:43:30 +0200
Subject: [SciPy-user] Numerical integration of a matrix
Message-ID: <3CE3B782.D7F3FDF0@mecha.uni-stuttgart.de>

Hi all,

How do I integrate the following matrix elements in an efficient manner
with scipy

c_{j,k} = \int\limits_0^\pi \varepsilon a(x) \sin (k x) \sin (j x) dx   
(Latex notation)

j, k = 1, ..., 9

\varepsilon = 0.1

a(x) = x^2 (\pi-x)^2 - \delta, \delta = 201.0

Thanks in advance.


                   Nils


From nwagner at mecha.uni-stuttgart.de  Thu May 16 10:14:12 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 16 May 2002 16:14:12 +0200
Subject: [SciPy-user] quadpack.error: Supplied function does not return a valid float.
Message-ID: <3CE3BEB4.1F894FF6@mecha.uni-stuttgart.de>

Hi,

I have experienced a problem while using quad

Traceback (most recent call last):
  File "quad.py", line 9, in ?
    print m,n,sinint(m,n,1)
  File "quad.py", line 6, in sinint
    return quad(integrand,0.,pi,args=(m,n,x))
  File
"/usr/local/lib/python2.1/site-packages/scipy/integrate/quadpack.py",
line 180, in quad
    retval = _quad(func,a,b,args,full_output,epsabs,epsrel,limit,points)
  File
"/usr/local/lib/python2.1/site-packages/scipy/integrate/quadpack.py",
line 244, in _quad
    return
_quadpack._qagse(func,a,b,args,full_output,epsabs,epsrel,limit)
quadpack.error: Supplied function does not return a valid float.

from scipy import *
from scipy.integrate import quad
def integrand(t,m,n,x):
   return sin(m*x*t)*sin(n*x*t)
def sinint(m,n,x):
   return quad(integrand,0.,pi,args=(m,n,x))
for m in arange(0,9):
   for n in arange(0,9):
      print m,n,sinint(m,n,1)

Any idea ?

Nils


From pearu at cens.ioc.ee  Thu May 16 13:59:49 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 16 May 2002 20:59:49 +0300 (EEST)
Subject: [SciPy-user] Numerical integration of a matrix
In-Reply-To: <3CE3B782.D7F3FDF0@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0205162050400.4051-100000@cens.ioc.ee>

On Thu, 16 May 2002, Nils Wagner wrote:

> Hi all,
> 
> How do I integrate the following matrix elements in an efficient manner
> with scipy
> 
> c_{j,k} = \int\limits_0^\pi \varepsilon a(x) \sin (k x) \sin (j x) dx   
> (Latex notation)
> 
> j, k = 1, ..., 9
> 
> \varepsilon = 0.1
> 
> a(x) = x^2 (\pi-x)^2 - \delta, \delta = 201.0

I think you can do it also analytically (use some CAS, for example).
But if you insist it to be done numerically then look at quadpack
functions QAWO and QAWF. Or disrcetize a(x) and use FFT.

Pearu



From clee at spiralis.merseine.nu  Thu May 16 14:48:49 2002
From: clee at spiralis.merseine.nu (clee at spiralis.merseine.nu)
Date: Thu, 16 May 2002 13:48:49 -0500
Subject: [SciPy-user] Numerical integration of a matrix
In-Reply-To: <3CA04003.BDAC5A15@mecha.uni-stuttgart.de>
References: <3CA04003.BDAC5A15@mecha.uni-stuttgart.de>
Message-ID: <15587.65297.423631.99572@spiralis.merseine.nu>

On Thu, 16 May 2002, Nils Wagner wrote:

> Hi all,
> 
> How do I integrate the following matrix elements in an efficient manner
> with scipy
> 
> c_{j,k} = \int\limits_0^\pi \varepsilon a(x) \sin (k x) \sin (j x) dx   
> (Latex notation)
> 
> j, k = 1, ..., 9
> 
> \varepsilon = 0.1
> 
> a(x) = x^2 (\pi-x)^2 - \delta, \delta = 201.0

Pearu's mail caught me while I was actually  in Mathematica, so I went ahead and
tried it. -chris


--mathematica code--
a[x_] := x^2 (Pi-x)^2 - 201.0; 
cm[j_,k_] := Integrate[a[x] Sin[j x] Sin[k x], {x, 0, Pi}];
results = Table[cm[j,k], {j,1,9}, {k,1,9}];
TeXForm[TableForm[results]]

--Here's the answer, embeded in latex.--

\documentclass[8pt]{report}
\usepackage[active]{srcltx}
\begin{document}


\[
  \matrix{ -308.274 & 0 & \frac{-45\,\pi }{64} & 0 & \frac{-65\,\pi }
    {1728} & 0 & \frac{-175\,\pi }{27648} & 0 & \frac{-1107\,\pi }
    {640000} \cr 0 & -310.482 & 0 & \frac{-20\,\pi }{27} & 0 & \frac{-45\,
      \pi }{1024} & 0 & \frac{-136\,\pi }{16875} & 0 \cr \frac{-45\,\pi }
    {64} & 0 & -310.601 & 0 & \frac{-765\,\pi }{1024} & 0 & \frac{-1827\,\pi }
    {40000} & 0 & \frac{-5\,\pi }{576} \cr 0 & \frac{-20\,\pi }
    {27} & 0 & -310.621 & 0 & \frac{-468\,\pi }{625} & 0 & \frac{-5\,\pi }
    {108} & 0 \cr \frac{-65\,\pi }{1728} & 0 & \frac{-765\,\pi }
    {1024} & 0 & -310.626 & 0 & \frac{-1295\,\pi }{1728} & 0 & \frac{-7155\,
      \pi }{153664} \cr 0 & \frac{-45\,\pi }{1024} & 0 & \frac{-468\,\pi }
    {625} & 0 & -310.628 & 0 & \frac{-1800\,\pi }{2401} & 0 \cr \frac{-175\,
      \pi }{27648} & 0 & \frac{-1827\,\pi }{40000} & 0 & \frac{-1295\,\pi }
    {1728} & 0 & -310.629 & 0 & \frac{-12285\,\pi }{16384} \cr 0 & \frac{
      -136\,\pi }{16875} & 0 & \frac{-5\,\pi }{108} & 0 & \frac{-1800\,\pi }
    {2401} & 0 & -310.629 & 0 \cr \frac{-1107\,\pi }{640000} & 0 & \frac{-5\,
      \pi }{576} & 0 & \frac{-7155\,\pi }{153664} & 0 & \frac{-12285\,\pi }
    {16384} & 0 & -310.629 \cr  } 
\]

\end{document}


From oliphant.travis at ieee.org  Thu May 16 15:21:23 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 16 May 2002 13:21:23 -0600
Subject: [SciPy-user] quadpack.error: Supplied function does not return
	a valid float.
In-Reply-To: <3CE3BEB4.1F894FF6@mecha.uni-stuttgart.de>
References: <3CE3BEB4.1F894FF6@mecha.uni-stuttgart.de>
Message-ID: <1021576885.3009.2.camel@travis>

On Thu, 2002-05-16 at 08:14, Nils Wagner wrote:
> Hi,
> 
> I have experienced a problem while using quad
> 
> Traceback (most recent call last):
>   File "quad.py", line 9, in ?
>     print m,n,sinint(m,n,1)
>   File "quad.py", line 6, in sinint
>     return quad(integrand,0.,pi,args=(m,n,x))
>   File
> "/usr/local/lib/python2.1/site-packages/scipy/integrate/quadpack.py",
> line 180, in quad
>     retval = _quad(func,a,b,args,full_output,epsabs,epsrel,limit,points)
>   File
> "/usr/local/lib/python2.1/site-packages/scipy/integrate/quadpack.py",
> line 244, in _quad
>     return
> _quadpack._qagse(func,a,b,args,full_output,epsabs,epsrel,limit)
> quadpack.error: Supplied function does not return a valid float.
> 
> from scipy import *
> from scipy.integrate import quad
> def integrand(t,m,n,x):
>    return sin(m*x*t)*sin(n*x*t)
> def sinint(m,n,x):
>    return quad(integrand,0.,pi,args=(m,n,x))
> for m in arange(0,9):
>    for n in arange(0,9):
>       print m,n,sinint(m,n,1)
> 
> Any idea ?
> 

This error was caused by a problem with PyFloat_AsDouble in the Python
CAPI.  This function does error checking on the object it is trying to
convert to a float and if an error occurs it returns -1.  As I was
checking for this case in the interface, it effectively made any
function which returns -1.0 raise an error.  

I rewrote the interface to do the error checking manually and use
PyFloat_AS_DOUBLE which is just a macro to extract the C-float from the
Python object.

The changes are checked into CVS.

-Travis






From jochen at unc.edu  Thu May 16 16:15:48 2002
From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=)
Date: 16 May 2002 16:15:48 -0400
Subject: [SciPy-user] quadpack.error: Supplied function does not return a valid float.
In-Reply-To: <1021576885.3009.2.camel@travis>
References: <3CE3BEB4.1F894FF6@mecha.uni-stuttgart.de>
	<1021576885.3009.2.camel@travis>
Message-ID: <lyelgbg87f.fsf@bock.chem.unc.edu>

On 16 May 2002 13:21:23 -0600 Travis Oliphant wrote:

Travis> This error was caused by a problem with PyFloat_AsDouble in the Python
Travis> CAPI.  This function does error checking on the object it is trying to
Travis> convert to a float and if an error occurs it returns -1.  

But PyFloat_AsDouble also raises an exception, which has to be checked
for by PyErr_Occurred(). See 
,----
| Python/C API Reference Manual:  1.3 Exceptions
`----

Travis> As I was checking for this case in the interface, it
Travis> effectively made any function which returns -1.0 raise an
Travis> error.

I believe if you replaced your check for -1 by PyErr_Occurred() all
would be fine and no re-writing of Python necessary.

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E



From andrea.riciputi at libero.it  Thu May 16 18:50:00 2002
From: andrea.riciputi at libero.it (Andrea Riciputi)
Date: Fri, 17 May 2002 00:50:00 +0200
Subject: [SciPy-user] Installing SciPy, help needed.
Message-ID: <40D93F14-691F-11D6-B9B5-000A278B3B82@libero.it>

Hi there,
I'm sorry if this is a already-asked question, but I'm quite new to python 
and completly new to SciPy. I'm considering SciPy as environment of choice 
to develope my Ph.D. thesis in astronomy. But I wasn't able to install it 
on my Linux box. Here is where the building process stops:

> In file included from fft/fftw_threads.h:23,
>                  from fft/fftw_wrap.c:559:
> fft/fftw.h:124: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:570: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:571: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:572: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:573: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:576: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:615: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:2651: warning: function declaration isn't a prototype
> fft/fftw_wrap.c:211: warning: `SWIG_addvarlink' defined but not used
> gcc -shared build/temp.linux-ppc-2.2/fftw_wrap.o -L/root/lib 
> -L/usr/lib/gcc-lib/ppc-yellowdog-linux/2.95.3/specs -L/usr/lib/gcc-
> lib/ppc-yellowdog-linux/2.95.3/specs -Lbuild/temp.linux-ppc-2.2 
> -Lbuild/temp.linux-ppc-2.2 -lfftw_threads -lrfftw_threads -lfftw -lrfftw 
> -lpthread -lamos -ltoms -lfitpack -lminpack -lquadpack -lodepack 
> -llinpack_lite -lblas -lmach -lg2c -lgist -lc_misc -lcephes -o build/lib.
> linux-ppc-2.2/scipy/fft/fftw.so
> /usr/bin/ld: cannot find -lfftw_threads
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> [root at localhost SciPy-0.1]#

Note that I've already installed FFTW as described in build instructions. 
I'm sorry but I'm not a Linux's wizard and I haven't any idea about what 
went wrong. Could anyone help me?

One more question: can I build SciPy without having installed wxPython? 
How?(I've got some problems with it too, and I don't really need it at the 
moment..)

Thanks in advance,
Andrea.

---
Andrea Riciputi        <mailto:andrea.riciputi at libero.it>

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)



From pearu at cens.ioc.ee  Fri May 17 03:28:13 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 17 May 2002 10:28:13 +0300 (EEST)
Subject: [SciPy-user] Installing SciPy, help needed.
In-Reply-To: <40D93F14-691F-11D6-B9B5-000A278B3B82@libero.it>
Message-ID: <Pine.LNX.4.21.0205171021540.26367-100000@cens.ioc.ee>

On Fri, 17 May 2002, Andrea Riciputi wrote:

> Note that I've already installed FFTW as described in build instructions. 
> I'm sorry but I'm not a Linux's wizard and I haven't any idea about what 
> went wrong. Could anyone help me?

I would suggest getting SciPy-0.2 from its CVS repository. It is more
stable than 0.1 and you don't need FFTW for building SciPy (in case you
wonder what happend to fft then in 0.2 it uses fftpack instead of the fftw 
library).

> One more question: can I build SciPy without having installed wxPython? 
> How?(I've got some problems with it too, and I don't really need it at the 
> moment..)

In scipy/setup.py remove 'xplt' item from the unix_packages list.

HTH,
	Pearu



From andrea.riciputi at libero.it  Fri May 17 04:47:14 2002
From: andrea.riciputi at libero.it (Andrea Riciputi)
Date: Fri, 17 May 2002 10:47:14 +0200
Subject: [SciPy-user] Installing SciPy, help needed.
In-Reply-To: <Pine.LNX.4.21.0205171021540.26367-100000@cens.ioc.ee>
Message-ID: <AF5A904D-6972-11D6-AB3C-000A278B3B82@libero.it>

On Friday, May 17, 2002, at 09:28 , Pearu Peterson wrote:

> I would suggest getting SciPy-0.2 from its CVS repository. It is more
> stable than 0.1 and you don't need FFTW for building SciPy (in case you
> wonder what happend to fft then in 0.2 it uses fftpack instead of the fftw
> library).
>

Thanks for the hint, but I got stuck in the middle of the download, for 
sake of precision the download stops at:

cvs server: Updating scipy/xplt/gist

...

U scipy/xplt/gist/xicky.h

Any help??

Thanks,
Andrea.

---
Andrea Riciputi        <mailto:andrea.riciputi at libero.it>

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)



From groma at nucleus.szbk.u-szeged.hu  Fri May 17 07:05:53 2002
From: groma at nucleus.szbk.u-szeged.hu (Geza Groma)
Date: Fri, 17 May 2002 13:05:53 +0200
Subject: [SciPy-user] build problem using cygwin - solved
References: <Pine.LNX.4.21.0205141538240.25998-100000@cens.ioc.ee>
Message-ID: <3CE4E411.DD628FC5@nucleus.szbk.u-szeged.hu>

Well, it took a while to trace back the problem... The root of that is analyzed in
 http://www.nanotech.wisc.edu/~khan/software/gnu-win32/mno-cygwin-howto.txt.
In a nutshell, the -mno-cygwin compiler flag (set by distutil in Python2.2) should ensure a
mingw-type linking,
but several mingw libraries (libgcc.a, libg2c.a, libiberty.a, libm.a, libobjc.a and
libstdc++.a) are not distributed in a standard cygwin package. In the case of scipy the
improper (cygwin-type) libg2c.a is linked to a dll. The solution is to copy the above
libraries from a mingw distribution to the /usr/lib/mingw directory. In my setup (gcc
2.95.3-5)  this is mounted to c:\cygwin\lib\mingw (_not_ to c:\cygwin\usr\lib\mingw!) In
this version the specs already knows this location, as well as that up the minw header files
which are distributed correctly.

The next problem is that the scipy distutils explicitly sets a -L flag pointing the original
path, so even if the correct libraries are in the correct place the wrong ones will be
linked. This is manage in the following peace of code in
scipy\scipy_distutils\command\build_flib.py:

class gnu_fortran_compiler(fortran_compiler_base):

    vendor = 'Gnu'
    #ver_match = r'g77 version (?P<version>[^\s*]*)'
    ver_match = r'GNU Fortran (?P<version>[^\s*]*)'

    def __init__(self, fc = None, f90c = None):
        fortran_compiler_base.__init__(self)
        if sys.platform == 'win32':
            self.libraries = ['gcc','g2c']
            self.library_dirs = self.find_lib_directories()
        else:
            # On linux g77 does not need lib_directories to be specified.
            self.libraries = ['g2c']
[snip]

The solution is to comment out the line
            self.library_dirs = self.find_lib_directories()
Also 'gcc' is not needed in self.libraries, that is gcc 2.95.3-5 on windows behaves
identical to that in linux.
I suggest to put an extra condition on 'win32' platform checking the the version of gcc
(probably not that of g77).
I have no idea that from what version the above mechanism works, but for me it helped to
build scipy completely.

Geza Groma

Pearu Peterson wrote:

> On Tue, 14 May 2002, Geza Groma wrote:
>
> > I tried to build scipy from the latest (MAy 13) CVS on a WindowsNT using
> > cygwin-1.3.10-1 and gcc-2.95.3-5.
> > It succesfully built atlas.3.3.15 and created the complete liblapack.a
> > library from LAPACK 3.0. Building of scipy, however,  is stopped at the
> > creation of the first dll with the error message below.
> >
> > Any idea what is wrong?
>
> No. But google seems to contain lots of messages reporting similar
> problems with cygwin. They may be helpful.
>
> > c:\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s
>                                      ^^^^^^^^^^ - ?
> > build\temp.win32-2.2\Release\fortranobject.o build\temp.win32-2.2\Rel
> > ease\fblasmodule.o build\temp.win32-2.2\Release\fblas.def -LC:\Atlaslib
> > -LC:\Atlaslib -Lbuild\temp.win32-2.2 -LC:\Python
> > 22\libs -Lbuild\temp.win32-2.2
> > -Lc:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 -lfblas -llapack
> > -lf77blas -lcblas -latla
> > s -lpython22 -lc_misc -lcephes -lrootfind -lgcc -lg2c -o
> > build\lib.win32-2.2\scipy\linalg\fblas.pyd
> > c:/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libg2c.a(s_stop.o)(.text+0x2f):s_stop.c:
> > undefined reference to `_impure_ptr'
> <snip>
>
> Pearu
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at codetent.com
> http://www.scipy.net/mailman/listinfo/scipy-user

--
G?za Groma
Institute of Biophysics,
Biological Research Center of Hungarian Academy of Sciences
Temesv?ri krt.62.
6726 Szeged
Hungary
phone: +36 62 432 232
fax:   +36 62 433 133




From jochen at unc.edu  Fri May 17 09:37:22 2002
From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=)
Date: 17 May 2002 09:37:22 -0400
Subject: [SciPy-user] Installing SciPy, help needed.
In-Reply-To: <AF5A904D-6972-11D6-AB3C-000A278B3B82@libero.it>
References: <AF5A904D-6972-11D6-AB3C-000A278B3B82@libero.it>
Message-ID: <lyoffeevzh.fsf@bock.chem.unc.edu>

On Fri, 17 May 2002 10:47:14 +0200 Andrea Riciputi wrote:

Andrea> Thanks for the hint, but I got stuck in the middle of the download,
Andrea> for sake of precision the download stops at:

Andrea> cvs server: Updating scipy/xplt/gist

I have seen scipy's cvs hanging over the last couple of days, too.
Ever since the "move", I believe.  It is hanging right now again.
(Sorry, I have no time to look into that currently -- that's also the
reason I hadn't reported it before.)

On a related topic, is the ml Sender: header fixed now, or is it going
to change a few more times?

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E



From eric at enthought.com  Fri May 17 10:18:53 2002
From: eric at enthought.com (eric)
Date: Fri, 17 May 2002 10:18:53 -0400
Subject: [SciPy-user] [ANN] Chaco: A 2D scientific graphics library
Message-ID: <03e501c1fdad$c668c8d0$6b01a8c0@ericlaptop>

I'm happy to announce that Enthought is developing a platform independent
plotting library for Python. The Chaco project, as it is named, is funded by
the Space Telescope Science Institute (STScI) and licensed under a BSD style
open source license. Chaco is designed for presentation quality scientific 2D
graphics on a variety of output devices. The initial targets are wxPython,
TkInter, Mac OS X, and PDF for hard copy output. It's design is extensible so
that other backends, such as OpenGL, can be added. Currently, the low-level API
for wxPython, Mac OS X, and PDF are operational.  The high level graphics
objects will be developed over the coming months.  Chaco is hosted at the SciPy
site. For more information visit:

        http://www.scipy.org/site_content/chaco

People are invited to comment on and contribute to the project.  Chaco's
discussion
list is:

    scipy-chaco at scipy.org

To subscribe, go to the mailing list's info page:

    http://scipy.net/mailman/listinfo/scipy-chaco

thanks,
eric jones

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057





From oliphant.travis at ieee.org  Sat May 18 12:32:25 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 18 May 2002 10:32:25 -0600
Subject: [SciPy-user] [ANN] Chaco: A 2D scientific graphics library
In-Reply-To: <03e501c1fdad$c668c8d0$6b01a8c0@ericlaptop>
References: <03e501c1fdad$c668c8d0$6b01a8c0@ericlaptop>
Message-ID: <1021739546.13534.4.camel@travis>

Hi Eric,

I've been kind of silent for a few weeks engaged in other matters
(including a vacation).  Good job on chaco so far (very clever name).

I've noticed that my password seems not to work on the cvs server
today.  It worked just a couple of days ago but now seems to not let me
update the cvs tree.  Any idea what's wrong?

Thanks,

-Travis




From dmorrill at enthought.com  Mon May 20 11:31:03 2002
From: dmorrill at enthought.com (David C. Morrill)
Date: Mon, 20 May 2002 10:31:03 -0500
Subject: [SciPy-user] SciPy.org web site improvements
References: <B90D9BB4.1DD%adam@scipy.com>
Message-ID: <026401c20013$5ad803c0$6501a8c0@Dave>

Over the last few days, there have been a number of improvements made to the
http://www.scipy.org web site. Some of the changes worth mentioning are:

- We now have a nightly build/test/update process in place that builds and
tests over 30 different platform and subcomponent configurations for SciPy.
Right now we are testing on Linux (Red Hat 7.2), Windows 2000 (cygwin) and
Windows 2000 (mingw), with various versions of Python, Numeric and f2py. The
latest CVS version of SciPy is used for each test. Some of the test
configurations also include the latest CVS versions of Python, Numeric and
f2py.

The results of each build/test process are automatically uploaded to the
SciPy.org web site and are made visible through the new "Downloads"
(http://www.scipy.org/site_content/download_list) and "Build/Test
Scoreboard" (http://www.scipy.org/site_content/scoreboard) pages.

- The new "Downloads" page (link is at the top of the site menu on the left
side of the page) provides links to all the latest SciPy source and binary
tarballs that are built nightly for each platform.

- The new "Build/Test Scoreboard" page (link is in the site navigation menu
on the left of each page) shows the latest build/test results for each
configuration tested, including whether or not it "built" successfully, the
number of tests that failed or had errors, as well as a link to the detailed
log generated by the build/test process.

- There have also been a number of "cosmetic" changes made to the site,
including streamlining and reorganizing of the site menus, which hopefully
will make the site easier to navigate.

Dave Morrill
---
David Morrill <dmorrill at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057




From adam at enthought.com  Mon May 20 13:16:18 2002
From: adam at enthought.com (Adam Barker)
Date: Mon, 20 May 2002 11:16:18 -0600
Subject: [SciPy-user] New CVS commit mailing list
Message-ID: <000d01c20022$11c7ccb0$7501a8c0@drklahn>

Hello all,

I'm pleased to announce that we now have a CVS commit log mailing list.
The new mailing list is called scipy-cvs, and is accessible at:

	http://www.scipy.net/mailman/listinfo/scipy-cvs

This list receives automatic updates on every commit to our repository.
Enjoy!

Let me know if you have any questions.

Thanks,

Adam



From ringzero at spl.at  Mon May 20 19:33:44 2002
From: ringzero at spl.at (ring zero)
Date: Mon, 20 May 2002 16:33:44 -0700 (PDT)
Subject: [SciPy-user] How To Plot List with None Values?
Message-ID: <20020520233344.EC3113ECD@sitemail.everyone.net>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20020520/457a1ab8/attachment.ksh>

From eric at enthought.com  Mon May 20 23:11:28 2002
From: eric at enthought.com (eric)
Date: Mon, 20 May 2002 23:11:28 -0400
Subject: [SciPy-user] How To Plot List with None Values?
References: <20020520233344.EC3113ECD@sitemail.everyone.net>
Message-ID: <009901c20075$32fa6700$6b01a8c0@ericlaptop>

One solution is to split the array up into the segments between the None values
and just plot these with gaps in spots that had None values.  You could modify
the code to connect the segments if that is preferable.

Hope that helps,

eric

--------------------

>>> import gui_thread
>>> import tp
>>> tp.plt_noneless([None,1,2,None,4,5,None])

--------------------
# tp.py
from Numeric import *

def noneless(a):
    a= asarray(a)
    ind = compress(a==None,arange(len(a)))
    ind = concatenate(([-1],ind,[len(a)]))
    pairs = zip(ind[:-1],ind[1:])

    segments = []
    for low,hi in pairs:
        sub_a = a[low+1:hi].astype(Float64)
        if sub_a:
            segments.append([arange(low+1,hi),sub_a])
    return segments

def plt_noneless(a,fmt ='b-'):
    from scipy import plt
    segments = noneless(a)
    plt.figure()
    plt.hold('on')
    for x,y in segments:
        plt.plot(x,y,fmt)
    plt.hold('off')



----- Original Message -----
From: "ring zero" <ringzero at spl.at>
To: <scipy-user at scipy.net>
Sent: Monday, May 20, 2002 7:33 PM
Subject: [SciPy-user] How To Plot List with None Values?


> Hello Everyone:
>
> Please forgive me if this question has been asked and answered.  I'm new to
scipy and scientific programming in general and I couldn't find an answer for
this in the list archives.
>
> I have multiple lists that I'd like to show on a single plot.  The first list
is just a bunch of floats, in the form of:
>
> [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]
>
> My problem is with my secondary lists, which are all in the form of:
>
> [None, None, 3.5, 4.5, 5.5, 6.5]
>
> Each of these secondary lists may have one or more None values at the
beginning.  My first naive approach was to replace each None with 0.0, and that
worked, but my plot scale was skewed to the point of uselessness.
>
> Can anyone point me to a solution?  I'd like each secondary list to plot right
aligned with the first, and with the initial None values dropped off.
>
> Any help is appreciated.
>
> rz
>
> p.s., thanks for scipy, it rocks.
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From nwagner at mecha.uni-stuttgart.de  Tue May 21 08:56:27 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 21 May 2002 14:56:27 +0200
Subject: [SciPy-user] cvs access
Message-ID: <3CEA43FB.8590D819@mecha.uni-stuttgart.de>

Hi,

How do I get access to the cvs version of scipy ?

Nils

cvs -z3 -d:pserver:anonymous at cvs.scipy.sourceforge.net:/cvsroot/scipy co
scipy
cvs server: cannot find module `scipy' - ignored
cvs [checkout aborted]: cannot expand modules


From travis at enthought.com  Tue May 21 09:29:21 2002
From: travis at enthought.com (Travis N. Vaught)
Date: Tue, 21 May 2002 08:29:21 -0500
Subject: [SciPy-user] cvs access
In-Reply-To: <3CEA43FB.8590D819@mecha.uni-stuttgart.de>
Message-ID: <KPEIKEPEIBGNGNKHDILIKEDHDFAA.travis@enthought.com>

Hey Nils,

We're running our own CVS server (not utilizing sourceforge for this).
Instructions are here:

http://www.scipy.org/site_content/tutorials/CVSInstruct

Let me know if you have any trouble.  By the way, there is a new nightly
build  from cvs for some platforms here (as well as a source tarball):

http://www.scipy.org/site_content/download_list

You might also be interested in the nightly build scoreboard for various
platforms:

http://www.scipy.org/site_content/scoreboard

Eric Jones, Dave Morrill, et al just put this process together and it is
sweet.

Travis V.

> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]On
> Behalf Of Nils Wagner
> Sent: Tuesday, May 21, 2002 7:56 AM
> To: scipy-user at scipy.net
> Subject: [SciPy-user] cvs access
>
>
> Hi,
>
> How do I get access to the cvs version of scipy ?
>
> Nils
>
> cvs -z3 -d:pserver:anonymous at cvs.scipy.sourceforge.net:/cvsroot/scipy co
> scipy
> cvs server: cannot find module `scipy' - ignored
> cvs [checkout aborted]: cannot expand modules
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user



From nwagner at mecha.uni-stuttgart.de  Tue May 21 09:52:31 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 21 May 2002 15:52:31 +0200
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 /xplt/gistCmodule.c' does not exist
Message-ID: <3CEA511F.EE24FFAC@mecha.uni-stuttgart.de>

Hi Travis,

I have used SciPy-0.2.0_alpha_101.3442 from

http://www.scipy.org/site_content/download_list


However the result of

python setup.py build 

is

/export/home/wagner/myscipy/SciPy-0.2.0_alpha_101.3442/fftpack/fftpackmodule.c:
At top level:
/export/home/wagner/myscipy/SciPy-0.2.0_alpha_101.3442/fftpack/fftpackmodule.c:484:
warning: function declaration isn't a prototype
g77 -shared build/temp.linux-i686-2.1/fftpackmodule.o
-Lbuild/temp.linux-i686-2.1 -Lbuild/temp.linux-i686-2.1 -lfftpack
-ldfftpack -lg2c -o build/lib.linux-i686-2.1/scipy/fftpack/fftpack.so
restoring linker_so ['gcc', '-shared']
scipy.xplt.gistC gistC needs fortran libraries 0 0
building 'scipy.xplt.gistC' extension
error: file
'/export/home/wagner/myscipy/SciPy-0.2.0_alpha_101.3442/xplt/gistCmodule.c'
does not exist

Any idea ?

Nils


From pearu at cens.ioc.ee  Tue May 21 10:18:09 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 17:18:09 +0300 (EEST)
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 /xplt/gistCmodule.c'
 does not exist
In-Reply-To: <3CEA511F.EE24FFAC@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0205211704300.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, Nils Wagner wrote:

> I have used SciPy-0.2.0_alpha_101.3442 from
> 
> http://www.scipy.org/site_content/download_list
> 
> However the result of
> 
> python setup.py build 
> 
> is

<snip>
> '/export/home/wagner/myscipy/SciPy-0.2.0_alpha_101.3442/xplt/gistCmodule.c'
> does not exist
> 
> Any idea ?

It seems that SciPy-0.2.0_alpha_101.3442_src.tar.gz is created under
Windows and that is why xplt is not included to this tar-ball.
If you don't care about xplt then you can disable it manually from
scipy/setup.py (look for unix_packages). If you do care, then get SciPy
from its CVS repository.

Also note that the CVS version number 101.3442 is very old (from the
middle of April, I believe) meaning that calc_cvs_version hooks in SciPy
CVS repository are still disabled. Adam?

Pearu



From nwagner at mecha.uni-stuttgart.de  Tue May 21 10:29:12 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 21 May 2002 16:29:12 +0200
Subject: [SciPy-user] SciPy from its CVS repository
Message-ID: <3CEA59B8.744A1908@mecha.uni-stuttgart.de>

Hi Pearu,

there seems to be a problem with the CVS repository ...

How do I get scipy from its CVS repository ?

cvs ... ????.


Nils


From pearu at cens.ioc.ee  Tue May 21 10:32:20 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 17:32:20 +0300 (EEST)
Subject: [SciPy-user] SciPy from its CVS repository
In-Reply-To: <3CEA59B8.744A1908@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0205211727390.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, Nils Wagner wrote:

> Hi Pearu,
> 
> there seems to be a problem with the CVS repository ...
> 
> How do I get scipy from its CVS repository ?
> 
> cvs ... ????.

See 

  http://www.scipy.org/site_content/tutorials/CVSInstruct

or

  cvs -d :pserver:anonymous at scipy.org:/home/cvsroot login
  [Enter for pw]
  cvs -z7 -d :pserver:anonymous at scipy.org:/home/cvsroot checkout scipy

Indeed, for some reasons this checkout also made my cvs to hang at

U scipy/xplt/gist/xicky.h

so that I cancelled it. But you can try later again using

  cd scipy && cvs -z7 -q up -P -d

Pearu



From pearu at cens.ioc.ee  Tue May 21 10:51:10 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 17:51:10 +0300 (EEST)
Subject: [SciPy-user] SciPy from its CVS repository
In-Reply-To: <Pine.LNX.4.21.0205211727390.8856-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.21.0205211744480.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, Pearu Peterson wrote:

> Indeed, for some reasons this checkout also made my cvs to hang at
> 
> U scipy/xplt/gist/xicky.h
> 
> so that I cancelled it.

But now I see that this is acctually the last fail from the CVS. Nils, I
think, after cancelling you can just continue with
 
  setup.py build

I have no idea why cvs hangs on this. The same is happens when doing
update from my account. May be logs in scipy.org show something
interesting?

Pearu




From nwagner at mecha.uni-stuttgart.de  Tue May 21 11:10:05 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 21 May 2002 17:10:05 +0200
Subject: [SciPy-user] AttributeError: 'scipy' module has no attribute 'names2all'
Message-ID: <3CEA634D.C1DBDD27@mecha.uni-stuttgart.de>

Hi all,

I have build and installed the latest scipy via cvs.
Again, there is a problem ...


Traceback (most recent call last):
  File "quad.py", line 1, in ?
    from scipy import *
  File "/usr/local/lib/python2.1/site-packages/scipy/__init__.py", line
56, in ?    import fftw
  File "/usr/local/lib/python2.1/site-packages/scipy/fftw/__init__.py",
line 6,
in ?
    scipy.names2all(__all__, _namespaces, globals())
AttributeError: 'scipy' module has no attribute 'names2all'

Any idea ?

Nils


From eric at enthought.com  Tue May 21 10:10:24 2002
From: eric at enthought.com (eric)
Date: Tue, 21 May 2002 10:10:24 -0400
Subject: [SciPy-user] SciPy from its CVS repository
References: <3CEA59B8.744A1908@mecha.uni-stuttgart.de>
Message-ID: <015a01c200d1$416c59e0$6b01a8c0@ericlaptop>

Hey Nils,

Did these instructions not work?

http://www.scipy.org/site_content/tutorials/CVSInstruct

The only alteration you might need is to remove the -z7 option on the checkout.

    cvs -d :pserver:anonymous at scipy.org:/home/cvsroot checkout scipy

I just tried them from a remote machine, and it worked fine.

We are using a newer version of CVS (11.x I think) on the new server, and it
seems to have some hiccups with the compression option.  Someone had reported
that it hangs on "xicky.h" before.  That is actually the last file received
during a checkout, so the entire repository is getting downloaded, even when the
process seems to hang.  It looks to me like the cvs server is just not closing
the socket or something like that when the compression flag is used.

Are others still having troubles with the CVS?  We've considered downgrading to
the previous CVS version since it seemed to work fine in all cases.

Please let us know about anything you see broken as a ton of stuff has changed.
I think we're about finished with the major migrations though, so we'd like to
get things back to normal as quickly as possible now.

see ya,
eric


----- Original Message -----
From: "Nils Wagner" <nwagner at mecha.uni-stuttgart.de>
To: <scipy-user at scipy.net>
Sent: Tuesday, May 21, 2002 10:29 AM
Subject: [SciPy-user] SciPy from its CVS repository


> Hi Pearu,
>
> there seems to be a problem with the CVS repository ...
>
> How do I get scipy from its CVS repository ?
>
> cvs ... ????.
>
>
> Nils
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From pearu at cens.ioc.ee  Tue May 21 11:15:32 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 18:15:32 +0300 (EEST)
Subject: [SciPy-user] AttributeError: 'scipy' module has no attribute
 'names2all'
In-Reply-To: <3CEA634D.C1DBDD27@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0205211813030.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, Nils Wagner wrote:

> Hi all,
> 
> I have build and installed the latest scipy via cvs.
> Again, there is a problem ...
> 
> 
> Traceback (most recent call last):
>   File "quad.py", line 1, in ?
>     from scipy import *
>   File "/usr/local/lib/python2.1/site-packages/scipy/__init__.py", line
> 56, in ?    import fftw
>   File "/usr/local/lib/python2.1/site-packages/scipy/fftw/__init__.py",
> line 6,
> in ?
>     scipy.names2all(__all__, _namespaces, globals())
> AttributeError: 'scipy' module has no attribute 'names2all'
> 
> Any idea ?

This looks like your old installation of scipy. For instance, in the
latest CVS scipy/fftw/__init__.py contains only 5 lines

""" FFT routines (FFTW) """

from FFT2 import *
from fftw import *
from sfftw import *

So, remove the old scipy and reinstall the new one.

Pearu



From nwagner at mecha.uni-stuttgart.de  Tue May 21 11:33:30 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 21 May 2002 17:33:30 +0200
Subject: [SciPy-user] AttributeError: 'scipy' module has no 
 attribute'names2all'
References: <Pine.LNX.4.21.0205211813030.8856-100000@cens.ioc.ee>
Message-ID: <3CEA68CA.C140294F@mecha.uni-stuttgart.de>

Pearu Peterson schrieb:
> 
> On Tue, 21 May 2002, Nils Wagner wrote:
> 
> > Hi all,
> >
> > I have build and installed the latest scipy via cvs.
> > Again, there is a problem ...
> >
> >
> > Traceback (most recent call last):
> >   File "quad.py", line 1, in ?
> >     from scipy import *
> >   File "/usr/local/lib/python2.1/site-packages/scipy/__init__.py", line
> > 56, in ?    import fftw
> >   File "/usr/local/lib/python2.1/site-packages/scipy/fftw/__init__.py",
> > line 6,
> > in ?
> >     scipy.names2all(__all__, _namespaces, globals())
> > AttributeError: 'scipy' module has no attribute 'names2all'
> >
> > Any idea ?
> 
> This looks like your old installation of scipy. For instance, in the
> latest CVS scipy/fftw/__init__.py contains only 5 lines
> 
> """ FFT routines (FFTW) """
> 
> from FFT2 import *
> from fftw import *
> from sfftw import *
> 
> So, remove the old scipy and reinstall the new one.
> 
> Pearu
> 

I have removed the build directory

rm -rf build/

python setup.py build
python setup.py install --force

Again, there is an

AttributeError: 'scipy' module has no attribute 'names2all'

Any idea ?

Nils


> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user


From nwagner at mecha.uni-stuttgart.de  Tue May 21 11:36:55 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 21 May 2002 17:36:55 +0200
Subject: [SciPy-user] build_fftw = 0 in setup.py
Message-ID: <3CEA6997.B19FE534@mecha.uni-stuttgart.de>

BTW, what is the meaning of

build_fftw = 0 in setup.py ?

Nils


From pearu at cens.ioc.ee  Tue May 21 11:32:22 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 18:32:22 +0300 (EEST)
Subject: [SciPy-user] AttributeError: 'scipy' module has no  attribute'names2all'
In-Reply-To: <3CEA68CA.C140294F@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0205211828580.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, Nils Wagner wrote:

> I have removed the build directory
> 
> rm -rf build/
> 
> python setup.py build
> python setup.py install --force
> 
> Again, there is an
> 
> AttributeError: 'scipy' module has no attribute 'names2all'
> 
> Any idea ?

You should also remove

  /usr/local/lib/python2.1/site-packages/scipy

Or you should check were scipy actually gets installed. May be its
different Python version, etc.

Note that

  cd /path/to/cvs/scipy && grep -r names2all *

shows no occurances of names2all.

Pearu



From pearu at cens.ioc.ee  Tue May 21 11:35:30 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 18:35:30 +0300 (EEST)
Subject: [SciPy-user] build_fftw = 0 in setup.py
In-Reply-To: <3CEA6997.B19FE534@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0205211832410.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, Nils Wagner wrote:

> BTW, what is the meaning of
> 
> build_fftw = 0 in setup.py ?

Its meaning is that building fftw is optional and it is disabled by
default. Currently scipy fft functions use fftpack routines for FFT.

Pearu



From dmorrill at enthought.com  Tue May 21 12:39:45 2002
From: dmorrill at enthought.com (David C. Morrill)
Date: Tue, 21 May 2002 11:39:45 -0500
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 /xplt/gistCmodule.c' does not exist
References: <Pine.LNX.4.21.0205211704300.8856-100000@cens.ioc.ee>
Message-ID: <00c901c200e6$1db69be0$6501a8c0@Dave>

>
> On Tue, 21 May 2002, Nils Wagner wrote:
>
> > I have used SciPy-0.2.0_alpha_101.3442 from
> >
> > http://www.scipy.org/site_content/download_list
> >
> > However the result of
> >
> > python setup.py build
> >
> > is
>
> <snip>
> >
'/export/home/wagner/myscipy/SciPy-0.2.0_alpha_101.3442/xplt/gistCmodule.c'
> > does not exist
> >
> > Any idea ?
>
> It seems that SciPy-0.2.0_alpha_101.3442_src.tar.gz is created under
> Windows and that is why xplt is not included to this tar-ball.

You have found a glitch in our new automated build process, and Pearu has
hit the nail on the head about the problem.

As a result, I've modified the build process to build the source tarballs
under Linux. This should cause all of the source code for SciPy to be
included (even in the Windows .zip file, which should just be ignored when
building SciPy on Windows platforms).

I'm running a test of the new process now, and the new source tarballs
should be available shortly.

BTW, the tables on the 'Downloads' and 'Scoreboard' pages are now color
coded to indicate the platform the build/process was run on. So you'll know
the new tarballs are available when the 'SciPy source' section on the
'Downloads' page turns from Windows 'green' to Linux 'pink' :-)

Thanks guys for catching this problem...

Dave Morrill
---
David Morrill <dmorrill at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057



From gvermeul at polycnrs-gre.fr  Tue May 21 14:12:12 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Tue, 21 May 2002 20:12:12 +0200
Subject: [SciPy-user] install problem on Mandrake-8.2
Message-ID: <200205211812.g4LICG112600@polycnrs-gre.fr>

Hi,

I am spending a lot of time on trying to install scipy (last week's and
today's CVS), but impossible to do successfully 'import scipy':

[packer at venus packer]$ python
Python 2.2.1 (#1, May  8 2002, 22:31:32)
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
Segmentation fault
[packer at venus packer]$

My environment is the following

1) Platform information
posix linux-i386
Linux venus.polycnrs-gre.fr 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i686 
unknown

Mandrake Linux release 8.2 (Bluebird) for i586

2) Compiler/linker information
   a) gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)

   b) g77 --version
GNU Fortran 0.5.26 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
Copyright (C) 1997 Free Software Foundation, Inc.
For more version information on components of the GNU Fortran
compilation system, especially useful when reporting bugs,
type the command `g77 --verbose'.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
or type the command `info -f g77 Copying'.

3) Python version:
2.2.1 (#1, May  8 2002, 22:31:32)
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)]
4) Numeric version:
21.0
5) f2py version:
2.13.175-1250

4) Atlas version: 3.3.15.
It took at least 8 hours to build on a 1 GHz AMD using gcc-2.9.66 :-(


Here is the output of
[packer at venus packer]$ python -v -c 'import scipy' 1&> scipy.log
Segmentation fault
[packer at venus packer]$

BTW:
(python -vv shows that the problem occurs, when:
# trying /home/packer/lib/python2.2/site-packages/scipy/optimize/_minpack.so
dlopen("/home/packer/lib/python2.2/site-packages/scipy/optimize/_minpack.so", 
2);
Segmentation fault)

-- scipy.log --
# /usr/lib/python2.2/site.pyc matches /usr/lib/python2.2/site.py
import site # precompiled from /usr/lib/python2.2/site.pyc
# /usr/lib/python2.2/os.pyc matches /usr/lib/python2.2/os.py
import os # precompiled from /usr/lib/python2.2/os.pyc
import posix # builtin
# /usr/lib/python2.2/posixpath.pyc matches /usr/lib/python2.2/posixpath.py
import posixpath # precompiled from /usr/lib/python2.2/posixpath.pyc
# /usr/lib/python2.2/stat.pyc matches /usr/lib/python2.2/stat.py
import stat # precompiled from /usr/lib/python2.2/stat.pyc
# /usr/lib/python2.2/UserDict.pyc matches /usr/lib/python2.2/UserDict.py
import UserDict # precompiled from /usr/lib/python2.2/UserDict.pyc
# /usr/lib/python2.2/copy_reg.pyc matches /usr/lib/python2.2/copy_reg.py
import copy_reg # precompiled from /usr/lib/python2.2/copy_reg.pyc
# /usr/lib/python2.2/types.pyc matches /usr/lib/python2.2/types.py
import types # precompiled from /usr/lib/python2.2/types.pyc
# /usr/lib/python2.2/__future__.pyc matches /usr/lib/python2.2/__future__.py
import __future__ # precompiled from /usr/lib/python2.2/__future__.pyc
Python 2.2.1 (#1, May  8 2002, 22:31:32) 
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more information.
import scipy # directory /home/packer/lib/python2.2/site-packages/scipy
# /home/packer/lib/python2.2/site-packages/scipy/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/__init__.py
import scipy # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/__init__.pyc
# /home/packer/lib/python2.2/site-packages/scipy/scipy_version.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/scipy_version.py
import scipy.scipy_version # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/scipy_version.pyc
# /home/packer/lib/python2.2/site-packages/scipy/__cvs_version__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/__cvs_version__.py
import scipy.__cvs_version__ # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/__cvs_version__.pyc
# /usr/lib/python2.2/site-packages/Numeric/Numeric.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/Numeric.py
import Numeric # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/Numeric.pyc
# /usr/lib/python2.2/site-packages/Numeric/numeric_version.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/numeric_version.py
import numeric_version # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/numeric_version.pyc
import _numpy # dynamically loaded from 
/usr/lib/python2.2/site-packages/Numeric/_numpy.so
import multiarray # dynamically loaded from 
/usr/lib/python2.2/site-packages/Numeric/multiarray.so
import umath # dynamically loaded from 
/usr/lib/python2.2/site-packages/Numeric/umath.so
# /usr/lib/python2.2/site-packages/Numeric/Precision.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/Precision.py
import Precision # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/Precision.pyc
# /usr/lib/python2.2/string.pyc matches /usr/lib/python2.2/string.py
import string # precompiled from /usr/lib/python2.2/string.pyc
import strop # dynamically loaded from /usr/lib/python2.2/lib-dynload/strop.so
import math # dynamically loaded from /usr/lib/python2.2/lib-dynload/math.so
# /usr/lib/python2.2/site-packages/Numeric/ArrayPrinter.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/ArrayPrinter.py
import ArrayPrinter # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/ArrayPrinter.pyc
# /usr/lib/python2.2/pickle.pyc matches /usr/lib/python2.2/pickle.py
import pickle # precompiled from /usr/lib/python2.2/pickle.pyc
import marshal # builtin
import struct # dynamically loaded from 
/usr/lib/python2.2/lib-dynload/struct.so
# /usr/lib/python2.2/re.pyc matches /usr/lib/python2.2/re.py
import re # precompiled from /usr/lib/python2.2/re.pyc
# /usr/lib/python2.2/sre.pyc matches /usr/lib/python2.2/sre.py
import sre # precompiled from /usr/lib/python2.2/sre.pyc
# /usr/lib/python2.2/sre_compile.pyc matches /usr/lib/python2.2/sre_compile.py
import sre_compile # precompiled from /usr/lib/python2.2/sre_compile.pyc
import _sre # builtin
# /usr/lib/python2.2/sre_constants.pyc matches 
/usr/lib/python2.2/sre_constants.py
import sre_constants # precompiled from /usr/lib/python2.2/sre_constants.pyc
# /usr/lib/python2.2/sre_parse.pyc matches /usr/lib/python2.2/sre_parse.py
import sre_parse # precompiled from /usr/lib/python2.2/sre_parse.pyc
import cStringIO # dynamically loaded from 
/usr/lib/python2.2/lib-dynload/cStringIO.so
# /usr/lib/python2.2/copy.pyc matches /usr/lib/python2.2/copy.py
import copy # precompiled from /usr/lib/python2.2/copy.pyc
# /usr/lib/python2.2/StringIO.pyc matches /usr/lib/python2.2/StringIO.py
import StringIO # precompiled from /usr/lib/python2.2/StringIO.pyc
import errno # dynamically loaded from /usr/lib/python2.2/lib-dynload/errno.so
import scipy_base # directory 
/home/packer/lib/python2.2/site-packages/scipy_base
# /home/packer/lib/python2.2/site-packages/scipy_base/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/__init__.py
import scipy_base # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/__init__.pyc
import scipy_base.fastumath # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy_base/fastumath.so
# /home/packer/lib/python2.2/site-packages/scipy_base/limits.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/limits.py
import scipy_base.limits # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/limits.pyc
import scipy_base.fastumath # previously loaded 
(/home/packer/lib/python2.2/site-packages/scipy_base/fastumath.so)
# /home/packer/lib/python2.2/site-packages/scipy_base/type_check.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/type_check.py
import scipy_base.type_check # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/type_check.pyc
# /home/packer/lib/python2.2/site-packages/scipy_base/index_tricks.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy_base/index_tricks.py
import scipy_base.index_tricks # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/index_tricks.pyc
# /home/packer/lib/python2.2/site-packages/scipy_base/function_base.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy_base/function_base.py
import scipy_base.function_base # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/function_base.pyc
# /home/packer/lib/python2.2/site-packages/scipy_base/shape_base.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/shape_base.py
import scipy_base.shape_base # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/shape_base.pyc
# /home/packer/lib/python2.2/site-packages/scipy_base/matrix_base.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/matrix_base.py
import scipy_base.matrix_base # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/matrix_base.pyc
# /usr/lib/python2.2/site-packages/Numeric/Matrix.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/Matrix.py
import Matrix # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/Matrix.pyc
# /usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.py
import LinearAlgebra # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.pyc
import lapack_lite # dynamically loaded from 
/usr/lib/python2.2/site-packages/Numeric/lapack_lite.so
# /usr/lib/python2.2/site-packages/Numeric/MLab.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/MLab.py
import MLab # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/MLab.pyc
# /usr/lib/python2.2/site-packages/Numeric/RandomArray.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/RandomArray.py
import RandomArray # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/RandomArray.pyc
import ranlib # dynamically loaded from 
/usr/lib/python2.2/site-packages/Numeric/ranlib.so
import time # dynamically loaded from /usr/lib/python2.2/lib-dynload/time.so
# /usr/lib/python2.2/site-packages/Numeric/UserArray.pyc matches 
/usr/lib/python2.2/site-packages/Numeric/UserArray.py
import UserArray # precompiled from 
/usr/lib/python2.2/site-packages/Numeric/UserArray.pyc
# /home/packer/lib/python2.2/site-packages/scipy_base/polynomial.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/polynomial.py
import scipy_base.polynomial # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/polynomial.pyc
# /home/packer/lib/python2.2/site-packages/scipy_base/scimath.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy_base/scimath.py
import scipy_base.scimath # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_base/scimath.pyc
# /home/packer/lib/python2.2/site-packages/scipy/helpmod.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/helpmod.py
import scipy.helpmod # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/helpmod.pyc
# /usr/lib/python2.2/inspect.pyc matches /usr/lib/python2.2/inspect.py
import inspect # precompiled from /usr/lib/python2.2/inspect.pyc
# /usr/lib/python2.2/dis.pyc matches /usr/lib/python2.2/dis.py
import dis # precompiled from /usr/lib/python2.2/dis.pyc
import imp # builtin
# /usr/lib/python2.2/tokenize.pyc matches /usr/lib/python2.2/tokenize.py
import tokenize # precompiled from /usr/lib/python2.2/tokenize.pyc
# /usr/lib/python2.2/token.pyc matches /usr/lib/python2.2/token.py
import token # precompiled from /usr/lib/python2.2/token.pyc
import scipy.special # directory 
/home/packer/lib/python2.2/site-packages/scipy/special
# /home/packer/lib/python2.2/site-packages/scipy/special/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/special/__init__.py
import scipy.special # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/special/__init__.pyc
# /home/packer/lib/python2.2/site-packages/scipy/special/special.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/special/special.py
import scipy.special.special # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/special/special.pyc
import scipy.special.cephes # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/special/cephes.so
import scipy.special.specfun # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/special/specfun.so
# /home/packer/lib/python2.2/site-packages/scipy/special/orthogonal.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy/special/orthogonal.py
import scipy.special.orthogonal # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/special/orthogonal.pyc
import scipy.linalg # directory 
/home/packer/lib/python2.2/site-packages/scipy/linalg
# /home/packer/lib/python2.2/site-packages/scipy/linalg/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/__init__.py
import scipy.linalg # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/__init__.pyc
# /home/packer/lib/python2.2/site-packages/scipy/linalg/basic.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/basic.py
import scipy.linalg.basic # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/basic.pyc
# /home/packer/lib/python2.2/site-packages/scipy/linalg/lapack.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/lapack.py
import scipy.linalg.lapack # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/lapack.pyc
import scipy_distutils # directory 
/home/packer/lib/python2.2/site-packages/scipy_distutils
# /home/packer/lib/python2.2/site-packages/scipy_distutils/__init__.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy_distutils/__init__.py
import scipy_distutils # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_distutils/__init__.pyc
# /home/packer/lib/python2.2/site-packages/scipy_distutils/misc_util.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy_distutils/misc_util.py
import scipy_distutils.misc_util # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy_distutils/misc_util.pyc
import scipy.linalg.flapack # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/flapack.so
import scipy.linalg.clapack # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/clapack.so
# /home/packer/lib/python2.2/site-packages/scipy/linalg/flinalg.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/flinalg.py
import scipy.linalg.flinalg # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/flinalg.pyc
import scipy.linalg._flinalg # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/_flinalg.so
import scipy.linalg.calc_lwork # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/calc_lwork.so
# /home/packer/lib/python2.2/site-packages/scipy/linalg/decomp.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/decomp.py
import scipy.linalg.decomp # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/decomp.pyc
# /usr/lib/python2.2/warnings.pyc matches /usr/lib/python2.2/warnings.py
import warnings # precompiled from /usr/lib/python2.2/warnings.pyc
# /home/packer/lib/python2.2/site-packages/scipy/linalg/matfuncs.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/matfuncs.py
import scipy.linalg.matfuncs # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/matfuncs.pyc
# /home/packer/lib/python2.2/site-packages/scipy/linalg/blas.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/linalg/blas.py
import scipy.linalg.blas # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/blas.pyc
import scipy.linalg.fblas # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/fblas.so
import scipy.linalg.cblas # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/linalg/cblas.so
import scipy.io # directory /home/packer/lib/python2.2/site-packages/scipy/io
# /home/packer/lib/python2.2/site-packages/scipy/io/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/io/__init__.py
import scipy.io # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/io/__init__.pyc
import scipy.io.numpyio # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/io/numpyio.so
# /home/packer/lib/python2.2/site-packages/scipy/io/mio.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/io/mio.py
import scipy.io.mio # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/io/mio.pyc
# /home/packer/lib/python2.2/site-packages/scipy/io/array_import.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/io/array_import.py
import scipy.io.array_import # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/io/array_import.pyc
# /home/packer/lib/python2.2/site-packages/scipy/io/data_store.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/io/data_store.py
import scipy.io.data_store # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/io/data_store.pyc
# /home/packer/lib/python2.2/site-packages/scipy/io/dumb_shelve.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/io/dumb_shelve.py
import scipy.io.dumb_shelve # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/io/dumb_shelve.pyc
# /usr/lib/python2.2/shelve.pyc matches /usr/lib/python2.2/shelve.py
import shelve # precompiled from /usr/lib/python2.2/shelve.pyc
import cPickle # dynamically loaded from 
/usr/lib/python2.2/lib-dynload/cPickle.so
import zlib # dynamically loaded from /usr/lib/python2.2/lib-dynload/zlib.so
# /home/packer/lib/python2.2/site-packages/scipy/io/pickler.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/io/pickler.py
import scipy.io.pickler # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/io/pickler.pyc
import scipy.stats # directory 
/home/packer/lib/python2.2/site-packages/scipy/stats
# /home/packer/lib/python2.2/site-packages/scipy/stats/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/stats/__init__.py
import scipy.stats # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/stats/__init__.pyc
# /usr/lib/python2.2/pstats.pyc matches /usr/lib/python2.2/pstats.py
import pstats # precompiled from /usr/lib/python2.2/pstats.pyc
# /home/packer/lib/python2.2/site-packages/scipy/stats/stats.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/stats/stats.py
import scipy.stats.stats # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/stats/stats.pyc
# /home/packer/lib/python2.2/site-packages/scipy/stats/pstat.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/stats/pstat.py
import scipy.stats.pstat # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/stats/pstat.pyc
# /usr/lib/python2.2/glob.pyc matches /usr/lib/python2.2/glob.py
import glob # precompiled from /usr/lib/python2.2/glob.pyc
# /usr/lib/python2.2/fnmatch.pyc matches /usr/lib/python2.2/fnmatch.py
import fnmatch # precompiled from /usr/lib/python2.2/fnmatch.pyc
# /home/packer/lib/python2.2/site-packages/scipy/stats/distributions.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy/stats/distributions.py
import scipy.stats.distributions # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/stats/distributions.pyc
# /home/packer/lib/python2.2/site-packages/scipy/stats/rv2.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/stats/rv2.py
import scipy.stats.rv2 # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/stats/rv2.pyc
import array # dynamically loaded from /usr/lib/python2.2/lib-dynload/array.so
# /home/packer/lib/python2.2/site-packages/scipy/stats/rv.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/stats/rv.py
import scipy.stats.rv # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/stats/rv.pyc
import scipy.stats.rand # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/stats/rand.so
import scipy.fftpack # directory 
/home/packer/lib/python2.2/site-packages/scipy/fftpack
# /home/packer/lib/python2.2/site-packages/scipy/fftpack/__init__.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/fftpack/__init__.py
import scipy.fftpack # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/fftpack/__init__.pyc
# /home/packer/lib/python2.2/site-packages/scipy/fftpack/fft.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/fftpack/fft.py
import scipy.fftpack.fft # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/fftpack/fft.pyc
import scipy.fftpack.fftpack # dynamically loaded from 
/home/packer/lib/python2.2/site-packages/scipy/fftpack/fftpack.so
# /home/packer/lib/python2.2/site-packages/scipy/common.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/common.py
import scipy.common # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/common.pyc
# /home/packer/lib/python2.2/site-packages/scipy/pilutil.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/pilutil.py
import scipy.pilutil # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/pilutil.pyc
import Image # from /usr/lib/python2.2/site-packages/PIL/Image.py
# can't create /usr/lib/python2.2/site-packages/PIL/Image.pyc
# /usr/lib/python2.2/lib-tk/FixTk.pyc matches 
/usr/lib/python2.2/lib-tk/FixTk.py
import FixTk # precompiled from /usr/lib/python2.2/lib-tk/FixTk.pyc
import _imaging # dynamically loaded from 
/usr/lib/python2.2/site-packages/PIL/_imaging.so
import ImagePalette # from 
/usr/lib/python2.2/site-packages/PIL/ImagePalette.py
# can't create /usr/lib/python2.2/site-packages/PIL/ImagePalette.pyc
import operator # dynamically loaded from 
/usr/lib/python2.2/lib-dynload/operator.so
import ImageFilter # from /usr/lib/python2.2/site-packages/PIL/ImageFilter.py
# can't create /usr/lib/python2.2/site-packages/PIL/ImageFilter.pyc
import scipy.optimize # directory 
/home/packer/lib/python2.2/site-packages/scipy/optimize
# /home/packer/lib/python2.2/site-packages/scipy/optimize/__init__.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy/optimize/__init__.py
import scipy.optimize # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/optimize/__init__.pyc
# /home/packer/lib/python2.2/site-packages/scipy/optimize/optimize.pyc 
matches /home/packer/lib/python2.2/site-packages/scipy/optimize/optimize.py
import scipy.optimize.optimize # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/optimize/optimize.pyc
# /home/packer/lib/python2.2/site-packages/scipy/optimize/minpack.pyc matches 
/home/packer/lib/python2.2/site-packages/scipy/optimize/minpack.py
import scipy.optimize.minpack # precompiled from 
/home/packer/lib/python2.2/site-packages/scipy/optimize/minpack.pyc

-- scipy.log --

Thanks for any help.

Gerard


From pearu at cens.ioc.ee  Tue May 21 14:30:27 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 21:30:27 +0300 (EEST)
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <200205211812.g4LICG112600@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205212120140.12941-100000@cens.ioc.ee>

On Tue, 21 May 2002, Gerard Vermeulen wrote:

> Segmentation fault
> [packer at venus packer]$
> 
> BTW:
> (python -vv shows that the problem occurs, when:
> # trying /home/packer/lib/python2.2/site-packages/scipy/optimize/_minpack.so
> dlopen("/home/packer/lib/python2.2/site-packages/scipy/optimize/_minpack.so", 
> 2);
> Segmentation fault)

Your environment as you reported looked good to me. Here follows some
hints for diagnostics.

Can you do

cd /home/packer/lib/python2.2/site-packages/scipy/optimize/
python -c 'import _minpack'

?

If it craches again then try gdb. Something like

$ gdb python
(gdb) run
>>> import _minpack

Also WAD

  http://systems.cs.uchicago.edu/wad

can be useful. Eg. if you have build libwadpy then doing

>>> import libwadpy
WAD Enabled
>>> import _minpack

should show a trace when craching.

Do you have other compilers on your system? What ldd _minpack.so is
showing?

HTH,
	Pearu



From gvermeul at polycnrs-gre.fr  Tue May 21 15:39:28 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Tue, 21 May 2002 21:39:28 +0200
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <Pine.LNX.4.21.0205212120140.12941-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205212120140.12941-100000@cens.ioc.ee>
Message-ID: <200205211939.g4LJdW119823@polycnrs-gre.fr>

On Tuesday 21 May 2002 20:30, Pearu Peterson wrote:
> On Tue, 21 May 2002, Gerard Vermeulen wrote:
> > Segmentation fault
> > [packer at venus packer]$
> >
> > BTW:
> > (python -vv shows that the problem occurs, when:
> > # trying
> > /home/packer/lib/python2.2/site-packages/scipy/optimize/_minpack.so
> > dlopen("/home/packer/lib/python2.2/site-packages/scipy/optimize/_minpack.
> >so", 2);
> > Segmentation fault)
>
> Your environment as you reported looked good to me. Here follows some
> hints for diagnostics.
>
> Can you do
>
> cd /home/packer/lib/python2.2/site-packages/scipy/optimize/
> python -c 'import _minpack'
>
[packer at venus optimize]$ python -c 'import _minpack'
Segmentation fault
[packer at venus optimize]$
>
> If it craches again then try gdb. Something like
>
> $ gdb python
> (gdb) run
>
> >>> import _minpack
>
[packer at venus optimize]$ gdb python
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-mandrake-linux"...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/python
(no debugging symbols found)...(no debugging symbols found)...[New Thread 
1024 (LWP 3971)]
Python 2.2.1 (#1, May  8 2002, 22:31:32)
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more information.
>>> import _minpack

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3971)]
_dl_relocate_object () at ../sysdeps/i386/dl-machine.h:436
436     ../sysdeps/i386/dl-machine.h: No such file or directory.
        in ../sysdeps/i386/dl-machine.h

I DID CONTROL-D HERE, BECAUSE I AM A NEWBIE WITH GDB

(gdb) The program is running.  Exit anyway? (y or n) y

Hmm, guess I have to rebuild Python with debugging information,
and where can I find "../sysdeps/i386/dl-machine.h"
>
> Also WAD
>
>   http://systems.cs.uchicago.edu/wad
>
> can be useful. Eg. if you have build libwadpy then doing
>
> >>> import libwadpy
>
> WAD Enabled
>
> >>> import _minpack
>
> should show a trace when craching.
>
[packer at venus optimize]$ python
Python 2.2.1 (#1, May  8 2002, 22:31:32)
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more information.
>>> import libwadpy
WAD Enabled
>>> import _minpack.so
WAD: Collecting debugging information...
WAD: Segmentation fault.
#8   0x400b737a in _PyImport_GetDynLoadFunc()
#7   0x400fae53 in dlopen()
#6   0x400fb21b in ?()
#5   0x4000c745 in 
_dl_catch_error(objname=0x8093090,errstring=0x8093094,operate=0x400fae70,args=0xbfffe7d0) 
in 'dl-error.c', line 153
#4   0x400fae9b in ?()
#3   0x40250dcf in _dl_open()
#2   0x4000c745 in 
_dl_catch_error(objname=0xbfffe668,errstring=0xbfffe66c,operate=0x40250790,args=0xbfffe670) 
in 'dl-error.c', line 153
#1   0x40250c69 in ?()
#0   0x4000a819 in _dl_relocate_object() in 'dl-reloc.c', line 436
[packer at venus optimize]$
>
> Do you have other compilers on your system? What ldd _minpack.so is
> showing?
>
No, I do not have other compilers on my system (thinking about installing
2.95.3 because of Atlas, though) and
[packer at venus optimize]$ ldd _minpack.so
        libm.so.6 => /lib/libm.so.6 (0x40022000)
        libc.so.6 => /lib/libc.so.6 (0x40044000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[packer at venus optimize]$ python -c 'import _minpack'


Thanks a lot for the quick response

Gerard


From pearu at cens.ioc.ee  Tue May 21 16:02:32 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 23:02:32 +0300 (EEST)
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <200205211939.g4LJdW119823@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205212250230.12941-100000@cens.ioc.ee>

On Tue, 21 May 2002, Gerard Vermeulen wrote:

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 3971)]
> _dl_relocate_object () at ../sysdeps/i386/dl-machine.h:436
> 436     ../sysdeps/i386/dl-machine.h: No such file or directory.
>         in ../sysdeps/i386/dl-machine.h

<snip>
 
> WAD: Collecting debugging information...
> WAD: Segmentation fault.
> #8   0x400b737a in _PyImport_GetDynLoadFunc()
> #7   0x400fae53 in dlopen()
> #6   0x400fb21b in ?()
> #5   0x4000c745 in 
> _dl_catch_error(objname=0x8093090,errstring=0x8093094,operate=0x400fae70,args=0xbfffe7d0) 
> in 'dl-error.c', line 153
> #4   0x400fae9b in ?()
> #3   0x40250dcf in _dl_open()
> #2   0x4000c745 in 
> _dl_catch_error(objname=0xbfffe668,errstring=0xbfffe66c,operate=0x40250790,args=0xbfffe670) 
> in 'dl-error.c', line 153
> #1   0x40250c69 in ?()
> #0   0x4000a819 in _dl_relocate_object() in 'dl-reloc.c', line 436

Obviously something is wrong with dynamic loading of libraries and I just
have a feeling that it could be related to a similar bug in your system 
Python that we saw months ago for Debian Python. Details can be found in

http://sourceforge.net/tracker/index.php?func=detail&aid=521854&group_id=5470&atid=105470
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135461&archive=yes&repeatmerged=yes

To check this, get the test code

http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=18294&aid=521854

unpack it, and run

  python runme.py

What is the output? If you see that var=1 at some point then it is a
bug of your system Python.

Pearu




From gvermeul at polycnrs-gre.fr  Tue May 21 16:37:04 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Tue, 21 May 2002 22:37:04 +0200
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <Pine.LNX.4.21.0205212250230.12941-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205212250230.12941-100000@cens.ioc.ee>
Message-ID: <200205212037.g4LKb8123822@polycnrs-gre.fr>

On Tuesday 21 May 2002 22:02, you wrote:
>
<snip>
>
> Obviously something is wrong with dynamic loading of libraries and I just
> have a feeling that it could be related to a similar bug in your system
> Python that we saw months ago for Debian Python. Details can be found in
>
I agree: the Mandrake developers copied a patch from Debian to build a shared
library version of libpython22 for Python-2.2. I have already built a 
Python-2.2.1 with and without this patch: both Pythons have the same problem
with scipy. The Mandrake patch only touches configure and Makefile's.
No source code.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=521854&group_id=54
>70&atid=105470
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135461&archive=yes&repeatm
>erged=yes
>
dynload-shlib.c in Python-2.2.1 contains the lines:
	dlopenflags = PyThreadState_Get()->interp->dlopenflags;
	...
	handle = dlopen(pathname, dlopenflags);
>
> To check this, get the test code
>
> http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_
>id=18294&aid=521854
>
> unpack it, and run
>
>   python runme.py
>
> What is the output? If you see that var=1 at some point then it is a
> bug of your system Python.
>
gcc -shared build/temp.linux-i686-2.2/bar.o build/temp.linux-i686-2.2/fun.o 
-o ./bar.so
>From foo: set_var: var=0; Doing var++
>From bar: set_var: var=0; Doing var++
[packer at venus py2.1-bug]$

Gerard


From pearu at cens.ioc.ee  Tue May 21 16:52:34 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 21 May 2002 23:52:34 +0300 (EEST)
Subject: [SciPy-user] SciPy from its CVS repository
In-Reply-To: <015a01c200d1$416c59e0$6b01a8c0@ericlaptop>
Message-ID: <Pine.LNX.4.21.0205211823200.8856-100000@cens.ioc.ee>

On Tue, 21 May 2002, eric wrote:

> The only alteration you might need is to remove the -z7 option on the checkout.
> 
>     cvs -d :pserver:anonymous at scipy.org:/home/cvsroot checkout scipy
> 
> I just tried them from a remote machine, and it worked fine.

Without -z? works also here.

> We are using a newer version of CVS (11.x I think) on the new server, and it
> seems to have some hiccups with the compression option.  Someone had reported
> that it hangs on "xicky.h" before.  That is actually the last file received
> during a checkout, so the entire repository is getting downloaded, even when the
> process seems to hang.  It looks to me like the cvs server is just not closing
> the socket or something like that when the compression flag is used.
> 
> Are others still having troubles with the CVS?  We've considered downgrading to
> the previous CVS version since it seemed to work fine in all cases.

CVS 11.x is not that new, I think. In our server we are using 1.11.1p1
without any problems. I don't remember anymore what was the version of CVS
earlier in scipy.org but I do remember that it had also problems so that
time to time you needed to restart it...

Pearu





From pearu at cens.ioc.ee  Tue May 21 17:02:00 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 22 May 2002 00:02:00 +0300 (EEST)
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <200205212037.g4LKb8123822@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee>

On Tue, 21 May 2002, Gerard Vermeulen wrote:

> gcc -shared build/temp.linux-i686-2.2/bar.o build/temp.linux-i686-2.2/fun.o 
> -o ./bar.so
> >From foo: set_var: var=0; Doing var++
> >From bar: set_var: var=0; Doing var++

Ok, it is not that bug.

Here follows another idea. It seems that you can import all other
extension modules except _minpack.so. Can you confirm that? Look
in scipy/build/lib.linux-i686-2.2/scipy/* for *.so files and try to import
them directly one-by-one. Do you find other failing modules?

When I compare the source of _minpack with other sources I see that it
does not use

#define PY_ARRAY_UNIQUE_SYMBOL PyArray_API

before including Numeric/arrayobject.h. I am not sure if it matters but
you can try to add this #define statement just before the

#include "Numeric/arrayobject.h" 

statement in scipy/optimize/minpack.h file.

Pearu



From eric at enthought.com  Tue May 21 16:37:16 2002
From: eric at enthought.com (eric)
Date: Tue, 21 May 2002 16:37:16 -0400
Subject: [SciPy-user] SciPy from its CVS repository
References: <Pine.LNX.4.21.0205211823200.8856-100000@cens.ioc.ee>
Message-ID: <027501c20107$4c0d3cd0$6b01a8c0@ericlaptop>

>
> On Tue, 21 May 2002, eric wrote:
>
> > The only alteration you might need is to remove the -z7 option on the
checkout.
> >
> >     cvs -d :pserver:anonymous at scipy.org:/home/cvsroot checkout scipy
> >
> > I just tried them from a remote machine, and it worked fine.
>
> Without -z? works also here.
>
> > We are using a newer version of CVS (11.x I think) on the new server, and it
> > seems to have some hiccups with the compression option.  Someone had
reported
> > that it hangs on "xicky.h" before.  That is actually the last file received
> > during a checkout, so the entire repository is getting downloaded, even when
the
> > process seems to hang.  It looks to me like the cvs server is just not
closing
> > the socket or something like that when the compression flag is used.
> >
> > Are others still having troubles with the CVS?  We've considered downgrading
to
> > the previous CVS version since it seemed to work fine in all cases.
>
> CVS 11.x is not that new, I think. In our server we are using 1.11.1p1
> without any problems. I don't remember anymore what was the version of CVS
> earlier in scipy.org but I do remember that it had also problems so that
> time to time you needed to restart it...

There were problems at one point, but the version we used for the last several
months worked fine.  We're using 11.2 currently.  Checking the page, it was
released last month on 4/17/2002.  Perhaps we should back off to 11.1p1 if your
having good luck with it.  On the face of it, the hang does seem to be CVS
related problem with the compression flag and not some system configuration
problem.

eric





From gvermeul at polycnrs-gre.fr  Wed May 22 04:41:29 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Wed, 22 May 2002 10:41:29 +0200
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee>
Message-ID: <200205220841.g4M8fY111362@polycnrs-gre.fr>

On Tuesday 21 May 2002 23:02, Pearu Peterson wrote:

> Here follows another idea. It seems that you can import all other
> extension modules except _minpack.so. Can you confirm that? Look
> in scipy/build/lib.linux-i686-2.2/scipy/* for *.so files and try to import
> them directly one-by-one. Do you find other failing modules?
>
Yes _minpack.so is the only failing module
>
> When I compare the source of _minpack with other sources I see that it
> does not use
>
> #define PY_ARRAY_UNIQUE_SYMBOL PyArray_API
>
> before including Numeric/arrayobject.h. I am not sure if it matters but
> you can try to add this #define statement just before the
>
> #include "Numeric/arrayobject.h"
>
> statement in scipy/optimize/minpack.h file.
>
Done, but it does not help (I think that it may matter with versions
of Numeric close to 20.0.0, but not with 21.0)

Tonight, I will try if scipy-0.2 works with Python-2.1.x on this machine.

But my motivation for installing scipy-0.2 is driven by an incompatibility
between scipy-0.1 and Python-2.2 (I managed to build scipy-0.1 for
python-2.2.1)
The problem is with colex in pstats.py (in scipy-0.1):

[packer at venus i586]$ python
Python 2.2.1 (#1, May  8 2002, 22:31:32)
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 42, in ?
    from misc import *
  File "/usr/lib/python2.2/site-packages/scipy/misc.py", line 21, in ?
    import scipy.stats
  File "/usr/lib/python2.2/site-packages/scipy/stats/__init__.py", line 4, in 
?
    from stats import *
  File "/usr/lib/python2.2/site-packages/scipy/stats/stats.py", line 204, in ?
    import math, string, sys, pstat, copy
  File "/usr/lib/python2.2/site-packages/scipy/stats/pstat.py", line 176
    exec execstring
SyntaxError: unqualified exec is not allowed in function 'colex' it contains 
a nested function with free variables
>>>

Is there a workaround for this? Apparently the semantics of exec
changed between Python-2.1 and Python-2.2.

Again, thanks a lot for the support.

Gerard


From pearu at cens.ioc.ee  Wed May 22 05:12:57 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 22 May 2002 12:12:57 +0300 (EEST)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
 problem on Mandrake-8.2)
In-Reply-To: <200205220841.g4M8fY111362@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205221150540.1189-100000@cens.ioc.ee>

On Wed, 22 May 2002, Gerard Vermeulen wrote:

> On Tuesday 21 May 2002 23:02, Pearu Peterson wrote:
> 
> > Here follows another idea. It seems that you can import all other
> > extension modules except _minpack.so. Can you confirm that? Look
> > in scipy/build/lib.linux-i686-2.2/scipy/* for *.so files and try to import
> > them directly one-by-one. Do you find other failing modules?
> >
> Yes _minpack.so is the only failing module

Good, in the sense that the problem is localized.

The next step would be playing around with 

  scipy/optimize/_minpackmodule.c

file. You can do that directly in scipy/optimize directory and building it
locally using

  ./setup_optimize.py build --build-platlib=.

and then

  python -c 'import sys;sys.path.insert(0,"optimize");import _minpack'

My suggestion would be to start commenting out various codelets from
the scipy/optimize/_minpackmodule.c file and what it includes until you
can succesfully import it.

> Tonight, I will try if scipy-0.2 works with Python-2.1.x on this machine.
> 
> But my motivation for installing scipy-0.2 is driven by an incompatibility
> between scipy-0.1 and Python-2.2 (I managed to build scipy-0.1 for
> python-2.2.1)
> The problem is with colex in pstats.py (in scipy-0.1):

> SyntaxError: unqualified exec is not allowed in function 'colex' it contains 
> a nested function with free variables
> >>>
> 
> Is there a workaround for this? Apparently the semantics of exec
> changed between Python-2.1 and Python-2.2.

Note that SciPy-0.1 has many other problems as well that are fixed in
SciPy-0.2 and therefore there is little interest to deal with
SciPy-0.1 problems again.

Regards,
	Pearu



From eric at enthought.com  Wed May 22 11:44:50 2002
From: eric at enthought.com (eric)
Date: Wed, 22 May 2002 11:44:50 -0400
Subject: [SciPy-user] install problem on Mandrake-8.2
References: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee> <200205220841.g4M8fY111362@polycnrs-gre.fr>
Message-ID: <037001c201a7$9c2853d0$6b01a8c0@ericlaptop>

Hey Gerard,

We want to figure out what's going on with builds on Mandrake, so I almost
hesitate to suggest this, but have you tried the grabbing the RH 7.2 binary
tarball of the latest CVS (built last night)?  You can find it here:

http://www.scipy.org/site_content/download_list


If you unpack it in your site-packages directory, it might work on Mandrake --
Mandrake and RH are supposed to be kissing cousins aren't they?  That said, I
spent 3 days getting weave to work around Mandrake bugs, and the fixes are
pretty convoluted.   That platform does seem to have some unpleasant
idiosyncracies.

eric

----- Original Message -----
From: "Gerard Vermeulen" <gvermeul at polycnrs-gre.fr>
To: <scipy-user at scipy.net>; "Pearu Peterson" <pearu at cens.ioc.ee>
Sent: Wednesday, May 22, 2002 4:41 AM
Subject: Re: [SciPy-user] install problem on Mandrake-8.2


> On Tuesday 21 May 2002 23:02, Pearu Peterson wrote:
>
> > Here follows another idea. It seems that you can import all other
> > extension modules except _minpack.so. Can you confirm that? Look
> > in scipy/build/lib.linux-i686-2.2/scipy/* for *.so files and try to import
> > them directly one-by-one. Do you find other failing modules?
> >
> Yes _minpack.so is the only failing module
> >
> > When I compare the source of _minpack with other sources I see that it
> > does not use
> >
> > #define PY_ARRAY_UNIQUE_SYMBOL PyArray_API
> >
> > before including Numeric/arrayobject.h. I am not sure if it matters but
> > you can try to add this #define statement just before the
> >
> > #include "Numeric/arrayobject.h"
> >
> > statement in scipy/optimize/minpack.h file.
> >
> Done, but it does not help (I think that it may matter with versions
> of Numeric close to 20.0.0, but not with 21.0)
>
> Tonight, I will try if scipy-0.2 works with Python-2.1.x on this machine.
>
> But my motivation for installing scipy-0.2 is driven by an incompatibility
> between scipy-0.1 and Python-2.2 (I managed to build scipy-0.1 for
> python-2.2.1)
> The problem is with colex in pstats.py (in scipy-0.1):
>
> [packer at venus i586]$ python
> Python 2.2.1 (#1, May  8 2002, 22:31:32)
> [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import scipy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 42, in ?
>     from misc import *
>   File "/usr/lib/python2.2/site-packages/scipy/misc.py", line 21, in ?
>     import scipy.stats
>   File "/usr/lib/python2.2/site-packages/scipy/stats/__init__.py", line 4, in
> ?
>     from stats import *
>   File "/usr/lib/python2.2/site-packages/scipy/stats/stats.py", line 204, in ?
>     import math, string, sys, pstat, copy
>   File "/usr/lib/python2.2/site-packages/scipy/stats/pstat.py", line 176
>     exec execstring
> SyntaxError: unqualified exec is not allowed in function 'colex' it contains
> a nested function with free variables
> >>>
>
> Is there a workaround for this? Apparently the semantics of exec
> changed between Python-2.1 and Python-2.2.
>
> Again, thanks a lot for the support.
>
> Gerard
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From gvermeul at polycnrs-gre.fr  Wed May 22 13:30:41 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Wed, 22 May 2002 19:30:41 +0200
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <037001c201a7$9c2853d0$6b01a8c0@ericlaptop>
References: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee> <200205220841.g4M8fY111362@polycnrs-gre.fr> <037001c201a7$9c2853d0$6b01a8c0@ericlaptop>
Message-ID: <200205221730.g4MHUj115302@polycnrs-gre.fr>

OK, Eric, I won't give up (yet). I suppose I can untar the RH stuff
in another directory and re-byte-compile?

Anyhow,  I made some progress along the lines Pearu suggested
(I am able to import a heavily amputated _minpack -- without __minpack.h,
but I also need to get some real work done). __minpack.h is quite large.

Maybe you're right about Mandrake. But, 8.2 is very slick, and IMHO,
better than SuSE (SuSE-7.3 Python packages had some important
modules missing - and I noticed quite a few other problems).

A pity, that Linux distributions seem to become less stable over time :-(

Gerard


On Wednesday 22 May 2002 17:44, eric wrote:
> Hey Gerard,
>
> We want to figure out what's going on with builds on Mandrake, so I almost
> hesitate to suggest this, but have you tried the grabbing the RH 7.2 binary
> tarball of the latest CVS (built last night)?  You can find it here:
>
> http://www.scipy.org/site_content/download_list
>
>
> If you unpack it in your site-packages directory, it might work on Mandrake
> -- Mandrake and RH are supposed to be kissing cousins aren't they?  That
> said, I spent 3 days getting weave to work around Mandrake bugs, and the
> fixes are pretty convoluted.   That platform does seem to have some
> unpleasant idiosyncracies.
>
> eric
>
> ----- Original Message -----
> From: "Gerard Vermeulen" <gvermeul at polycnrs-gre.fr>
> To: <scipy-user at scipy.net>; "Pearu Peterson" <pearu at cens.ioc.ee>
> Sent: Wednesday, May 22, 2002 4:41 AM
> Subject: Re: [SciPy-user] install problem on Mandrake-8.2
>
> > On Tuesday 21 May 2002 23:02, Pearu Peterson wrote:
> > > Here follows another idea. It seems that you can import all other
> > > extension modules except _minpack.so. Can you confirm that? Look
> > > in scipy/build/lib.linux-i686-2.2/scipy/* for *.so files and try to
> > > import them directly one-by-one. Do you find other failing modules?
> >
> > Yes _minpack.so is the only failing module
> >
> > > When I compare the source of _minpack with other sources I see that it
> > > does not use
> > >
> > > #define PY_ARRAY_UNIQUE_SYMBOL PyArray_API
> > >
> > > before including Numeric/arrayobject.h. I am not sure if it matters but
> > > you can try to add this #define statement just before the
> > >
> > > #include "Numeric/arrayobject.h"
> > >
> > > statement in scipy/optimize/minpack.h file.
> >
> > Done, but it does not help (I think that it may matter with versions
> > of Numeric close to 20.0.0, but not with 21.0)
> >
> > Tonight, I will try if scipy-0.2 works with Python-2.1.x on this machine.
> >
> > But my motivation for installing scipy-0.2 is driven by an
> > incompatibility between scipy-0.1 and Python-2.2 (I managed to build
> > scipy-0.1 for python-2.2.1)
> > The problem is with colex in pstats.py (in scipy-0.1):
> >
> > [packer at venus i586]$ python
> > Python 2.2.1 (#1, May  8 2002, 22:31:32)
> > [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386
> > Type "help", "copyright", "credits" or "license" for more information.
> >
> > >>> import scipy
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 42, in
> > ? from misc import *
> >   File "/usr/lib/python2.2/site-packages/scipy/misc.py", line 21, in ?
> >     import scipy.stats
> >   File "/usr/lib/python2.2/site-packages/scipy/stats/__init__.py", line
> > 4, in ?
> >     from stats import *
> >   File "/usr/lib/python2.2/site-packages/scipy/stats/stats.py", line 204,
> > in ? import math, string, sys, pstat, copy
> >   File "/usr/lib/python2.2/site-packages/scipy/stats/pstat.py", line 176
> >     exec execstring
> > SyntaxError: unqualified exec is not allowed in function 'colex' it
> > contains a nested function with free variables
> >
> >
> > Is there a workaround for this? Apparently the semantics of exec
> > changed between Python-2.1 and Python-2.2.
> >
> > Again, thanks a lot for the support.
> >
> > Gerard
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user


From oliphant.travis at ieee.org  Wed May 22 13:59:00 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 22 May 2002 11:59:00 -0600
Subject: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <200205221730.g4MHUj115302@polycnrs-gre.fr>
References: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee>
	<200205220841.g4M8fY111362@polycnrs-gre.fr>
	<037001c201a7$9c2853d0$6b01a8c0@ericlaptop> 
	<200205221730.g4MHUj115302@polycnrs-gre.fr>
Message-ID: <1022090341.2762.19.camel@travis>

On Wed, 2002-05-22 at 11:30, Gerard Vermeulen wrote:
> OK, Eric, I won't give up (yet). I suppose I can untar the RH stuff
> in another directory and re-byte-compile?
> 
> Anyhow,  I made some progress along the lines Pearu suggested
> (I am able to import a heavily amputated _minpack -- without __minpack.h,
> but I also need to get some real work done). __minpack.h is quite large.
> 
> Maybe you're right about Mandrake. But, 8.2 is very slick, and IMHO,
> better than SuSE (SuSE-7.3 Python packages had some important
> modules missing - and I noticed quite a few other problems).

I'm using Mandrake 8.2 with Python 2.2 and scipy currently with no
problems.

However, I'm using my own compiled version of Python2.2 --- that may be
the difference here.

-Travis






From gvermeul at polycnrs-gre.fr  Wed May 22 14:09:27 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Wed, 22 May 2002 20:09:27 +0200
Subject: PS: Re: [SciPy-user] install problem on Mandrake-8.2
In-Reply-To: <037001c201a7$9c2853d0$6b01a8c0@ericlaptop>
References: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee> <200205220841.g4M8fY111362@polycnrs-gre.fr> <037001c201a7$9c2853d0$6b01a8c0@ericlaptop>
Message-ID: <200205221809.g4MI9W118871@polycnrs-gre.fr>

On Wednesday 22 May 2002 17:44, eric wrote:
>
> We want to figure out what's going on with builds on Mandrake, so I almost
> hesitate to suggest this, but have you tried the grabbing the RH 7.2 binary
> tarball of the latest CVS (built last night)?  You can find it here:
>
> http://www.scipy.org/site_content/download_list
>
>
> If you unpack it in your site-packages directory, it might work on Mandrake
> -- Mandrake and RH are supposed to be kissing cousins aren't they?  That
> said, I spent 3 days getting weave to work around Mandrake bugs, and the
> fixes are pretty convoluted.   That platform does seem to have some
> unpleasant idiosyncracies.
>
This works: untarred the stuff in ~/usr/lib/python2.2/site-packages
and happily running scipy.test(9) :-)

I will try to follow Pearu's direction's tonight. BTW: RH72's gcc
is still good old lousy gcc-2.9.66 isn't it?
Can you give me the compiler switches for RH72 Python's package?

I will also cleanup my Python installation, discovered libpython22.a
alongside a libpython22.so :-(

Gerard 


From dmorrill at enthought.com  Wed May 22 16:46:55 2002
From: dmorrill at enthought.com (David C. Morrill)
Date: Wed, 22 May 2002 15:46:55 -0500
Subject: [SciPy-user] install problem on Mandrake-8.2
References: <Pine.LNX.4.21.0205212352380.12941-100000@cens.ioc.ee> <200205220841.g4M8fY111362@polycnrs-gre.fr> <037001c201a7$9c2853d0$6b01a8c0@ericlaptop> <200205221809.g4MI9W118871@polycnrs-gre.fr>
Message-ID: <014901c201d1$cf5d5c30$6501a8c0@Dave>

> I will try to follow Pearu's direction's tonight. BTW: RH72's gcc
> is still good old lousy gcc-2.9.66 isn't it?

On our RH 7.2 build system, 'gcc --version' returned '2.96'.

BTW, the generic Intel processor version of Atlas 3.3.15 we built on that
system was compiled with kgcc. 'kgcc --version' returned: 'egcs-2.91.66'.

Dave Morrill
---
David Morrill <dmorrill at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057



From gvermeul at polycnrs-gre.fr  Thu May 23 03:17:51 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Thu, 23 May 2002 09:17:51 +0200
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install problem on Mandrake-8.2)
In-Reply-To: <Pine.LNX.4.21.0205221150540.1189-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205221150540.1189-100000@cens.ioc.ee>
Message-ID: <200205230717.g4N7Hub24572@polycnrs-gre.fr>

On Wednesday 22 May 2002 11:12, you wrote:

<snip>

> > > import them directly one-by-one. Do you find other failing modules?
> >
> > Yes _minpack.so is the only failing module
>
> Good, in the sense that the problem is localized.
>
> The next step would be playing around with
>
>   scipy/optimize/_minpackmodule.c
>

<snip>

I ended up disabling all methods in minpack_module_methods[]
except "_chkder" in _minpackmodule.c

In __minpack.h, I commented out everything, except
for minpack_chker(). In this function I had to comment out
the two calls to CHKDER().

Without the calls to CHKDER() importing succeeds and
with the calls it fails.

So, it looks like if there is something wrong with
calling Fortran from C in this module.

If there is nothing wrong with the compiler/linker flags
produced by setup.py, there is something wrong with
Mandrake's gcc/g77-2.96.

Travis, did you use the standard Mandrake gcc & g77?

Best regards -- Gerard


From pearu at cens.ioc.ee  Thu May 23 03:41:33 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 23 May 2002 10:41:33 +0300 (EEST)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
 problem on Mandrake-8.2)
In-Reply-To: <200205230717.g4N7Hub24572@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205231031520.31572-100000@cens.ioc.ee>

On Thu, 23 May 2002, Gerard Vermeulen wrote:

> > The next step would be playing around with
> >
> >   scipy/optimize/_minpackmodule.c
> >
> 
> <snip>
> 
> I ended up disabling all methods in minpack_module_methods[]
> except "_chkder" in _minpackmodule.c
> 
> In __minpack.h, I commented out everything, except
> for minpack_chker(). In this function I had to comment out
> the two calls to CHKDER().
> 
> Without the calls to CHKDER() importing succeeds and
> with the calls it fails.

Can you try the following prototype for chkder:

  void CHKDER(int*,int*,double*,double*,int*,double*,double*,int*,double*);

instead of

  void CHKDER();

?

> So, it looks like if there is something wrong with
> calling Fortran from C in this module.
> 
> If there is nothing wrong with the compiler/linker flags
> produced by setup.py, there is something wrong with
> Mandrake's gcc/g77-2.96.

If you do

  f2py -c -m fun minpack/chkder.f minpack/dpmpar.f
  python -c 'import fun'

what happens? SEGFAULT? Nothing?

Pearu



From gvermeul at polycnrs-gre.fr  Thu May 23 05:01:04 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Thu, 23 May 2002 11:01:04 +0200
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install problem on Mandrake-8.2)
In-Reply-To: <Pine.LNX.4.21.0205231031520.31572-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205231031520.31572-100000@cens.ioc.ee>
Message-ID: <200205230901.g4N919b07867@polycnrs-gre.fr>

On Thursday 23 May 2002 09:41, you wrote:
> On Thu, 23 May 2002, Gerard Vermeulen wrote:
> > > The next step would be playing around with
> > >
> > >   scipy/optimize/_minpackmodule.c
> >
> > <snip>
> >
> > I ended up disabling all methods in minpack_module_methods[]
> > except "_chkder" in _minpackmodule.c
> >
> > In __minpack.h, I commented out everything, except
> > for minpack_chker(). In this function I had to comment out
> > the two calls to CHKDER().
> >
> > Without the calls to CHKDER() importing succeeds and
> > with the calls it fails.
>
> Can you try the following prototype for chkder:
>
>   void CHKDER(int*,int*,double*,double*,int*,double*,double*,int*,double*);
>
> instead of
>
>   void CHKDER();
>
> ?
Forgot to tell you, I had changed the prototype already.
>
> > So, it looks like if there is something wrong with
> > calling Fortran from C in this module.
> >
> > If there is nothing wrong with the compiler/linker flags
> > produced by setup.py, there is something wrong with
> > Mandrake's gcc/g77-2.96.
>
> If you do
>
>   f2py -c -m fun minpack/chkder.f minpack/dpmpar.f
>   python -c 'import fun'
>
> what happens? SEGFAULT? Nothing?
>
SEGFAULT

Gerard


From pearu at cens.ioc.ee  Thu May 23 16:46:32 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 23 May 2002 23:46:32 +0300 (EEST)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
 problem on Mandrake-8.2)
In-Reply-To: <200205230901.g4N919b07867@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205232321340.19451-100000@cens.ioc.ee>

On Thu, 23 May 2002, Gerard Vermeulen wrote:

> > > So, it looks like if there is something wrong with
> > > calling Fortran from C in this module.
> > >
> > > If there is nothing wrong with the compiler/linker flags
> > > produced by setup.py, there is something wrong with
> > > Mandrake's gcc/g77-2.96.
> >
> > If you do
> >
> >   f2py -c -m fun minpack/chkder.f minpack/dpmpar.f
> >   python -c 'import fun'
> >
> > what happens? SEGFAULT? Nothing?
> >
> SEGFAULT

This is very interesting. If you can succesfully import large number of
extension modules that wrap various Fortran functions but only this
function, chkder, is causing import failures, and when looking the chkder
code I cannot see anything special in it, then I would like to suggest it
is a compiler bug. But on the other hand, I am not an expert on compilers
and it could be easily something else, something so obvious that we
cannot see it. I am starting to be very curious what is going on here.

So, if you are willing to continue this bug tracking (I can easily
understand if you are not, then may be updating a compiler would be a
way to proceed), then the next step would be playing around
with minpack/chkder.f. Again, I would suggest commenting out various part
of it (the code itself is rather small) and run

  f2py -c -m fun minpack/chkder.f minpack/dpmpar.f
  python -c 'import fun'

until you can import succesfully.


Pearu



From gvermeul at polycnrs-gre.fr  Thu May 23 18:11:42 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Thu, 23 May 2002 22:11:42 GMT
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
Message-ID: <200205232211.g4NMBgm24004@polycnrs-gre.fr>

> 
> On Thu, 23 May 2002, Gerard Vermeulen wrote:
> 
> > > > So, it looks like if there is something wrong with
> > > > calling Fortran from C in this module.
> > > >
> > > > If there is nothing wrong with the compiler/linker flags
> > > > produced by setup.py, there is something wrong with
> > > > Mandrake's gcc/g77-2.96.
> > >
> > > If you do
> > >
> > >   f2py -c -m fun minpack/chkder.f minpack/dpmpar.f
> > >   python -c 'import fun'
> > >
> > > what happens? SEGFAULT? Nothing?
> > >
> > SEGFAULT
> 
> This is very interesting. If you can succesfully import large number of
> extension modules that wrap various Fortran functions but only this
> function, chkder, is causing import failures, and when looking the chkder
> code I cannot see anything special in it, then I would like to suggest it
> is a compiler bug. But on the other hand, I am not an expert on compilers
> and it could be easily something else, something so obvious that we
> cannot see it. I am starting to be very curious what is going on here.
> 
> So, if you are willing to continue this bug tracking (I can easily
> understand if you are not, then may be updating a compiler would be a
> way to proceed), then the next step would be playing around
> with minpack/chkder.f. Again, I would suggest commenting out various part
> of it (the code itself is rather small) and run
> 
>   f2py -c -m fun minpack/chkder.f minpack/dpmpar.f
>   python -c 'import fun'
> 
> until you can import succesfully.
>
Tried to play with this stuff on Mandrake-8.1 and everything worked.
Then, I discovered that Mandrake-8.2 g77 comes with two libraries:
libg2c.a and libg2c-pic.a. Guess this might win a femtosecond
or a nanobyte (my supposition is that there is a libg2c WITHOUT
an a libg2c WITH position independent code -- but I should take
a look in their gcc-2.96 RPM package to be sure -- and where do
you report gcc-2.96 bugs?).

So, I modified build_flib.py to replace the g77 library "g2c" by
"g2c-pic" and now I can happily do "from scipy import *".

But running "scipy.test()" dies with

.zswap:n=3
....... ** On entry to DGESDD parameter number 12 had an illegal value
[packer at venus packer]$

This did not happen with the Red Hat compiled SciPy that I untarred
(this SciPy is probably linked against a rather vanilla Atlas, isn't it?)

Anyhow, I plan to reinstall a gcc/g77-2.95.3 to rebuild the ATLAS
libraries and to get rid of the libg2c-pic.a idiosyncrasy and will
hopefully solve the DGESDD problem at the same time :-)

I will let you know. And Pearu, thanks a lot for your help and
patience.

Gerard.
PS: how fundamental is Atlas to SciPy? Installing ATLAS is a big
obstacle for most users. Could it be possible to make ATLAS optional?
I have still a few old machines (150-300 MHz) and hate the prospect
of installing Atlas on
those.

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From clee at spiralis.merseine.nu  Thu May 23 18:38:30 2002
From: clee at spiralis.merseine.nu (clee at spiralis.merseine.nu)
Date: Thu, 23 May 2002 17:38:30 -0500
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <200205232211.g4NMBgm24004@polycnrs-gre.fr>
References: <200205232211.g4NMBgm24004@polycnrs-gre.fr>
Message-ID: <15597.28518.736802.55225@spiralis.merseine.nu>

>>>>> "gvermeul" == gvermeul  <gvermeul at polycnrs-gre.fr> writes:

    gvermeul> Tried to play with this stuff on Mandrake-8.1 and everything
    gvermeul> worked.  Then, I discovered that Mandrake-8.2 g77 comes with two
    gvermeul> libraries: libg2c.a and libg2c-pic.a. Guess this might win a
    gvermeul> femtosecond or a nanobyte (my supposition is that there is a
    gvermeul> libg2c WITHOUT an a libg2c WITH position independent code -- but I
    gvermeul> should take a look in their gcc-2.96 RPM package to be sure -- and
    gvermeul> where do you report gcc-2.96 bugs?).

[Sorry, I'm butting-in in the middle of your discussion]

You may want to compare your gcc with the latest gcc release for redhat 7.x just
in case they have fixed your bug. My machine has (updated a few months ago):

> rpm -qa | grep gcc
gcc-g77-2.96-98
gcc-2.96-98
gcc-c++-2.96-98
gcc-objc-2.96-98


    gvermeul> Anyhow, I plan to reinstall a gcc/g77-2.95.3 to rebuild the ATLAS
    gvermeul> libraries and to get rid of the libg2c-pic.a idiosyncrasy and will
    gvermeul> hopefully solve the DGESDD problem at the same time :-)


You might want to try the standard (non-accelerated) BLAS and LAPACK libaries:
ATLAS is a great library, but I have occasionally found routines that don't
follow the lapack/blas documentation--this get fixed quickly, but sometimes they
are only in the very latest version.  So I keep around the non-accelerated
libraries and link to them for comparison when I'm trying to track weird bugs
like this down.

    gvermeul> I will let you know. And Pearu, thanks a lot for your help and
    gvermeul> patience.

    gvermeul> Gerard.  PS: how fundamental is Atlas to SciPy? Installing ATLAS
    gvermeul> is a big obstacle for most users. Could it be possible to make
    gvermeul> ATLAS optional?  I have still a few old machines (150-300 MHz) and
    gvermeul> hate the prospect of installing Atlas on those.

ATLAS does provide a big boost in speed.  There are usually binary versions of
ATLAS available. The gcc-2.95.3 compiled versions work with gcc-2.96 linking
(and are much faster).  This would save you the effort of doing ATLAS's
long-install.  If there aren't already binary versions available, scipy.org
could provide some.  As an alternative, Intel provides free lapack/blas
libraries for x86 processors as part of their performance library (libraries for
older processors are available from the <a
href="http://www.cs.utk.edu/~ghenry/distrib> ASCI-Red project </a> ).

-chris


From eric at enthought.com  Thu May 23 18:00:25 2002
From: eric at enthought.com (eric)
Date: Thu, 23 May 2002 18:00:25 -0400
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
References: <200205232211.g4NMBgm24004@polycnrs-gre.fr>
Message-ID: <068e01c202a5$3e6cc3d0$6b01a8c0@ericlaptop>

> Tried to play with this stuff on Mandrake-8.1 and everything worked.
> Then, I discovered that Mandrake-8.2 g77 comes with two libraries:
> libg2c.a and libg2c-pic.a. Guess this might win a femtosecond
> or a nanobyte (my supposition is that there is a libg2c WITHOUT
> an a libg2c WITH position independent code -- but I should take
> a look in their gcc-2.96 RPM package to be sure -- and where do
> you report gcc-2.96 bugs?).
>
> So, I modified build_flib.py to replace the g77 library "g2c" by
> "g2c-pic" and now I can happily do "from scipy import *".

Hmmm.  Good detective work.  But... this is really goofy.  I can't imagine even
wanting to support detection of the g2c-pic library.  I curious as to why Travis
O's scipy builds fine without this library substitution.  His comment that he
had rebuilt python on his own might have an influence, but I don't think so --
especially since the RH compiled SciPy works fine on your machine.  Looking at
the gcc RPM sounds like a good plan.  I don't know where to report bugs though.

>
> But running "scipy.test()" dies with
>
> .zswap:n=3
> ....... ** On entry to DGESDD parameter number 12 had an illegal value
> [packer at venus packer]$
>
> This did not happen with the Red Hat compiled SciPy that I untarred
> (this SciPy is probably linked against a rather vanilla Atlas, isn't it?)

It is compiled on a Pentium III for Linux (P4 on windows), but both are set up
to build the generic version of ATLAS without SSE1 or SSE2 support.  So yes, it
is pretty vanilla.

>
> Anyhow, I plan to reinstall a gcc/g77-2.95.3 to rebuild the ATLAS
> libraries and to get rid of the libg2c-pic.a idiosyncrasy and will
> hopefully solve the DGESDD problem at the same time :-)

good plan.

>
> I will let you know. And Pearu, thanks a lot for your help and
> patience.
>
> Gerard.
> PS: how fundamental is Atlas to SciPy? Installing ATLAS is a big
> obstacle for most users. Could it be possible to make ATLAS optional?
> I have still a few old machines (150-300 MHz) and hate the prospect
> of installing Atlas on
> those.

I agree.  SciPy is starting to mature enough where non-geeks should be able to
install it.  ATLAS is definitely the biggest hurdle.  We could distribute the
SciPy tarballs with f2py rolled in so that Python and Numeric were the only
dependencies (and we *could* roll Numeric in to get rid of it as a dependency,
but it made some unhappy in the SciPy-0.1 release).  This assumes people have a
lapack and blas on their system (is this standard)?

There are several solutions to the ATLAS issue:

    1. Supply ATLAS binaries for the common platforms.
    2. Make the setup.py script work with the
       standard lapack and blas impelementation.

We are likely to supply some ATLAS binaries, but (1) is probably a bigger task
than I want to deal with.

As far as (2), there are currently two reasons we link to ALTAS.  The first is
speed.  The 2nd is that it has C versions of most of the interfaces which
theoretically should be faster because they don't require a memory transpose
before matrix operations.  There is probably some benefit to this on the faster
operations, but Pearu's test have shown that the commonly used matrix
factorizations (order N^3) overshadow the transpose time enough to make it
negligible.  It is probably a reasonable question whether the C interfaces are
really that important.  The speed issue really isn't that big of a deal.  People
who want speed can use ATLAS.  Others can link to the standard LAPACK and BLAS
libraries (which still take 10 or so minutes to build).

So the things that have to change for out-of-the-box building with non-ATLAS
libraries are

 (1) We would need to add a lapack_info to search for lapack and blas if
atlas_info failed to find the libraries.  This would be pretty much identical to
atlas_info, accept that it would only detect lapack and blas.

 (2) linalg_setup.py would have to check whether it was building with ATLAS or
with plain LAPACK.  If with the plain lapack, it would need to disable the build
of the clapack and cblas interfaces.

Pearu did a good job with linalg so that it actually detects whether the C
versions of the interfaces are present.  If they are, it uses them.  If not it
rolls to the fortran versions.  So, I don't think the switch would require any
changes to the actual SciPy code base (or minimal anyway).  It is only the build
process that needs changes.

On a side note, has anyone built against non ATLAS libraries?  Are there any
issues to watch out for?

eric




>
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From gvermeul at polycnrs-gre.fr  Fri May 24 03:14:38 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Fri, 24 May 2002 09:14:38 +0200
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <068e01c202a5$3e6cc3d0$6b01a8c0@ericlaptop>
References: <200205232211.g4NMBgm24004@polycnrs-gre.fr> <068e01c202a5$3e6cc3d0$6b01a8c0@ericlaptop>
Message-ID: <200205240714.g4O7Ehm28567@polycnrs-gre.fr>

On Friday 24 May 2002 00:00, you wrote:
> > PS: how fundamental is Atlas to SciPy? Installing ATLAS is a big
> > obstacle for most users. Could it be possible to make ATLAS optional?
> > I have still a few old machines (150-300 MHz) and hate the prospect
> > of installing Atlas on
> > those.
>
> I agree.  SciPy is starting to mature enough where non-geeks should be able
> to install it.  ATLAS is definitely the biggest hurdle.  We could
> distribute the SciPy tarballs with f2py rolled in so that Python and
> Numeric were the only dependencies (and we *could* roll Numeric in to get
> rid of it as a dependency, but it made some unhappy in the SciPy-0.1
> release).  This assumes people have a lapack and blas on their system (is
> this standard)?
>
I do not like Numeric in SciPy. I had made my own SciPy-0.1 RPM with
the numeric part removed (except for fastumath). Mandrake provides RPMs
for Numeric and some other packages depend on it. You do less harm
to their slick RPM system if you do not include Numeric.

LAPACK/BLAS packages are provided by Mandrake, SuSE & probably others.

>
> There are several solutions to the ATLAS issue:
>
>     1. Supply ATLAS binaries for the common platforms.
>     2. Make the setup.py script work with the
>        standard lapack and blas impelementation.
>
I think (2) is good enough.

Gerard


From oliphant at ee.byu.edu  Fri May 24 13:24:14 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 24 May 2002 11:24:14 -0600 (MDT)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <15597.28518.736802.55225@spiralis.merseine.nu>
Message-ID: <Pine.LNX.4.33L2.0205241121220.11926-100000@oliphant.ee.byu.edu>

I just remembered an important piece of this puzzle.  I was experience
these funny segfaults on Mandrake 8.2 as well until I changed the compiler
flags in /usr/lib/python2.2/config/Makefile  to remove the -fPIC option
that is there.

This causes all extension modules to not be compiled with the -fPIC
option.  This seems to have fixed the problem for me as I have not had
trouble since then (and promptly forgot what I had done.)

I'm sorry I didn't remember this earlier.

-Travis O.




From oliphant at ee.byu.edu  Fri May 24 13:26:42 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 24 May 2002 11:26:42 -0600 (MDT)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <068e01c202a5$3e6cc3d0$6b01a8c0@ericlaptop>
Message-ID: <Pine.LNX.4.33L2.0205241125010.11926-100000@oliphant.ee.byu.edu>

> > Tried to play with this stuff on Mandrake-8.1 and everything worked.
> > Then, I discovered that Mandrake-8.2 g77 comes with two libraries:
> > libg2c.a and libg2c-pic.a. Guess this might win a femtosecond
> > or a nanobyte (my supposition is that there is a libg2c WITHOUT
> > an a libg2c WITH position independent code -- but I should take
> > a look in their gcc-2.96 RPM package to be sure -- and where do
> > you report gcc-2.96 bugs?).
> >
> > So, I modified build_flib.py to replace the g77 library "g2c" by
> > "g2c-pic" and now I can happily do "from scipy import *".
>
> Hmmm.  Good detective work.  But... this is really goofy.  I can't imagine even
> wanting to support detection of the g2c-pic library.  I curious as to why Travis
> O's scipy builds fine without this library substitution.  His comment that he
> had rebuilt python on his own might have an influence, but I don't think so --
> especially since the RH compiled SciPy works fine on your machine.  Looking at
> the gcc RPM sounds like a good plan.  I don't know where to report bugs though.
>

This makes total sense, now.  I solved the problem by not compiling with
-fPIC while the better? solution is to link against g2c-pic.  The problem
comes down to the separation of the "PIC" support code in Mandrake 8.2.

I have no idea why they did this.

-Travis O.




From pearu at cens.ioc.ee  Fri May 24 14:20:26 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 24 May 2002 21:20:26 +0300 (EEST)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <Pine.LNX.4.33L2.0205241125010.11926-100000@oliphant.ee.byu.edu>
Message-ID: <Pine.LNX.4.21.0205242055150.12590-100000@cens.ioc.ee>

On Fri, 24 May 2002, Travis Oliphant wrote:

> > > So, I modified build_flib.py to replace the g77 library "g2c" by
> > > "g2c-pic" and now I can happily do "from scipy import *".
> >
> > Hmmm.  Good detective work.  But... this is really goofy.  I can't imagine even
> > wanting to support detection of the g2c-pic library.  I curious as to why Travis
> > O's scipy builds fine without this library substitution.  His comment that he
> > had rebuilt python on his own might have an influence, but I don't think so --
> > especially since the RH compiled SciPy works fine on your machine.  Looking at
> > the gcc RPM sounds like a good plan.  I don't know where to report bugs though.
> >
> 
> This makes total sense, now.  I solved the problem by not compiling with
> -fPIC while the better? solution is to link against g2c-pic.  The problem
> comes down to the separation of the "PIC" support code in Mandrake 8.2.
> 
> I have no idea why they did this.

So, what do you suggest? As I understand, there are three options for
Mandrake:
1) let their users modify python's Makefile --- a pain for some users, I
guess;
2) let build_flib.py use "g2c-pic" instead of "g2c" --- works only for
"out of box" cases and assuming that Mandrake is consistent with using
"g2c-pic" among its all (recent and future) releases. Need a way to
determine if linux system is from Mandrake;
3) do nothing  --- preferred for users who build their own compiler.

Any other ideas?

Pearu



From gvermeul at polycnrs-gre.fr  Fri May 24 15:00:39 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Fri, 24 May 2002 21:00:39 +0200
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <Pine.LNX.4.21.0205242055150.12590-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205242055150.12590-100000@cens.ioc.ee>
Message-ID: <200205241900.g4OJ0jm13027@polycnrs-gre.fr>

On Friday 24 May 2002 20:20, you wrote:
> > This makes total sense, now.  I solved the problem by not compiling with
> > -fPIC while the better? solution is to link against g2c-pic.  The problem
> > comes down to the separation of the "PIC" support code in Mandrake 8.2.
> >
> > I have no idea why they did this.
>
> So, what do you suggest? As I understand, there are three options for
> Mandrake:
> 1) let their users modify python's Makefile --- a pain for some users, I
> guess;
> 2) let build_flib.py use "g2c-pic" instead of "g2c" --- works only for
> "out of box" cases and assuming that Mandrake is consistent with using
> "g2c-pic" among its all (recent and future) releases. Need a way to
> determine if linux system is from Mandrake;
> 3) do nothing  --- preferred for users who build their own compiler.
>
Well, if you opt for (2), this feature is new in Mandrake-8.2 (8.1 is OK).

A way to check the version of a Red Hat/Mandrake distribution is to use:

[packer at venus packer]$ cat /etc/mandrake-release
Mandrake Linux release 8.2 (Bluebird) for i586
[packer at venus packer]$ cat /etc/redhat-release
Mandrake Linux release 8.2 (Bluebird) for i586
[packer at venus packer]$

Other idea is to use:
[packer at venus packer]$ g77 -print-search-dirs
to get a list of directories and to look for libg2c-pic.a, mine is here:

[packer at venus packer]$ ls /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/
cc1*       cpp0*        crtend.o   include/      libgcc.a       specs
cc1plus*   crtbegin.o   crtendS.o  libg2c.a      libstdc++.a@   SYSCALLS.c.X
collect2*  crtbeginS.o  f771*      libg2c-pic.a  libstdc++.so@  tradcpp0*
[packer at venus packer]$

We can only hope, that if other distributions have/copy this idea, they give
this library the same name.

Gerard

PS: adding a FAQ or KNOWN-PROBLEMS is fine with me, if you opt for (3).
I can try to send a bug report to Mandrake, so that they will undo this
innovation in the future.


From oliphant at ee.byu.edu  Fri May 24 16:03:29 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 24 May 2002 14:03:29 -0600 (MDT)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <200205241900.g4OJ0jm13027@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.33L2.0205241402070.12319-100000@oliphant.ee.byu.edu>

On Fri, 24 May 2002, Gerard Vermeulen wrote:

> > So, what do you suggest? As I understand, there are three options for
> > Mandrake:
> > 1) let their users modify python's Makefile --- a pain for some users, I
> > guess;
> > 2) let build_flib.py use "g2c-pic" instead of "g2c" --- works only for
> > "out of box" cases and assuming that Mandrake is consistent with using
> > "g2c-pic" among its all (recent and future) releases. Need a way to
> > determine if linux system is from Mandrake;
> > 3) do nothing  --- preferred for users who build their own compiler.

I suggest that we do 3)

Mandrake messed up here as far as I'm concerned.   Why don't you send them
a bug-report Gerard?

> PS: adding a FAQ or KNOWN-PROBLEMS is fine with me, if you opt for (3).
> I can try to send a bug report to Mandrake, so that they will undo this
> innovation in the future.

-Travis




From pearu at cens.ioc.ee  Fri May 24 16:06:24 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 24 May 2002 23:06:24 +0300 (EEST)
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
In-Reply-To: <068e01c202a5$3e6cc3d0$6b01a8c0@ericlaptop>
Message-ID: <Pine.LNX.4.21.0205242131020.12590-100000@cens.ioc.ee>

On Thu, 23 May 2002, eric wrote:
> 
> I agree.  SciPy is starting to mature enough where non-geeks should be able to
> install it.  ATLAS is definitely the biggest hurdle.  We could distribute the
> SciPy tarballs with f2py rolled in so that Python and Numeric were the only
> dependencies (and we *could* roll Numeric in to get rid of it as a dependency,
> but it made some unhappy in the SciPy-0.1 release).  This assumes people have a
> lapack and blas on their system (is this standard)?

I agree with Gerard. Many linux distributions already provide Numeric and 
shipping it with SciPy may break local installations. For Windows
platforms things may be different. I guess majority of non-geeks
use Windows and there shipping everything in one package may be a
good idea. On the other hand, most Linux users should be geeks already so
that they should be able to hit few make commands to install few extra
packages that SciPy needs.

Ideally, we should let Linux distributors or their users to deal with
SciPy dependencies. It seems that other larger projects use similar
approach.

BTW, I wonder what lawyers say if LGPL'ed f2py is rolled in to SciPy? I
hope it is not a problem.

> There are several solutions to the ATLAS issue:
> 
>     1. Supply ATLAS binaries for the common platforms.
>     2. Make the setup.py script work with the
>        standard lapack and blas impelementation.
> 
> We are likely to supply some ATLAS binaries, but (1) is probably a bigger task
> than I want to deal with.

(2) was already in my TODO list ;)

> As far as (2), there are currently two reasons we link to ALTAS.  The first is
> speed.  The 2nd is that it has C versions of most of the interfaces which
> theoretically should be faster because they don't require a memory transpose
> before matrix operations.  There is probably some benefit to this on the faster
> operations, but Pearu's test have shown that the commonly used matrix
> factorizations (order N^3) overshadow the transpose time enough to make it
> negligible.

To be exact, transposing a large matrix in-situ is quite an expensive and
nontrivial operation (one must swap elements that are very
far from each other in memory). However, transposing a matrix by
just copying it to another matrix is very fast but twice more memory is
used.

If N is few thousand or less, then memory usage is not really a big issue.
For example, 1000x1000 and 3000x3000 double arrays take approximately 7MB
and 70MB, respectively. (I assume that 512MB RAM is standard nowadays.)

However, if N is larger, then the computer memory must be used carefully
and special consideration is required anyway, whether the transposition is
carried out in-situ or by copying. And here the C interface to ATLAS
may become important. 

> It is probably a reasonable question whether the C interfaces are
> really that important.  The speed issue really isn't that big of a deal.  People
> who want speed can use ATLAS.  Others can link to the standard LAPACK and BLAS
> libraries (which still take 10 or so minutes to build).

I agree. Having the C interfaces around is useful only if there is a
memory issue.

> On a side note, has anyone built against non ATLAS libraries?  Are there any
> issues to watch out for?

I expect it to be very smooth after system_info can detect Fortran
BLAS/LAPACK libraries and setup_linalg starts to use them if atlas is not 
available as you suggested.

Pearu



From tim.carlson at pnl.gov  Fri May 24 16:12:19 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Fri, 24 May 2002 13:12:19 -0700 (PDT)
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 on Mac OS X. Hopefully simple problem
In-Reply-To: <Pine.LNX.4.33L2.0205241402070.12319-100000@oliphant.ee.byu.edu>
Message-ID: <Pine.LNX.4.44.0205241306070.4822-100000@roach.emsl.pnl.gov>

I've shelved HPUX for now :)

Built Python-2.2.1 on OS X without a problem.

Trying to get SciPy-0.2.0_alpha_101.3442 going now. My problem is that
os.name reports a name that has a space in it

Python 2.2.1 (#5, May 24 2002, 11:39:10)
[GCC 2.95.2 19991024 (release)] on darwin
>>> import os
>>> os.uname()
('Darwin', 'osx.emsl.pnl.gov', '5.4', 'Darwin Kernel Version 5.4: Wed Apr
10 09:27:47 PDT 2002; root:xnu/xnu-201.19.3.obj~1/RELEASE_PPC ', 'Power Macintosh')

That makes several programs unhappy.. example

ranlib: can't open file: build/temp.darwin-5.4-Power (No such file or directory)
ranlib: can't open file: Macintosh-2.2/libgist.a (No such file or directory)

Here, ranlib tried to open two files like it was supposed to do since I
gave it two arguments :)

Any easy workaround?  Could I force os.uname()[4] to be PowerMacintosh
someplace?

Thanks

Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support



From pearu at cens.ioc.ee  Fri May 24 16:32:56 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 24 May 2002 23:32:56 +0300 (EEST)
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 on Mac OS X. Hopefully
 simple problem
In-Reply-To: <Pine.LNX.4.44.0205241306070.4822-100000@roach.emsl.pnl.gov>
Message-ID: <Pine.LNX.4.21.0205242322280.12590-100000@cens.ioc.ee>

On Fri, 24 May 2002, Tim Carlson wrote:

> I've shelved HPUX for now :)
> 
> Built Python-2.2.1 on OS X without a problem.
> 
> Trying to get SciPy-0.2.0_alpha_101.3442 going now. My problem is that
> os.name reports a name that has a space in it
> 
> Python 2.2.1 (#5, May 24 2002, 11:39:10)
> [GCC 2.95.2 19991024 (release)] on darwin
> >>> import os
> >>> os.uname()
> ('Darwin', 'osx.emsl.pnl.gov', '5.4', 'Darwin Kernel Version 5.4: Wed Apr
> 10 09:27:47 PDT 2002; root:xnu/xnu-201.19.3.obj~1/RELEASE_PPC ', 'Power Macintosh')
> 
> That makes several programs unhappy.. example
> 
> ranlib: can't open file: build/temp.darwin-5.4-Power (No such file or directory)
> ranlib: can't open file: Macintosh-2.2/libgist.a (No such file or directory)

This seems to be a bug in the get_platform function in distutils/util.py

> Any easy workaround?  Could I force os.uname()[4] to be PowerMacintosh
> someplace?

As an easy workaround, fix get_platform in your Python distutils/util.py.
For example, put
 machine = machine.replace(' ','')
after the line
 ... = os.uname()

A bug report to Python would be nice. You can submit it in

http://sourceforge.net/tracker/?group_id=5470&atid=305470

See the category distutils.

Pearu



From eric at enthought.com  Fri May 24 15:31:08 2002
From: eric at enthought.com (eric)
Date: Fri, 24 May 2002 15:31:08 -0400
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 on Mac OS X. Hopefully simple problem
References: <Pine.LNX.4.44.0205241306070.4822-100000@roach.emsl.pnl.gov>
Message-ID: <010001c20359$8e3b5160$d2566a42@ericlaptop>

Hey Tim,


> I've shelved HPUX for now :)
>
> Built Python-2.2.1 on OS X without a problem.
>
> Trying to get SciPy-0.2.0_alpha_101.3442 going now. My problem is that
> os.name reports a name that has a space in it
>
> Python 2.2.1 (#5, May 24 2002, 11:39:10)
> [GCC 2.95.2 19991024 (release)] on darwin
> >>> import os
> >>> os.uname()
> ('Darwin', 'osx.emsl.pnl.gov', '5.4', 'Darwin Kernel Version 5.4: Wed Apr
> 10 09:27:47 PDT 2002; root:xnu/xnu-201.19.3.obj~1/RELEASE_PPC ', 'Power
Macintosh')
>
> That makes several programs unhappy.. example
>
> ranlib: can't open file: build/temp.darwin-5.4-Power (No such file or
directory)
> ranlib: can't open file: Macintosh-2.2/libgist.a (No such file or directory)
>
> Here, ranlib tried to open two files like it was supposed to do since I
> gave it two arguments :)
>
> Any easy workaround?  Could I force os.uname()[4] to be PowerMacintosh
> someplace?

Hmmm, this looks like a distutils bug.  In distutils/util.py, line 43 in
get_platform() of my distributions is the following:

    (osname, host, release, version, machine) = os.uname()

Can you replace this with the following and see if that solves your problem:

    import string
    os_stuff = map(lambda x: string.replace(x,' ','_'),os.uname())
    (osname, host, release, version, machine) = os_stuff

This just removes spaces form any of this information.  The build directory is
made (at least partially) by the following format string:

    return "%s-%s-%s" % (osname, release, machine)

It looks like your problem is that "machine" is "Power Macintosh".  Removing the
spaces with the replace hopefully solves the problem.

Let me know if this works.  If so, we'll define our own get_platform() and plug
it into distutils for scipy builds as a temporary fix.  The better solution is
to fix distutils to work correctly with the Macs.  If the above works, could you
please submit it as a bug fix to Python?

thanks,
eric





From jjl at pobox.com  Fri May 24 16:38:44 2002
From: jjl at pobox.com (John J. Lee)
Date: Fri, 24 May 2002 21:38:44 +0100 (BST)
Subject: [SciPy-user] How To Plot List with None Values?
In-Reply-To: <009901c20075$32fa6700$6b01a8c0@ericlaptop>
Message-ID: <Pine.SOL.4.30.0205242137310.27842-100000@mimosa.csv.warwick.ac.uk>

On Mon, 20 May 2002, eric wrote:

>
> One solution is to split the array up into the segments between the None values
> and just plot these with gaps in spots that had None values.  You could modify
> the code to connect the segments if that is preferable.
[...]

There's also the MA package from Numeric -- which I presume works somehow
with the scipy plotting stuff?  In any case, I'm sure you could write a
function to make them work together without any trouble.


John



From eric at enthought.com  Fri May 24 15:38:34 2002
From: eric at enthought.com (eric)
Date: Fri, 24 May 2002 15:38:34 -0400
Subject: [SciPy-user] How To Plot List with None Values?
References: <Pine.SOL.4.30.0205242137310.27842-100000@mimosa.csv.warwick.ac.uk>
Message-ID: <010e01c2035a$97d31bd0$d2566a42@ericlaptop>

> On Mon, 20 May 2002, eric wrote:
>
> >
> > One solution is to split the array up into the segments between the None
values
> > and just plot these with gaps in spots that had None values.  You could
modify
> > the code to connect the segments if that is preferable.
> [...]
>
> There's also the MA package from Numeric -- which I presume works somehow
> with the scipy plotting stuff?

Nothing has been done to try and incorporate it.

>  In any case, I'm sure you could write a
> function to make them work together without any trouble.

eric





From tim.carlson at pnl.gov  Fri May 24 16:58:17 2002
From: tim.carlson at pnl.gov (Tim Carlson)
Date: Fri, 24 May 2002 13:58:17 -0700 (PDT)
Subject: [SciPy-user] SciPy-0.2.0_alpha_101.3442 on Mac OS X. Hopefully
 simple problem
In-Reply-To: <Pine.LNX.4.21.0205242322280.12590-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.44.0205241350110.4822-100000@roach.emsl.pnl.gov>

> As an easy workaround, fix get_platform in your Python distutils/util.py.
> For example, put
>  machine = machine.replace(' ','')
> after the line
>  ... = os.uname()

Cool.. that worked nicely

> A bug report to Python would be nice. You can submit it in
>
> http://sourceforge.net/tracker/?group_id=5470&atid=305470

Bug submitted.

Compilation continued smoothly and I am able to import the scipy without a
problem and am running it through the tests.

The Matrix numbers are *really* different when using scipy


Thanks for the help!

Tim

          Finding matrix determinant
      ==================================
      |    contiguous     |   non-contiguous
----------------------------------------------
 size |  scipy  | Numeric |  scipy  | Numeric
   20 |   0.30  |   0.70  |   0.30  |   0.76     (secs for 2000 calls)
  100 |   0.53  |   3.73  |   0.53  |   4.02     (secs for 300 calls)
  500 |   0.67  |   5.60  |   0.57  |   5.75     (secs for 4 calls)
.

      Solving system of linear equations
      ==================================
      |    contiguous     |   non-contiguous
----------------------------------------------
 size |  scipy  | Numeric |  scipy  | Numeric
   20 |   0.47  |   0.60  |   0.47  |   0.66     (secs for 2000 calls)
  100 |   0.60  |   3.55  |   0.57  |   3.80     (secs for 300 calls)
  500 |   0.67  |   5.51  |   0.57  |   5.59     (secs for 4 calls)
.
           Finding matrix inverse
      ==================================
      |    contiguous     |   non-contiguous
----------------------------------------------
 size |  scipy  | Numeric |  scipy  | Numeric
   20 |   0.60  |   1.34  |   0.60  |   1.40     (secs for 2000 calls)
  100 |   1.65  |  11.04  |   1.60  |  11.36     (secs for 300 calls)
  500 |   1.58  |  19.62  |   1.57  |  19.72     (secs for 4 calls)






From gvermeul at polycnrs-gre.fr  Sat May 25 05:27:19 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Sat, 25 May 2002 09:27:19 GMT
Subject: [SciPy-user] compiler & lapack issues
Message-ID: <200205250927.g4P9RJm28662@polycnrs-gre.fr>

Hi,

gcc-2.95.3 is an order of magnitude faster than Mandrake-8.2's gcc-2.96
in compiling the Atlas libraries. Use of 2.95.3 decreased the time
from an estimated 8 hours to far less than 1 hour on a 1 GHz AMD.

It is really worthwhile to install a minimal version of th gcc-2.95.3
compilers (no shared libraries) in /usr/local/bin.


The fact that running scipy.test() on my system dies with

.zswap:n=3
....... ** On entry to DGESDD parameter number 12 had an illegal value
[packer at venus packer]$

is related to a LAPACK issue.

Mandrake's LAPACK rpms come with a lot of patches that have been released
after "Update, Version 3.0:  May 31, 2000", see 
http://netlib2.cs.utk.edu/lapack/release_notes.html

This includes new versions of ?gesdd.f with corrected work space
calculations. Probably, the parameter checks in the corresponding
*.pyf files are out of sync with those post-latest-Update release.

What to do about this? Changing the *.pyf files will uncover errors
in LAPACK installations without those patches. On the other hand,
one one would not like to see a bridge collapse, due to an unapplied
patch, isn't it?

Gerard


---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From pearu at cens.ioc.ee  Sat May 25 07:12:33 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 25 May 2002 14:12:33 +0300 (EEST)
Subject: [SciPy-user] compiler & lapack issues
In-Reply-To: <200205250927.g4P9RJm28662@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205251340560.12590-100000@cens.ioc.ee>

On Sat, 25 May 2002 gvermeul at polycnrs-gre.fr wrote:

> The fact that running scipy.test() on my system dies with
> 
> .zswap:n=3
> ....... ** On entry to DGESDD parameter number 12 had an illegal value
> [packer at venus packer]$
> 
> is related to a LAPACK issue.
> 
> Mandrake's LAPACK rpms come with a lot of patches that have been released
> after "Update, Version 3.0:  May 31, 2000", see 
> http://netlib2.cs.utk.edu/lapack/release_notes.html
> 
> This includes new versions of ?gesdd.f with corrected work space
> calculations. Probably, the parameter checks in the corresponding
> *.pyf files are out of sync with those post-latest-Update release.
> 
> What to do about this? Changing the *.pyf files will uncover errors
> in LAPACK installations without those patches. On the other hand,
> one one would not like to see a bridge collapse, due to an unapplied
> patch, isn't it?

The latest official LAPACK release update does not include these patches.
We could fix *.pyf according to these LAPACK patches but then we must
include these patches also to SciPy distribution so that people can use
their existing LAPACK libraries and only the latest routines come from
SciPy. It complicates things a bit but it should work.

Meanwhile you can downgrade gesdd routines by copying official ?gesdd.f
files to scipy/linalg/src directory and add the names ?gesdd.f to
the flinalg list in setup_linalg.py similarly to files det.f and lu.f. The
same technique can be later used for upgrading gesdd routines but let us
know if it works.

Pearu



From pearu at cens.ioc.ee  Sat May 25 10:45:05 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 25 May 2002 17:45:05 +0300 (EEST)
Subject: [SciPy-user] compiler & lapack issues
In-Reply-To: <200205250927.g4P9RJm28662@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205251735100.12590-100000@cens.ioc.ee>

On Sat, 25 May 2002 gvermeul at polycnrs-gre.fr wrote:

> The fact that running scipy.test() on my system dies with
> 
> .zswap:n=3
> ....... ** On entry to DGESDD parameter number 12 had an illegal value
> [packer at venus packer]$
> 
> is related to a LAPACK issue.
> 
> Mandrake's LAPACK rpms come with a lot of patches that have been released
> after "Update, Version 3.0:  May 31, 2000", see 
> http://netlib2.cs.utk.edu/lapack/release_notes.html
> 
> This includes new versions of ?gesdd.f with corrected work space
> calculations. Probably, the parameter checks in the corresponding
> *.pyf files are out of sync with those post-latest-Update release.

I just downloaded LAPACK patches from

  ftp://netlib2.cs.utk.edu/lapack/patch/src/

and compiled linalg with it. And I don't get this error. I even put a
print statement into dgesdd.f to see that it was actually used (indeed,
it was but in different places, not after the "zswap:n=3" message).
Can you determine which test in linalg/tests/test_*.py actually fails?
Also, where can I get Mandrake lapack.src.rpm's to see what they have
done?

Pearu



From gvermeul at polycnrs-gre.fr  Sat May 25 14:49:31 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Sat, 25 May 2002 18:49:31 GMT
Subject: [SciPy-user] compiler & lapack issues
Message-ID: <200205251849.g4PInVm31749@polycnrs-gre.fr>

> 
> On Sat, 25 May 2002 gvermeul at polycnrs-gre.fr wrote:
> 
> > The fact that running scipy.test() on my system dies with
> > 
> > .zswap:n=3
> > ....... ** On entry to DGESDD parameter number 12 had an illegal value
> > [packer at venus packer]$
> > 
> > is related to a LAPACK issue.
> > 
> > Mandrake's LAPACK rpms come with a lot of patches that have been released
> > after "Update, Version 3.0:  May 31, 2000", see 
> > http://netlib2.cs.utk.edu/lapack/release_notes.html
> > 
> > This includes new versions of ?gesdd.f with corrected work space
> > calculations. Probably, the parameter checks in the corresponding
> > *.pyf files are out of sync with those post-latest-Update release.
> 
> I just downloaded LAPACK patches from
> 
>   ftp://netlib2.cs.utk.edu/lapack/patch/src/
> 
> and compiled linalg with it. And I don't get this error. I even put a
> print statement into dgesdd.f to see that it was actually used (indeed,
> it was but in different places, not after the "zswap:n=3" message).
> Can you determine which test in linalg/tests/test_*.py actually fails?
> Also, where can I get Mandrake lapack.src.rpm's to see what they have
> done?
> 
You can get a Mandrake src.rpm (allthough advertised to be for the future
Mandrake-8.3/9.0, it is still the same rpm) 

ftp://ftp.free.fr/mirrors/ftp.mandrake-linux.com/Mandrake-devel/contrib/SRPMS/lapack-3.0-4mdk.src.rpm

Rebuilding LAPACK with g77-2.95.3 and without patches made this message
disappear. Now, I am rebuilding the stuff with patches to check what
happens (uninstalled g77-2.96, lapack rpms, ... - steps towards a build
environment enforcing g77-2.95.3 AND g++-2.96, but leaving the choice
between gcc-2.95.3 or 2.96). I am a bit reluctant to undo this, but if
you insist.... I'd rather prefer to help to get the LAPACK patches integrated
than hunt for Mandrake's gcc-2.96/g2c-pic related problems.

Gerard


---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From pearu at cens.ioc.ee  Sat May 25 17:10:38 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 26 May 2002 00:10:38 +0300 (EEST)
Subject: [SciPy-user] compiler & lapack issues
In-Reply-To: <200205251849.g4PInVm31749@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205252356440.12590-100000@cens.ioc.ee>


On Sat, 25 May 2002 gvermeul at polycnrs-gre.fr wrote:

> > I just downloaded LAPACK patches from
> > 
> >   ftp://netlib2.cs.utk.edu/lapack/patch/src/
> > 
> > and compiled linalg with it. And I don't get this error. I even put a
> > print statement into dgesdd.f to see that it was actually used (indeed,
> > it was but in different places, not after the "zswap:n=3" message).
> > Can you determine which test in linalg/tests/test_*.py actually fails?
> > Also, where can I get Mandrake lapack.src.rpm's to see what they have
> > done?
> > 
> You can get a Mandrake src.rpm (allthough advertised to be for the future
> Mandrake-8.3/9.0, it is still the same rpm) 
> 
> ftp://ftp.free.fr/mirrors/ftp.mandrake-linux.com/Mandrake-devel/contrib/SRPMS/lapack-3.0-4mdk.src.rpm

Thanks.

> Rebuilding LAPACK with g77-2.95.3 and without patches made this message
> disappear. Now, I am rebuilding the stuff with patches to check what
> happens (uninstalled g77-2.96, lapack rpms, ... - steps towards a build
> environment enforcing g77-2.95.3 AND g++-2.96, but leaving the choice
> between gcc-2.95.3 or 2.96). I am a bit reluctant to undo this, but if
> you insist.... I'd rather prefer to help to get the LAPACK patches integrated
> than hunt for Mandrake's gcc-2.96/g2c-pic related problems.

I didn't assume that it is a gcc-2.96/g2c-pic releated problem. And I
think if you have a working system, keep it, don't break it because of me.
I'll play a bit with Mandrake patches in order to determine whether the
test failure is due to these patches. If yes, then I can look how to fix
the interfaces to lapack. As I said before, I have not been able to
reproduce the test failure with the latest LAPACK patches. Now I'll try to
build scipy without ATLAS but using Fortran LAPACK/BLAS...

Pearu



From gvermeul at polycnrs-gre.fr  Sun May 26 07:17:39 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Sun, 26 May 2002 11:17:39 GMT
Subject: [SciPy-user] compiler & lapack issues
Message-ID: <200205261117.g4QBHdm24585@polycnrs-gre.fr>

Pearu wrote:

> > > I just downloaded LAPACK patches from
> > > 
> > >   ftp://netlib2.cs.utk.edu/lapack/patch/src/
> > > 
> > > and compiled linalg with it. And I don't get this error. I even put a
> > > print statement into dgesdd.f to see that it was actually used (indeed,
> > > it was but in different places, not after the "zswap:n=3" message).
> > > Can you determine which test in linalg/tests/test_*.py actually fails?

test_svd fails (I commented out almost everything except for this test, but
impossible the get rid of the zswap:n=3" message). No failure if I also
comment out test_svd.

> > > Also, where can I get Mandrake lapack.src.rpm's to see what they have
> > > done?

I will integrate the latest patches in my lapack. Maybe a patch has been
superseded by another.


BTW, a small glitch in build_flib.py (it is fairly dead code):

    def find_lib_directories(self):
        lib_dir = []
        match = r'Reading specs from (.*)/specs'

        # works I think only for unix...
        exit_status, out_text = run_command('g77 -v')

I would replace ('g77 -v') with ('%s -v' % self.f77_compiler)


Request: I would like to be able to do something like:

python setup.py build fc-compiler=/usr/local/bin/g77

or

python setup.py build --fc-compiler=g77-2.95.3

Actually, there is less need to tweak the C compiler than the
Fortran compiler. Would it not be nice to specify a Fortran
compiler when running Python's configure (--with-fcc=...)?
Now I have the choice of hardcoding a specific g77 in SciPy's
distutils scripts or of relying on dynamic links.

Gerard


---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From pearu at cens.ioc.ee  Sun May 26 07:40:27 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 26 May 2002 14:40:27 +0300 (EEST)
Subject: [SciPy-user] compiler & lapack issues
In-Reply-To: <200205261117.g4QBHdm24585@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205261427510.8693-100000@cens.ioc.ee>

On Sun, 26 May 2002 gvermeul at polycnrs-gre.fr wrote:

> test_svd fails (I commented out almost everything except for this test, but
> impossible the get rid of the zswap:n=3" message). No failure if I also
> comment out test_svd.

I think zswap:n=3 comes from test_fblas.py.

> > > > Also, where can I get Mandrake lapack.src.rpm's to see what they have
> > > > done?
> 
> I will integrate the latest patches in my lapack. Maybe a patch has been
> superseded by another.
> 
> 
> BTW, a small glitch in build_flib.py (it is fairly dead code):
> 
>     def find_lib_directories(self):
>         lib_dir = []
>         match = r'Reading specs from (.*)/specs'
> 
>         # works I think only for unix...
>         exit_status, out_text = run_command('g77 -v')
> 
> I would replace ('g77 -v') with ('%s -v' % self.f77_compiler)

Fixed. I am really not sure but mingw or cygwin may need it. For unices it
is dead indeed.

> Request: I would like to be able to do something like:
> 
> python setup.py build fc-compiler=/usr/local/bin/g77
> 
> or
> 
> python setup.py build --fc-compiler=g77-2.95.3
> 
> Actually, there is less need to tweak the C compiler than the
> Fortran compiler. Would it not be nice to specify a Fortran
> compiler when running Python's configure (--with-fcc=...)?
> Now I have the choice of hardcoding a specific g77 in SciPy's
> distutils scripts or of relying on dynamic links.

We already have what you requested. Use

  python setup.py build build_flib --fcompiler-exec=/path/to/f77

See also

  python setup.py build_flib --help

Pearu



From gvermeul at polycnrs-gre.fr  Sun May 26 10:27:45 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Sun, 26 May 2002 14:27:45 GMT
Subject: [SciPy-user] compiler & lapack issues
Message-ID: <200205261427.g4QERjm03271@polycnrs-gre.fr>

Pearu wrote:
> 
> > test_svd fails (I commented out almost everything except for this test, but
> > impossible the get rid of the zswap:n=3" message). No failure if I also
> > comment out test_svd.
> 
> I think zswap:n=3 comes from test_fblas.py.
> 
> > 
> > I will integrate the latest patches in my lapack. Maybe a patch has been
> > superseded by another.
> >
test_svd fails, with newest patches applied.

So, I tried to mask dgesdd, as you suggested. Problem is that dgessd
is linked into _flinalg.so and flapack.so. On my system,
the one in flapack.so is called during the test.

Attached (hackish) patch replaces dgesdd.o in both *.so's.
So, in principle, it is possible to repair "broken" LAPACK
installations.

Gerard




---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linalg.patch
Type: application/octet-stream
Size: 1342 bytes
Desc: not available
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20020526/2aff0fb8/attachment.obj>

From gvermeul at polycnrs-gre.fr  Sun May 26 10:43:16 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Sun, 26 May 2002 14:43:16 GMT
Subject: [SciPy-user] compiler & lapack issues
Message-ID: <200205261443.g4QEhGm04383@polycnrs-gre.fr>

> 
> Attached (hackish) patch replaces dgesdd.o in both *.so's.
> So, in principle, it is possible to repair "broken" LAPACK
> installations.
> 
> Gerard

In human readable format:
 
--- SciPy-0.2.0_alpha_101.3442/linalg/setup_linalg.py.gv	Fri May 24 11:01:07 2002
+++ SciPy-0.2.0_alpha_101.3442/linalg/setup_linalg.py	Sun May 26 15:51:58 2002
@@ -39,12 +39,19 @@
                    'flapack':['generic_flapack.pyf'],
                    'clapack':['generic_clapack.pyf']}
     
+    flapack_mask = []
+    for f in ['dgesdd.f'
+              ]:
+        flapack_mask.append(os.path.join(local_path,'src',f))
+
     for mod_name,sources in mod_sources.items():
         sources = [os.path.join(local_path,s) for s in sources]
         mod_file = os.path.join(local_path,mod_name+'.pyf')
         if dep_util.newer_group(sources,mod_file):
             generate_interface(mod_name,sources[0],mod_file)
         sources = filter(lambda s:s[-4:]!='.pyf',sources)
+        if mod_name in ['flapack']:
+            sources += flapack_mask
         ext_args = {'name':dot_join(parent_package,'linalg',mod_name),
                     'sources':[mod_file]+sources}
         dict_append(ext_args,**atlas_info)
@@ -56,6 +63,7 @@
     for f in ['det.f','lu.f', #'wrappers.c','inv.f',
               ]:
         flinalg.append(os.path.join(local_path,'src',f))
+    flinalg += flapack_mask
     ext_args = {'name':dot_join(parent_package,'linalg','_flinalg'),
                 'sources':flinalg}
     dict_append(ext_args,**atlas_info)



---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From pearu at cens.ioc.ee  Sun May 26 11:47:34 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 26 May 2002 18:47:34 +0300 (EEST)
Subject: [SciPy-user] compiler & lapack issues
In-Reply-To: <200205261427.g4QERjm03271@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205261836450.8693-100000@cens.ioc.ee>

On Sun, 26 May 2002 gvermeul at polycnrs-gre.fr wrote:

> Pearu wrote:
> > 
> > > test_svd fails (I commented out almost everything except for this test, but
> > > impossible the get rid of the zswap:n=3" message). No failure if I also
> > > comment out test_svd.
> > 
> > I think zswap:n=3 comes from test_fblas.py.
> > 
> > > 
> > > I will integrate the latest patches in my lapack. Maybe a patch has been
> > > superseded by another.
> > >
> test_svd fails, with newest patches applied.
> 
> So, I tried to mask dgesdd, as you suggested. Problem is that dgessd
> is linked into _flinalg.so and flapack.so. On my system,
> the one in flapack.so is called during the test.
> 
> Attached (hackish) patch replaces dgesdd.o in both *.so's.
> So, in principle, it is possible to repair "broken" LAPACK
> installations.

Thanks for the patch. I am now able to produce this error and already
fixed it (see below). Also I have implemented hooks to use LAPACK and BLAS
libriaries if ATLAS is not available. I need to clean up things and run
the tests and then I'll commit my changes to CVS.

Fix: replace the following line at the end of subroutine gesdd in file
scipy/linalg/src/calc_lwork.f

      max_lwork = MAXWRK

with

      max_lwork = MAX(MINWRK,MAXWRK)

With this fix both official and patched LAPACK should work so that no
additional special hooks will be needed. I hope that you can confirm this.

Regards,
	Pearu



From gvermeul at polycnrs-gre.fr  Sun May 26 13:35:46 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Sun, 26 May 2002 17:35:46 GMT
Subject: [SciPy-user] compiler & lapack issues
Message-ID: <200205261735.g4QHZkm14568@polycnrs-gre.fr>

Pearu wrote:
> 
> Fix: replace the following line at the end of subroutine gesdd in file
> scipy/linalg/src/calc_lwork.f
> 
>       max_lwork = MAXWRK
> 
> with
> 
>       max_lwork = MAX(MINWRK,MAXWRK)
> 
> With this fix both official and patched LAPACK should work so that no
> additional special hooks will be needed. I hope that you can confirm this.
>
patched LAPACK works fine.

Thanks + regards -- Gerard 




---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From gvermeul at polycnrs-gre.fr  Mon May 27 13:13:16 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Mon, 27 May 2002 19:13:16 +0200
Subject: [SciPy-user] SciPy and I do not like libg2c-pic.a in Mandrake's gcc-2.96 and 3.xx
Message-ID: <200205271713.g4RHDKe03449@polycnrs-gre.fr>

Dear Gwenole,

I am using Python -- interfaced to Numerical libraries -- for computing.

When installing SciPy - a suite of scientific extensions for Python,
see www.scipy.org - I ran into a problem that I finally traced to
the requirement of having to link in libg2c-pic.a for dynamically loadable
libraries.

See:  
http://www.scipy.org/site_content/mailman?fn=scipy-user/2002-May/000402.html
and other messages in the same thread.

The developers of SciPy see this as a "Mandrake idiosyncrasy", and I do
agree. Looking in the SRPMS of the gcc compilers, I see that libg2c-pic.a is
new in Mandrake-8.2 and that it exists in gcc-2.96 and 3.0.x.

No doubt you have a good reason for introducing libg2c-pic.a, but it is an 
innovation that made me loose quite a lot of time. And I am hoping that you
will undo it.

If not, can you explain why you have introduced libg2c-pic.a and if you
know of other distro's following the same policy (using an identical name), 
please tell.

It will be great if SciPy builds out of the box on future versions of 
Mandrake!

Best regards -- Gerard Vermeulen

PS: Mandrake-8.2 is great -- keep up the good work!



From gbeauchesne at mandrakesoft.com  Mon May 27 13:49:17 2002
From: gbeauchesne at mandrakesoft.com (Gwenole Beauchesne)
Date: Mon, 27 May 2002 19:49:17 +0200 (CEST)
Subject: [SciPy-user] Re: SciPy and I do not like libg2c-pic.a in Mandrake's gcc-2.96 and
 3.xx
In-Reply-To: <200205271713.g4RHDKe03449@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.44.0205271939130.15789-100000@thalys.mandrakesoft.com>

Hi,

> When installing SciPy - a suite of scientific extensions for Python,
> see www.scipy.org - I ran into a problem that I finally traced to
> the requirement of having to link in libg2c-pic.a for dynamically loadable
> libraries.

Any DSO must have PIC code. libg2c.a does not contain PIC code. Thus
introducing libg2c-pic.a before libg2c was finally made shared in gcc3.1.  
You haven't realized that problem yet probably because you were lucky
enough under Linux/x86. This is not true everywhere.

However, if linking with libg2c-pic doesn't help, please let me know.

> The developers of SciPy see this as a "Mandrake idiosyncrasy", and I do
> agree. Looking in the SRPMS of the gcc compilers, I see that libg2c-pic.a is
> new in Mandrake-8.2 and that it exists in gcc-2.96 and 3.0.x.

Those compilers didn't have a shared version of libg2c.

> If not, can you explain why you have introduced libg2c-pic.a and if you
> know of other distro's following the same policy (using an identical name), 
> please tell.

Debian, at least. I used their same naming convention. Otherwise, people 
would be messed up. ;-)

> It will be great if SciPy builds out of the box on future versions of 
> Mandrake!

It will since next version is GCC 3.1 based which provides a shared 
version of libg2c with PIC code.

> PS: Mandrake-8.2 is great -- keep up the good work!

Thanks.

Bye,
Gwenole.




From pearu at cens.ioc.ee  Mon May 27 16:57:39 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 27 May 2002 23:57:39 +0300 (EEST)
Subject: [SciPy-user] Re: SciPy and I do not like libg2c-pic.a in Mandrake's
 gcc-2.96 and 3.xx
In-Reply-To: <Pine.LNX.4.44.0205271939130.15789-100000@thalys.mandrakesoft.com>
Message-ID: <Pine.LNX.4.21.0205272348290.17569-100000@cens.ioc.ee>

On Mon, 27 May 2002, Gwenole Beauchesne wrote:

> Hi,
> 
> > When installing SciPy - a suite of scientific extensions for Python,
> > see www.scipy.org - I ran into a problem that I finally traced to
> > the requirement of having to link in libg2c-pic.a for dynamically loadable
> > libraries.
> 
> Any DSO must have PIC code. libg2c.a does not contain PIC code. Thus
> introducing libg2c-pic.a before libg2c was finally made shared in gcc3.1.  
> You haven't realized that problem yet probably because you were lucky
> enough under Linux/x86. This is not true everywhere.

I have added hooks to scipy_distutils to check if g2c-pic is available
(it was not too difficult) and use it instead of g2c if available. 
And indeed, also on debian gcc 2.95.4 and 3.0.x have g2c-pic library but
not in gcc 3.1.
Here follows a relevant fragment of the gcc changelog in debian woody:

gcc-2.95 (2.95.4.ds4-0.010826) unstable; urgency=low

  * Build libg2c.a with -fPIC -DPIC and name the result libg2c-pic.a.
    Link with this library to avoid linking with non-pic code.
    Use this library when building dynamically loadable objects (python
    modules, gimp plugins, ...), which need to be linked against g2c or
    a library which is linked against g2c (i.e. lapack). Packages needing
    '-lg2c-pic' must have a build dependency on
    'g77-2.95 (>= 1:2.95.4-0.010826).

 -- Matthias Klose <doko at debian.org>  Sun, 26 Aug 2001 13:59:03 +0200

Regards,
	Pearu



From gvermeul at polycnrs-gre.fr  Mon May 27 17:39:17 2002
From: gvermeul at polycnrs-gre.fr (gvermeul at polycnrs-gre.fr)
Date: Mon, 27 May 2002 21:39:17 GMT
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
Message-ID: <200205272139.g4RLdHe18178@polycnrs-gre.fr>

Sorry, Pearu, it's me again:

After installing SciPy on a machine without ATLAS,
scipy.test() resulted in

======================================================================
ERROR: Test persisting a function in the default catalog
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.1/site-packages/scipy/weave/tests/test_catalog.py",
line 274, in check_add_function_persistent1
    q.add_function_persistent('code',i)
  File "/usr/lib/python2.1/site-packages/scipy/weave/catalog.py", line 615, in
add_function_persistent
    module = getmodule(function)
  File "/usr/lib/python2.1/site-packages/scipy/weave/catalog.py", line 66, in
getmodule
    if mod and object in mod.__dict__.values():
  File "/usr/lib/python2.1/site-packages/scipy_distutils/misc_util.py", line 13,
in __getattr__
    raise self._info[0],self._info[1]
ImportError: /usr/lib/python2.1/site-packages/scipy/linalg/fblas.so: undefined
symbol: srotmg_
----------------------------------------------------------------------
Ran 447 tests in 2.017s

FAILED (errors=2)
<unittest.TextTestRunner instance at 0x853506c>
>>>

grepping the output of nm, I found "srotmg" back in the ATLAS libraries
on another machine but not in the standard LAPACK/BLAS libraries.

Gerard


---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/




From eric at enthought.com  Mon May 27 16:53:54 2002
From: eric at enthought.com (eric)
Date: Mon, 27 May 2002 16:53:54 -0400
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
References: <200205272139.g4RLdHe18178@polycnrs-gre.fr>
Message-ID: <03fe01c205c0$9d219a40$d2566a42@ericlaptop>

Hey Gerard,

Not sure why weave linked anything against fblas, but I am pretty sure that this
error occured only because you had previously built/tested SciPy with weave.
Try deleting the .python_compiled directory in your home directory to get rid of
any old compiled files.  If that doesn't solve the problem, also delete
/tmp/python2x_intermediate where x is the version you are testing.

eric

----- Original Message -----
From: <gvermeul at polycnrs-gre.fr>
To: <scipy-user at scipy.net>
Sent: Monday, May 27, 2002 5:39 PM
Subject: [SciPy-user] testing SciPy without ATLAS ;-(


> Sorry, Pearu, it's me again:
>
> After installing SciPy on a machine without ATLAS,
> scipy.test() resulted in
>
> ======================================================================
> ERROR: Test persisting a function in the default catalog
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python2.1/site-packages/scipy/weave/tests/test_catalog.py",
> line 274, in check_add_function_persistent1
>     q.add_function_persistent('code',i)
>   File "/usr/lib/python2.1/site-packages/scipy/weave/catalog.py", line 615, in
> add_function_persistent
>     module = getmodule(function)
>   File "/usr/lib/python2.1/site-packages/scipy/weave/catalog.py", line 66, in
> getmodule
>     if mod and object in mod.__dict__.values():
>   File "/usr/lib/python2.1/site-packages/scipy_distutils/misc_util.py", line
13,
> in __getattr__
>     raise self._info[0],self._info[1]
> ImportError: /usr/lib/python2.1/site-packages/scipy/linalg/fblas.so: undefined
> symbol: srotmg_
> ----------------------------------------------------------------------
> Ran 447 tests in 2.017s
>
> FAILED (errors=2)
> <unittest.TextTestRunner instance at 0x853506c>
> >>>
>
> grepping the output of nm, I found "srotmg" back in the ATLAS libraries
> on another machine but not in the standard LAPACK/BLAS libraries.
>
> Gerard
>
>
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From pearu at cens.ioc.ee  Mon May 27 18:02:02 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 28 May 2002 01:02:02 +0300 (EEST)
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <200205272139.g4RLdHe18178@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205280045160.17569-100000@cens.ioc.ee>


On Mon, 27 May 2002 gvermeul at polycnrs-gre.fr wrote:

> ImportError: /usr/lib/python2.1/site-packages/scipy/linalg/fblas.so: undefined
> symbol: srotmg_
> ----------------------------------------------------------------------
> Ran 447 tests in 2.017s
> 
> FAILED (errors=2)
> <unittest.TextTestRunner instance at 0x853506c>
> >>>
> 
> grepping the output of nm, I found "srotmg" back in the ATLAS libraries
> on another machine but not in the standard LAPACK/BLAS libraries.

Hmm, where did you get the BLAS libraries? srotmg _is_ in the standard
BLAS, see
  http://www.netlib.org/blas/srotmg.f

However, the BLAS included to the standard LAPACK does not contain
srotmg.f. I have not checked if there are other BLAS functions that are
missing in LAPACK but probably there are.

So, what are the suggestions if ATLAS is not available:
1) to require the standard BLAS and the standard LAPACK?
2) or to require the standard LAPACK with the included but incomplete
BLAS?

I would prefer (1) because linalg claims to have wrappers to the BLAS
routines. However, if it is common that distributors provide only
incomplete BLAS, we can consider (2) or let users to complain to
distributors.

What do you think?

Pearu




From gvermeul at polycnrs-gre.fr  Tue May 28 03:27:07 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Tue, 28 May 2002 09:27:07 +0200
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <Pine.LNX.4.21.0205280045160.17569-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205280045160.17569-100000@cens.ioc.ee>
Message-ID: <200205280727.g4S7RCe25478@polycnrs-gre.fr>

On Tuesday 28 May 2002 00:02, Pearu Peterson wrote:
> >
> > grepping the output of nm, I found "srotmg" back in the ATLAS libraries
> > on another machine but not in the standard LAPACK/BLAS libraries.
>
> Hmm, where did you get the BLAS libraries? srotmg _is_ in the standard
> BLAS, see
>   http://www.netlib.org/blas/srotmg.f
>
> However, the BLAS included to the standard LAPACK does not contain
> srotmg.f. I have not checked if there are other BLAS functions that are
> missing in LAPACK but probably there are.
>
Yes, indeed I have the BLAS that comes with the standard LAPACK.
>
> So, what are the suggestions if ATLAS is not available:
> 1) to require the standard BLAS and the standard LAPACK?
> 2) or to require the standard LAPACK with the included but incomplete
> BLAS?
>
> I would prefer (1) because linalg claims to have wrappers to the BLAS
> routines. However, if it is common that distributors provide only
> incomplete BLAS, we can consider (2) or let users to complain to
> distributors.
>
> What do you think?
>
Or fixing up BLAS in the way you suggested masking the "post-update
LAPACK routine". Maybe getinfo("blas") can peek into BLAS (using nm) to
see what is available and provide a list of extra fortran sources to
be compiled and are included with SciPy. If you like I can start to look
for them, tonight.

So, it boils down to being most user-friendly: meaning (2), but providing all 
functionality of (1) behind the user's back.

Maybe, we should inform the LAPACK authors/packagers of the missing blas
functionality?

Regards -- Gerard


From gvermeul at polycnrs-gre.fr  Tue May 28 03:41:55 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Tue, 28 May 2002 09:41:55 +0200
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <03fe01c205c0$9d219a40$d2566a42@ericlaptop>
References: <200205272139.g4RLdHe18178@polycnrs-gre.fr> <03fe01c205c0$9d219a40$d2566a42@ericlaptop>
Message-ID: <200205280742.g4S7g0e27444@polycnrs-gre.fr>

Hi Eric,

true, that I am mixing builds of CVS sources, downloaded tarballs and
DIY generated tarballs from CVS, but as far as I can see: weave
is in the SciPy tarball, so it should be rebuild on a full rebuild, isn't it?

I really think the problem comes from the standard LAPACK provided
BLAS.

Gerard

On Monday 27 May 2002 22:53, eric wrote:
> Hey Gerard,
>
> Not sure why weave linked anything against fblas, but I am pretty sure that
> this error occured only because you had previously built/tested SciPy with
> weave. Try deleting the .python_compiled directory in your home directory
> to get rid of any old compiled files.  If that doesn't solve the problem,
> also delete /tmp/python2x_intermediate where x is the version you are
> testing.
>
> eric
>


From pearu at cens.ioc.ee  Tue May 28 03:55:04 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 28 May 2002 10:55:04 +0300 (EEST)
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <200205280727.g4S7RCe25478@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205281038380.17569-100000@cens.ioc.ee>

On Tue, 28 May 2002, Gerard Vermeulen wrote:

> On Tuesday 28 May 2002 00:02, Pearu Peterson wrote:
<snip>
> > So, what are the suggestions if ATLAS is not available:
> > 1) to require the standard BLAS and the standard LAPACK?
> > 2) or to require the standard LAPACK with the included but incomplete
> > BLAS?
> >
> > I would prefer (1) because linalg claims to have wrappers to the BLAS
> > routines. However, if it is common that distributors provide only
> > incomplete BLAS, we can consider (2) or let users to complain to
> > distributors.
> >
> > What do you think?
> >
> Or fixing up BLAS in the way you suggested masking the "post-update
> LAPACK routine". Maybe getinfo("blas") can peek into BLAS (using nm) to
> see what is available and provide a list of extra fortran sources to
> be compiled and are included with SciPy. If you like I can start to look
> for them, tonight.

Unfortunately it is not that easy. This information is needed already 
in interface_gen.py that generates the *.pyf files. It is always possible
to add additional hooks but I would prefer that these hooks would be
as simple as possible.
Another concern is with win32 platform - is there nm equivalent easily
available?

> So, it boils down to being most user-friendly: meaning (2), but providing all 
> functionality of (1) behind the user's back.
> 
> Maybe, we should inform the LAPACK authors/packagers of the missing blas
> functionality?

I think so too. Please, do that.

Regards,
	Pearu





From pearu at cens.ioc.ee  Tue May 28 04:17:04 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 28 May 2002 11:17:04 +0300 (EEST)
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <Pine.LNX.4.21.0205281038380.17569-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.21.0205281110310.4850-100000@cens.ioc.ee>

On Tue, 28 May 2002, Pearu Peterson wrote:

> 
> On Tue, 28 May 2002, Gerard Vermeulen wrote:
> 
> > On Tuesday 28 May 2002 00:02, Pearu Peterson wrote:
> <snip>
> > > So, what are the suggestions if ATLAS is not available:
> > > 1) to require the standard BLAS and the standard LAPACK?
> > > 2) or to require the standard LAPACK with the included but incomplete
> > > BLAS?
> > >
> > > I would prefer (1) because linalg claims to have wrappers to the BLAS
> > > routines. However, if it is common that distributors provide only
> > > incomplete BLAS, we can consider (2) or let users to complain to
> > > distributors.
> > >
> > > What do you think?
> > >
> > Or fixing up BLAS in the way you suggested masking the "post-update
> > LAPACK routine". Maybe getinfo("blas") can peek into BLAS (using nm) to
> > see what is available and provide a list of extra fortran sources to
> > be compiled and are included with SciPy. If you like I can start to look
> > for them, tonight.
> 
> Unfortunately it is not that easy. This information is needed already 
> in interface_gen.py that generates the *.pyf files. It is always possible
> to add additional hooks but I would prefer that these hooks would be
> as simple as possible.

Actually we can (i) factor out BLAS routines that are not included in
LAPACK, (ii) put them into a separate .pyf file, (iii) include this file
to generic_fblas.pyf, and (iv) let users comment out the corresponding
include statement if they have an incomplete BLAS. 
How this sounds? End users need to learn only the last step, of course.

Pearu



From gvermeul at polycnrs-gre.fr  Tue May 28 04:32:26 2002
From: gvermeul at polycnrs-gre.fr (Gerard Vermeulen)
Date: Tue, 28 May 2002 10:32:26 +0200
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <Pine.LNX.4.21.0205281110310.4850-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0205281110310.4850-100000@cens.ioc.ee>
Message-ID: <200205280832.g4S8WVe02103@polycnrs-gre.fr>

On Tuesday 28 May 2002 10:17, Pearu Peterson wrote:
> >
> > <snip>
> >
> > > > So, what are the suggestions if ATLAS is not available:
> > > > 1) to require the standard BLAS and the standard LAPACK?
> > > > 2) or to require the standard LAPACK with the included but incomplete
> > > > BLAS?
> > > >
> > > > I would prefer (1) because linalg claims to have wrappers to the BLAS
> > > > routines. However, if it is common that distributors provide only
> > > > incomplete BLAS, we can consider (2) or let users to complain to
> > > > distributors.
> > > >
> > > > What do you think?
> > >
> > > Or fixing up BLAS in the way you suggested masking the "post-update
> > > LAPACK routine". Maybe getinfo("blas") can peek into BLAS (using nm) to
> > > see what is available and provide a list of extra fortran sources to
> > > be compiled and are included with SciPy. If you like I can start to
> > > look for them, tonight.
> >
> > Unfortunately it is not that easy. This information is needed already
> > in interface_gen.py that generates the *.pyf files. It is always possible
> > to add additional hooks but I would prefer that these hooks would be
> > as simple as possible.
>
> Actually we can (i) factor out BLAS routines that are not included in
> LAPACK, (ii) put them into a separate .pyf file, (iii) include this file
> to generic_fblas.pyf, and (iv) let users comment out the corresponding
> include statement if they have an incomplete BLAS.
> How this sounds? End users need to learn only the last step, of course.
>
Not bad, but I will need to take a look at your code to understand exactly
what you are proposing. It would be even nicer if it can be more automatic.

I will try to send a message to the LAPACK authors.

Gerard


From pearu at cens.ioc.ee  Tue May 28 04:37:07 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 28 May 2002 11:37:07 +0300 (EEST)
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
In-Reply-To: <200205280832.g4S8WVe02103@polycnrs-gre.fr>
Message-ID: <Pine.LNX.4.21.0205281133390.4850-100000@cens.ioc.ee>


On Tue, 28 May 2002, Gerard Vermeulen wrote:

> I will try to send a message to the LAPACK authors.

I am not sure that LAPACK is to blame as it includes only BLAS routines
that it needs, nothing wrong with that.

Pearu



From eric at enthought.com  Tue May 28 23:33:42 2002
From: eric at enthought.com (eric)
Date: Tue, 28 May 2002 23:33:42 -0400
Subject: SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install
References: <Pine.LNX.4.21.0205242131020.12590-100000@cens.ioc.ee>
Message-ID: <077401c206c1$a1fdba10$d2566a42@ericlaptop>

> Pearu wrote:
>
> On Thu, 23 May 2002, eric wrote:
> >
> > I agree.  SciPy is starting to mature enough where non-geeks should be able
to
> > install it.  ATLAS is definitely the biggest hurdle.  We could distribute
the
> > SciPy tarballs with f2py rolled in so that Python and Numeric were the only
> > dependencies (and we *could* roll Numeric in to get rid of it as a
dependency,
> > but it made some unhappy in the SciPy-0.1 release).  This assumes people
have a
> > lapack and blas on their system (is this standard)?
>
> I agree with Gerard. Many linux distributions already provide Numeric and
> shipping it with SciPy may break local installations. For Windows
> platforms things may be different. I guess majority of non-geeks
> use Windows and there shipping everything in one package may be a
> good idea. On the other hand, most Linux users should be geeks already so
> that they should be able to hit few make commands to install few extra
> packages that SciPy needs.

I think I agree with this on the Linux side.  On windows, we might have a
"plain" and "with peanuts" version.  It all comes down to the logistics of
maintaining/building so many different versions.  When you bundle things
together, it is easier to test, and easier to predict the end users experience.
As an example, things like the compatibility issue of MSVC and GCC can cause
real problems.  Distributing a gcc compiled Numeric with SciPy on Windows solves
this.  Travis O. has repeatedly figured out work arounds for this one, so
hopefully it is solved, but others undoubtedly still exist.

>
> Ideally, we should let Linux distributors or their users to deal with
> SciPy dependencies. It seems that other larger projects use similar
> approach.

Yes. We should be shooting to have SciPy pre-installed on distributions.  I
haven't thought about what this entails at all -- there are pluses and minuses
for such a quickly changing project.  At some point, we should try to define a
PEP-like document with a feature list in it for the 1.0 distribution.  This'll
have to be slated for later as more pressing things exist right now.

>
> BTW, I wonder what lawyers say if LGPL'ed f2py is rolled in to SciPy? I
> hope it is not a problem.

I have thought about this.  I view f2py in slightly different light as I do
components of the library because it is a tool required to build SciPy, not a
package users will have in their application if the choose to use SciPy.  As a
result, SciPy based applications are not bound by the f2py license. Only
applications that choose to incorporate f2py into them would be bound by the
license.  This seems logical to me, but perhaps I am wrong about this.  If I am,
we'll need to leave them separate.

I don't feel the same way about things like IPython, MayaVi, or any algorithms
because these are definitely components that people will incorporate into their
SciPy based application (especially MayaVi, but IPython also).

>
> > There are several solutions to the ATLAS issue:
> >
> >     1. Supply ATLAS binaries for the common platforms.
> >     2. Make the setup.py script work with the
> >        standard lapack and blas impelementation.
> >
> > We are likely to supply some ATLAS binaries, but (1) is probably a bigger
task
> > than I want to deal with.
>
> (2) was already in my TODO list ;)

And, by the looks of the checkin list, you've already done it. Thanks.

>
> > As far as (2), there are currently two reasons we link to ALTAS.  The first
is
> > speed.  The 2nd is that it has C versions of most of the interfaces which
> > theoretically should be faster because they don't require a memory transpose
> > before matrix operations.  There is probably some benefit to this on the
faster
> > operations, but Pearu's test have shown that the commonly used matrix
> > factorizations (order N^3) overshadow the transpose time enough to make it
> > negligible.
>
> To be exact, transposing a large matrix in-situ is quite an expensive and
> nontrivial operation (one must swap elements that are very
> far from each other in memory). However, transposing a matrix by
> just copying it to another matrix is very fast but twice more memory is
> used.
>
> If N is few thousand or less, then memory usage is not really a big issue.
> For example, 1000x1000 and 3000x3000 double arrays take approximately 7MB
> and 70MB, respectively. (I assume that 512MB RAM is standard nowadays.)
>
> However, if N is larger, then the computer memory must be used carefully
> and special consideration is required anyway, whether the transposition is
> carried out in-situ or by copying. And here the C interface to ATLAS
> may become important.
>
> > It is probably a reasonable question whether the C interfaces are
> > really that important.  The speed issue really isn't that big of a deal.
People
> > who want speed can use ATLAS.  Others can link to the standard LAPACK and
BLAS
> > libraries (which still take 10 or so minutes to build).
>
> I agree. Having the C interfaces around is useful only if there is a
> memory issue.

Lets keep them.  Your packaging in linalg makes the fail over to flapack
completely transparent, so the only cost is maintaining the code.  That may not
be a small cost though -- these wrappers definitions are pretty dang complex
now.  I saw that you split the Fortran and C wrappers files at some point.  I
had really wanted to avoid this to help with maintainability but assume it was
done to handle the callstatement() stuff.  I do wish they were still unified.
Do you think it might be possible to introduce a <c_section> and <f_section> tag
to our interface_gen generic scripts to include specific sections in the
generated interface files depending on the target language?

>
> > On a side note, has anyone built against non ATLAS libraries?  Are there any
> > issues to watch out for?
>
> I expect it to be very smooth after system_info can detect Fortran
> BLAS/LAPACK libraries and setup_linalg starts to use them if atlas is not
> available as you suggested.

very good.

Thanks, Pearu, for smoothing the linear algebra installation issues out.

eric




From eric at enthought.com  Tue May 28 23:45:18 2002
From: eric at enthought.com (eric)
Date: Tue, 28 May 2002 23:45:18 -0400
Subject: [SciPy-user] testing SciPy without ATLAS ;-(
References: <200205272139.g4RLdHe18178@polycnrs-gre.fr> <03fe01c205c0$9d219a40$d2566a42@ericlaptop> <200205280742.g4S7g0e27444@polycnrs-gre.fr>
Message-ID: <078e01c206c3$40c95180$d2566a42@ericlaptop>

Hey Gerard,

> Hi Eric,
>
> true, that I am mixing builds of CVS sources, downloaded tarballs and
> DIY generated tarballs from CVS, but as far as I can see: weave
> is in the SciPy tarball, so it should be rebuild on a full rebuild, isn't it?

It is, but in the testsing phase, weave generates extension modules of the
tested code snippets and places them in .python_compiled for future use.  The
next time weave sees this code snippet, it checks .python_compiled to see if the
code is already compiled. If so, it loads the appropriate shared library and
executes the pre-compiled function without having to re-compile.  I have tried
to make the test cleaned up after themselves so that later tests always have to
re-compile code (and thus test weave), but it proved tricky (and impossible on
windows...  I couldn't delete a dll file when it is in use).  I don't remember
the final mechanism I used, but it is possible some tests may slip through the
cracks leaving your freshly compiled SciPy to pick up a weave compiled module
from a past scipy.test(10) statement.  This is all slightly confusing, I know.

>
> I really think the problem comes from the standard LAPACK provided
> BLAS.

Very good.  Then ignore the above... :)

eric





From postmaster at asiab2bonline.com  Wed May 29 01:27:14 2002
From: postmaster at asiab2bonline.com (postmaster at asiab2bonline.com)
Date: Wed, 29 May 2002 13:27:14 +0800
Subject: [SciPy-user] MDaemon Warning - Virus Found
Message-ID: <MDAEMON84718471200205291327.AA2714026@asiab2bonline.com>

The following message had attachment(s) which contained viruses:

>From      : scipy-user at scipy.net
To        : loryxu at 263.net
Subject   : Japanese girl VS playboy
Date      : 
Message-ID: 

Attachment                    Virus name               Action taken
------------------------------------------------------------------------------
cf1949426207.att              Exploit.IFrame.FileDownloadRemoved
Hro.bat                       I-Worm.Klez.h            Removed