[Numpy-discussion] Release of scipy core beta will happen next week.

[Robert Kern]

Gerard Vermeulen wrote:
> On Sat, 24 Sep 2005 22:51:27 -0600
> Travis Oliphant <oliphant at ee.byu.edu> wrote:
> 
>>At the SciPy 2005 conference I announced that I was hoping to get a beta 
>>of the new scipy (core) (aka Numeric3 aka Numeric Next Generation) 
>>released by the end of the conference.  
>>
>>This did not happen.  Some last minute features were suggested by 
>>Fernando Perez that I think will be relatively easy to add and make the 
>>release that much stronger. 
>>
>>Look for the beta announcement next week.
>>
>>For the impatient,  the svn server is always available:
>>
>>http://svn.scipy.org/svn/scipy_core/branches/newcore
>  
> Hi Travis,
> 
> when I tried a few months ago to compile one of my C++ Python modules with
> Numeric3, g++-3.4.3 choked on the line
> 
> typedef unsigned char bool;
> 
> in arrayobject.h, because bool is a predefined type in C++.
> 
> I see the offending line is still in SVN (did not try to build it though).

Will this do the trick?

#ifndef __cplusplus
typedef unsigned char bool;
#define false 0
#define true 1
#endif /* __cplusplus */

> Sorry for sitting on the bug so long;  the main reason is that at the time
> (I suppose it is still the case) Numeric3 does not coexist well with
> Numeric in the same Python interpreter (I remember import conflicts).
> If a typical Linux user wants to play with Numeric3, he has either to remove
> Numeric (and break possible dependencies) or build his own Python for Numeric3.
> I think that most Linux users are not going to do this and that it will take more
> than a year before distros make the move.  Hence, my lack of motivation for
> reporting bugs or giving it a real try.

scipy_core does not interfere with Numeric anymore. It's installed as
scipy (so it *will* interfere with previous versions of scipy).

While we're on the subject of bugs (for reference, I'm on OS X 10.4 with
Python 2.4.1):

* When linking umath.so, distutils is including a bare "-l" that causes
the link to fail (gcc can't interpret the argument). I have no idea
where it's coming from. Just after the Extension object for umath.so is
created, the libraries attribute is empty, just like the other Extension
objects.

* When linking against Accelerate.framework, it can't find cblas.h . I
have a patch in scipy.distutils.system_info for that (and also to remove
the -framework arguments for compiling; they're solely linker flags).

* setup.py looks for an optimized BLAS through blas_info, but getting
lapack_info is commented out. Is this deliberate?

* Despite comment lines claiming the contrary, scipy.linalg hasn't been
converted yet. basic_lite.py tries to import lapack and flapack.

* scipy.base.limits is missing (and is used in basic_lite.py).

Feature request:

* Bundle the include directory in with the package itself and provide a
function somewhere that returns the appropriate directory. People
writing setup.py scripts for extension modules that use scipy_core can
then do the following:

    from scipy.distutils import get_scipy_include
    ...
    someext = Extension('someext', include_dirs=[get_scipy_include(),
                                                 ...], ...)

This would help people who can't write to
sys.prefix+'/include/python2.4' and people like me who are trying to
package scipy_core into a PythonEgg (which doesn't yet support
installing header files to the canonical location).

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter