Improve debugger GUI to help adoption?

Hi @jlperla, I tried Infiltrator and liked it a lot. It’s equivalent to Matlab’s “keyboard” which I am familiar with.

The scenario we do need a full visual debugger is, again, not to debug one’s own code, but to understand others’ code when there is no good documentation or clear architecture. When you have a spaghetti ball of function calls and you have to follow the execution to understand what the hell is going on, and when re-architecturing the whole thing is not an option, a visual debugger is the convenient detective tool one can apply to follow through at least a few typical cases and try to understand how the code works.

This happens a lot with some big projects that evolved over years. Of course a new Julia project wouldn’t be in such a sorry state, but I can understand people still want the tool to be there. :slight_smile:

5 Likes

I am 100% with you on the end-goal of a matlab debugger. It is outstanding and I live in it with matlab. But it will only happen towards that slowly without a huge external invsetment.

My goal is to figure out what is the best solution given the currently available tradeoffs. My feeling is that if Infiltrator was put into the GUI - for matlab style users - it would be a better set of tradeoffs (i.e. no stepping into functions or especially dynamic walking through a function, but running at a reasonable speed) than the current interpreter based approach which have different tradeoffs.

But I am not sure…

4 Likes

I’m not going to promise any timeline, but we still plan to integrate the debugger into the VS Code extension at some point. We would automatically get a very good UI that way that we don’t have to maintain.

10 Likes

@davidanthoff Looking forward to it!

I guess any improvement to JuliaInterpreter speed, as well as automatic switching between compiled mode vs. interpreted mode, etc. would still be useful in the VS Code extension, right?

Yes, whenever we get to work on this, we would just be using whatever debugger infrastructure exists at that point.

What we need to do to enable this scenario in VS Code is write a debug adapter. We’ve started a little bit already, but this is not a small project, and right now we are focusing on polishing some other things in the extension.

For reference this is. It normally a problem.

That is generally cheap enough.
It’s only voiding (part of) compile cache.
Extreme worse case scenario is it takes as long as first run time.

Any action you take during to user IO only needs to fast vs human reaction time.

You don’t want to recompile in your hot loop. But for setting breakpoints? No worries.

MixedModeDebugger trigger a similar amount of recompilation when you set a breakpoint.

1 Like

@pfitzseb things a approach similar to MixedModeDebugger’s could be added to Infiltrator to allow this.
(I’m not sure I see how to do that, exactly. But it feels right.)

My gut tells me you are right. Even if it is a little slow in some functions, it is due to an explicit user action. When people are exploring code, they can choose to set less breakpoints if they find it slow in a particular function.

Anyways, I am someone who loves the matlab debugger, and has a good sense for how people use it for code and algorithm exploration. Given the current tradeoffs, I think mixed mode and Infiltrator likely have the tradeoffs those users would find most palatable. People will still complain until the tradeoffs disappear, but they would find it useful. Whereas I am not sure the interpreter based approach can fulfill the “explore a big codebase with an algorithm running at an acceptable speed” usecase without massive investment. It does a much better job on the “I have organized my code properly into a whole bunch of functions and want to debug one of them which failed a unit test” usecase. Useful and worth continued investment, but not one most matlab users want.

Just one opinion… And without Gui integration, it is hard to know. @davidanthoff have you thought about trying one of those debuggers for vscode integration?

2 Likes

I haven’t looked into those, but now that I know they exist I will.

I believe that Infiltrator is less experimental and pretty robust (while mixedmode is more likely to gain cool features, but has a cassette dependency and more fragile at the moment). So worth building the UI settings to make debuggers swappable (since they have different tradeoffs) but Infiltrator is a better one to start with. @oxinabox and @pfitzseb is that fair?

1 Like

It’s not fragile, it uses Cassette in a very light way.
It is however, experimental, and may not be so maintained etc.
The experiment is mostly complete. Though other people trying it out and commenting and brenchmarking (formally or informally) is still valuable.
It is proving the concept so we can think about using it in Debugger.jl / the rest of that stack.

It directly calls into Debugger.jl to display the UI.
Which is great for in the REPL, but probably wrong for if in a GUI.

I made a lot of progress lately on the VS Code debugger integration, to the point where I think I could get something shippable maybe even in the next release of the extension. BUT, right now I need some help from the JuliaInterpreter crew :slight_smile: In particular, if anyone could help with https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/362 and https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/361, that would be awesome. @tim.holy, if there is some way to tempt you, let me know :wink:

7 Likes

I would be much more happy if you would fix three year old issues like this one: https://github.com/julia-vscode/julia-vscode/issues/307 instead of just doing fun stuff…

But I guess that’s life in open source development :frowning:

12 posts were split to a new topic: VSCode LOAD_PATH discussion

I share a bit the other users frustrations… VSCode and Juno are fantastic… …but also fantastically bugged…

For a project I had to go on Python… Spyder (but also RStudio) are inferior products… but way more stable and fast (idem for QtCreator, the other ide I know).

I know Julia, not node or js, so I can’t help in their development… but… why not an editor in Julia itself? After all, the main advantage of Julia is indeed that libraries can be write in Julia itself, lowering the distance between users and developers…

2 Likes

Most of both the Atom and vs-code Julia extensions are written in Julia itself. In neither case has it seemed to bring in a bunch of programmers beyond the people who started the project (in fact, the emacs Julia mode is definitely not written in Julia and currently has more contributors than both Atom.jl and LanguageServer.jl which is the heart of the vs-code extension). There’s no evidence that writing a whole editor in Julia would be any different, and I suspect you underestimate the magnitude of the undertaking. That said, if you do decide to undertake such a project, all the best to you of course. :slight_smile: Your prior art is:

4 Likes

THere’s been a lot of work done one modal editors with TUI interfaces. Better to interface the existing code than rewrite a massive library IMO.

I actually wrote one using Gtk.jl, and even though there’s some nice things about it (e.g. you can directly hide UI elements from the console, hot reload code, it’s quite snappy, or has exotic completions/refactoring options) it probably has more bugs than VSCode and Juno combined, and some of those are segfaults since it’s quite low level on the Gtk side.

4 Likes

Just a quick update on the VS Code debugger integration: it is going to ship in v0.15 of the extension. Right now we are trying to get 0.14 out the door, but then everything is ready to have the debugger PR merged.

I’ve been using it a fair bit, and one co-worker has been using it extensively over the last week or so. While it is not perfect, it is quite usable at this point :slight_smile: The biggest problem is probably performance, but that is something that will have to be solved in a more fundamental way in JuliaInterpreter.jl, not in the UI frontend…

18 Likes

We just shipped a new version of the VS Code extension that includes the debugger: VS Code extension v0.15 - debugger.

8 Likes