Plan for tags + release

[KristofferC]

@timholy What are your thoughts about tagging + releasing and making a bit of noise so that people start trying things out. Do you feel the interpreter needs some more maturing based on the julia tests you are running or is it in a stable enough state for external use?

[timholy]

Just having people try stuff probably doesn't gain us much, given that we know (see #13) that many things are broken. But more contributors would be golden. TBH given my experience with Revise I am a little skeptical that many will jump on the bandwagon, but you never know.

From the standpoint of making noise, I also confess a small temptation to wait until we have something really good so that people don't have a bad first impression. From the standpoint of "internals" (aka, leaving aside the issue of Juno integration) I think the two big tasks left are (1) improving the correctness of JuliaInterpreter, and (2) integrating with Revise. Maybe I'm naive, but I am guessing fancy features like breakpoints will be pretty easy.

If I were to design a dream path, given the improvements in #24 so that #13 is more useful, I'd shift my own emphasis: I'd switch to tackling (2) while others slog away at (1) (I'm happy to provide advice, of course). Then when we've gotten somewhere I or someone would add the breakpoint stuff here, someone (not me) would do the Juno side. Then we make a big announcement, and then hope that a flood of excited people help out with all the difficult correctness issues (1).

Thoughts?

[pfitzseb]

I'd be happy to take a look at implementing breakpoints (and obviously integrate this with Juno). I can also try to help with (1), but I'd probably not be as immediately useful there (although the docs are going to help a lot, so who knows).

[davidanthoff]

I'd love to see the package registered and tagged, just so that it is a bit easier to use. From my point of view the making noise part could then still come later :)

[timholy]

I think we're now getting close; as of this morning the prospect for robust signature detection is looking very good, so I'm increasingly confident we aren't going to need a massive API break in the very near future. (The world-age issues did require pretty massive breakage, so it was good we waited.)

Before we make this public, we need to decide our tolerance for errors. In case it's not clear to folks, here's why #13 is so important: we're going to implement breakpoints (including "break on error") by running all code in the interpreter. That means JuliaInterpret has to be competent to run code all the way from high-level user code down to the ccalls, intrinsic functions, and builtins that lie at the bottom-most level of the call chain. If there are any errors on the way, the user can't even step through code.

Note that this is far more demanding on the interpreter than ASTInterpreter2 was. ASTInterpreter2 used the equivalent of Compiled() for every call except ones that the user explicitly stepped into, so the interpreter was running only a tiny fraction of the code. With breakpoints turned on, everything will run in the interpreter. This is why we have to have a pretty high bar for correctness.

Now, I think #13 is starting to look rather good, but we obviously have a few things left to fix. Here's my list:

