Hi! Sorry for the flaming title… but I’m really frustrated. For me, the vscode debugger just never works; I always end up putting print and show statements somewhere and relying on revise. That also works, but sometimes I’d love to step through the callstack. Maybe someone can help me to find out if I’m doing sth wrong. So here’s a recent example:
using Pkg
Pkg.activate(".")
using ArchGDAL
using Rasters
using GeoFormatTypes: EPSG
epsg = EPSG("EPSG:32609")
gridsize = 1000;
min_x = 273500;
max_x = 2507100;
min_y = 4077900;
max_y = 7234200;
x = X(min_x:gridsize:max_x);
y = Y(min_y:gridsize:max_y);
A = Raster(zeros(UInt8,y,x), crs=epsg)
Rasters.write("/home/max/deleteme.tif", A; driver="COG", options=Dict("BLOCKSIZE" => 256), force=true)
The last line contains a bug. I basically know where it is and what it is, but I want to pinpoint it. So I set a breakpoint at that line, and click “run and debug”. The program then runs up to the breakpoint and stops there, indicated by a yellow line as seen below:
First try: When I click “step into” just nothing happens. So I started writing this post. I alt tab back to the window, still nothing, I press F11, and wow, it steps into the function. I step into and over and so on, until it’s just frozen again. So I set a breakpoint in the file I’m interested, restart the debugger and let it run. It never reaches the breakpoint (at least not in 5 minutes). So I thought: Let’s add all modules except the ones I’m interested in and Main to the list of compiled modules. Didn’t help. Next to “call stack” on the left, it always says “paused on step”, no matter what I do. Oh and when I click on Global (Main) under variables I get an eternally spinning disk and the debugger freezes. Can anyone help me so that this is not a complete waste of my Sunday’s time?
julia 1.9.0
julia for vscode extension 1.54.2
vscode 1.83.1
Not sure if this is your problem here, but, the debugger allows parts of the code to be compiled (otherwise it would be hopelessly slow). Make sure that you set the library of interest to be not compiled. There’s a menu for selecting that somewhere.
Yes, it now seems to work after I found out that I have to click this lousy red dot next to “julia: compiled code” that only appears when you hover over it. So I added some dependencies to the compiled list and made sure the library of interest is interpreted. Yeah… and then I have to hit the step over / step into keys several times until they take effect… Would be nice if the debugger automatically put all packages into compiled mode by default, except for the ones you have set breakpoints for. And runs in compiled mode by default.
i am on a mobile so canot show the full story. What you are seeing is a, I agree, extremely annoying feature where the debugger only jumps into a function after having executed all (or nearly all, never found out) calls that are implicit in the command line. Right-clicking on the function name the third or fourth option from the bottom has an option that let us select function name and the it will go tgeee directly. Still very annoying but a little better.
Another bad experience comes when, if we edit the file, the debugger sometimes starts to stop on the wrong lines. Then, only option us to kill the repl and restart all over again. Including wait for precompiles. .
Ok, slowly I get it. So in the above example there are all the calls that construct the keyword argument tuple, the dict etc in the same line. Stepping into the function requires stepping through all these first, which is why I had to do it 8 times. The hint with right click and target selection works; there I can skip all intermediate steps and jump right into the call. Thanks!
One thing that I found out which is actually quite cool is that it’s possible to re-run a call post mortem in case you accidentally stepped over it.
Well, most of the time I don’t, but sometimes it really helps not having to perform the dynamic dispatch mentally.