Mailman 3 December 2007 - SciPy-Dev

scipy.scons branch: building numpy and scipy with scons
by David Cournapeau Dec. 4, 2007

Dec. 4, 2007

Hi, I've just reached a first usable scipy.scons branch, so that scipy can be built entirely with scons (assuming you build numpy with scons too). You can get it from http://svn.scipy.org/svn/scipy/branches/scipy.scons. To build it, you just need to use numpy.scons branch instead of the trunk, and use setupscons.py instead of setup.py. Again, I would be happy to hear about failures, success (please report a ticket in this case), etc... Some of the most interesting things I can think of which work with scons: - you can control fortran and C flags from the command line: CFLAGS and FFLAGS won't override necessary flags, only optimization flags, so you can easily play with warning, optimization flags. For example: CFLAGS='-W -Wall -Wextra -DDEBUG' FFLAGS='-DDEBUG -W -Wall -Wextra' python setupscons build for debugging will work. No need to care about -fPIC and co, all this is handled automatically. - dependencies are handled correctly thanks to scons: for example, if you change a library (e.g. by using MKL=None to disable mkl), only link step will be redone. platforms known to work ----------------------- - linux with gcc/g77 or gcc/gfortran (both atlas and mkl 9 were tested). - linux with intel compilers (intel and gnu compilers can also be mixed, AFAIK). - solaris with sun compilers with sunperf, only tested on indiana. Notable non working things: --------------------------- - using netlib BLAS and LAPACK is not supported (only optimized ones are available: sunperf, atlas, mkl, and vecLib/Accelerate). - parallel build does NOT work (AFAICS, this is because f2py which do some things which are not thread-safe, but I have not yet found the exact problem). - I have not yet implemented umfpack checker, and as such umfpack cannot be built yet - I have not yet tweaked fortran compiler configurations for optimizations except for gnu compilers - c++ compilers configurations are not handled either. cheers, David

1 0

test_mio.py
by Nils Wagner Dec. 4, 2007

Dec. 4, 2007

Hi all, python test_mio.py yields Traceback (most recent call last): File "/data/home/nwagner/local/lib64/python2.3/site-packages/scipy/io/tests/test_mio.py", line 25, in ? class TestMIOArray(NumpyTestCase): File "/data/home/nwagner/local/lib64/python2.3/site-packages/scipy/io/tests/test_mio.py", line 235, in TestMIOArray format = case in case_table4 and '4' or '5' ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() I am using python2.3 and the latest svn. Nils

1 0

How to regenerate swig generated files ?
by David Cournapeau Dec. 4, 2007

Dec. 4, 2007

Hi, I encounter a relatively trivial build bug in sparsetools (ticket 549), which requires regenerating the sources by swig. I would like to know which version should be used, and which options ? It would be good to have those options noted somewhere, I think. As an aside, it would be good also if the source file could be split into several compilation units: a 3 Mb C++ source file is extremely heavy (compiling it with g++ and -O2 takes up to 400 Mb of ram, this is not pleasant when compiling scipy on virtual machines). cheers, David

2 2

scipy 0.6.0 tests kill python interpreter
by Ondrej Certik Dec. 3, 2007

Dec. 3, 2007

Hi, if I install scipy 0.6.0 on Debian and run tests, it kills the interpreter with Illegal instruction. More details here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452991 Is anyone able to reproduce it on their system, or is it just related to Debian? Could you please send me the correct run of tests, so that I can discover where exactly it differs? Thanks a lot, Ondrej

2 5

Re: [SciPy-dev] what the heck is an egg ;-)
by Joe Harrington Dec. 1, 2007

Dec. 1, 2007

> setup.py and using distutils is not novel: this is the standard way to > distribute python packages to be built for years (distutils was included > in python in 2000, 2001 ?). Well, it's a matter of perspective, and the perspective I take is that of a new user to Python, or even a non-Python-using system manager who is installing numpy and friends for others to use. To them, *anything* that is not a tar.gz, RPM, or Deb is novel, and most would not dare to use even an un-novel tar.gz in their OS directories. Then we say, here, execute this setup.py as root, it's code for an interpreted language and you have no idea what it will do. Well, that's pretty terrifying, especially to the security-conscious. I know almost nothing about eggs. I see them being used for all the Enthought code, which provides the de facto standard 3D environment, mayavi2. What's a numerical package without a 3D environment? While that's not on scipy.org, it's darn close, and necessary for an environment that competes with IDL or Matlab. I agree that the correct path is to push everything into binary installs, even the experimental stuff. I love the OS installers, and I thank the packagers from the bottom of my heart! If only there were more of them, and if only they could handle more of these packages. The OS installers may not deal with multiple package version on Linux, but I have never wanted more than one version. Someone who does is probably a developer and can handle the tar installs, eggs, or whatever, and direct Python to find the results. I believe that we would double our community's size if all our major packages were available in binary installs for all major platforms. But, a plethora of packagers is not our situation. It would help the inexperienced (including the aforementioned system manager, who will never be experienced in Python) to have some plain talk about what these Python-specific installers do, and how to use them to install, uninstall, and automatically update. It can probably be knocked off in about a page per installer, but it has to be done by someone who knows them well. --jh--

4 3

what the heck is an egg ;-)
by Joe Harrington Dec. 1, 2007

Dec. 1, 2007

A lot of the add-on software for numpy/scipy is distributed using novel Python install processes (eggs, setup.py) rather than tarballs or the preferred OS-native installers (dpkg, rpm, etc.). I'm sure they are described, perhaps even well, in other places, but, since scipy.org is our portal, I think it would be good to have a few-line description of each method on the Download page and a link to more detailed descriptions elsewhere (or on subsidiary pages). An example of installing a package many will want, like mayavi2, would be great. In particular, many sysadmins (who might be considering a user's request for an install and know nothing about python) get nervous when package managers other than the native one for the OS start mucking around in the system directories, and are hesitant to use something like eggs. Some statements describing what they do and where they put stuff would be good (like, a guarrantee that they only tread in certain directories). How to update and how to completely remove a package would be good. Is there a way to have them check periodically for updates? Of course, a statement near the top of why these methods are used rather than the native OS installers would help a lot. Thanks, --jh--

3 2