Does there exist one?
What I’d like to use is the equivalent of a C good debugger for Julia (See SGI’s graphical debugger for examples.. To help me learn Julia, I (the generic ‘I’) could open a package that interests me in debugger mode, and run it, stepping through line by line (if desired) so we could, for example, step through that function while watching how the variables, outputs, inputs, and etc are changed by the current line of code. Ideally, watching a 2 or 3 page code listing being stepped through. This greatly helped me learn C, about a million years ago.
Julia doesn’t have any truly killer debuggers.
There is Debugger.jl + the Julia Visual Studio Code extension. It has the full set of features you’d expect from a debugger and a great GUI. However, it has to use Julia’s interpreter for any code where you want breakpoints which means it can be very slow for any complicated code. It has also had some stability issues in the past (present?) where it would randomly crash in the middle of a debugging session.
Then, there is Infiltrator.jl. It allows you to run code in full compiled mode so it is very fast. However, it does not support “stepping” through the code once you hit a breakpoint. You just get a REPL session at the breakpoint where you can poke around the variables to see what’s going on, then continue. It also doesn’t have a GUI (that I’m aware of).
One more thought here – if you are using any libraries that use macros, the debugger can sometimes be a little confusing because the macro will expand out, and as you step through, you’ll teleport into a the macro’s source code which will probably look very confusing, and then teleport to a function that you use at the site where macro is invoked, and then teleport back to your function body.
It’s all the correct behavior, but if you don’t know it’s coming, it can be a bit jarring. Macros are powerful, but discouraged for these kind of complexity reasons
Yes (as said above).
No way. Debugging experience in Julia can be very despairing (it often is). But for simpler codes and those that do not act over large arrays (where slowness is ablosutely killing) it is good enough as a learning tool. Breakpoints have their own mood (code doesn’t stop at them after some code edits, or stop even when we remove them) but we have to lieve with it.