Gustavo Goretkin | 1 Aug 2011 02:16
Picon
Gravatar

setup.py develop

Hey Devs,

I'm making some tiny local changes to SciPy and I'd like to install it in virtualenv using setup.py develop (as opposed to setup.py install) as I've done for other projects. What's the way to do this for SciPy?

Thanks,
Gustavo

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Ralf Gommers | 1 Aug 2011 18:31
Gravatar

Re: setup.py develop



On Mon, Aug 1, 2011 at 2:16 AM, Gustavo Goretkin <gustavo.goretkin <at> gmail.com> wrote:
Hey Devs,

I'm making some tiny local changes to SciPy and I'd like to install it in virtualenv using setup.py develop (as opposed to setup.py install) as I've done for other projects. What's the way to do this for SciPy?

Thanks,
Gustavo
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev


_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Fernando Perez | 3 Aug 2011 09:40
Picon
Gravatar

Re: [ANN] IPython 0.11 is officially out

On Sun, Jul 31, 2011 at 10:19 AM, Fernando Perez <fperez.net <at> gmail.com> wrote:

> Please see our release notes for the full details on everything about
> this release: https://github.com/ipython/ipython/zipball/rel-0.11

And embarrassingly, that URL was for a zip download instead
(copy/paste error), the detailed release notes are here:

http://ipython.org/ipython-doc/rel-0.11/whatsnew/version0.11.html

Sorry about the mistake...

Cheers,

f
Benjamin Root | 4 Aug 2011 03:31
Picon
Favicon

Re: setup.py develop

On Mon, Aug 1, 2011 at 11:31 AM, Ralf Gommers <ralf.gommers <at> googlemail.com> wrote:


On Mon, Aug 1, 2011 at 2:16 AM, Gustavo Goretkin <gustavo.goretkin <at> gmail.com> wrote:
Hey Devs,

I'm making some tiny local changes to SciPy and I'd like to install it in virtualenv using setup.py develop (as opposed to setup.py install) as I've done for other projects. What's the way to do this for SciPy?


Just a quick question... how are the two commands:

python setup.py build_ext -i
python setupegg.py develop --prefix=${HOME}

different from just simply doing:

python setupegg.py develop --user

besides from the obvious that the final location is slightly different (with --user, the location on more recent linuxes is ~/.local).

Thanks,
Ben Root

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Ralf Gommers | 4 Aug 2011 19:11
Gravatar

Re: setup.py develop



On Thu, Aug 4, 2011 at 3:31 AM, Benjamin Root <ben.root <at> ou.edu> wrote:
On Mon, Aug 1, 2011 at 11:31 AM, Ralf Gommers <ralf.gommers <at> googlemail.com> wrote:


On Mon, Aug 1, 2011 at 2:16 AM, Gustavo Goretkin <gustavo.goretkin <at> gmail.com> wrote:
Hey Devs,

I'm making some tiny local changes to SciPy and I'd like to install it in virtualenv using setup.py develop (as opposed to setup.py install) as I've done for other projects. What's the way to do this for SciPy?


Just a quick question... how are the two commands:

python setup.py build_ext -i
python setupegg.py develop --prefix=${HOME}

different from just simply doing:

python setupegg.py develop --user

besides from the obvious that the final location is slightly different (with --user, the location on more recent linuxes is ~/.local).

--user is not documented (http://packages.python.org/distribute/setuptools.html#develop-deploy-the-project-source-in-development-mode), so I'm not sure. But of these three options I prefer "python setup.py build_ext -i" since that's the only one that doesn't invoke setuptools/distribute. That's a useful feature...

Ralf

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
josef.pktd | 6 Aug 2011 10:12
Picon

documenting scipy.special functions

This came up in https://github.com/scipy/scipy/pull/52

Josef:
One more comment about scipy.special docstrings: From what I have seen
they are semiautomatically created. I think eventually we should
switch to docstrings following the numpy standard. There are several
functions where I would have liked to add more information. The
current docstrings of many special functions are awfully uninformative
about details.

Chris:
As for the comments...that's actually not as simple as it sounds. Or
at least it wasn't. I just submitted a pull request to numpy to help
change that. ufuncs are python objects whose docstrings are read-only.
They are set at object creation. The either (1)must be passed in to
the C function creating the ufunc (at which point you have to have the
docs in some C header file or parse them in from a Python header file
with the docs), or (2) you must reset what the ufunc doc pointer
points to at the C level. The add_newdoc method doesn't work on
ufuncs. (And in fact there are a number of calls to add_newdoc in
numpy/add_newdocs.py that don't change the documentation. It isn't
noticed because add_newdoc specifically catches all errors and does
nothing.)
---

Is it possible to improve the docstring for the scipy.special
functions (in the long run)?

I'm just a consumer of scipy.special, but every once in a while I
would like to add some information to special functions.

for some it looks possible to edit (and bring them to numpy standard),
e.g. http://docs.scipy.org/scipy/docs/scipy.special.orthogonal.hermite/#hermite

others, for example
http://docs.scipy.org/scipy/docs/scipy.special._cephes.pdtr/#pdtr ,
cannot be edited, but there is a lot of information hidden in the
fortran files, if one looks for it long enough.

Josef
Jordi Gutiérrez Hermoso | 7 Aug 2011 22:26
Gravatar

ARPACK situation

(Mass email, please hit reply-all to keep everyone abreast of the
situation. May get some bounces from mailing lists.)

I'm writing this email to discuss the future of ARPACK. The problem is
this: it's a widely-used library, but it seems abandoned upstream (and
upstream, to whom this is addressed, can confirm or deny). This has
resulted in the problem of many mini-forks as each organisation
distributes ARPACK patches its own way, and very often, for the same
bugs. These are the ones I could find:

     http://hg.savannah.gnu.org/hgweb/octave/file/tip/libcruft/arpack/
     http://patch-tracker.debian.org/package/arpack/2.1+parpack96.dfsg-3
     https://github.com/inducer/arpack
     http://mathema.tician.de/software/arpack
     http://dev.gentoo.org/~bicatali/
     http://pkgs.org/centos-5-rhel-5/epel-x86_64/arpack-2.1-13.el5.x86_64.rpm.html
     https://github.com/scipy/scipy/tree/fa21e840ad69fbac7ff600a7ef2b36929c18b975/scipy/sparse/linalg/eigen/arpack
     http://bazaar.launchpad.net/~igraph/igraph/0.5-main/files/1139.1.143/src/arpack/

Additionally, the Mathworks (they make Matlab) probably also has their
own version of ARPACK, but I wasn't able to find a public version of
it, nor an email to send them questions to. If someone could contact
them, it would be nice to let them know.

These all seem to have modified ARPACK in some way, with minor or
major bugfixes, and as far as I can tell, have mostly done so
independently. To me, this seems like unnecessary work, if we're all
patching the library again and again and making our own private forks.
What I therefore propose is to have some sort of central location for
it and we all pool our efforts on this one location. I think it would
be easiest to use Andreas Klöckner's existing fork on github, since
this requires the least maintenance and work from anyone. All that it
requires for now is for each of the people above to see what patches
they have made and transplant them to the git repo.

It would be helpful if upstream could confirm that they are happy with
ARPACK development continuing on github and mention this on the ARPACK
webpage, so that new people who are interested on ARPACK can be
redirected.

Thanks,
- Jordi G. H.
  GNU Octave developer
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Jordi Gutiérrez Hermoso | 8 Aug 2011 16:45
Gravatar

Re: ARPACK situation

(If you missed my first email, this is the context:

     http://jordi.inversethought.com/blog/arpack-situation/

and you're receiving this because I thought you were involved with
ARPACK distribution or maintenance.)

On 7 August 2011 22:04, Lehoucq, Richard <rblehou <at> sandia.gov> wrote:
> Thank you for your well articulated email. ARPACK is the property of
> Rice University and so any "upstream" decision ultimately resides
> with Rice.

I understand.

Can you give us contact information for someone at Rice University who
may could be in a position to decide to change the ARPACK website to
point to a hypothetical community-maintained version of the software?
Addresses like arpack <at> caam.rice.edu obtained from this website have
bounced.

Thanks again,
- Jordi G. H.
  GNU Octave Developer
Ben Willmore | 9 Aug 2011 18:09
Picon

installation of scipy on Mac OS X 10.7

I have spent a day attempting to get a version of scipy that passes unit tests on Mac OS X 10.7. I hope the
results of my investigations (below) are useful to others trying to do the same thing.

Ben

== Introduction

I have attempted to obtain a version of scipy on Mac OS X 10.7 that passes 
unit tests, both by downloading it, or by compiling against the system's
python, using the three C compilers available, and various compile flags.

== Conclusions

1. Both Enthought Python 7.1 and the scipy superpack crash during scipy unit 
tests.

2. Compilation with the default C compiler (llvm-gcc-4.2) also leads to a
crash during unit tests.

3. Compilation using either of the other C compilers (gcc-4.2 or clang) 
allows scipy to complete unit tests, only if the fortran flag --ff2c is used.
In both cases, scipy passes almost all tests -- producing errors on one, and
failing two more. With gcc-4.2, numpy passes all tests. With clang, numpy 
fails one test.

4. The following recipe was most successful for me:

* Remove everything in /usr/local and /Library/Python/2.7/site-packages
  (BEWARE! These directories may well contain stuff you care about)

* Install gfortran from here:
  http://r.research.att.com/gfortran-lion-5666-3.pkg

mkdir ~/tmp
cd ~/tmp
git clone git://github.com/numpy/numpy.git
cd numpy
export CC=gcc-4.2
export CXX=g++-4.2
export FFLAGS=-ff2c
python setupegg.py build --fcompiler=gfortran
sudo python setupegg.py install

cd ~/tmp
git clone git://github.com/scipy/scipy.git
cd scipy
export CC=gcc-4.2
export CXX=g++-4.2
export FFLAGS=-ff2c
python setupegg.py build --fcompiler=gfortran
sudo python setupegg.py install

(repeat for matplotlib, ipython ...)

== Details of test results

= Enthought python 7.1
numpy.test(): OK
scipy.test(): Crash (Segmentation fault)

= Scipy superpack
numpy.test(): 3 failures:
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, 1, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, -1, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, 0.0, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, -0.0, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, inf, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, -inf, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, nan, 
 inf, inf, inf)
FAIL: test_umath_complex.TestCsqrt.test_special_values(<ufunc 'sqrt'>, -inf, 
 1, 0.0, inf)
scipy.test(): Crash (Abort trap)

= Compilation from scratch (see above for recipe)

= llvm-gcc-4.2
= (no compiler flags)
numpy.test(): OK
scipy.test(): Crash (Segmentation fault: 11)

= gcc-4.2
= CC=gcc-4.2 CXX=g++-4.2
numpy.test(): OK
scipy.test(): Hang (during ARPACK tests)

= clang
= CC=clang CXX=clang++
numpy.test(): 1 failure:
FAIL: Test basic arithmetic function errors
AssertionError: Type <type 'numpy.complex64'> did not raise fpe error ''.
scipy.test(): Hang (during ARPACK tests)

= llvm-gcc-4.2 and -ff2c
= FFLAGS=-ff2c
numpy.test(): OK
scipy.test(): Crash (Segmentation fault: 11)

= gcc-4.2 and -ff2c
= CC=gcc-4.2 CXX=g++-4.2 FFLAGS=-ff2c
numpy.test(): OK
scipy.test(): 1 error, 2 failures:
ERROR: test_arpack.test_hermitian_modes(True, <gen-hermitian>, 'F', 2, 'SA', 
 None, None, <function aslinearoperator at 0x1098cd500>)
FAIL: test_iterative.test_convergence(<function bicg at 0x1098cdd70>, 
 <nonsymposdef>)
FAIL: test_expon (test_morestats.TestAnderson)

= clang and -ff2c
= CC=clang CXX=clang++ FFLAGS=-ff2c
numpy.test(): 1 failure:
FAIL: Test basic arithmetic function errors
AssertionError: Type <type 'numpy.complex64'> did not raise fpe error ''.
scipy.test(): 1 error, 2 failures:
ERROR: test_arpack.test_hermitian_modes(True, <gen-hermitian>, 'F', 2, 'SA', 
 None, None, <function aslinearoperator at 0x1098cd500>)
FAIL: test_iterative.test_convergence(<function bicg at 0x1098cdd70>, 
 <nonsymposdef>)
FAIL: test_expon (test_morestats.TestAnderson)
Robert Cimrman | 10 Aug 2011 14:55
Picon

ANN: SfePy 2011.3

I am pleased to announce release 2011.3 of SfePy.

Description
-----------
SfePy (simple finite elements in Python) is a software for solving
systems of coupled partial differential equations by the finite element
method. The code is based on NumPy and SciPy packages. It is distributed
under the new BSD license.

Home page: http://sfepy.org
Mailing lists, issue tracking: http://code.google.com/p/sfepy/
Git (source) repository: http://github.com/sfepy

Documentation: http://docs.sfepy.org/doc

Highlights of this release
--------------------------
- major update of terms aiming at easier usage and definition
   while retaining original C functions
- overriding problem description items on command line
- improved developer guide
- Primer tutorial - a step-by-step walk-through of the process to solve
   a simple mechanics problem

For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/2011.3_RELEASE_NOTES.txt
(full release notes, rather long and technical).

Best regards,
Robert Cimrman and Contributors (*)

(*) Contributors to this release (alphabetical order):

Vladimír Lukeš, Matyáš Novák, Andre Smit
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev

Gmane