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?
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?
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 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
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
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…
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. Your prior art is:
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.
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 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…
We just shipped a new version of the VS Code extension that includes the debugger: VS Code extension v0.15 - debugger.