Error handling in Juno

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


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.

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

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

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

      terminal: "termite"
    firstBoot: false
    juliaOptions: {}
      enableMenu: true
      enableToolBar: true
      usePlotPane: false


    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

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

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.

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

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.

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:

1 Like

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).


Yeah that sounds right. +1 :slight_smile:

:smile::+1: So fast!! :smile: good stuff!! :+1::+1::+1:

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


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.

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

1 Like

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.