[SciPy-dev] Re: scipy / SGI MIPSpro compiler (part 3)

[Pearu]

Steve,

On Sat, 24 Aug 2002, Steve M. Robbins wrote:

> On Sat, Aug 24, 2002 at 05:03:19PM -0500, Pearu wrote:

> > Actually there is no exception raised. Only the exception message is shown 
> > as a warning of missing cblas. cblas (and clapack) is build only if ATLAS 
> > is available. 
> 
> Oh.  So you're saying that both "No module named clapack" and "No
> module named cblas" came from a single warning message, and that I
> simply mis-parsed them as two?

No. When running tests then there were also the same warnings for clapack.
I see no problem here, though.

> > Could you get the latest 
> > f2py from CVS and run the following tests:
> > 
> > cd f2py2e && python setup.py install
> 
> This bombed with a message about scipy_distutils missing.
> I made a symlink scipy_distutils -> ../scipy-cvs/scipy_distutils
> where the scipy-cvs directory holds scipy checked out from
> CVS within the last day or so.  Is this OK?

That is OK. Normally scipy_distutils is shipped also with f2py. To install 
scipy, one needs f2py first. f2py installs f2py2e and scipy_distutils 
packages. And then scipy re-installs scipy_distutils. 

> Incidentally, it looks like f2py installs scipy_distutils itself.  
> Am I right?  If so, is there a way to inhibit this?

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.

> 
> > cd f2py2e/tests/f77
> > python return_integer.py --quiet
> 
> Sadly, this failed.  Here is the non-quiet output from 
> "python return_integer.py 2>&1":
> 
> 
> cc-3303 cc: WARNING File = /tmp/@425198.0/ext_return_integermodule.c, Line = 179
>   A type qualifier on a return type is meaningless.
> 
>                              const void (*f2py_func)(int*,int*)) {
>                                           ^

These warnings are now fixed.

> Traceback (most recent call last):
>   File "return_integer.py", line 99, in ?
>     runtest(t)
>   File "return_integer.py", line 56, in runtest
>     assert t(-123)==-123
> AssertionError
> 
> 
> 
> I ran the test "t(-123)" by hand, and it is only the "t1"
> version that fails:
> 
> 	>>> t1(-123)
> 	133
> 
> So the integer*1 is unsigned, perhaps?  The SGI cc manual says "The
> default is to treat values of type char as if they had type unsigned
> char".  I guess the generated code should use "signed char".

Yes, fixed in f2py CVS.
 
> > python return_real.py --quiet
> 
> This time I got a bus error from python.  :-(
> Running the tests manually, I find that 
> 
> 	abs(t([234])-234)<=err
> 
> with t=t0 is the first test that coredumps.

This is known bug with SGI compilers (when using optimization flags) and 
Python 2.1. See

http://sourceforge.net/tracker/index.php?func=detail&aid=435026&group_id=5470&atid=105470

I have worked around this bug for f2py and SGI.

> > python return_complex.py --quiet
> 
>     try: raise RuntimeError,`t(10l**400)`
> RuntimeError: (inf+0j)

Fixed.

> > python return_character.py --quiet

> Traceback (most recent call last):
>   File "return_character.py", line 62, in ?
>     runtest(t)
>   File "return_character.py", line 50, in runtest
>     assert t(array(77))=='M'
> AssertionError

Fixed.

> Both t0(array(77)) and t1(array(77)) return ''.
> 
> 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?

Thanks for the bug reports. I believe they are all fixed now in f2py CVS. 
Could you verify that?

Thanks,
	Pearu