My experience with debuggers is primarily from python these days, but when I debug a similar code in Python and experience a crash while in debugging mode the debugger does not actually detach but rather remains active such that I can still query the debugger and step up through the stack.
However even if the debugger detaches I would have expected at a minimum an error message saying which line the code crashed on?
From you message I don’t see anything about a debugging console, where I can write my own expression and evaluate them against the local scope of the code. I assume that is not a thing in flexible julia? Is it planned or do you have a roadmap for what the future holds for flexible julia?
However even if the debugger detaches I would have expected at a minimum an error message saying which line the code crashed on?
You should be getting the error from the debugger in the terminal or julia repl depending on what you used. and files in there are clickable (with inline location) via ctrl+click. Otherwise there’d be no crash. I do not get more info than the debgger provides though…
As for python: I also write python a lot. Experience is similar across the IDEs - but it depends on whether it is a hard crash or not.
As for ending the debugger - i could potentially give you an option in the settings that allows you to define whether you want the debugger to exit with the program or keep going. It may make it a little less userfriendly for some, but it is possible for me to do.
The evaluate expression is indeed a good starting point towards what I am looking for, and something I was not aware of. (Mine is also hidden in the 3 vertical dots so not the easiest to find)
Normally in python I would be able to write my expressions directly in the console window and be able to evaluate them against the code in its current state.
From quickly testing the Evaluate option it seems to be missing some functionality.
I can use it to get the size of a current variable: size(iyr)
However I cannot see print messages (stdout): print("Horse")
And I cannot actually change the state of my code with it: a = 10
And then evaluate it: a
returns unknown variable.
Oh, yeah, you won’t be able to modify the current session and the print output is missing. You cannot do that in Java or other languages either though. But perhaps i can fix that in a future release (it is a bit tricky, because i am messing with internals here, but I might see a way). Could you open tickets for all of these, please? makes it easier for me to track.
You should be getting the error from the debugger in the terminal or julia repl depending on what you used. and files in there are clickable (with inline location) via ctrl+click. Otherwise there’d be no crash.
Oh, yeah, you won’t be able to modify the current session and the print output is missing. You cannot do that in Java or other languages either though.
You can in Python, and I’m also pretty sure you could in Fortran though it is more than 10 years ago I worked in Fortran so I could easily be mistaken on that one.
Could you open tickets for all of these, please? makes it easier for me to track.
try to hover over boot.jl (which i believe is in your code) and press ctrl. It should change colors? if not that might be a bug.
As for the debugger:
Not quite. I rely on the debugger.jl logic - think of it as a hook inside your running julia program that allows me to collect data. Debugger.jl is the most popular and widely used option. I then use and interpret the results (I also wrapped it to add some additional functionality, but that’s another story).
Basically regardless of how you debug, you need a DAP (Debug Adapter Protocol) to hook into the running code. In java or python it is built in, but needs to be enabled via flag. In many other languages you add it as a dependency. This is my dependency. The rest I do on top is interaction.
That is why you get the local / global etc variables in the tree. Debugger.jl collects different variables in different contexts for a running project. It makes sense, but may confuse some, because when you are starting out, you expect a rather flat view like you got in Python.
Anyway, in the end, it is the best solution for this. Debugger.jl gives you a very detailed drill down. The links you saw are from the stack trace - going far back. The first few lines are where the exception is thrown.
Irregardless of it all, also for code quality reasons, I would really suggest wrapping in try/catch blocks more often. It prevents both the debugging session from breaking and gives you more infos…
In these days, I’d say debug is quite easy by using AI. Just setup a julia-mcp and the AI will iteratively run julia code in the mcp until the bug is identified or even fixed. You just sit there and wait
Not quite. I rely on the debugger.jl logic - think of it as a hook inside your running julia program that allows me to collect data. Debugger.jl is the most popular and widely used option. I then use and interpret the results (I also wrapped it to add some additional functionality, but that’s another story).
Basically regardless of how you debug, you need a DAP (Debug Adapter Protocol) to hook into the running code. In java or python it is built in, but needs to be enabled via flag. In many other languages you add it as a dependency. This is my dependency. The rest I do on top is interaction.
In that case I’m very surprised why flexible Julia is allowing me to step past the original line in my code that was completely blocking my code when I evaluated it in the default debugger in VS code, since it seems to be the same debugger.
I am not sure if there’s a default in jetbrains for that (or debugger.jl). But I don’t see why not. I could probably halt and interpret when raised.
Also: conditional breakpoints would be sweet, too. JetBrains does support those by right clicking on a breakpoint in the file gutter and adding some context. But i haven’t tried it with our implementation yet. That said - happy to add. (I once created a custom language for conditional breakpoints even for a commercial IDE plugin - it was great).
If you like, add a ticket, so I don’t forget, yea?
@madppiper Did you look into DebugAdapter.jl for the JetBrains plugin? I realize it’s borderline unusable as a dependency, but maybe it would make sense to focus efforts there.
There are currently two main issues when it comes to configuration
the ALL_MODULES_EXCEPT_MAIN functionality isn’t super discoverable
the shipped list of compiled functions is very outdated (and will also cause a bunch of issues, depending on the Julia version)
Both of those are a quick fix though, so the next version should have saner defaults at least.
I already looked at this and believe I should have set it up correctly when I was trying to debug this in VS code, but I could have been mistaken.
I remember that I found the option: ALL_MODULES_EXCEPT_MAIN, somewhere yesterday and that it looked like it should compile everything except my own code, however I cannot find it again now…
