Error handling in Juno

lhupe · August 20, 2018, 9:58am

I have recently noticed that error messages (the red pop-up thingies) in Juno are having some kind of problem.
The MWE

throw(ErrorException("test"))

creates this error message

MethodError: no method matching -(::Nothing, ::Int64)
Closest candidates are:
  -(!Matched::Complex{Bool}, ::Real) at complex.jl:298
  -(!Matched::Missing, ::Number) at missing.jl:93
  -(!Matched::Base.CoreLogging.LogLevel, ::Integer) at logging.jl:107

This problem does not occur when I run the code in the REPL (both in a seperate terminal and in Juno).
I use julia-0.7.0 with all packages up to date.

Edit: as discussed below, this is not a Juno problem but an issue with the julia binaries provided by Arch Linux. I haven’t filed a bug report with the Arch repo yet, but if the problem doesn’t disappear in 1.0, I will.

pfitzseb · August 20, 2018, 10:34am

I can’t reproduce this problem with the latest release of Juno on Julia 1.0 (or Julia 0.7):

lhupe · August 20, 2018, 11:03am

Hmm. Weird. Do you know any configuration problem that could have caused
this behaviour on my side?

pfitzseb · August 20, 2018, 11:06am

No, but could you paste the contents of the "julia-client" portion of ~/.atom/config.cson here? Also, what does pkg> status look like?

lhupe · August 20, 2018, 11:09am

  "julia-client":
    consoleOptions:
      terminal: "termite"
    firstBoot: false
    juliaOptions: {}
    uiOptions:
      enableMenu: true
      enableToolBar: true
      usePlotPane: false

and

    Status `~/.julia/environments/v0.7/Project.toml`
  [c52e3926] Atom v0.7.3
  [6e4b80f9] BenchmarkTools v0.4.0
  [53a63b46] CodeTools v0.6.1
  [31c24e10] Distributions v0.16.2
  [33d173f1] DocSeeker v0.2.0
  [4986ee89] DynamicalBilliards v2.1.0+ [`~/.julia/dev/DynamicalBilliards`]
  [7a1cc6ca] FFTW v0.2.4
  [5789e2e9] FileIO v1.0.1
  [cd3eb016] HTTP v0.6.14
  [7073ff75] IJulia v1.9.3
  [a98d9a8b] Interpolations v0.8.0
  [033835bb] JLD2 v0.1.0
  [e5e0dc1b] Juno v0.5.2
  [2fda8390] LsqFit v0.6.0+ [`~/.julia/dev/LsqFit`]
  [32113eaa] PkgBenchmark v0.1.1
  [438e738f] PyCall v1.18.0
  [d330b81b] PyPlot v2.6.0
  [295af30f] Revise v0.7.0
  [90137ffa] StaticArrays v0.8.3
  [2913bbd2] StatsBase v0.25.0
  [f218859d] TimeseriesPrediction v0.4.0
  [a2a6695c] TreeViews v0.3.0
  [9602ed7d] Unrolled v0.1.0

pfitzseb · August 20, 2018, 11:16am

Hm, those look fine. Anything weird you did before trying to eval that code?

lhupe · August 20, 2018, 11:28am

I think I found the issue: until now I’ve been using the Arch Linux julia-0.7.0 package. Switching to the official binaries solved the problem.

pfitzseb · August 20, 2018, 11:30am

Very weird. Glad it’s working for you now though.

lhupe · August 21, 2018, 1:17pm

Update: still doesn’t work with the new julia 1.0 package (julia-2:1.0.0-1) – I have filed a bug report with the Arch package maintainer, we’ll have to wait and see what happens.

NHDaly · August 21, 2018, 1:46pm

Huh, I’m not so sure. I’m on a Mac, using julia v0.7.0 downloaded from the Julia website, and i’m seeing similar error messages.

I, like pfitzseb, don’t experience your problem with your test example (for me, throw(ErrorException("test")) correctly prints > test in red).

However, I do see the exact same error message as you when I experience a StackOverflowException:

Here’s my MWE:

foo() = foo()     # > foo
foo()             # causes "Julia Client – Internal Error" "MethodError: no method matching -(::Nothing, ::Int64)"

And here’s the full Atom error message:

Julia Client – Internal Error
MethodError: no method matching -(::Nothing, ::Int64)
Closest candidates are:
  -(!Matched::Complex{Bool}, ::Real) at complex.jl:298
  -(!Matched::Missing, ::Number) at missing.jl:93
  -(!Matched::Base.CoreLogging.LogLevel, ::Integer) at logging.jl:107
  ...
try_yieldto(::typeof(Base.ensure_rescheduled), ::Base.RefValue{Task}) at event.jl:196
wait() at event.jl:255
wait(::Condition) at event.jl:46
_wait(::Task) at task.jl:189
macro expansion at task.jl:205 [inlined]
(::getfield(Atom, Symbol("##107#112")))(::Dict{String,Any}) at eval.jl:82
handlemsg(::Dict{String,Any}, ::Dict{String,Any}) at comm.jl:168
(::getfield(Atom, Symbol("##14#17")){Array{Any,1}})() at task.jl:262

And in the REPL Console, I get the expected error:

julia> foo()
ERROR: StackOverflowError:

pfitzseb · August 21, 2018, 2:03pm

Ahaaa, that was very helpful. Bug is fixed with this commit. Thanks, @NHDaly!

There still seems to be something wrong with the Arch executable considering that it throws weird errors (or stackoverflows in the wrong place).

NHDaly · August 21, 2018, 2:05pm

Yeah that sounds right. +1

So fast!! good stuff!!

lhupe · August 21, 2018, 2:16pm

Using Atom.jl master, the only difference between Arch and julialang is now that the Arch version returns a much more verbose error message

verbose_error

pfitzseb · August 21, 2018, 2:25pm

Hm, so the problem here is that the stacktrace should contain a

in include_string at base\loading.jl:1002

entry as the second to last one.

Is there an easy way for me to install that version of Julia on Manjaro? AFAICT their package sources aren’t updated yet.

lhupe · August 21, 2018, 2:34pm

Possibly using the unstable branch? I don’t know much about Manjaro, but according to their wiki the unstable repo is < 3 days behind the Arch stable repos, so julia should already be at least at 0.7

pfitzseb · August 21, 2018, 2:50pm

Ok, so there’s something weird going on with stacktraces in that version of Julia:

Left is how it should look, right is what the Arch repo version gives. I suspect that happens because the directory structure is so radically different, but who knows.