Is the VSCode plugin based on Interpreter.jl ? The remark “unoffical workaround” was referring to Infiltrator.jl which is a very different piece of SW.
1 Like
Sorry to butt in, but I never knew about the “Apply default compiled modules/functions” bit. Suddenly the debugger is usable - thanks!
3 Likes
The ALL_MODULES_EXCEPT_MAIN method has never worked for me outside of standalone scripts though.
Are you sure the modules are actually interpreted? For me, all the modules are listed as interpreted under “All”, but they are not. E.g. Plots is listed there, but if I put a breakpoint in the plot function, it doesn’t work. If I remove ALL_MODULES_EXCEPT_MAIN from “Compiled”, the breakpoint works.
And this setup for my own package seems to work:
Yep, me too. Crashing frequency and non-stoping-at-breakpoints (or keep stopping on cleared ones) seems to have increased over time.
As it has been stated several times in past reincarnations of this discussion, a debugger a lot more than just a debugging tool. It’s a tool to understand code flows. I simply can’t understand how people can pretend that testing or variations of printf are alternatives.
3 Likes
I did recently fix a few more bugs in the VS Code link to the debugger, but I can’t push it out at the moment because there is another part in the extension that needs a few more bug fixes before I can tag a new prerelease build.
I think there are broadly two “big” ideas on the table at the moment how the debugger could be made more performant for good. One is to stick with the basic current design of an interpreter, but make some drastic changes to how it works to make it faster. I think WIP: a new serialization format for optimizing & executing lowered IR by timholy · Pull Request #309 · JuliaDebug/JuliaInterpreter.jl · GitHub was the start of something along those lines. The other big idea is to go more in the direction of other native-code debuggers, i.e. probably something like emit a debug version of the compiled code, and then work with that (maybe with similar tricks of handling breakpoints etc as a native code debugger). AFAIK there is no one working on either of those options at the moment.
The other question is whether there are more short-term things one could do to improve the situation. One reason debuggers in interpreted languages like Python have a much better out-of-the-box experience is that they automatically have pretty sensible defaults in terms of which code parts to “skip” from debugging: if you read a CSV file from Python, most likely that code is written in C, and the interpreter debugger won’t try to step through that, but just run the compiled version of that. In Julia most things are written in Julia itself, so we don’t have these “pretty reasonable” points in the code where one jumps out of the interpreter and just runs a compiled version of things. But maybe we could improve that situation: one option might be that in DebugAdapter.jl we just keep a list of methods in popular packages that should be compiled. Or maybe a package could somehow itself declare which methods should be added to the list of compiled methods. It might well be that if we can by default have things like file loading etc compiled that the entire experience would be quite a bit better for newcomers.
2 Likes
Don’t know if in the same spirit of the list of compiled methods but one thing I find very annoying is that when stepping into functions (F11) I have to keep going to “Step into target” because otherwise I have to keep pressing F11 lots of times till it consumes all function arguments that call other Julia code. If that could be avoided, that is a F11 always go directly to the function, that would skip also potentially quite a lot of visited code.
1 Like
I agree, but that is really a design choice of the VS Code debugger UI… There is a feature where you can right click in the source (while the debugger is paused) and select Step Into Target and then select which function call exactly you want to step into. But that is well hidden, cumbersome and also we don’t exactly generate the most readable list there 
Maybe another small fix could be an option to never step into the getproperty method that just calls getfield, that is where this annoys me the most…
1 Like
If the implication is that the Julia extension for VS Code is official, then AFAIK that’s not the case; the debugger in REPL mode is not part of Julia’s standard library. As notable as it is, it seems to be as separately developed as other third-party libraries.
An interactive REPL can execute function calls one at a time, just like a debugger can. Along with printf debugging, you can get and change targeted information. Not at all the same as a fully featured source debugger program, even one that’s not attached to an IDE. Infiltrator also differentiates itself from “actual debuggers.”
Thing is MATLAB’s runtime is not mostly interpreted. It has a JIT compiler to help, and core numeric routines are compiled from C/C++ that you’ll never see. Python doesn’t have a JIT (not by default anyway), but debugger performance also benefits from stepping over a lot of compiled C code. Julia code on the other hand tends to implement numeric routines in Julia; the plus is we can often step much more deeply into code, the minus is we can’t compile code we step into or put breakpoints in because compilation doesn’t preserve the source’s structure. Bugs aside, compile mode and excluding packages from interpretation are designed to promise the debugger that we won’t pause some calls, even if we had set breakpoints in their methods, so it can run compiled code instead; in a way, it’s the inverse of compiled code being unapproachable by interactive source debuggers.
1 Like