# Debugger in Juno for Julia 1.0
**URL:** https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727
**Category:** New to Julia
**Tags:** juno, debugging
**Created:** [January 16, 2019, 11:36pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727 "2019-01-16T23:36:07Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@michaelkyu](https://discourse.julialang.org/u/michaelkyu)
#### Post date: [January 16, 2019, 11:36pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/1 "2019-01-16T23:36:07Z")
What is the state of the debugger in Juno for Julia \>=1.0? The [documentation for Juno 0.6](http://docs.junolab.org/release-0.6/man/basic_usage.html#Using-the-Debugger-(experimental)-1) mentions a prototype debugger based on ASTInterpreter2. However, the [“latest” documentation](http://docs.junolab.org/latest/) for Juno does not mention debugging. What happened?
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [January 17, 2019, 2:30am UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/2 "2019-01-17T02:30:14Z")
You can use the ASTInterpreter2 stepping debugger. Despite the name, it works fairly well. That’s all there is, I’m afraid. There are also many discourse threads about people wanting a debugger.
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [January 17, 2019, 9:10am UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/3 "2019-01-17T09:10:03Z")
I’ll publish a new Juno release with ASTInterpreter2-based debugging ASAP, but you’ll still need to
```julia
pkg> add ASTInterpreter2#master
pkg> add DebuggerFrameworkg#master
```
for now.
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [January 22, 2019, 8:43am UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/4 "2019-01-22T08:43:17Z")
Quick update on this – latest Juno release works with ASTInterpreter2#master and DebuggerFramework#master:
Feel free to try it for a bit, but this is very likely to break very soon due to big changes coming to ASTInterpreter.
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [January 23, 2019, 5:53pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/5 "2019-01-23T17:53:13Z")
> is very likely to break very soon due to big changes coming to ASTInterpreter.
Yes, sorry about that. Reference is [Towards a semi-performant recursive interpreter by timholy · Pull Request #37 · JuliaDebug/ASTInterpreter2.jl · GitHub](https://github.com/JuliaDebug/ASTInterpreter2.jl/pull/37).
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [January 23, 2019, 6:08pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/6 "2019-01-23T18:08:48Z")
Eh, it’s a two-line diff for this to work with your PR, which is super awesome in and of itself (also, wohoo, documentation ❤) .
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [January 23, 2019, 7:30pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/7 "2019-01-23T19:30:45Z")
Yeah, but I think it’s going to get worse before it gets better. As you know I think we need to break up packages, but that’s still in the future, so there’s going to be a transition period that is almost guaranteed to be ugly.
---
### Author:  [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)
#### Post date: [January 23, 2019, 9:24pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/8 "2019-01-23T21:24:11Z")
> [@tim.holy](#):
>
> > is very likely to break very soon due to big changes coming to ASTInterpreter.
>
> Yes, sorry about that. Reference is [Towards a semi-performant recursive interpreter by timholy · Pull Request #37 · JuliaDebug/ASTInterpreter2.jl · GitHub](https://github.com/JuliaDebug/ASTInterpreter2.jl/pull/37).
I wonder about [your post in that pull](https://github.com/JuliaDebug/ASTInterpreter2.jl/pull/37#issuecomment-456933202):
> Also something that may help explain a lot: when you’re dealing with `Expr` s then basically _nothing_ is inferrable. If you want decent performance, you have to change your style of writing Julia code: instead of
>
> `foo(a::Typ1) = 1`
> `foo(a::Typ2) = 2`
> `foo(x)`
>
> you want _only one method for foo_ (so that Julia’s compiler knows which `foo` you mean without needing to know anything about types) which is written something like
>
> function foo(x) isa(x, Typ1) && return 1 isa(x, Typ2) && return 2 error("unhandled type ", typeof(x)) end
>
> You get good performance from the latter even if you don’t know the type of `x` going in.
>
> If you want the best of both worlds, you can combine these and write it like this:
>
> \_foo(x::Typ1) = 1 \_foo(x::Typ2) = 2 function foo(x) # make sure there is only one `foo` method isa(x, Typ1) && return \_foo(x) # here it knows to dispatch to the Typ1 implementation isa(x, Typ2) && return \_foo(x) # here it knows to dispatch to the Typ2 implementation return \_foo(x) # fallback implementation (requires dynamic dispatch if `typeof(x)` is unknown) end
>
> This version will be fast if `x` is `Typ1` or `Typ2` , and slow otherwise (assuming the existing of more methods of `_foo` that can handle other types.
Could you explain what is going on here?
It seems something like manual dispatching. Why is any better than what Julia would do automatically?
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [January 24, 2019, 9:43am UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/9 "2019-01-24T09:43:01Z")
It’s because normal dispatch has to “spin up” the whole generic machinery for subtyping, and that’s expensive. But for concrete types there’s a trivial implementation. You can see that with the following demo:
```julia
julia> x = Ref{Any}(3) # create an Int that's "hidden" from inference
Base.RefValue{Any}(3)
julia> isintref(x::Ref) = isa(x[], Int)
isintref (generic function with 1 method)
julia> isintegerref(x::Ref) = isa(x[], Integer)
isintegerref (generic function with 1 method)
```
Now compare `@code_llvm isintref(x)` to `@code_llvm isintegerref(x)`; you’ll see that `isintref` has a line
```julia
%11 = icmp eq %jl_value_t addrspace(10)* %10, addrspacecast (%jl_value_t* inttoptr (i64 140355592194032 to %jl_value_t*) to %jl_value_t addrspace(10)*)
```
which is just a pointer-comparison, whereas `isintegerref` has a line
```julia
%11 = call i32 @jl_subtype(%jl_value_t addrspace(10)* nonnull %10, %jl_value_t addrspace(10)* addrspacecast (%jl_value_t* inttoptr (i64 140355676482752 to %jl_value_t*) to %jl_value_t addrspace(10)*))
```
`jl_subtype` invokes Julia’s type-analysis machinery (which is awesome, but not trivial).
Now, could normal dispatch do this? Yes—in principle it could check to see if every method of a function is defined solely in terms of concrete types, and if so do dispatch via this simple short-circuit. This is somewhere between an optimization not-yet-implemented (modulo Union-splitting, which is what this really is) and an optimization we don’t want (I worry it would encourage people to specify concrete types on all their function arguments and thus break the lovely polymorphism of most well-written Julia code). The “switch statement” alternative allows people who know what they are doing to achieve the same thing without such downsides.
---
### Author:  [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)
#### Post date: [February 27, 2019, 8:43pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/10 "2019-02-27T20:43:34Z")
this is breaking for me with julia 1.1 and ASTInterpreter2#master and DebuggerFramework#master
(executed in Atom Juno julia console)
```julia
julia> @enter gcd(3,2)
ERROR: MethodError: no method matching maybe_next_call!(::ASTInterpreter2.JuliaStackFrame)
Closest candidates are:
maybe_next_call!(::Any, ::Any) at C:\Users\me\.julia\packages\ASTInterpreter2\2L2CW\src\interpret.jl:524
maybe_next_call!(::Any, ::Any, ::Any) at C:\Users\me\.julia\packages\ASTInterpreter2\2L2CW\src\interpret.jl:519
Stacktrace:
[1] top-level scope at C:\Users\me\.julia\packages\Atom\UtmXq\src\debugger\stepper.jl:33
```
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [February 27, 2019, 8:57pm UTC](https://discourse.julialang.org/t/debugger-in-juno-for-julia-1-0/19727/11 "2019-02-27T20:57:29Z")
Use Debugger.jl instead ([GitHub - JuliaDebug/Debugger.jl: Julia debugger](https://github.com/JuliaDebug/Debugger.jl))