Hi All, A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs. Chuck
Hi, On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.
I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install... Thanks a lot, Matthew
Hi, On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.
I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...
Current trunk wheel at http://nipy.bic.berkeley.edu/scipy_installers/numpy-1.8.0.dev_a89a36e-cp27-n... Testing welcome. You'll need OSX and latest setuptools and latest pip and : curl -O http://nipy.bic.berkeley.edu/scipy_installers/numpy-1.8.0.dev_a89a36e-cp27-n... pip install --pre --no-index --find-links . numpy I built the wheel on a 10.9 laptop and tested it on a bare-metal no-compiler 10.6 laptop, so I think it will work. I'll set up daily wheel build / tests on our buildbots as well. Cheers, Matthew
What's up with the OpenBLAS work? Any chance that might make it into official binaries? Or is is just too fresh? Also -- from an off-hand comment in the thread is looked like OpenBLAS could provide a library that selects for optimized code at run-time depending on hardware -- this would solve the "superpack" problem with wheels, which would be really nice... Or did I dream that? -Chris On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.
I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...
Thanks a lot,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- 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
I build wheels for 32bit and 64bit (Windows, OpenBLAS) and put them here: https://drive.google.com/folderview?id=0B4DmELLTwYmlX05WSWpYVWJfRjg&usp=sharing Due to shortage of time I give not much more detailed informations before 1st of March. Carl 2014-02-25 1:53 GMT+01:00 Chris Barker <chris.barker@noaa.gov>:
What's up with the OpenBLAS work?
Any chance that might make it into official binaries? Or is is just too fresh?
Also -- from an off-hand comment in the thread is looked like OpenBLAS could provide a library that selects for optimized code at run-time depending on hardware -- this would solve the "superpack" problem with wheels, which would be really nice...
Or did I dream that?
-Chris
On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.
I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...
Thanks a lot,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
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
Hi, I have a PR that fix way too much printing to stdout when finding the blas linking information: https://github.com/numpy/numpy/pull/4081 This was created by change in NumPy. I was requested as a comment to put the removed information in the dict that we return to the user. I won't have the time to do this for the 1.8.1rc as I'm in vacation next week and I need to prepar that. I'll try to find someone else to finish this, but it is not sure. I'll keep you updated on this. thanks Frédéric On Tue, Feb 25, 2014 at 5:52 PM, Carl Kleffner <cmkleffner@gmail.com> wrote:
I build wheels for 32bit and 64bit (Windows, OpenBLAS) and put them here: https://drive.google.com/folderview?id=0B4DmELLTwYmlX05WSWpYVWJfRjg&usp=sharing Due to shortage of time I give not much more detailed informations before 1st of March.
Carl
2014-02-25 1:53 GMT+01:00 Chris Barker <chris.barker@noaa.gov>:
What's up with the OpenBLAS work?
Any chance that might make it into official binaries? Or is is just too fresh?
Also -- from an off-hand comment in the thread is looked like OpenBLAS could provide a library that selects for optimized code at run-time depending on hardware -- this would solve the "superpack" problem with wheels, which would be really nice...
Or did I dream that?
-Chris
On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.
I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...
Thanks a lot,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thanks for posting those wheels Matthew. I'm on a Mac (10.9.2) and I had trouble installing numpy from your wheel in a fresh virtualenv with the latests pip, setuptools, and wheel. ``` $pip install ~/Downloads/numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl is not a supported wheel on this platform. Storing debug log for failure in /Users/admin/.pip/pip.log ``` When I build a wheel from source, my platform is `x86_64`. Changing `intel` to `x86_64`: ``` $mv numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_x86_64.whl ``` and then running `pip install` on that wheel successfully installed numpy (and the test suite passed). I've been searching for where the platform tag is defined, but haven't had luck yet. I'll post if I find anything. -- View this message in context: http://numpy-discussion.10968.n7.nabble.com/1-8-1-release-tp36603p36655.html Sent from the Numpy-discussion mailing list archive at Nabble.com.
On Wed, Feb 26, 2014 at 8:27 AM, Tom Augspurger <tom.augspurger88@gmail.com>wrote:
Thanks for posting those wheels Matthew.
I'm on a Mac (10.9.2) and I had trouble installing numpy from your wheel in a fresh virtualenv with the latests pip, setuptools, and wheel.
``` $pip install ~/Downloads/numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl is not a supported wheel on this platform. Storing debug log for failure in /Users/admin/.pip/pip.log ```
IIRC, those wheels are built for the pyton.org builds of python: macosx_10_9 means it was built on 10.9 (though that should be 10.6, I think, as it is built FOR 106+, not only 10.9..) _intel means it's an Intel build, which in the nomenclature used in the pyton.org builds, means it's a universal 32 and 64 bit Intel
When I build a wheel from source, my platform is `x86_64`.
What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers? ```
$mv numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_x86_64.whl ```
and then running `pip install` on that wheel successfully installed numpy (and the test suite passed).
I'm not entirely sure we can count on that working, as I _think_ the SDK that the wheel was built against is different than the one your python was built against. But it theory, one should be able to install a universal wheel into a one-of-the-architectures build, the other one will get ignored (as it seems to be for you), but I think it's fragile in general. This is a serious issue with binary wheels -- there are so many variations to a "platform" -- the naming scheme covers OS, OS version, and bit depth, but not system library versions, and who the heck knows what else. This has been discussed a lot on the dist_utils list, with no real solution in sight: - there are other alternative, for instance, I think conda packages have some sort of hash or something to make sure that binary packages all match. - convention is the other option: - use binary wheel for in-house deplyment to similar systems - use binary wheels for a well-defined python build: - for PyPi, that's the python.org builds for Windows and OS- -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
Hi, Arnaud finished that in a different way then we had discussed in the PR. https://github.com/numpy/numpy/pull/4081 Fred On Wed, Feb 26, 2014 at 10:07 AM, Frédéric Bastien <nouiz@nouiz.org> wrote:
Hi,
I have a PR that fix way too much printing to stdout when finding the blas linking information:
https://github.com/numpy/numpy/pull/4081
This was created by change in NumPy. I was requested as a comment to put the removed information in the dict that we return to the user. I won't have the time to do this for the 1.8.1rc as I'm in vacation next week and I need to prepar that.
I'll try to find someone else to finish this, but it is not sure. I'll keep you updated on this.
thanks
Frédéric
On Tue, Feb 25, 2014 at 5:52 PM, Carl Kleffner <cmkleffner@gmail.com> wrote:
I build wheels for 32bit and 64bit (Windows, OpenBLAS) and put them here: https://drive.google.com/folderview?id=0B4DmELLTwYmlX05WSWpYVWJfRjg&usp=sharing Due to shortage of time I give not much more detailed informations before 1st of March.
Carl
2014-02-25 1:53 GMT+01:00 Chris Barker <chris.barker@noaa.gov>:
What's up with the OpenBLAS work?
Any chance that might make it into official binaries? Or is is just too fresh?
Also -- from an off-hand comment in the thread is looked like OpenBLAS could provide a library that selects for optimized code at run-time depending on hardware -- this would solve the "superpack" problem with wheels, which would be really nice...
Or did I dream that?
-Chris
On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.
I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...
Thanks a lot,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Wed, Feb 26, 2014 at 11:02 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Feb 26, 2014 at 8:27 AM, Tom Augspurger <tom.augspurger88@gmail.com> wrote:
Thanks for posting those wheels Matthew.
I'm on a Mac (10.9.2) and I had trouble installing numpy from your wheel in a fresh virtualenv with the latests pip, setuptools, and wheel.
``` $pip install ~/Downloads/numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl is not a supported wheel on this platform. Storing debug log for failure in /Users/admin/.pip/pip.log ```
IIRC, those wheels are built for the pyton.org builds of python:
macosx_10_9 means it was built on 10.9 (though that should be 10.6, I think, as it is built FOR 106+, not only 10.9..)
_intel means it's an Intel build, which in the nomenclature used in the pyton.org builds, means it's a universal 32 and 64 bit Intel
When I build a wheel from source, my platform is `x86_64`.
What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers?
``` $mv numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_x86_64.whl ```
and then running `pip install` on that wheel successfully installed numpy (and the test suite passed).
I'm not entirely sure we can count on that working, as I _think_ the SDK that the wheel was built against is different than the one your python was built against.
But it theory, one should be able to install a universal wheel into a one-of-the-architectures build, the other one will get ignored (as it seems to be for you), but I think it's fragile in general.
This is a serious issue with binary wheels -- there are so many variations to a "platform" -- the naming scheme covers OS, OS version, and bit depth, but not system library versions, and who the heck knows what else.
This has been discussed a lot on the dist_utils list, with no real solution in sight: - there are other alternative, for instance, I think conda packages have some sort of hash or something to make sure that binary packages all match.
- convention is the other option: - use binary wheel for in-house deplyment to similar systems - use binary wheels for a well-defined python build: - for PyPi, that's the python.org builds for Windows and OS-
Thanks - that is a very useful summary. It would make sense I think to provide numpy wheels like mine via pypi - as pyzmq does for example. In this case, I believe (Chris correct me if I'm wrong) that someone running via system python would get the usual compile / install, but someone running python.org python would get a near instant numpy, so that seems like a clear win. Cheers, Matthew
On Wed, Feb 26, 2014 at 11:34 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
- convention is the other option: - use binary wheel for in-house deplyment to similar systems - use binary wheels for a well-defined python build: - for PyPi, that's the python.org builds for Windows and OS-
Thanks - that is a very useful summary.
It would make sense I think to provide numpy wheels like mine via pypi - as pyzmq does for example.
Indeed -- and I really appreciate your efforts on this -- I think we should be able to get the whole "stack" up there pretty soon (though there is an issue with iPython and readline...) Ralf had put together a test set of these, too a little while ago.
In this case, I believe (Chris correct me if I'm wrong) that someone running via system python would get the usual compile / install, but someone running python.org python would get a near instant numpy,
That's the idea -- though not entirely sure how that would go without testing. Also, I think with pip, you need to tell it to look for binary wheels -- it won't do that by default. pip install --use-wheel numpy so that seems like a clear win.
Agreed. The trick is that it's reasonable for users of Apple's python build to want this too -- but I don't know how we can hope to provide that. (and macports, and homebrew... but those I feel better about requiring to build your own -- really, that's what those systems are designed 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
Hi, On Wed, Feb 26, 2014 at 2:33 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Feb 26, 2014 at 11:34 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
- convention is the other option: - use binary wheel for in-house deplyment to similar systems - use binary wheels for a well-defined python build: - for PyPi, that's the python.org builds for Windows and OS-
Thanks - that is a very useful summary.
It would make sense I think to provide numpy wheels like mine via pypi - as pyzmq does for example.
Indeed -- and I really appreciate your efforts on this -- I think we should be able to get the whole "stack" up there pretty soon (though there is an issue with iPython and readline...) Ralf had put together a test set of these, too a little while ago.
In this case, I believe (Chris correct me if I'm wrong) that someone running via system python would get the usual compile / install, but someone running python.org python would get a near instant numpy,
That's the idea -- though not entirely sure how that would go without testing.
It's currently working for pyzmq - so I supect it would work.
Also, I think with pip, you need to tell it to look for binary wheels -- it won't do that by default.
pip install --use-wheel numpy
I think --use-wheel is the default for the latest pip ...
so that seems like a clear win.
Agreed. The trick is that it's reasonable for users of Apple's python build to want this too -- but I don't know how we can hope to provide that.
We don't support system python for the mpkg, so I think it's reasonable to leave this little gift for our fellow python.org friends. In that case, the OSX instructions could (within the next few months) be as simple as: Install python from binary installer at python.org curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py python get-pip.py pip install scipy-stack or similar.
(and macports, and homebrew... but those I feel better about requiring to build your own -- really, that's what those systems are designed to do)
Yes, that seems right to me. Cheers, Matthew
Thanks Chris, Chris Barker - NOAA Federal wrote
What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers?
I'm using homebrew python, so the platform difference seems to have come from there. I agree about renaming the file as not being a real solution. I'd say the official python.org python is the one to worry about for PyPI (which is what pyzmq seems to do). -Tom -- View this message in context: http://numpy-discussion.10968.n7.nabble.com/1-8-1-release-tp36603p36662.html Sent from the Numpy-discussion mailing list archive at Nabble.com.
Hi, On Wed, Feb 26, 2014 at 3:10 PM, Tom Augspurger <tom.augspurger88@gmail.com> wrote:
Thanks Chris,
Chris Barker - NOAA Federal wrote
What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers?
I'm using homebrew python, so the platform difference seems to have come from there. I agree about renaming the file as not being a real solution. I'd say the official python.org python is the one to worry about for PyPI (which is what pyzmq seems to do).
I use homebrew myself, but only for big libraries. I've stuck with python.org python on the basis that that is what we ask new users to install. Of course that has meant problems with installing the scipy stack - but I think we're now close to a standard libre solution to that with wheels. Cheers, Matthew
On Wed, Feb 26, 2014 at 2:48 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Agreed. The trick is that it's reasonable for users of Apple's python build to want this too -- but I don't know how we can hope to provide that.
We don't support system python for the mpkg, so I think it's reasonable to leave this little gift for our fellow python.org friends.
I agree. We decided long ago on the pythonmac list that supporting Apple's python builds was a dead-end.
In that case, the OSX instructions could (within the next few months) be as simple as:
Install python from binary installer at python.org curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py python get-pip.py pip install scipy-stack
or similar.
yup -- that'st he goal, and think we really are close. Does pip and PyPi "officially" support meta-packages like that? i.e. I take it that scipy-stack would be a package that had nothing except dependencies. I do like the idea. Getting a bit OT for the numpy list, but... As I understand it, there was a stumbling block with wheels for the SciPy stack around iPython and readline -- some systems require th readline package, some don't. As I write this, I can't remember why it would be the lest bit hard to simply require readline in teh Mac Wheels, but there was some debate on the iPython list, and it seemed not-so-easy to resolve... -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 Wed, Feb 26, 2014 at 3:10 PM, Tom Augspurger <tom.augspurger88@gmail.com>wrote:
Chris Barker - NOAA Federal wrote
What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers?
I'm using homebrew python, so the platform difference seems to have come from there.
and it _should_ -- in theory, and often in practice, you should be able to get packages for hamebrew with either: brew install the_package_name or pip install the_package_name and let it compile away. But we wouldn't want a brew python to find a binary wheel built for the python.org python -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 26 February 2014 22:48, Matthew Brett <matthew.brett@gmail.com> wrote:
In that case, the OSX instructions could (within the next few months) be as simple as:
Install python from binary installer at python.org curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py python get-pip.py pip install scipy-stack
or similar.
Python 3.4 will be released by then and will ship with pip pre-installed: http://legacy.python.org/dev/peps/pep-0453/ So then it could be: 1) Install Python 3.4 from binary installer at python.org 2) pip install scipy-stack. Oscar
Hi, Should [1] be considered a release blocker for 1.8.1? Skipper [1] https://github.com/numpy/numpy/issues/4442
On 06.03.2014 19:46, Skipper Seabold wrote:
Hi,
Should [1] be considered a release blocker for 1.8.1?
Skipper
as far as I can tell its a regression of the 1.8.0 release but not the 1.8.1 release so I wouldn't consider it a blocker. But its definitely a very nice to have. Unfortunately it is probably also complicated and invasive to fix as it would need either modifications of nditer or gufuncs (or a revert to non gufunc) which are both quite complicated pieces of code.
participants (9)
-
Carl Kleffner
-
Charles R Harris
-
Chris Barker
-
Frédéric Bastien
-
Julian Taylor
-
Matthew Brett
-
Oscar Benjamin
-
Skipper Seabold
-
Tom Augspurger