Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

[Ralf Gommers]

On Wed, Jan 27, 2016 at 4:47 AM, Charles R Harris  wrote:

>
>
> On Tue, Jan 26, 2016 at 7:45 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jan 26, 2016 at 7:13 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jan 26, 2016 at 6:58 PM, Charles R Harris <
>>> charlesr.har...@gmail.com> wrote:
>>>


 On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier <
 de...@astro.physik.uni-goettingen.de> wrote:

> Hi Chuck,
>
> > I'm pleased to announce that Numpy 1.11.0b1 is now available on
> sourceforge. This is a source release as the mingw32 toolchain is broken.
> Please test it out and report any errors that you discover. Hopefully we
> can do better with 1.11.0 than we did with 1.10.0 ;)
>
> the tarball seems to be incomplete, hope that does not bode ill ;-)
>
>   adding
> 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
> to sources.
> executing numpy/core/code_generators/generate_numpy_api.py
> error: [Errno 2] No such file or directory:
> 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'
>

 Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the
 `multiarray/*.c.src` files are included, but it works fine in 1.10.x. The
 changes are minimal, the only thing that would seem to matter is the
 removal of setupegg.py. Ralf, any ideas.


> > tar tvf /sw/src/numpy-1.11.0b1.tar.gz |grep arraytypes
> -rw-rw-r-- charris/charris   62563 2016-01-21 20:38
> numpy-1.11.0b1/numpy/core/include/numpy/ndarraytypes.h
> -rw-rw-r-- charris/charris 981 2016-01-21 20:38
> numpy-1.11.0b1/numpy/core/src/multiarray/arraytypes.h
>
> FWIW, the maintenance/1.11.x branch (there is no tag for the beta?)
> builds and passes all tests with Python 2.7.11
> and 3.5.1 on  Mac OS X 10.10.
>
>
 You probably didn't fetch the tags, if they can't be reached from the
 branch head they don't download automatically. Try `git fetch --tags
 upstream`


>>> setupegg.py doesn't seem to matter...
>>>
>>>
>> OK, it is the changes in the root setup.py file, probably the switch to
>> setuptools.
>>
>
> Yep, it's setuptools. If I import sdist from distutils instead, everything
> works fine.
>

Setuptools starts build_src, don't know why yet but it doesn't look to me
like it should be doing that. Issue for more detailed discussion:
https://github.com/numpy/numpy/issues/7127

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[G Young]

Hello all,

I'm trying to update the documentation for building Numpy from source, and
I've hit a brick wall in trying to build the library using OpenBLAS because
I can't seem to link the libopenblas.dll file.  I tried following the
suggestion of placing the DLL in numpy/core as suggested here
 but it
still doesn't pick it up.  What am I doing wrong?

Thanks,

Greg
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

[Nadav Horesh]

Why the dot function/method is slower than @ on python 3.5.1? Tested from the 
latest 1.11 maintenance branch.



np.__version__
Out[39]: '1.11.0.dev0+Unknown'


%timeit A @ c
1 loops, best of 3: 185 µs per loop


%timeit A.dot(c)
1000 loops, best of 3: 526 µs per loop


%timeit np.dot(A,c)
1000 loops, best of 3: 527 µs per loop


A.dtype, A.shape, A.flags
Out[43]: 
(dtype('float32'), (100, 100, 3),   C_CONTIGUOUS : True
   F_CONTIGUOUS : False
   OWNDATA : True
   WRITEABLE : True
   ALIGNED : True
   UPDATEIFCOPY : False)


c.dtype, c.shape, c.flags
Out[44]: 
(dtype('float32'), (3, 3),   C_CONTIGUOUS : True
   F_CONTIGUOUS : False
   OWNDATA : True
   WRITEABLE : True
   ALIGNED : True
   UPDATEIFCOPY : False)





From: NumPy-Discussion  on behalf of 
Charles R Harris 
Sent: 26 January 2016 22:49
To: numpy-discussion; SciPy Developers List; SciPy Users List
Subject: [Numpy-discussion] Numpy 1.11.0b1 is out
  



Hi All,

 I'm pleased to announce that  Numpy 1.11.0b1 is now available on sourceforge. 
This is a source release as the mingw32 toolchain is broken. Please test it out 
and report any errors that you discover. Hopefully we can do better with 1.11.0 
than we did with 1.10.0 ;)

 Chuck

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

[Sebastian Berg]

On Mi, 2016-01-27 at 11:19 +, Nadav Horesh wrote:
> Why the dot function/method is slower than @ on python 3.5.1? Tested
> from the latest 1.11 maintenance branch.
> 

The explanation I think is that you do not have a blas optimization. In
which case the fallback mode is probably faster in the @ case (since it
has SSE2 optimization by using einsum, while np.dot does not do that).

Btw. thanks for all the work getting this done Chuck!

- Sebastian


> 
> 
> np.__version__
> Out[39]: '1.11.0.dev0+Unknown'
> 
> 
> %timeit A @ c
> 1 loops, best of 3: 185 µs per loop
> 
> 
> %timeit A.dot(c)
> 1000 loops, best of 3: 526 µs per loop
> 
> 
> %timeit np.dot(A,c)
> 1000 loops, best of 3: 527 µs per loop
> 
> 
> A.dtype, A.shape, A.flags
> Out[43]: 
> (dtype('float32'), (100, 100, 3),   C_CONTIGUOUS : True
>F_CONTIGUOUS : False
>OWNDATA : True
>WRITEABLE : True
>ALIGNED : True
>UPDATEIFCOPY : False)
> 
> 
> c.dtype, c.shape, c.flags
> Out[44]: 
> (dtype('float32'), (3, 3),   C_CONTIGUOUS : True
>F_CONTIGUOUS : False
>OWNDATA : True
>WRITEABLE : True
>ALIGNED : True
>UPDATEIFCOPY : False)
> 
> 
> 
> 
> 
> From: NumPy-Discussion  on behalf
> of Charles R Harris 
> Sent: 26 January 2016 22:49
> To: numpy-discussion; SciPy Developers List; SciPy Users List
> Subject: [Numpy-discussion] Numpy 1.11.0b1 is out
>   
> 
> 
> 
> Hi All,
> 
>  I'm pleased to announce that  Numpy 1.11.0b1 is now available on
> sourceforge. This is a source release as the mingw32 toolchain is
> broken. Please test it out and report any errors that you discover.
> Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;)
> 
>  Chuck
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[Michael Sarahan]

I'm not sure about the mingw tool chain, but usually on windows at link
time you need a .lib file, called the import library.  The .dll is used at
runtime, not at link time.  This is different from *nix, where the .so
serves both purposes.  The link you posted mentions import files, so I hope
this is helpful information.

Best,
Michael

On Wed, Jan 27, 2016, 03:39 G Young  wrote:

> Hello all,
>
> I'm trying to update the documentation for building Numpy from source, and
> I've hit a brick wall in trying to build the library using OpenBLAS because
> I can't seem to link the libopenblas.dll file.  I tried following the
> suggestion of placing the DLL in numpy/core as suggested here
>  but it
> still doesn't pick it up.  What am I doing wrong?
>
> Thanks,
>
> Greg
> ___
> 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] Building Numpy with OpenBLAS

[G Young]

I do have my site.cfg file pointing to my library which contains a .lib
file along with the appropriate include_dirs parameter.  However, NumPy
can't seem to find / use the DLL file no matter where I put it (numpy/core,
same directory as openblas.lib).  By the way, I should mention that I am
using a slightly dated version of OpenBLAS (0.2.9), but that shouldn't have
any effect I would imagine.

Greg

On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan  wrote:

> I'm not sure about the mingw tool chain, but usually on windows at link
> time you need a .lib file, called the import library.  The .dll is used at
> runtime, not at link time.  This is different from *nix, where the .so
> serves both purposes.  The link you posted mentions import files, so I hope
> this is helpful information.
>
> Best,
> Michael
>
> On Wed, Jan 27, 2016, 03:39 G Young  wrote:
>
>> Hello all,
>>
>> I'm trying to update the documentation for building Numpy from source,
>> and I've hit a brick wall in trying to build the library using OpenBLAS
>> because I can't seem to link the libopenblas.dll file.  I tried following
>> the suggestion of placing the DLL in numpy/core as suggested here
>>  but
>> it still doesn't pick it up.  What am I doing wrong?
>>
>> Thanks,
>>
>> Greg
>> ___
>> 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

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[Michael Sarahan]

When you say find/use, can you please clarify whether you have completed
the compilation/linking successfully?  I'm not clear on exactly when you're
having problems.  What is the error output?

One very helpful tool in diagnosing dll problems is dependency walker:
http://www.dependencywalker.com/

It may be that your openblas has a dependency that it can't load for some
reason.  Dependency walker works on .pyd files as well as .dll files.

Hth,
Michael

On Wed, Jan 27, 2016, 07:40 G Young  wrote:

> I do have my site.cfg file pointing to my library which contains a .lib
> file along with the appropriate include_dirs parameter.  However, NumPy
> can't seem to find / use the DLL file no matter where I put it (numpy/core,
> same directory as openblas.lib).  By the way, I should mention that I am
> using a slightly dated version of OpenBLAS (0.2.9), but that shouldn't have
> any effect I would imagine.
>
> Greg
>
> On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan 
> wrote:
>
>> I'm not sure about the mingw tool chain, but usually on windows at link
>> time you need a .lib file, called the import library.  The .dll is used at
>> runtime, not at link time.  This is different from *nix, where the .so
>> serves both purposes.  The link you posted mentions import files, so I hope
>> this is helpful information.
>>
>> Best,
>> Michael
>>
>> On Wed, Jan 27, 2016, 03:39 G Young  wrote:
>>
>>> Hello all,
>>>
>>> I'm trying to update the documentation for building Numpy from source,
>>> and I've hit a brick wall in trying to build the library using OpenBLAS
>>> because I can't seem to link the libopenblas.dll file.  I tried following
>>> the suggestion of placing the DLL in numpy/core as suggested here
>>>  but
>>> it still doesn't pick it up.  What am I doing wrong?
>>>
>>> Thanks,
>>>
>>> Greg
>>> ___
>>> 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 mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[G Young]

NumPy will "build" successfully, but then when I type "import numpy", it
cannot import the multiarray PYD file.

I am using dependency walker, and that's how I know it's the
libopenblas.dll file that it's not linking to properly, hence my original
question.

Greg

On Wed, Jan 27, 2016 at 1:58 PM, Michael Sarahan  wrote:

> When you say find/use, can you please clarify whether you have completed
> the compilation/linking successfully?  I'm not clear on exactly when you're
> having problems.  What is the error output?
>
> One very helpful tool in diagnosing dll problems is dependency walker:
> http://www.dependencywalker.com/
>
> It may be that your openblas has a dependency that it can't load for some
> reason.  Dependency walker works on .pyd files as well as .dll files.
>
> Hth,
> Michael
>
> On Wed, Jan 27, 2016, 07:40 G Young  wrote:
>
>> I do have my site.cfg file pointing to my library which contains a .lib
>> file along with the appropriate include_dirs parameter.  However, NumPy
>> can't seem to find / use the DLL file no matter where I put it (numpy/core,
>> same directory as openblas.lib).  By the way, I should mention that I am
>> using a slightly dated version of OpenBLAS (0.2.9), but that shouldn't have
>> any effect I would imagine.
>>
>> Greg
>>
>> On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan 
>> wrote:
>>
>>> I'm not sure about the mingw tool chain, but usually on windows at link
>>> time you need a .lib file, called the import library.  The .dll is used at
>>> runtime, not at link time.  This is different from *nix, where the .so
>>> serves both purposes.  The link you posted mentions import files, so I hope
>>> this is helpful information.
>>>
>>> Best,
>>> Michael
>>>
>>> On Wed, Jan 27, 2016, 03:39 G Young  wrote:
>>>
 Hello all,

 I'm trying to update the documentation for building Numpy from source,
 and I've hit a brick wall in trying to build the library using OpenBLAS
 because I can't seem to link the libopenblas.dll file.  I tried following
 the suggestion of placing the DLL in numpy/core as suggested here
  but
 it still doesn't pick it up.  What am I doing wrong?

 Thanks,

 Greg
 ___
 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 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] Building Numpy with OpenBLAS

[Ralf Gommers]

On Wed, Jan 27, 2016 at 3:19 PM, G Young  wrote:

> NumPy will "build" successfully, but then when I type "import numpy", it
> cannot import the multiarray PYD file.
>
> I am using dependency walker, and that's how I know it's the
> libopenblas.dll file that it's not linking to properly, hence my original
> question.
>

The support for MingwPy in numpy.distutils had to be temporarily reverted
(see https://github.com/numpy/numpy/pull/6536), because the patch caused
other issues. So likely it just won't work out of the box now. If you need
it, maybe you can reapply that reverted patch. But otherwise I'd wait a
little bit; we'll sort out the MingwPy build in the near future.

Ralf



> Greg
>
> On Wed, Jan 27, 2016 at 1:58 PM, Michael Sarahan 
> wrote:
>
>> When you say find/use, can you please clarify whether you have completed
>> the compilation/linking successfully?  I'm not clear on exactly when you're
>> having problems.  What is the error output?
>>
>> One very helpful tool in diagnosing dll problems is dependency walker:
>> http://www.dependencywalker.com/
>>
>> It may be that your openblas has a dependency that it can't load for some
>> reason.  Dependency walker works on .pyd files as well as .dll files.
>>
>> Hth,
>> Michael
>>
>> On Wed, Jan 27, 2016, 07:40 G Young  wrote:
>>
>>> I do have my site.cfg file pointing to my library which contains a .lib
>>> file along with the appropriate include_dirs parameter.  However, NumPy
>>> can't seem to find / use the DLL file no matter where I put it (numpy/core,
>>> same directory as openblas.lib).  By the way, I should mention that I am
>>> using a slightly dated version of OpenBLAS (0.2.9), but that shouldn't have
>>> any effect I would imagine.
>>>
>>> Greg
>>>
>>> On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan 
>>> wrote:
>>>
 I'm not sure about the mingw tool chain, but usually on windows at link
 time you need a .lib file, called the import library.  The .dll is used at
 runtime, not at link time.  This is different from *nix, where the .so
 serves both purposes.  The link you posted mentions import files, so I hope
 this is helpful information.

 Best,
 Michael

 On Wed, Jan 27, 2016, 03:39 G Young  wrote:

> Hello all,
>
> I'm trying to update the documentation for building Numpy from source,
> and I've hit a brick wall in trying to build the library using OpenBLAS
> because I can't seem to link the libopenblas.dll file.  I tried following
> the suggestion of placing the DLL in numpy/core as suggested here
>  but
> it still doesn't pick it up.  What am I doing wrong?
>
> Thanks,
>
> Greg
> ___
> 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 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

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[G Young]

I don't need it at this point.  I'm just going through the exercise for
purposes of updating building from source on Windows.  But that's good to
know though.  Thanks!

Greg

On Wed, Jan 27, 2016 at 2:48 PM, Ralf Gommers 
wrote:

>
>
> On Wed, Jan 27, 2016 at 3:19 PM, G Young  wrote:
>
>> NumPy will "build" successfully, but then when I type "import numpy", it
>> cannot import the multiarray PYD file.
>>
>> I am using dependency walker, and that's how I know it's the
>> libopenblas.dll file that it's not linking to properly, hence my original
>> question.
>>
>
> The support for MingwPy in numpy.distutils had to be temporarily reverted
> (see https://github.com/numpy/numpy/pull/6536), because the patch caused
> other issues. So likely it just won't work out of the box now. If you need
> it, maybe you can reapply that reverted patch. But otherwise I'd wait a
> little bit; we'll sort out the MingwPy build in the near future.
>
> Ralf
>
>
>
>> Greg
>>
>> On Wed, Jan 27, 2016 at 1:58 PM, Michael Sarahan 
>> wrote:
>>
>>> When you say find/use, can you please clarify whether you have completed
>>> the compilation/linking successfully?  I'm not clear on exactly when you're
>>> having problems.  What is the error output?
>>>
>>> One very helpful tool in diagnosing dll problems is dependency walker:
>>> http://www.dependencywalker.com/
>>>
>>> It may be that your openblas has a dependency that it can't load for
>>> some reason.  Dependency walker works on .pyd files as well as .dll files.
>>>
>>> Hth,
>>> Michael
>>>
>>> On Wed, Jan 27, 2016, 07:40 G Young  wrote:
>>>
 I do have my site.cfg file pointing to my library which contains a .lib
 file along with the appropriate include_dirs parameter.  However, NumPy
 can't seem to find / use the DLL file no matter where I put it (numpy/core,
 same directory as openblas.lib).  By the way, I should mention that I am
 using a slightly dated version of OpenBLAS (0.2.9), but that shouldn't have
 any effect I would imagine.

 Greg

 On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan 
 wrote:

> I'm not sure about the mingw tool chain, but usually on windows at
> link time you need a .lib file, called the import library.  The .dll is
> used at runtime, not at link time.  This is different from *nix, where the
> .so serves both purposes.  The link you posted mentions import files, so I
> hope this is helpful information.
>
> Best,
> Michael
>
> On Wed, Jan 27, 2016, 03:39 G Young  wrote:
>
>> Hello all,
>>
>> I'm trying to update the documentation for building Numpy from
>> source, and I've hit a brick wall in trying to build the library using
>> OpenBLAS because I can't seem to link the libopenblas.dll file.  I tried
>> following the suggestion of placing the DLL in numpy/core as suggested
>> here
>>  but
>> it still doesn't pick it up.  What am I doing wrong?
>>
>> Thanks,
>>
>> Greg
>> ___
>> 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 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 mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[Ralf Gommers]

On Wed, Jan 27, 2016 at 3:51 PM, G Young  wrote:

> I don't need it at this point.  I'm just going through the exercise for
> purposes of updating building from source on Windows.  But that's good to
> know though.  Thanks!
>

That effort is much appreciated by the way. Updating the build info on all
platforms on http://scipy.org/scipylib/building/index.html is a significant
amount of work, and it has never been in a state one could call complete.
So more contributions definitely welcome!

Ralf



>
> Greg
>
> On Wed, Jan 27, 2016 at 2:48 PM, Ralf Gommers 
> wrote:
>
>>
>>
>> On Wed, Jan 27, 2016 at 3:19 PM, G Young  wrote:
>>
>>> NumPy will "build" successfully, but then when I type "import numpy", it
>>> cannot import the multiarray PYD file.
>>>
>>> I am using dependency walker, and that's how I know it's the
>>> libopenblas.dll file that it's not linking to properly, hence my original
>>> question.
>>>
>>
>> The support for MingwPy in numpy.distutils had to be temporarily reverted
>> (see https://github.com/numpy/numpy/pull/6536), because the patch caused
>> other issues. So likely it just won't work out of the box now. If you need
>> it, maybe you can reapply that reverted patch. But otherwise I'd wait a
>> little bit; we'll sort out the MingwPy build in the near future.
>>
>> Ralf
>>
>>
>>
>>> Greg
>>>
>>> On Wed, Jan 27, 2016 at 1:58 PM, Michael Sarahan 
>>> wrote:
>>>
 When you say find/use, can you please clarify whether you have
 completed the compilation/linking successfully?  I'm not clear on exactly
 when you're having problems.  What is the error output?

 One very helpful tool in diagnosing dll problems is dependency walker:
 http://www.dependencywalker.com/

 It may be that your openblas has a dependency that it can't load for
 some reason.  Dependency walker works on .pyd files as well as .dll files.

 Hth,
 Michael

 On Wed, Jan 27, 2016, 07:40 G Young  wrote:

> I do have my site.cfg file pointing to my library which contains a
> .lib file along with the appropriate include_dirs parameter.  However,
> NumPy can't seem to find / use the DLL file no matter where I put it
> (numpy/core, same directory as openblas.lib).  By the way, I should 
> mention
> that I am using a slightly dated version of OpenBLAS (0.2.9), but that
> shouldn't have any effect I would imagine.
>
> Greg
>
> On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan 
> wrote:
>
>> I'm not sure about the mingw tool chain, but usually on windows at
>> link time you need a .lib file, called the import library.  The .dll is
>> used at runtime, not at link time.  This is different from *nix, where 
>> the
>> .so serves both purposes.  The link you posted mentions import files, so 
>> I
>> hope this is helpful information.
>>
>> Best,
>> Michael
>>
>> On Wed, Jan 27, 2016, 03:39 G Young  wrote:
>>
>>> Hello all,
>>>
>>> I'm trying to update the documentation for building Numpy from
>>> source, and I've hit a brick wall in trying to build the library using
>>> OpenBLAS because I can't seem to link the libopenblas.dll file.  I tried
>>> following the suggestion of placing the DLL in numpy/core as suggested
>>> here
>>>  but
>>> it still doesn't pick it up.  What am I doing wrong?
>>>
>>> Thanks,
>>>
>>> Greg
>>> ___
>>> 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 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 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/m

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

[Derek Homeier]

On 27 Jan 2016, at 2:58 AM, Charles R Harris  wrote:
> 
> FWIW, the maintenance/1.11.x branch (there is no tag for the beta?) builds 
> and passes all tests with Python 2.7.11
> and 3.5.1 on  Mac OS X 10.10.
> 
> 
> You probably didn't fetch the tags, if they can't be reached from the branch 
> head they don't download automatically. Try `git fetch --tags upstream`

Thanks, that did it. Successfully tested v1.11.0b1 on 10.11 and with Python 
2.7.8 and 3.4.1 on openSUSE 13.2 as well.

Derek

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Bump warning stacklevel

[Sebastian Berg]

Hi all,

in my PR about warnings suppression, I currently also have a commit
which bumps the warning stacklevel to two (or three), i.e. use:

warnings.warn(..., stacklevel=2)

(almost) everywhere. This means that for example (take only the empty
warning):

np.mean([])

would not print:

/usr/lib/python2.7/dist-packages/numpy/core/_methods.py:55:
RuntimeWarning: Mean of empty slice.
  warnings.warn("Mean of empty slice.", RuntimeWarning)

but instead print the actual `np.mean([])` code line (the repetition of
the warning command is always a bit funny).

The advantage is nicer printing for the user.

The disadvantage would probably mostly be that existing warning filters
that use the `module` keyword argument, will fail.

Any objections/thoughts about doing this change to try to better report
the offending code line? Frankly, I am not sure whether there might be
a python standard about this, but I would expect that for a library
such as numpy, it makes sense to change. But, if downstream uses
warning filters with modules, we might want to reconsider for example.

- Sebastian

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building Numpy with OpenBLAS

[Carl Kleffner]

In my timeplan the next mingwpy PR on numpy master is anticipated to take
place at the weekend, together with a build description. This PR is
targeted to build numpy with OpenBLAS.

Carl

2016-01-27 16:01 GMT+01:00 Ralf Gommers :

>
>
> On Wed, Jan 27, 2016 at 3:51 PM, G Young  wrote:
>
>> I don't need it at this point.  I'm just going through the exercise for
>> purposes of updating building from source on Windows.  But that's good to
>> know though.  Thanks!
>>
>
> That effort is much appreciated by the way. Updating the build info on all
> platforms on http://scipy.org/scipylib/building/index.html is a
> significant amount of work, and it has never been in a state one could call
> complete. So more contributions definitely welcome!
>
> Ralf
>
>
>
>>
>> Greg
>>
>> On Wed, Jan 27, 2016 at 2:48 PM, Ralf Gommers 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 27, 2016 at 3:19 PM, G Young  wrote:
>>>
 NumPy will "build" successfully, but then when I type "import numpy",
 it cannot import the multiarray PYD file.

 I am using dependency walker, and that's how I know it's the
 libopenblas.dll file that it's not linking to properly, hence my original
 question.

>>>
>>> The support for MingwPy in numpy.distutils had to be temporarily
>>> reverted (see https://github.com/numpy/numpy/pull/6536), because the
>>> patch caused other issues. So likely it just won't work out of the box now.
>>> If you need it, maybe you can reapply that reverted patch. But otherwise
>>> I'd wait a little bit; we'll sort out the MingwPy build in the near future.
>>>
>>> Ralf
>>>
>>>
>>>
 Greg

 On Wed, Jan 27, 2016 at 1:58 PM, Michael Sarahan 
 wrote:

> When you say find/use, can you please clarify whether you have
> completed the compilation/linking successfully?  I'm not clear on exactly
> when you're having problems.  What is the error output?
>
> One very helpful tool in diagnosing dll problems is dependency walker:
> http://www.dependencywalker.com/
>
> It may be that your openblas has a dependency that it can't load for
> some reason.  Dependency walker works on .pyd files as well as .dll files.
>
> Hth,
> Michael
>
> On Wed, Jan 27, 2016, 07:40 G Young  wrote:
>
>> I do have my site.cfg file pointing to my library which contains a
>> .lib file along with the appropriate include_dirs parameter.  However,
>> NumPy can't seem to find / use the DLL file no matter where I put it
>> (numpy/core, same directory as openblas.lib).  By the way, I should 
>> mention
>> that I am using a slightly dated version of OpenBLAS (0.2.9), but that
>> shouldn't have any effect I would imagine.
>>
>> Greg
>>
>> On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan 
>> wrote:
>>
>>> I'm not sure about the mingw tool chain, but usually on windows at
>>> link time you need a .lib file, called the import library.  The .dll is
>>> used at runtime, not at link time.  This is different from *nix, where 
>>> the
>>> .so serves both purposes.  The link you posted mentions import files, 
>>> so I
>>> hope this is helpful information.
>>>
>>> Best,
>>> Michael
>>>
>>> On Wed, Jan 27, 2016, 03:39 G Young  wrote:
>>>
 Hello all,

 I'm trying to update the documentation for building Numpy from
 source, and I've hit a brick wall in trying to build the library using
 OpenBLAS because I can't seem to link the libopenblas.dll file.  I 
 tried
 following the suggestion of placing the DLL in numpy/core as suggested
 here
  but
 it still doesn't pick it up.  What am I doing wrong?

 Thanks,

 Greg
 ___
 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 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-Dis

Re: [Numpy-discussion] Bump warning stacklevel

[Ralf Gommers]

On Wed, Jan 27, 2016 at 7:26 PM, Sebastian Berg 
wrote:

> Hi all,
>
> in my PR about warnings suppression, I currently also have a commit
> which bumps the warning stacklevel to two (or three), i.e. use:
>
> warnings.warn(..., stacklevel=2)
>
> (almost) everywhere. This means that for example (take only the empty
> warning):
>
> np.mean([])
>
> would not print:
>
> /usr/lib/python2.7/dist-packages/numpy/core/_methods.py:55:
> RuntimeWarning: Mean of empty slice.
>   warnings.warn("Mean of empty slice.", RuntimeWarning)
>
> but instead print the actual `np.mean([])` code line (the repetition of
> the warning command is always a bit funny).
>
> The advantage is nicer printing for the user.
>
> The disadvantage would probably mostly be that existing warning filters
> that use the `module` keyword argument, will fail.
>
> Any objections/thoughts about doing this change to try to better report
> the offending code line?


This has annoyed me for a long time, it's hard now to figure out where
warnings really come from. Especially when running something large like
scipy.test(). So +1.


> Frankly, I am not sure whether there might be
> a python standard about this, but I would expect that for a library
> such as numpy, it makes sense to change. But, if downstream uses
> warning filters with modules, we might want to reconsider for example.
>

There probably are usages of `module`, but I'd expect that it's used a lot
less than `category` or `message`. A quick search through the scipy repo
gave me only a single case where `module` was used, and that's in
deprecated weave code so soon the count is zero.  Also, even for relevant
usage, nothing will break in a bad way - some more noise or a spurious test
failure in numpy-using code isn't the end of the world I'd say.

One issue will be how to keep this consistent. `stacklevel` is used so
rarely that new PRs will always omit it for new warnings. Will we just rely
on code review, or would a private wrapper around `warn` to use inside
numpy plus a test that checks that the wrapper is used everywhere be
helpful here?

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Bump warning stacklevel

[Nathaniel Smith]

+1

On Wed, Jan 27, 2016 at 10:26 AM, Sebastian Berg  wrote:

> Hi all,
>
> in my PR about warnings suppression, I currently also have a commit
> which bumps the warning stacklevel to two (or three), i.e. use:
>
> warnings.warn(..., stacklevel=2)
>
> (almost) everywhere. This means that for example (take only the empty
> warning):
>
> np.mean([])
>
> would not print:
>
> /usr/lib/python2.7/dist-packages/numpy/core/_methods.py:55:
> RuntimeWarning: Mean of empty slice.
>   warnings.warn("Mean of empty slice.", RuntimeWarning)
>
> but instead print the actual `np.mean([])` code line (the repetition of
> the warning command is always a bit funny).
>
> The advantage is nicer printing for the user.
>
> The disadvantage would probably mostly be that existing warning filters
> that use the `module` keyword argument, will fail.
>
> Any objections/thoughts about doing this change to try to better report
> the offending code line? Frankly, I am not sure whether there might be
> a python standard about this, but I would expect that for a library
> such as numpy, it makes sense to change. But, if downstream uses
> warning filters with modules, we might want to reconsider for example.
>
> - Sebastian
> ___
> 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] Building Numpy with OpenBLAS

[G Young]

That's great!  I look forward to seeing that.

Greg

On Wed, Jan 27, 2016 at 6:27 PM, Carl Kleffner  wrote:

> In my timeplan the next mingwpy PR on numpy master is anticipated to take
> place at the weekend, together with a build description. This PR is
> targeted to build numpy with OpenBLAS.
>
> Carl
>
> 2016-01-27 16:01 GMT+01:00 Ralf Gommers :
>
>>
>>
>> On Wed, Jan 27, 2016 at 3:51 PM, G Young  wrote:
>>
>>> I don't need it at this point.  I'm just going through the exercise for
>>> purposes of updating building from source on Windows.  But that's good to
>>> know though.  Thanks!
>>>
>>
>> That effort is much appreciated by the way. Updating the build info on
>> all platforms on http://scipy.org/scipylib/building/index.html is a
>> significant amount of work, and it has never been in a state one could call
>> complete. So more contributions definitely welcome!
>>
>> Ralf
>>
>>
>>
>>>
>>> Greg
>>>
>>> On Wed, Jan 27, 2016 at 2:48 PM, Ralf Gommers 
>>> wrote:
>>>


 On Wed, Jan 27, 2016 at 3:19 PM, G Young  wrote:

> NumPy will "build" successfully, but then when I type "import numpy",
> it cannot import the multiarray PYD file.
>
> I am using dependency walker, and that's how I know it's the
> libopenblas.dll file that it's not linking to properly, hence my original
> question.
>

 The support for MingwPy in numpy.distutils had to be temporarily
 reverted (see https://github.com/numpy/numpy/pull/6536), because the
 patch caused other issues. So likely it just won't work out of the box now.
 If you need it, maybe you can reapply that reverted patch. But otherwise
 I'd wait a little bit; we'll sort out the MingwPy build in the near future.

 Ralf



> Greg
>
> On Wed, Jan 27, 2016 at 1:58 PM, Michael Sarahan 
> wrote:
>
>> When you say find/use, can you please clarify whether you have
>> completed the compilation/linking successfully?  I'm not clear on exactly
>> when you're having problems.  What is the error output?
>>
>> One very helpful tool in diagnosing dll problems is dependency
>> walker: http://www.dependencywalker.com/
>>
>> It may be that your openblas has a dependency that it can't load for
>> some reason.  Dependency walker works on .pyd files as well as .dll 
>> files.
>>
>> Hth,
>> Michael
>>
>> On Wed, Jan 27, 2016, 07:40 G Young  wrote:
>>
>>> I do have my site.cfg file pointing to my library which contains a
>>> .lib file along with the appropriate include_dirs parameter.  However,
>>> NumPy can't seem to find / use the DLL file no matter where I put it
>>> (numpy/core, same directory as openblas.lib).  By the way, I should 
>>> mention
>>> that I am using a slightly dated version of OpenBLAS (0.2.9), but that
>>> shouldn't have any effect I would imagine.
>>>
>>> Greg
>>>
>>> On Wed, Jan 27, 2016 at 1:14 PM, Michael Sarahan >> > wrote:
>>>
 I'm not sure about the mingw tool chain, but usually on windows at
 link time you need a .lib file, called the import library.  The .dll is
 used at runtime, not at link time.  This is different from *nix, where 
 the
 .so serves both purposes.  The link you posted mentions import files, 
 so I
 hope this is helpful information.

 Best,
 Michael

 On Wed, Jan 27, 2016, 03:39 G Young  wrote:

> Hello all,
>
> I'm trying to update the documentation for building Numpy from
> source, and I've hit a brick wall in trying to build the library using
> OpenBLAS because I can't seem to link the libopenblas.dll file.  I 
> tried
> following the suggestion of placing the DLL in numpy/core as suggested
> here
>  but
> it still doesn't pick it up.  What am I doing wrong?
>
> Thanks,
>
> Greg
> ___
> 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 mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> 

Re: [Numpy-discussion] Bump warning stacklevel

[sebastian]

On 2016-01-27 21:01, Ralf Gommers wrote:

On Wed, Jan 27, 2016 at 7:26 PM, Sebastian Berg
 wrote:


Hi all,

in my PR about warnings suppression, I currently also have a commit
which bumps the warning stacklevel to two (or three), i.e. use:

warnings.warn(..., stacklevel=2)

(almost) everywhere. This means that for example (take only the
empty
warning):

np.mean([])

would not print:

/usr/lib/python2.7/dist-packages/numpy/core/_methods.py:55:
RuntimeWarning: Mean of empty slice.
warnings.warn("Mean of empty slice.", RuntimeWarning)

but instead print the actual `np.mean([])` code line (the repetition
of
the warning command is always a bit funny).

The advantage is nicer printing for the user.

The disadvantage would probably mostly be that existing warning
filters
that use the `module` keyword argument, will fail.

Any objections/thoughts about doing this change to try to better
report
the offending code line?


This has annoyed me for a long time, it's hard now to figure out where
warnings really come from. Especially when running something large
like scipy.test(). So +1.


Frankly, I am not sure whether there might be
a python standard about this, but I would expect that for a library
such as numpy, it makes sense to change. But, if downstream uses
warning filters with modules, we might want to reconsider for
example.


There probably are usages of `module`, but I'd expect that it's used a
lot less than `category` or `message`. A quick search through the
scipy repo gave me only a single case where `module` was used, and
that's in deprecated weave code so soon the count is zero.  Also, even
for relevant usage, nothing will break in a bad way - some more noise
or a spurious test failure in numpy-using code isn't the end of the
world I'd say.

One issue will be how to keep this consistent. `stacklevel` is used so
rarely that new PRs will always omit it for new warnings. Will we just
rely on code review, or would a private wrapper around `warn` to use
inside numpy plus a test that checks that the wrapper is used
everywhere be helpful here?



Yeah, I mean you could add tests for the individual functions in 
principle.
I am not sure if adding an alias helps much, how are we going to test 
that
warnings.warn is not being used? Seems like quite a bit of voodoo 
necessary

for that.

- Sebastian




Ralf


___
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] Bump warning stacklevel

[Ralf Gommers]

On Wed, Jan 27, 2016 at 11:02 PM, sebastian 
wrote:

> On 2016-01-27 21:01, Ralf Gommers wrote:
>
>>
>> One issue will be how to keep this consistent. `stacklevel` is used so
>> rarely that new PRs will always omit it for new warnings. Will we just
>> rely on code review, or would a private wrapper around `warn` to use
>> inside numpy plus a test that checks that the wrapper is used
>> everywhere be helpful here?
>>
>>
> Yeah, I mean you could add tests for the individual functions in principle.
> I am not sure if adding an alias helps much, how are we going to test that
> warnings.warn is not being used? Seems like quite a bit of voodoo necessary
> for that.
>

I was thinking something along these lines, but with a regexp checking for
warnings.warn:
https://github.com/scipy/scipy/blob/master/scipy/fftpack/tests/test_import.py

Probably more trouble than it's worth though.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Bump warning stacklevel

[Benjamin Root]

I like the idea of bumping the stacklevel in principle, but I am not sure
it is all that practical. For example, if a warning came up when doing "x /
y", I am assuming that it is emitted from within the ufunc np.divide(). So,
you would need two stacklevels based on whether the entry point was the
operator or a direct call to np.divide()? Also, I would imagine it might
get weird for numpy functions called within other numpy functions. Or
perhaps I am not totally understanding how this would be done?

Ben Root


On Wed, Jan 27, 2016 at 5:07 PM, Ralf Gommers 
wrote:

>
>
> On Wed, Jan 27, 2016 at 11:02 PM, sebastian 
> wrote:
>
>> On 2016-01-27 21:01, Ralf Gommers wrote:
>>
>>>
>>> One issue will be how to keep this consistent. `stacklevel` is used so
>>> rarely that new PRs will always omit it for new warnings. Will we just
>>> rely on code review, or would a private wrapper around `warn` to use
>>> inside numpy plus a test that checks that the wrapper is used
>>> everywhere be helpful here?
>>>
>>>
>> Yeah, I mean you could add tests for the individual functions in
>> principle.
>> I am not sure if adding an alias helps much, how are we going to test that
>> warnings.warn is not being used? Seems like quite a bit of voodoo
>> necessary
>> for that.
>>
>
> I was thinking something along these lines, but with a regexp checking for
> warnings.warn:
> https://github.com/scipy/scipy/blob/master/scipy/fftpack/tests/test_import.py
>
> Probably more trouble than it's worth though.
>
> Ralf
>
>
> ___
> 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