Thanks for all your ideas. The next version will contain an augumented libopenblas.dll in both numpy and scipy. On the long term I would prefer an external openblas wheel package, if there is an agreement about this among numpy-dev.
Another idea for the future is to conditionally load a debug version of libopenblas instead. Together with the backtrace.dll (part of mingwstatic, but undocumentated right now) a meaningfull stacktrace in case of segfaults inside the code comiled with mingwstatic will be given. 2015-01-26 2:16 GMT+01:00 Sturla Molden <[email protected]>: > On 25/01/15 22:15, Matthew Brett wrote: > > > I agree, that shipping openblas with both numpy and scipy seems > > perfectly reasonable to me - I don't think anyone will much care about > > the 30M, and I think our job is to make something that works with the > > least complexity and likelihood of error. > > Yes. Make something that works first, optimize for space later. > > > > It would be good to rename the dll according to the package and > > version though, to avoid a scipy binary using a pre-loaded but > > incompatible 'libopenblas.dll'. Say something like > > openblas-scipy-0.15.1.dll - on the basis that there can only be one > > copy of scipy loaded at a time. > > That is a good idea and we should do this for NumPy too I think. > > > > Sturla > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
