This is not a new topic, and I am aware progress is being made… Just would like to bump its priority if possible.
Currently the VSCode Julia debugger’s standard mode is too slow for practical use if large packages are used. The experimental Compiled Mode has good speed but would not break inside any function call - only the level the current debugger is working on is breakable and it’s not reliable enough either. The same was true for Juno based on Atom.
I have been promoting Julia for a key internal project among engineers for over a year, and the battel was lost. Colleagues still chose Python due to the debugging experience and overall IDE maturity. Managers still chose Python due to its popularity (easy to hire, easy to collaborate). And frankly, for majority of engineering applications Python’s slow speed is tolerable, so if writing in Python is more pleasant, few would like to spend weeks to pick up a new language.
The debugging experience seems to be a constant pain point for switching to Julia for those who are familiar with Matlab or Python but are not career programmers. I truly appreciate the work from developers that drive constant progress to the IDE and regret that I lack the skills to help in the development, but I’d just like to bump this up again since based on my experience, Julia is already great in language features and execution speed; the debugging experience seems to be THE BIGGEST obstacle for adoption that the community can solve in near term, followed by the time-to-first-plot issue (which is being improved). (Popularity is a bigger problem but that’s not something one can just work and solve.)
If Julia’s IDE can work as well as Spyder or RStudio, I believe this alone will drive more adoption.
Thanks again for the great language and extension.
I agree with OP. Has there been any new development on this front? I am not sure though if this is the right place to ask this question since Julia already provides a “debugger”, but having to type in something in the source file (as opposed to using a breakpoint), is a real pain.
[While Python and Matlab already have great debugger, even C++ has a better GUI debugger these days (I’m not referring to gdb, which while excellent is not something folks moving from Python or Matlab would like to use). I am referring to Python’s “pretty print” packages which works great with C/C++ STL data types and even works with C++ Eigen library, for all linear algebra/math heavy work].
I can also highly recommend the Infiltrator.jl package, which I use regularly in my projects. You also don’t get any noticeable speed loss when debugging with @infiltrate.
@DNF and @kfrb Thanks for these notes. Does the debugger work within the Julia extension in vscode? I am particularly interested in using a breakpoint to be able to debug/step into the function, without having to type in anything in the source code (source code remain untouched during the debugging process and only use breakpoint).
I empathize, I’ve had similar issues getting some of my collaborators to make the switch to Julia from python. I have also had issues with the debugger in VSCode where it will just hang and never start or if it does its very slow (minutes to start).
I don’t have any giant projects yet, but I have found the VSCode debugger responds faster if you break your code up into smaller individual functions. Probably not practical in all situations.
But I have to think, there are some big complicated Julia packages out there – how did the developers manage to create them if debugging was such as issue? Just suffer through it?
I was not familiar with Infiltrator.jl, I’ll have to look into it.
At the risk of repeating myself, I have been programming in Julia since 2014. I have not needed a debugger yet. At the moment I maintain close to 30 major packages in Julia. Perhaps 50,000 lines of code or so. I have used Infiltrator once or twice: very useful for interactive work that requires computation of significant results, and hence a longish time to get to the point I’m interested in.
Doesn’t seem like it. I just tried in VSCode and it didn’t work (well, it did but it was buggy). Makes sense, the github page warns about using it in VSCode.
Yes. You click in the gutter to create a breakpoint, which shows up as a red dot. This breakpoint can be edited to be made conditional on some expression. There is no need to modify the source code, but you need to invoke the debugger, either from the VS Code menu, or by invoking your function call with the @run macro.
And when I tried it in VSCode by adding @infiltrate inside a function and then clicking Julia: Activate File in REPL it was buggy. It entered the >infil prompt but nothing could be evaluated. I then did it again from the Julia REPL, just from my terminal (not the integrated terminal in VSCode) and it worked fine.
I keep getting the following error whenever I try to use the Julia debugger in VS Code. [I click on the “Start Debugging” option under the “Run” tab of the VS Code toolbar]. I think the script (where I have the breakpoints set) I am using is not really an issue here since it runs fine if ran in non-debug mode in VS Code.
Connecting to debugger… Done!
┌ Error: Some Julia code in the VS Code extension crashed
└ @ VSCodeDebugger ~/.vscode/extensions/julialang.language-julia-1.5.8/scripts/error_handler.jl:15
ERROR: ArgumentError: lowering did not return a :thunk expression, got $(
Do any of you get the same error, or does this error not occur on your end at all? Thanks a lot for any help.
hear hear. Just starting out and trying to get along using a simple text editor and trying to think it through before hand. I was an emacs junkie but I spent more time on macros than code.
I tried out vscode and for my purposes it’s too noisy. I AM enjoying using Pluto though, it’s a blast. Can’t wait for Plutohooks.
I am able to resolve my error in VSCode and the Julia debugger works fine now (albeit a bit slow than I expected, but something is better than nothing, I figure). It was related to declaring local/global variables.
I’ve been struggling a lot today with the debugger. (A few days ago it seemed to work fine) I want to debug quite a large package that does image processing. It is far too slow if I don’t use compiled mode. So I put all the packages in compiled mode except the package I want to debug. But breakpoints only seem to just now and then work. Also if I hit a breakpoint and then click on continue it often does not continue. It just seems to hange
I agree, currently the main obstacle, from my point of view, to work in productive way with Julia is the unreliable debugger. Outside the debug mode, I receive a message where the error occur / is detected
But in the debug mode I do not reach to this point, the debugger crashes (silently) already before I reach this position.
One workaround is of course the intensive use of println() …
Does it make a difference, if I use the LTS-version instead of the current release?
