From: Robert K. <rk...@uc...> - 2005-09-26 02:59:21
|
Gerard Vermeulen wrote: > On Sat, 24 Sep 2005 22:51:27 -0600 > Travis Oliphant <oli...@ee...> 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 rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter |