[FR] Release schedule for debugger

[timholy]

Debugger.jl and Rebugger.jl should both be ready to go Tuesday, March 19 (the date we expect Debugger.jl to be registered; I'll tag new releases of Revise & Rebugger the same day). Should we wait for Juno or just go ahead and announce? I'd rather wait, if it's only a few days, but would rather not wait if it will be weeks/months.

In case you missed it, you probably don't need Debugger.jl at all; JuliaInterpreter.debug_command should have everything you need (and it's already a tagged, released package). Let me know if I can help! CC @KristofferC.

[pfitzseb]

I have a working implementation in JunoLab/Atom.jl#138 with a couple of todos left.
I think I can implement all of that today.

In case you missed it, you probably don't need Debugger.jl at all; JuliaInterpreter.debug_command should have everything you need (and it's already a tagged, released package).

Right now I'm using Debugger.jl directly, mostly because I want to steal the REPL mode and things like that. :)

[KristofferC]

Do you gain a lot by using Debugger.jl?

It would be nice from a Debugger.jl's point of view if the only exported feature would be the REPL interface. Otherwise we need to be very careful not to break the Juno debugger just by changing internals of Debugger.jl

[pfitzseb]

Right now not really, no, but as I said, I did plan on stealing the REPL as a fallback for code without lineinfo, if that makes sense? I do see the appeal of not having to worry about Juno digging into Debugger's internals :)

[timholy]

I did plan on stealing the REPL as a fallback for code without lineinfo, if that makes sense?

Example?

[pfitzseb]

JuliaDebug/Debugger.jl#21, but I'm not sure if something like that is still likely to happen -- to be fair I never encountered that situation, so maybe should deal with it when it comes up.

[timholy]

One option is to rely on Revise + CodeTracking, for which definition should give you the source expression regardless. Example:

julia> using Debugger

julia> @enter floor(missing)
In floor(#temp#, digits, base) at missing.jl
112         ($f)(::Missing, digits::Integer=0, base::Integer=0) = missing
113         ($f)(::Type{>:Missing}, ::Missing) = missing
114         ($f)(::Type{T}, ::Missing) where {T} =
115             throw(MissingException("cannot convert a missing value to type $T: use Union{$T, Missing} instead"))
116         ($f)(::Type{T}, x::Any) where {T>:Missing} = $f(nonmissingtype(T), x)

vs

julia> using Rebugger

interpret> floor(missing)[ Info: tracking Base   # I hit meta-i here

floor(::Missing) in Base at missing.jl:112
  #temp# = missing
 112  floor(::Missing, digits::Integer=0, base::Integer=0) = begin
 112          missing
          end

Obviously this can't work for definition(method, String), but it does for definition(method, Expr) (which is the default, and this is the reason why).

[timholy]

In JuliaDebug/Debugger.jl#21 I'm guessing Zygote builds methods by expression, e.g.,

julia> ex = :(f(x) = convert(UInt, x))
:(f(x) = begin
          #= REPL[11]:1 =#
          convert(UInt, x)
      end)

julia> popfirst!(ex.args[2].args)
:(#= REPL[11]:1 =#)

julia> eval(ex)
f (generic function with 1 method)

julia> using Debugger

julia> @enter f(1)
In f(x) at none
1   1 ─ %1 = (convert)(UInt64, x)
2   └──      return %1

About to run: (convert)(UInt64, 1)
1|debug> 

So yes, you'd sacrifice that, but I'm not sure Juno expects to display lowered code in one of its editing windows? It would seem OK for Juno to rely on source text. Probably you shouldn't display expressions either, so I don't think you need to worry about such "fancy" cases.

[pfitzseb]

Right, finding the expression is possible, but I'm not sure how to best expose that to the user considering we don't really have a file to show a stepper in.
I'll just switch the implementation to JuliaInterpreter for now -- shouldn't be difficult.

One thing I'm not sure about is how to best handle breakpoints -- the expected workflow probably is to just click a line number in an arbitrary file (and that's it). AFAICT that means that Juno will need to call Revise.track on that file, because otherwise

julia> JuliaInterpreter.breakpoint("/home/pfitzseb/Documents/julia-1.1.0/share/julia/base/intfuncs.jl", 31)
ERROR: no signatures found at /home/pfitzseb/Documents/julia-1.1.0/share/julia/base/intfuncs.jl, 31.
Restarting and `using Revise` and the relevant package may fix this problem.

might happen. Tracking an individual file doesn't seem to be a good idea, but at least with my Julia version (official download), tracking Base doesn't suffice to set a breakpoint...

[timholy]

CodeTracking.signatures_at? It will call Revise for you.

[timholy]

In general you shouldn't use Revise directly, perhaps other than to load the package. All "where is my code?" queries should go through CodeTracking.

[pfitzseb]

julia> CodeTracking.signatures_at("/home/pfitzseb/Documents/julia-1.1.0/share/julia/base/intfuncs.jl", 31)
ERROR: /home/pfitzseb/Documents/julia-1.1.0/share/julia/base/intfuncs.jl not found, perhaps the package is not loaded

Maybe because I'm using the official binaries or something?

[timholy]

Will fix!

[pfitzseb]

Awesome, then I don't have to worry about any of that and can just use JuliaInterpreter.breakpoint. Thanks!