[release-0.4] backports for 0.4.7 #18478
Conversation
(cherry picked from commit 2965d24)
The original location of the "Elementary Function" section broke the flow between "Numerical Conversions" about round and the next section: "Rounding Functions". Additionally moved the "Elementary Function" section to be a subsection of "Numeric Comparisons". (cherry picked from commit d1cf43c) removed reference to new-in-0.5 `f.(A)` syntax in backport
The manual would sometimes refer to the language as either "Julia" or "julia". This commit changes references to the Julia language as "Julia" and any reference to the command line program as `julia`. (cherry picked from commit cbefb9b)
(cherry picked from commit c8c417a)
(cherry picked from commit aa6515a)
(cherry picked from commit 904f34c)
"Julia" refers to the language while "`julia`" (lowercase in backticks) specifically refers to the executable. (cherry picked from commit 6313630)
sgesdd by using nextfloat. Now with comments and test so this commit supersedes ad59ceb See http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=13&t=4587&p=11036&hilit=sgesdd#p11036 and scipy/scipy#5401 Fixes #15784 (cherry picked from commit b6988df) ref #15824
This fixes error when calling `Mmap.sync!` on an array that is not memory mapped from a pagesized offset of a file.
````
julia> using Base.Mmap
julia> f = open("arrayfile", "r+");
julia> A = Mmap.mmap(f, Vector{Int64}, (200,), 0);
julia> Mmap.sync!(A)
julia> B = Mmap.mmap(f, Vector{Int64}, (200,), 8);
julia> Mmap.sync!(B)
ERROR: SystemError: msync: Invalid argument
[inlined code] from ./int.jl:33
in sync!(Base.Mmap.#sync!, Array{Int64,1}, Int64) at ./mmap.jl:207 (repeats 2 times)
in eval at ./boot.jl:267
````
Since `Mmap.mmap` maps from the beginning of a page boundary, `pointer(A)` is not at the page boundary when an offset is provided.
But since the pointer returned from `mmap` is aligned at page boundary, `sync!` now recalculates the offset before calling `msync!`.
````
julia> using Base.Mmap
julia> f = open("arrayfile", "r+");
julia> B = Mmap.mmap(f, Vector{Int64}, (200,), 8);
julia> Mmap.sync!(B)
````
(cherry picked from commit fc9fd22)
ref #14885
add note about code signing, and add arm [ci skip] (cherry picked from commit d0a378d)
(cherry picked from commit ad04871)
Fixes #17780 (cherry picked from commit 3f6b2b2)
This mostly reverts #17906 and puts #15521 back in place, but from a slightly more permanent download location now. Unfortunately using the latest opensuse copy of the gcc dll's is causing issues when a cygwin-built Julia tries to load an opensuse-built libzmq.dll. Using these slightly old gcc 5 versions seems to fix it. I suspect the difference is which libstdc++ ABI is being used. GCC 5 has both old and new available, but many distros had it using the old ABI by default for compatibility. GCC 6 (which opensuse is using now) is more likely to be using the new ABI by default. (cherry picked from commit 7b4077f)
This link has moved. (cherry picked from commit 0f805fb)
* Avoid aliasing in in UniformScaling*AbstractMatrix ...and remove unnecessary UniformScaling*SparseMatrixCSC methods * Broaden the tests for non-commutative multiplication * Add Quaternion test case for q*[q] and clean up the Quaternion test type (cherry picked from commit cd94c99)
Fix a redirect for TimeZones.jl flagged by linkcheck
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels |
|
I was expecting just a couple of things in 0.4.7, but that is quite a handful of stuff.Nice! |
|
haven't put out an 0.4 release since just before juliacon, been focused on 0.5 |
|
Mads and Mamba had a strange error with DualNumbers that may or may not be precompilation-related, NullableArrays had a DomainError that looks like a real issue: https://gist.github.com/f2cf4758c26675669fdeba881d628917 |
|
It's probably because precompile has poor support support right now for dealing with packages that drop a dependency (it starts trying to load the existing module, sees that it depends on a non-existant package, but then doesn't have a good solution for dealing with failure in this case) |
|
All these packages are in regular use on JuliaBox, so we do need to keep them all working. Otherwise, I will be swamped with a bunch of stuff. @nkottary Let's try out this branch and see if it fixes all the other recent package issues we have been noticing on JuliaBox. |
|
Ok, sure. |
|
Yeah I'd like to avoid repeatable regressions if we can. This issue with DualNumbers (also manifests with FileIO sometimes) has been seen before on PkgEval JuliaCI/PackageEvaluator.jl#138 so a bit hard to tell if it's new here or intermittent. NullableArrays should be tested locally on this branch, and bisected if reproducible. The second to last commit here should have a build up on julianightlies if binaries helps. |
* Attempt to fix osx travis We're now getting > Error: You must `brew link autoconf` before staticfloat/julia/julia can be installed Probably because Homebrew officially started supporting 10.12 Sierra, and that broke something. Try to use the 10.10 Travis OSX image instead of the default 10.9 (https://docs.travis-ci.com/user/osx-ci-environment/) * explicitly install cmake on osx travis (cherry picked from commit 45bc17d)
|
The NullableArrays issue looks like it's caused by this line https://github.com/JuliaStats/NullableArrays.jl/blob/v0.0.8/test/operators.jl#L81. For reasons I don't understand at all, 57d0834 changed the results of random numbers despite an |
|
Re-ran pkgeval with basically no changes here. https://gist.github.com/3c01c5766474c9cc21520be63bd8df53
|
@nanosoldier
runbenchmarks(ALL, vs = "@2e358ce975029ec97aba5994c17d4a2169c3b085")vs v0.4.6will also run pkgeval
(32 bit linux travis hit an intermittent failure due to a fixed-on-0.5 race condition during bootstrap, log backed up to https://gist.github.com/caa5dcd3cfd4af0081c79b6648926e1c and restarted)