goerch

Lots of `ranges` tests fail due to ``` high precision: Error During Test at C:\Users\Win10\AppData\Local\Programs\Julia-1.7.0\share/julia/test\ranges.jl:87 Test threw exception Expression: cmp_sn(widen(x) + widen(y), hi, lo) MethodError: no method matching cmp_sn(::Float32, ::Float16,...

Regarding failures in `numbers`: in the Julia test we find ``` real_types = [Base.BitInteger64_types..., [Rational{T} for T in Base.BitInteger64_types]..., Float32, Float64] for A = real_types, B = real_types T =...

Test distribution also looks broken on Windows. With 5 workers I see: 

Learning by doing: I'm excluding `stdlib` for now and get with my latest commit ``` Julia Version 1.7.0 Commit 3bf9d17731 (2021-11-30 12:12 UTC) Platform Info: OS: Windows (x86_64-w64-mingw32) CPU: Intel(R)...

For a completely different take on this problem see [here](https://github.com/goerch/JuliaInterp.jl). Having made that experience I'd like to propose the following changes: - Maintaining a local copy of Julia tests in...

We can now somehow compare the results from [here](https://github.com/JuliaDebug/JuliaInterpreter.jl/pull/508/files#diff-a50bcc4820918ed9d6d0daa6fe8c473e8bbd7b8435c9bc066864885bebcd7d09) and [there](https://github.com/goerch/JuliaInterp.jl#results). It seems to me there is a bit room for improvement. Do you have any proposals how to best...

`report_package("DiffEqJump")` generates these warnings ``` [toplevel-info] entered into C:\Users\Win10\.julia\packages\DiffEqJump\LVPFs\src\spatial\flatten.jl WARNING: using DiffEqJump.NSM in module DiffEqJump conflicts with an existing identifier. WARNING: using DiffEqJump.JumpSet in module DiffEqJump conflicts with an existing...

Looks like `PaddedViews` is JET-clean now: ``` ═════ 1 possible error found ═════ ┌ @ C:\Users\Win10\.julia\packages\PaddedViews\7EBsT\src\PaddedViews.jl:300 PaddedViews.error("must supply at least one array with concrete axes") │┌ @ error.jl:33 error(::String) ││...

The test case works for me on Julia 1.8.0 yielding ``` WARNING: Wrapping `Vararg` directly in UnionAll is deprecated (wrap the tuple instead). WARNING: Wrapping `Vararg` directly in UnionAll is...

@aviatesk: OP seems to be more concerned about seeing *no* message on the ARM platform?