[Numpy-discussion] Build fortran extension on Windows with gfortran and MSVC
Hi! It seems that on Windows + Python-3.5 fortran extensions cannot be built anymore with f2py and mingw32 compilers, because of new MSVC. Here is the short description of the errors one gets: http://stackoverflow.com/questions/33822554/build-fortran-extension-on-windows-with-gfortran-and-msvc This is sad, because this worked quite nicely with all previous python versions. I'm curious what are the options now? Is this going to be supported in the future, with mingw-w64 for example? Regards, -- Marek --- Politechnika Åódzka Lodz University of Technology TreÅÄ tej wiadomoÅci zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteÅcie PaÅstwo jej adresatem, bÄ dź otrzymaliÅcie jÄ przez pomyÅkÄ prosimy o powiadomienie o tym nadawcy oraz trwaÅe jej usuniÄcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Build fortran extension on Windows with gfortran and MSVC
Hi, On 11 February 2016 at 15:40, Marek Wojciechowski wrote: > It seems that on Windows + Python-3.5 fortran extensions cannot be built > anymore with f2py and mingw32 compilers, because of new MSVC. Here is the > short description of the errors one gets: > Off-topic, but this is something that I get asked quite often, and I don't know what to say, not being a windows user: Is there some "howto" compile f2py fortran modules from scratch in windows with anaconda available? Jose ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Build fortran extension on Windows with gfortran and MSVC
Dnia czwartek, 11 lutego 2016 16:40:22 Marek Wojciechowski pisze: > Hi! > > It seems that on Windows + Python-3.5 fortran extensions cannot be built > anymore with f2py and mingw32 compilers, because of new MSVC. Here is the > short description of the errors one gets: > > http://stackoverflow.com/questions/33822554/build-fortran-extension-on-windo > ws-with-gfortran-and-msvc > > This is sad, because this worked quite nicely with all previous python > versions. I'm curious what are the options now? Is this going to be > supported in the future, with mingw-w64 for example? I found that the effort is on the way: http://mingwpy.github.io. The roadmap is quite ambitious... Regards, -- Marek --- Politechnika Åódzka Lodz University of Technology TreÅÄ tej wiadomoÅci zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteÅcie PaÅstwo jej adresatem, bÄ dź otrzymaliÅcie jÄ przez pomyÅkÄ prosimy o powiadomienie o tym nadawcy oraz trwaÅe jej usuniÄcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Build fortran extension on Windows with gfortran and MSVC
Dnia czwartek, 11 lutego 2016 16:23:23 Jose Gomez-Dans pisze: > Hi, > > On 11 February 2016 at 15:40, Marek Wojciechowski wrote: > > It seems that on Windows + Python-3.5 fortran extensions cannot be built > > anymore with f2py and mingw32 compilers, because of new MSVC. Here is the > > > short description of the errors one gets: > Off-topic, but this is something that I get asked quite often, and I don't > know what to say, not being a windows user: > Is there some "howto" compile f2py fortran modules from scratch in windows > with anaconda available? After installing mingw (conda install mingw), you should go like on Linux. I think f2py is choosing --compiler=mingw32 by default. -- Marek --- Politechnika Åódzka Lodz University of Technology TreÅÄ tej wiadomoÅci zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteÅcie PaÅstwo jej adresatem, bÄ dź otrzymaliÅcie jÄ przez pomyÅkÄ prosimy o powiadomienie o tym nadawcy oraz trwaÅe jej usuniÄcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating `numpy.iterable`
We certainly can (and probably should) deprecate this, but we can't remove it for a very long time. np.iterable is used in a lot of third party code. On Wed, Feb 10, 2016 at 7:09 PM, Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > I have created a PR to deprecate `np.iterable` > (https://github.com/numpy/numpy/pull/7202). It is a very old function, > introduced as a utility in 2005 > ( > https://github.com/numpy/numpy/commit/052a7b2e3276a303be1083022fc24d43084d2e14 > ), > and there is no good reason for it to be part of the public API. It is > used internally 10 times within numpy. I have repaced those usages > with a private function `np.lib.function_base._iterable` and added a > `DeprecationWarning` to the public function. > > Is there anyone that objects to deprecating this function? > > Regards, > > -Joseph > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating `numpy.iterable`
Oh wow, yeah, there are tons of uses: https://github.com/search?q=%22np.iterable%22&ref=simplesearch&type=Code&utf8=%E2%9C%93 Meh, I dunno, maybe we're stuck with it. It's not a major maintenance burden at least. -n On Thu, Feb 11, 2016 at 10:25 AM, Stephan Hoyer wrote: > We certainly can (and probably should) deprecate this, but we can't remove > it for a very long time. > > np.iterable is used in a lot of third party code. > > On Wed, Feb 10, 2016 at 7:09 PM, Joseph Fox-Rabinovitz > wrote: >> >> I have created a PR to deprecate `np.iterable` >> (https://github.com/numpy/numpy/pull/7202). It is a very old function, >> introduced as a utility in 2005 >> >> (https://github.com/numpy/numpy/commit/052a7b2e3276a303be1083022fc24d43084d2e14), >> and there is no good reason for it to be part of the public API. It is >> used internally 10 times within numpy. I have repaced those usages >> with a private function `np.lib.function_base._iterable` and added a >> `DeprecationWarning` to the public function. >> >> Is there anyone that objects to deprecating this function? >> >> Regards, >> >> -Joseph >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Nathaniel J. Smith -- https://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating `numpy.iterable`
Huh... matplotlib could use that! We have been using our own internal function left over from the numerix days, I think. Ben Root On Thu, Feb 11, 2016 at 2:12 PM, Nathaniel Smith wrote: > Oh wow, yeah, there are tons of uses: > > https://github.com/search?q=%22np.iterable%22&ref=simplesearch&type=Code&utf8=%E2%9C%93 > > Meh, I dunno, maybe we're stuck with it. It's not a major maintenance > burden at least. > > -n > > On Thu, Feb 11, 2016 at 10:25 AM, Stephan Hoyer wrote: > > We certainly can (and probably should) deprecate this, but we can't > remove > > it for a very long time. > > > > np.iterable is used in a lot of third party code. > > > > On Wed, Feb 10, 2016 at 7:09 PM, Joseph Fox-Rabinovitz > > wrote: > >> > >> I have created a PR to deprecate `np.iterable` > >> (https://github.com/numpy/numpy/pull/7202). It is a very old function, > >> introduced as a utility in 2005 > >> > >> ( > https://github.com/numpy/numpy/commit/052a7b2e3276a303be1083022fc24d43084d2e14 > ), > >> and there is no good reason for it to be part of the public API. It is > >> used internally 10 times within numpy. I have repaced those usages > >> with a private function `np.lib.function_base._iterable` and added a > >> `DeprecationWarning` to the public function. > >> > >> Is there anyone that objects to deprecating this function? > >> > >> Regards, > >> > >> -Joseph > >> ___ > >> NumPy-Discussion mailing list > >> NumPy-Discussion@scipy.org > >> https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating `numpy.iterable`
It appears that deprecating `numpy.iterable` would be counterproductive. I have reverted my PR to just making the return value an actual `bool` instead of an `int`. On Thu, Feb 11, 2016 at 2:54 PM, Benjamin Root wrote: > Huh... matplotlib could use that! We have been using our own internal > function left over from the numerix days, I think. > > Ben Root > > On Thu, Feb 11, 2016 at 2:12 PM, Nathaniel Smith wrote: >> >> Oh wow, yeah, there are tons of uses: >> >> https://github.com/search?q=%22np.iterable%22&ref=simplesearch&type=Code&utf8=%E2%9C%93 >> >> Meh, I dunno, maybe we're stuck with it. It's not a major maintenance >> burden at least. >> >> -n >> >> On Thu, Feb 11, 2016 at 10:25 AM, Stephan Hoyer wrote: >> > We certainly can (and probably should) deprecate this, but we can't >> > remove >> > it for a very long time. >> > >> > np.iterable is used in a lot of third party code. >> > >> > On Wed, Feb 10, 2016 at 7:09 PM, Joseph Fox-Rabinovitz >> > wrote: >> >> >> >> I have created a PR to deprecate `np.iterable` >> >> (https://github.com/numpy/numpy/pull/7202). It is a very old function, >> >> introduced as a utility in 2005 >> >> >> >> >> >> (https://github.com/numpy/numpy/commit/052a7b2e3276a303be1083022fc24d43084d2e14), >> >> and there is no good reason for it to be part of the public API. It is >> >> used internally 10 times within numpy. I have repaced those usages >> >> with a private function `np.lib.function_base._iterable` and added a >> >> `DeprecationWarning` to the public function. >> >> >> >> Is there anyone that objects to deprecating this function? >> >> >> >> Regards, >> >> >> >> -Joseph >> >> ___ >> >> NumPy-Discussion mailing list >> >> NumPy-Discussion@scipy.org >> >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> > >> > >> > ___ >> > NumPy-Discussion mailing list >> > NumPy-Discussion@scipy.org >> > https://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> >> >> >> -- >> Nathaniel J. Smith -- https://vorpus.org >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Hook in __init__.py to let distributors patch numpy
Hi, Over at https://github.com/numpy/numpy/issues/5479 we're discussing Windows wheels. On thing that we would like to be able to ship Windows wheels, is to be able to put some custom checks into numpy when you build the wheels. Specifically, for Windows, we're building on top of ATLAS BLAS / LAPACK, and we need to check that the system on which the wheel is running, has SSE2 instructions, otherwise we know ATLAS will crash (almost everybody does have SSE2 these days). The way I propose we do that, is this patch here: https://github.com/numpy/numpy/pull/7231 diff --git a/numpy/__init__.py b/numpy/__init__.py index 0fcd509..ba3ba16 100644 --- a/numpy/__init__.py +++ b/numpy/__init__.py @@ -190,6 +190,12 @@ def pkgload(*packages, **options): test = testing.nosetester._numpy_tester().test bench = testing.nosetester._numpy_tester().bench +# Allow platform-specific build to intervene in numpy init +try: +from . import _distributor_init +except ImportError: +pass + from . import core from .core import * from . import compat So, numpy __init__.py looks for a module `_distributor_init`, in which the distributor might have put custom code to do any checks and initialization needed for the particular platform. We don't by default ship a `_distributor_init.py` but leave it up to packagers to generate this when building binaries. Does that sound like a sensible approach to y'all? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Hook in __init__.py to let distributors patch numpy
+1. This seems nicer than patching __init__.py itself, in that it is much more transparent. Good idea. Michael On Thu, Feb 11, 2016 at 7:19 PM Matthew Brett wrote: > Hi, > > Over at https://github.com/numpy/numpy/issues/5479 we're discussing > Windows wheels. > > On thing that we would like to be able to ship Windows wheels, is to > be able to put some custom checks into numpy when you build the > wheels. > > Specifically, for Windows, we're building on top of ATLAS BLAS / > LAPACK, and we need to check that the system on which the wheel is > running, has SSE2 instructions, otherwise we know ATLAS will crash > (almost everybody does have SSE2 these days). > > The way I propose we do that, is this patch here: > > https://github.com/numpy/numpy/pull/7231 > > diff --git a/numpy/__init__.py b/numpy/__init__.py > index 0fcd509..ba3ba16 100644 > --- a/numpy/__init__.py > +++ b/numpy/__init__.py > @@ -190,6 +190,12 @@ def pkgload(*packages, **options): > test = testing.nosetester._numpy_tester().test > bench = testing.nosetester._numpy_tester().bench > > +# Allow platform-specific build to intervene in numpy init > +try: > +from . import _distributor_init > +except ImportError: > +pass > + > from . import core > from .core import * > from . import compat > > So, numpy __init__.py looks for a module `_distributor_init`, in which > the distributor might have put custom code to do any checks and > initialization needed for the particular platform. We don't by > default ship a `_distributor_init.py` but leave it up to packagers to > generate this when building binaries. > > Does that sound like a sensible approach to y'all? > > Cheers, > > Matthew > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
