I work at a small consulting company who’s primary business involves solving large scale PDE constrained optimization problems. Back in 2015 we decided to move our code base from fortran into Julia - it was a painful process at times but has more than paid off with greatly reduced development times. A huge thank you to everyone who has contributed to the development of the language!
We are currently still running Julia 1.0.2 as #30679 has broken a large portion of our code on the 1.0.3 and 1.1 releases. This has been fixed now on master, however it looks as though #31435 is going to prevent us from using 1.2 when it comes out unless it get addressed before the release.
We have been able to modify some of our code to run under 1.1 and we see a significant improvement in the speed of those codes - this is great! I’m very eager to be able to pass those speedups on to our clients but I’m concerned that we are going to have to have to stay on 1.0.2 again after 1.2 comes out as a result of #31435. We will get a pull request submitted shortly to provide a potential fix, however it is somewhat hard to do that without understanding the intent and desired behaviour of the of the commit that caused the problem in the first place.
I’m interested in any advice anyone can provide on how we may be able to overcome these difficulties. Is it possible to get an increase in the frequency of patch releases? We would be happy to help out with this if we can, but I wouldn’t know where to start on that front.
I realize this probably isn’t what you’re looking for, but if there really is just a single function you are having a problem with, as a last resort you can always just fix it by overwriting the offending method. Ever since Julia 0.6 it has been easy to safely overwrite any method, regardless of whether it is defined in Base or in some other module. Of course, with this kind of monkey-patching you have just as much power and responsibility as if you were changing Julia’s source yourself, but the advantage is that there is no need to recompile anything manually:
julia> using SparseArrays
julia> SparseArrays.sprand(x::Integer, y::Integer, p::AbstractFloat) = println("hello world")
julia> sprand(1, 2, 0.1)
hello world
I wouldn’t recommend this unless there’s no other way, but given that the issue you refer to appears to be something that could be (temporarily) resolved by just overwriting one method, this seems like a potential solution.
Julia release candidates are tested against open source packages that are registered, so I assume your problem comes from not being able to make your code public.
You could test your packages/infrastructure on master (or nightly) continuously, so you would learn about regressions very quickly and be able report and act on them.
Alternatively (this is complementary to the above) perhaps you can package and register some of your code, again catching bugs in release candidates.
You may be able to subcontract all of this to a trusted third party, eg Julia Computing.
Shoot — what a confluence of edge cases and papercuts. That’s frustrating.
It looks like your proposed fix for #31435 is simple and easy — and even though we’re now in the feature freeze it’s a bug/regression that can still be fixed before the 1.2 release happens. The easiest way to get attention here is by bumping the relevant issues or (better yet) just going ahead and submitting a pull request to fix it.
As far as the other issue, it’s flagged for a 1.1.1 backport, but I’m not sure what the status of the 1.1.1 release is.
Edit: I’ll also add that I’ve done exactly what @rdeits suggested above — it’s a great solution in a pinch.
It also sounds like it should be possible to upgrade to 1.0.4 which appears to have fixed the original bug that was blocking the use of 1.0.3. Of course, upgrading to 1.2 is preferable for many reasons.