[Numpy-discussion] Video meeting this week

[Carl Kleffner]

2015-07-10 19:06 GMT+02:00 Olivier Grisel <olivier.grisel at ensta.org>:

> 2015-07-10 16:47 GMT+02:00 Carl Kleffner <cmkleffner at gmail.com>:
> > Hi Olivier,
> >
> > yes, this is all explained in
> > https://github.com/xianyi/OpenBLAS/wiki/Faq#choose_target_dynamic as
> well.
> > This seems to be necessary for CI systems, right?
>
> The auto detection should work. If not it's a bug and we should find a
> minimalistic reproduction case to report it to the openblas
> maintainers.
>
> I have a debug version of libopenblaspy.dll at hand for 32bit
architecture, 64bit I have to build. I propose to build small testcases
with python, as @wernsaar, the main developer of the newer OpenBLAS kernels
is able to handle this.

Debug builds of libopenblaspy.dll can be used as drop in replacement and
can be used to emit a stack trace as long the segfault is thrown from numpy
or OpenBLAS code. DrMingw may be able to catch segfaults from either, I
havn't tried this yet.


> Or we could choose to build openblas for an old architecture that
> should work everywhere like nehalem for instance.
>

This is a safe solution. Or one could leave out all kernels above
sandybridge in a dynamic build as long OpenBLAS has errors with newer
kernels.

>
> > BTW: i just now renewed the numpy-1.9.2 and scipy-0.15.0 wheels for
> > python-2.6, 2.7, 3.3, 3.4 on anaconda.org.
>
>
The best technical solution IMHO would be to make an extra mingwpy.openblas
python package to load libopenblaspy.dll into the process space, as this
package could be upgraded independant from numpy/scipy. On the other side
this would mean an additionally package dependancy for numpy at least on
the windows platform.


> You mean binstar.org right? What did you change in the new
> numpy-1.9.2? Have you upgraded OpenBLAS? Which version is embedded by
> the way?
>

anaconda.org is the new replacement for binstar.org as announced in the
anaconda ml and should be used right now.

Openblas versions contained:
32bit: 3e33afe  (june)
64bit: fb02cb0  (april used due to a segfault in the more recent rev)


> > I also added scipy-0.16.0rc1 for
> > python-2.6, 2.7, 3.3, 3.4. This means I phase out python-3.2 builds for
> the
> > future.
>
> I don't think Windows users care about python 3.2 support.
>
> > python-3.5 support is up in the air right now.
>
> What do you mean?
>
> Python-3.5 uses VC 2105 on windows. This compiler uses a complete new
variant of CRT libraries. Google for 'universal CRT' to find more
information. The mingw-w64 community does not support this right now. I
didn't find the time to explore this.

Carl

--
> Olivier
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150710/e78f42e6/attachment.html>