<div dir="ltr">Got it. Thanks, Nathaniel -- this is really good information.<div><br></div><div>-Robert<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 19, 2015 at 6:55 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 19, 2015 at 2:26 AM, Olivier Grisel<br>
<<a href="mailto:olivier.grisel@ensta.org">olivier.grisel@ensta.org</a>> wrote:<br>
>> Is it possible to test this with py35 as well?<br>
><br>
> Unfortunately not yet.<br>
><br>
>> For MSVC, py35 requires a new compiler toolchain (VS2015) -- is that<br>
>> something mingwpy/mingw-w64 can handle?<br>
><br>
> I am pretty sure that mingwpy does not support Python 3.5 yet.<br>
<br>
</span>Correct.<br>
<span class=""><br>
> I don't know the status of the interop of mingw-w64 w.r.t. VS2015 but as far<br>
> as I know it's not supported yet either. Once the issue is fixed at the<br>
> upstream level, I think mingwpy could be rebuilt to benefit from the fix.<br>
<br>
</span>Upstream mingw-w64 doesn't support interop with any version of visual<br>
studio that was released this millennium -- all the interop stuff is<br>
new in mingwpy.<br>
<br>
VS2015 had a major reorganization of how it handles runtime libraries,<br>
so it's not quite so trivial as just adding support the same way as<br>
was done for VS2008 and VS2010. Or rather, IIUC: we *could* just add<br>
support the same way as before, but there are undocumented rules about<br>
which parts of the new runtime are considered stable and which are<br>
not, so if we did this willy-nilly then we might end up using some of<br>
the "unstable" parts. And then in 2017 the Windows team does some<br>
internal refactoring and pushes it out through windows update and<br>
suddenly NumPy / R / Julia / git / ... all start segfaulting at<br>
startup on Windows, which would be a disaster from everyone's point of<br>
view. We've pointed this out to the Python team at Microsoft and<br>
they've promised to try and put Carl and the relevant mingw-w64 folks<br>
in touch with the relevant internal folks at MS to hopefully tell us<br>
how to do this correctly... fingers crossed :-).<br>
<br>
Aside from that, the main challenge for mingwpy in general is exactly<br>
the issue of upstream support: if we don't get the interop stuff<br>
pushed upstream from mingwpy to mingw-w64, then it will rot and break.<br>
And upstream would love to have this interoperability as an officially<br>
supported feature... but upstream doesn't consider what we have right<br>
now to be maintainable, so they won't take it as is. (And honestly,<br>
this is a reasonable opinion.) So what I've been trying to do is to<br>
scrounge up some funding to support Carl and upstream doing this right<br>
(the rough estimate is ~3 person-months of work).<br>
<br>
The original goal was to get MS to pay for this, on the theory that<br>
they should be cleaning up their own messes, but after 6 months of<br>
back-and-forth we've pretty much given up on that at this point, and<br>
I'm in the process of emailing everyone I can think of who might be<br>
convinced to donate some money to the cause. Maybe we should have a<br>
kickstarter or something, I dunno :-).<br>
<span class="HOEnZb"><font color="#888888"><br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="http://vorpus.org" rel="noreferrer" target="_blank">http://vorpus.org</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div>