Make Rmath.jl work on Windows

[davidanthoff]

This issue is just tracking JuliaStats/Rmath.jl#7. I believe this issue here needs to be added to the 0.5.0 milestone, and that is why I added a duplicate here in the julia repo.

My understanding is that StatsFuns.jl relies on rmath. Previously rmath was part of base and worked on all platforms. #6131 moved it out into JuliaStats/Rmath.jl, but that package doesn't work on Windows, so now StatsFuns.jl doesn't work anymore on Windows, and with that essentially the whole julia statistics stack.

[StefanKarpinski]

What is the action that needs to be taken in Base Julia to address this?

[davidanthoff]

Nothing in base, I believe. But this should still be release blocking for 0.5.0. #17293 removed a feature from base that the whole stats stack relies on, without having a replacement on Windows. Probably #17293 should just not have been merged until the replacement (Rmath.jl) was ready, or now, given that it is merged, a 0.5.0 should wait until the replacement is in shape.

[tkelman]

Yeah Stefan you merged that way before it was ready. I'm working on this but it's not a base issue, it's just a lot of packages that are broken that could have been done less disruptively.

[StefanKarpinski]

Who are we worried about disrupting? People who use master to do statistical work? Seems like an imaginary crowd to me. I agree that JuliaStats/Rmath.jl#7 is a very high priority, but forcing Base to wait around until it's fixed doesn't get it fixed any faster. Let's get a release out the door and packages like Rmath can catch up as soon as they're able.

[tkelman]

People who we're asking to test 0.5 and report ways in which it's broken. A release doesn't do much good if it's unusable.

[davidanthoff]

And note that this breaks almost everything. StatsFun.jl is really, really at the base of an enormous dependency graph. Almost every single package that I'm trying to use right now doesn't work, even lots that at first glance have nothing to do with statistical work. I think one complicating factor is that this seems to break the precompile chain, i.e. StatsFun doesn't precompile, and so no depending package precompiles either.

In terms of process management, I think this really has to be addressed before 0.5.0 is released, i.e. it should be a release criteria for the final version. If you want to release a RC before that, it would mean that probably no windows dev could check and update packages or use the RC in any even half meaningful way. Not ideal, but maybe that is what you want to do. If so, it does mean that you should have one milestone 0.5.0-RC1 and one for 0.5.0, otherwise how would you track something like this?

[tkelman]

forcing Base to wait around until it's fixed doesn't get it fixed any faster

On the contrary, it very much would have. I've had to waste a huge amount of time the past week putting out fires that never needed to exist if I could have spent another day or two putting in place the non disruptive version ahead of time for a smooth transition. When something is marked WIP by the author, please ask before fixing what you assume to be the remaining issues with it and merging instantly. I'm going to be making more PR's from my personal fork to avoid that.