Gerard Vermeulen wrote:

On Sat, 24 Sep 2005 22:51:27 -0600 Travis Oliphant 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@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter