Re: [Numpy-discussion] Dropping support for, Accelerate/veclib?
I think for Scipy homebrew uses the Gfortran ABI: https://trac.macports.org/browser/trunk/dports/python/py-scipy/Portfile
fwiw, homebrew is not macports. it's a more recent replacement that seems to be taking over gradually.
On Tue, Jun 11, 2013 at 10:22 AM, Nils Becker <n.becker@amolf.nl> wrote:
fwiw, homebrew is not macports. it's a more recent replacement that seems to be taking over gradually.
And then there is (or was) fink---- Anyway, it would be really nice if numpy could work well out-of-the box with the pyton.org python (and or the Apple-supplied one) without any need fro macports, homebrew, etc. It's actually pretty cool that Apple provides veclib, and and I liked that it got used by default with a simple "setup.py build". It would be nice to keep it that way. If a user (or distributor of binaries) wants to build the whole scipy stack, they'll need to figure out all this *&^%& anyway, changing a config in numpy to build differently would be the easiest part. And yes, there really are folks that use numpy a lot without scipy. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Tue, Jun 11, 2013 at 9:44 PM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
On Tue, Jun 11, 2013 at 10:22 AM, Nils Becker <n.becker@amolf.nl> wrote:
fwiw, homebrew is not macports. it's a more recent replacement that seems to be taking over gradually.
And then there is (or was) fink----
Anyway, it would be really nice if numpy could work well out-of-the box with the pyton.org python (and or the Apple-supplied one) without any need fro macports, homebrew, etc.
The binaries will still be built against python.org Python, so there shouldn't be an issue here. Same for building from source.
It's actually pretty cool that Apple provides veclib, and and I liked that it got used by default with a simple "setup.py build".
Yeah, I still have an OS X 10.6 machine and Accelerate works great there. But they screwed it up pretty bad in 10.7, and then made it worse for 10.8. Not so cool anymore.... It would be nice to keep it that way.
If a user (or distributor of binaries) wants to build the whole scipy stack, they'll need to figure out all this *&^%& anyway, changing a config in numpy to build differently would be the easiest part.
And yes, there really are folks that use numpy a lot without scipy.
I think we have to indeed keep it easy to build from source. Maybe providing a script to automatically fetch all dependencies and then build (like MPL does) would be a good way to go. Ralf
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jun 11, 2013 at 1:28 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
The binaries will still be built against python.org Python, so there shouldn't be an issue here. Same for building from source.
My point was that it's nice to be able to have it build with an out of teh box wetup.py with accelerated LAPACK and all... If whoever is building binaries wants to get fancy, great.
Yeah, I still have an OS X 10.6 machine and Accelerate works great there. But they screwed it up pretty bad in 10.7, and then made it worse for 10.8. Not so cool anymore....
oh well, not on 10.8 yet myself -- if it's broken, it's broken :-(
I think we have to indeed keep it easy to build from source. Maybe providing a script to automatically fetch all dependencies and then build (like MPL does) would be a good way to go.
Maybe, but stand alone scripts like that get pretty fragile ( I know, I have a few of them myself...) I really want to have a better system in place to build binaries for the mac -- ideally a system that uses the same infrastructure to build a variety of Mac packages, rather than each package having it's own build scripts that need to be maintained and probably overlap with each other. I"m looking at gattai as a system to build on. (http://sourceforge.net/projects/gattai/) There is also the issue of third-party dependencies (libpng, libfreetype, blas, etc, etc) I kind of like how Anaconda appears to be doing it. They have packages that have the shared libs in them, and then other packages can depend on those. Anyway, lots to do! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 11/06/2013 22:11, Chris Barker - NOAA Federal wrote:
On Tue, Jun 11, 2013 at 1:28 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
The binaries will still be built against python.org Python, so there shouldn't be an issue here. Same for building from source.
My point was that it's nice to be able to have it build with an out of teh box wetup.py with accelerated LAPACK and all... If whoever is building binaries wants to get fancy, great.
Yes, please. The current system does seem to work for at least some of us. And, if I understand the thread in the scipy mailing list, it's not actually clear that there's a bug, as opposed to incompatible fortran ABIs (which doesn't seem like a bug to me). But I guess the most important thing would be that it can be used with apple or python.org Python builds (my reading of some of the suggestions would be requiring one of homebrew/fink/macports), preferably out-of-the-box -- even if that meant restricting to prebuilt binaries. Being able to run non-obscure installers (i.e., from the main python.org and scipy.org sites) for Python + numpy + scipy + matplotlib and get optimized versions would be sufficient. Andrew
On Thu, Jun 13, 2013 at 1:25 PM, Andrew Jaffe <a.h.jaffe@gmail.com> wrote:
On 11/06/2013 22:11, Chris Barker - NOAA Federal wrote:
On Tue, Jun 11, 2013 at 1:28 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
The binaries will still be built against python.org Python, so there shouldn't be an issue here. Same for building from source.
My point was that it's nice to be able to have it build with an out of teh box wetup.py with accelerated LAPACK and all... If whoever is building binaries wants to get fancy, great.
Yes, please. The current system does seem to work for at least some of us. And, if I understand the thread in the scipy mailing list, it's not actually clear that there's a bug, as opposed to incompatible fortran ABIs (which doesn't seem like a bug to me).
But I guess the most important thing would be that it can be used with apple or python.org Python builds (my reading of some of the suggestions would be requiring one of homebrew/fink/macports),
No we should support all pythons; python.org being the one supported by our binary installers. Ralf
preferably out-of-the-box -- even if that meant restricting to prebuilt binaries. Being able to run non-obscure installers (i.e., from the main python.org and scipy.org sites) for Python + numpy + scipy + matplotlib and get optimized versions would be sufficient.
FYI: https://github.com/numpy/numpy/pull/3439 -- Pauli Virtanen
participants (5)
-
Andrew Jaffe -
Chris Barker - NOAA Federal -
Nils Becker -
Pauli Virtanen -
Ralf Gommers