Re: [Numpy-discussion] new mingw-w64 based numpy and scipy wheel (still experimental)
Just a wild guess:
(1) update your pip and try again
(2) use the bitbucket wheels with:
pip install --no-index -f
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads numpy
pip install --no-index -f
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads scipy
(3) check if there i something left in site-packages\numpy in the case you
have uninstalled another numpy distribution before.
Carl
2015-01-24 15:48 GMT+01:00 cjw c...@ncf.ca:
On 22-Jan-15 6:23 PM, Nathaniel Smith wrote:
On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner cmkleff...@gmail.com
wrote:
I took time to create mingw-w64 based wheels of numpy-1.9.1 and
scipy-0.15.1
source distributions and put them on
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as
on
binstar.org. The test matrix is python-2.7 and 3.4 for both 32bit and
64bit.
Feedback is welcome.
The wheels can be pip installed with:
pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy
Some technical details: the binaries are build upon OpenBLAS as
accelerated
BLAS/Lapack. OpenBLAS itself is build with dynamic kernels (similar to
MKL)
and automatic runtime selection depending on the CPU. The minimal
requested
feature supplied by the CPU is SSE2. SSE1 and non-SSE CPUs are not
supported
with this builds. This is the default for 64bit binaries anyway.
According to the steam hardware survey, 99.98% of windows computers
have SSE2. (http://store.steampowered.com/hwsurvey , click on other
settings at the bottom). So this is probably OK :-).
OpenBLAS is deployed as part of the numpy wheel. That said, the scipy
wheels
mentioned above are dependant on the installation of the OpenBLAS based
numpy and won't work i.e. with an installed numpy-MKL.
This sounds like it probably needs to be fixed before we can recommend
the scipy wheels for anyone? OTOH it might be fine to start
distributing numpy wheels first.
For the numpy 32bit builds there are 3 failures for special FP value
tests,
due to a bug in mingw-w64 that is still present. All scipy versions show
up
7 failures with some numerical noise, that could be ignored (or corrected
with relaxed asserts in the test code).
PR's for numpy and scipy are in preparation. The mingw-w64 compiler used
for
building can be found at
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads.
Correct me if I'm wrong, but it looks like there isn't any details on
how exactly the compiler was set up? Which is fine, I know you've been
doing a ton of work on this and it's much appreciated :-). But
eventually I do think a prerequisite for us adopting these as official
builds is that we'll need a text document (or an executable script!)
that walks through all the steps in setting up the toolchain etc., so
that someone starting from scratch could get it all up and running.
Otherwise we run the risk of eventually ending up back where we are
today, with a creaky old mingw binary snapshot that no-one knows how
it works or how to reproduce...
-n
Karl,
I tried and failed, even after adding --pre.
My log file is here:
C:\Python27\Scripts\pip run on 01/24/15 07:51:10
Downloading/unpacking https://pypi.binstar.org/carlkl/simple
Downloading simple
Downloading from URL https://pypi.binstar.org/carlkl/simple
Cleaning up...
Exception:
Traceback (most recent call last):
File C:\Python27\lib\site-packages\pip\basecommand.py, line 122, in
main
status = self.run(options, args)
File C:\Python27\lib\site-packages\pip\commands\install.py, line 278,
in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle,
bundle=self.bundle)
File C:\Python27\lib\site-packages\pip\req.py, line 1197, in
prepare_files
do_download,
File C:\Python27\lib\site-packages\pip\req.py, line 1375, in
unpack_url
self.session,
File C:\Python27\lib\site-packages\pip\download.py, line 582, in
unpack_http_url
unpack_file(temp_location, location, content_type, link)
File C:\Python27\lib\site-packages\pip\util.py, line 627, in
unpack_file
and is_svn_page(file_contents(filename))):
File C:\Python27\lib\site-packages\pip\util.py, line 210, in
file_contents
return fp.read().decode('utf-8')
File C:\Python27\lib\encodings\utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x8b in position 1:
invalid start byte
Do you have any suggestions?
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new mingw-w64 based numpy and scipy wheel (still experimental)
On 22-Jan-15 6:23 PM, Nathaniel Smith wrote:
On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner cmkleff...@gmail.com wrote:
I took time to create mingw-w64 based wheels of numpy-1.9.1 and scipy-0.15.1
source distributions and put them on
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as on
binstar.org. The test matrix is python-2.7 and 3.4 for both 32bit and 64bit.
Feedback is welcome.
The wheels can be pip installed with:
pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy
Some technical details: the binaries are build upon OpenBLAS as accelerated
BLAS/Lapack. OpenBLAS itself is build with dynamic kernels (similar to MKL)
and automatic runtime selection depending on the CPU. The minimal requested
feature supplied by the CPU is SSE2. SSE1 and non-SSE CPUs are not supported
with this builds. This is the default for 64bit binaries anyway.
According to the steam hardware survey, 99.98% of windows computers
have SSE2. (http://store.steampowered.com/hwsurvey , click on other
settings at the bottom). So this is probably OK :-).
OpenBLAS is deployed as part of the numpy wheel. That said, the scipy wheels
mentioned above are dependant on the installation of the OpenBLAS based
numpy and won't work i.e. with an installed numpy-MKL.
This sounds like it probably needs to be fixed before we can recommend
the scipy wheels for anyone? OTOH it might be fine to start
distributing numpy wheels first.
For the numpy 32bit builds there are 3 failures for special FP value tests,
due to a bug in mingw-w64 that is still present. All scipy versions show up
7 failures with some numerical noise, that could be ignored (or corrected
with relaxed asserts in the test code).
PR's for numpy and scipy are in preparation. The mingw-w64 compiler used for
building can be found at
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads.
Correct me if I'm wrong, but it looks like there isn't any details on
how exactly the compiler was set up? Which is fine, I know you've been
doing a ton of work on this and it's much appreciated :-). But
eventually I do think a prerequisite for us adopting these as official
builds is that we'll need a text document (or an executable script!)
that walks through all the steps in setting up the toolchain etc., so
that someone starting from scratch could get it all up and running.
Otherwise we run the risk of eventually ending up back where we are
today, with a creaky old mingw binary snapshot that no-one knows how
it works or how to reproduce...
-n
Karl,
I tried and failed, even after adding --pre.
My log file is here:
C:\Python27\Scripts\pip run on 01/24/15 07:51:10
Downloading/unpacking https://pypi.binstar.org/carlkl/simple
Downloading simple
Downloading from URL https://pypi.binstar.org/carlkl/simple
Cleaning up...
Exception:
Traceback (most recent call last):
File C:\Python27\lib\site-packages\pip\basecommand.py, line 122, in
main
status = self.run(options, args)
File C:\Python27\lib\site-packages\pip\commands\install.py, line
278, in run
requirement_set.prepare_files(finder,
force_root_egg_info=self.bundle, bundle=self.bundle)
File C:\Python27\lib\site-packages\pip\req.py, line 1197, in
prepare_files
do_download,
File C:\Python27\lib\site-packages\pip\req.py, line 1375, in unpack_url
self.session,
File C:\Python27\lib\site-packages\pip\download.py, line 582, in
unpack_http_url
unpack_file(temp_location, location, content_type, link)
File C:\Python27\lib\site-packages\pip\util.py, line 627, in
unpack_file
and is_svn_page(file_contents(filename))):
File C:\Python27\lib\site-packages\pip\util.py, line 210, in
file_contents
return fp.read().decode('utf-8')
File C:\Python27\lib\encodings\utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x8b in position 1:
invalid start byte
Do you have any suggestions?
Colin W.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] What should recfromcsv defaults be?
Hi All, This question comes apropos this bugfix #5495 https://github.com/numpy/numpy/pull/5495 that ensures that the default options get passed down the call chain. The current defaults are kwargs.setdefault(case_sensitive, lower) kwargs.setdefault(names, True) kwargs.setdefault(delimiter, ,) kwargs.setdefault(dtype, None) The ones in question are for names and case_sensitive, that, due to the bug, were defaulting to 'True' and None respectively. I think those defaults should be kept rather than the values currently specified in the recfromcsv definition. However, I don't use these tools, so would like some feedback from those who do. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new mingw-w64 based numpy and scipy wheel (still experimental)
2015-01-23 0:23 GMT+01:00 Nathaniel Smith n...@pobox.com: On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner cmkleff...@gmail.com wrote: I took time to create mingw-w64 based wheels of numpy-1.9.1 and scipy-0.15.1 source distributions and put them on https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as on binstar.org. The test matrix is python-2.7 and 3.4 for both 32bit and 64bit. Feedback is welcome. The wheels can be pip installed with: pip install -i https://pypi.binstar.org/carlkl/simple numpy pip install -i https://pypi.binstar.org/carlkl/simple scipy Some technical details: the binaries are build upon OpenBLAS as accelerated BLAS/Lapack. OpenBLAS itself is build with dynamic kernels (similar to MKL) and automatic runtime selection depending on the CPU. The minimal requested feature supplied by the CPU is SSE2. SSE1 and non-SSE CPUs are not supported with this builds. This is the default for 64bit binaries anyway. According to the steam hardware survey, 99.98% of windows computers have SSE2. (http://store.steampowered.com/hwsurvey , click on other settings at the bottom). So this is probably OK :-). OpenBLAS is deployed as part of the numpy wheel. That said, the scipy wheels mentioned above are dependant on the installation of the OpenBLAS based numpy and won't work i.e. with an installed numpy-MKL. This sounds like it probably needs to be fixed before we can recommend the scipy wheels for anyone? OTOH it might be fine to start distributing numpy wheels first. I very much prefer dynamic linking to numpy\core\libopenblas.dll instead of static linking to avoid bloat. This matters, because libopenblas.dll is a heavy library (around 30Mb for amd64). As a consequence all packages with dynamic linkage to OpenBLAS depend on numpy-openblas. This is not different to scipy-MKL that has a dependancy to numpy-MKL - see C. Gohlke's site. For the numpy 32bit builds there are 3 failures for special FP value tests, due to a bug in mingw-w64 that is still present. All scipy versions show up 7 failures with some numerical noise, that could be ignored (or corrected with relaxed asserts in the test code). PR's for numpy and scipy are in preparation. The mingw-w64 compiler used for building can be found at https://bitbucket.org/carlkl/mingw-w64-for-python/downloads. Correct me if I'm wrong, but it looks like there isn't any details on how exactly the compiler was set up? Which is fine, I know you've been doing a ton of work on this and it's much appreciated :-). But eventually I do think a prerequisite for us adopting these as official builds is that we'll need a text document (or an executable script!) that walks through all the steps in setting up the toolchain etc., so that someone starting from scratch could get it all up and running. Otherwise we run the risk of eventually ending up back where we are today, with a creaky old mingw binary snapshot that no-one knows how it works or how to reproduce... This has to be done and is in preperation, but not ready for consumption right now. Some preliminary information is given here: https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwstatic-2014-11-readme.md -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ 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
