[SciPy-dev] Re: scipy / SGI MIPSpro compiler (part 3)
Steve M. Robbins
steven.robbins at videotron.ca
Sun Aug 25 10:26:48 CDT 2002
Thanks so much for the f2py patches. All the tests/f77 are now "ok".
I've installed the new f2py and am now rebuilding scipy to see if
some of the latter's problems go away ...
On Sun, Aug 25, 2002 at 06:30:58AM -0500, Pearu wrote:
> Yes, you are right. f2py and scipy_distutils are developed very closely,
> so usually there is no problem if either scipy or f2py installs
> scipy_distutils, just make sure that you have the latest scipy_distutils
> from scipy CVS. I also use symlink from scipy to f2py2e directory while
> working with the codes. However, if you really want to stop f2py to
> re-installing scipy_distutils, then you must edit f2py2e/setup.py.
This is fine when working with both sources from CVS, but how about
the binary packages of f2py and scipy?
One of the other hats I wear is "Debian developer", and I'm interested
in getting a package of scipy in Debian. [And f2py, since scpiy
requires it to build.] Joe Reinhardt has made some experimental
packages, but they have not yet been uploaded to Debian proper.
It is possible to have the f2py and scipy packages both install
scipy_distutils, but this is a nuisance. I would be worried that at
some point the packages' copies get out of sync, and that installing
"f2py" would cause "scipy" to stop working, or vice-versa.
I can think of two ways to uncouple the two packages. One is to
have f2py install/use the distutils under a different name, e.g.
f2py_distutils. The other way is to split out scipy_distutils into
a seperately-installable package that would be a prerequisite for
both scipy and f2py.
I realise that either solution causes work for you, and that binary
packaging isn't your primary concern at the moment. However, I thought
I'd test the waters to see whether decoupling the packages is at all
feasible. Perhaps there are other options that I'm overlooking.
> > There may be some other weirdness going on. While running some of
> > the "return_character.py" tests by hand, I had the python process
> > killed by the system, with a note in the syslog:
> > Aug 24 20:48:14 1A:wart unix: |$(0x6dd)ALERT: Process [python] 428471 generated trap, but has signal 11 held or ignored
> > Aug 24 20:48:14 6A:wart unix: epc 0xfa3a38c ra 0xfa3abd4 badvaddr 0x4973f130
> > Aug 24 20:48:14 6A:wart unix: Process has been killed to prevent infinite loop
> > Aug 24 20:49:10 1A:wart unix: |$(0x6dd)ALERT: Process [python] 428406 generated trap, but has signal 11 held or ignored
> > Aug 24 20:49:10 6A:wart unix: epc 0xfa3a38c ra 0xfa3abd4 badvaddr 0x4973f180
> > Aug 24 20:49:10 6A:wart unix: Process has been killed to prevent infinite loop
> > This diagnostic is a new one to me.
> Hmm, can you reproduce this one and send the details to me?
Unfortunately, it was one of those transient bugs. I was running
python interactively and the process got killed at different times.
Sometimes after I had just typed in something innocuous like "t=t1".
I may have a look again later today, but in reality now that f2py
is working, it is not high on my priority list.
More information about the Scipy-dev