• must do: develop a workaround for MWE of char crash #28 (note the proposed fix for llvmcall below might do this as a side-effect)
• should do: fix llvmcall (proposed strategy: Julia tests don't pass #13 (comment))
• must do (because of its huge impact and the fact that we're so close): add breakpoints
• at least in "stub" form: integration with Revise (Tim)

The hardest of these by far is the Revise integration, and I'm assigning it to myself. The "stub version" should not be too hard and could be done quite quickly, e.g., within the next couple of days: it's basically "think a bit more about the API in CodeTracking and get Juno using it." Getting real integration with Revise will take longer, but I'm trying to design this in a way that this step won't hold up release of the rest of the debugging stack.

I'd love help with the rest of the issues on that list!

[timholy]

@pfitzseb, can you give a brief "hacker's intro" to Juno's interaction with JuliaInterpreter? Specifically, which repo(s) and file(s) should one start looking at? I'd like to have some sense for what might need to be added to CodeTracking.

EDIT: nvm, I found Atom.jl/src/stepping.jl

[timholy]

I've finished everything on my list above except breakpoints. @pfitzseb, I might start working on them tomorrow unless you object (#23 (comment)).

[KristofferC]

Ill start on the "frontend" part for breakpoints then in Debugger.jl.

[KristofferC]

Should breakpoints live here or in the Debugger package? If here, then we might want to move over the eval_code functionality which evaluates an expression into a frame to this repository since it will likely be needed for conditional breakpoints.

[timholy]

Not sure about eval_code. Doing that on every loop would be painfully slow. But mostly likely we can cache the Expr, build a stackframe out of it, and then interpret it.

As far as where they should live, I'm still not certain whether Rebugger wants the REPL mode of Debugger or if the two will conflict. (I think of Debugger as the "stepping debugger" and Rebugger as the "mini-editor debugger.") If there is a conflict, the easiest way is to centralize breakpoints in JuliaInterpreter. But there's a chance Rebugger will want to coexist with Debugger, in which case it doesn't much matter.

[pfitzseb]

I've finished everything on my list above except breakpoints. @pfitzseb, I might start working on them tomorrow unless you object (#23 (comment)).

I probably won't be able to spend too much time on this for the next days (sorry), so go ahead :) I'll chime in when I can, for whatever that is worth.

Should breakpoints live here or in the Debugger package?

Here, I think. A breakpoint is basically the same as injecting code, and that seems like a generally useful thing one might want to do, even when not using JuliaInterpreter for debugging.

[timholy]

My list above is done. My thought is we should decide on the API cleanups discussed in JuliaDebug/Debugger.jl#41, implement them, and then register this sucker. We'll still have 3 days to iron out bugs and write up a blog post.

[KristofferC]

Yeah, JuliaInterpreter feels in a good shape!

On the Debugger side, I must confess I have gotten a bit less done than I would have wanted (partly other work and partly being unfamiliar with a lot of the things here, so things go slowly). Right now, I would not want to release Debugger.jl until the UI side is better (especially handling breakpoints) and proper docs are written. This of course doesn't stop the interpreter from being released.

A positive thing now is that almost all real functionality is in JuliaInterpreter, so someone that wants to make their own frontend for a debugger would likely just do that on top of JuliaInterpreter directly.

[timholy]

Shall we try the linked list thing? I can put a couple of hours into that and see how it goes.

[KristofferC]

It feels like the only way to really see how it feels is to try it out, yeah.

One thing i like about the vector stuff is when you e.g. hit a breakpoint the stack is already fixed for you and you can just pop the top frame off and set that as the "active" frame. With a list I guess you have to go to the head but it might very well be just as simple as state.frame = head(state.frame) or something...

[timholy]

Alright, I will give it a whirl. Could take a day or three, I will probably wait to register until we decide.

A positive thing now is that almost all real functionality is in JuliaInterpreter, so someone that wants to make their own frontend for a debugger would likely just do that on top of JuliaInterpreter directly.

I am wondering about stealing bits from Debugger to accentuate this, and let Debugger become strictly the REPL "stepping" interface. Thoughts?

[KristofferC]

I am wondering about stealing bits from Debugger to accentuate this, and let Debugger become strictly the REPL "stepping" interface. Thoughts?

Yeah, I think this is a good idea. The name Debugger.jl is then perhaps a bit too "definite". Maybe REPLDebugger or something might be more suitable?

[timholy]

i can be persuaded of almost anything. I do think that package is worthy of having "Debugger" in the name, since many people will expect that to mean a s/n/c debugger. (Interestingly, I only just noticed that there isn't a "continue = run to completion" option! Maybe because we haven't had breakpoints.) That said, I also agree if it's one particular interface to the debugging infrastructure it may be a bit grandiose. Regarding REPLDebugger, to add to the confusion Rebugger is also a REPL Debugger: it's the "high level REPL debugger" (easy but limited) and what is currently Debugger is the "low level REPL Debugger" (more tedious but greater control). Despite this, I think REPLDebugger is a viable name.

Maybe it's worth considering both packages simultaneously in terms of name (I'm willing to rename Rebugger). Brainstorming options:

• Debugger/Rebugger (what we have now)
• SNCDebugger/UIDebugger (SNC for "step, next, continue", UI for the fact that Rebugger is mimicking the interface that a graphical debugger might offer)
• REPLDebugger/KeyDebugger (that the "interpret" mode of Rebugger will be controlled by single keystrokes---of course, Rebugger's "edit" mode makes this a bit confusing)
• DebugController/DebugPlayer

I don't really mean to present these strictly as pairs, we could mix & match.

[timholy]

Ready or not, here we come! JuliaLang/METADATA.jl#22121