That sucks. If you have something particular in mind, you can always reach out - the goal is to have it work really well for all of us, so happy to improve this in my plugin 
That is indeed a nice introduction. However from what I can read and from what others have mentioned about how to program with Julia using REPL. These adaptations in workflow seems like workarounds that people have invented because there isn’t a good debugger.
I remember when I was using python in the early days and one fo the big IDEs was spyder, which seems to function kinda like how people are using Julia/REPL from what I understand.
1 Like
I found the settings.json file and added this to the top
"julia.debuggerDefaultCompiled": [
"ALL_MODULES_EXCEPT_MAIN",
But it made no difference on the debugger it still got stuck on the same line.
Can you try a simple example like the one in my screenshot?
Either something is very weird about your setup, or you’re running the debugger differently – loading a 5MB CSV takes very little time for me.
Sorry, I may have not been very clear but my comments were about VSCode experience.
1 Like
I guess I’m doing something wrong:
I do not have time to look at what exactly I’m doing wrong now, but I will check back in later and try to fix it.
Just run that in the REPL, not in a dedicated debugger process. I wouldn’t usually recommend running the whole file through a debugger, ref Debugging · Julia in VS Code.
5 Likes
My primary debugging workflow involves adding @show (or display for types like Matrix that are hard to read in @show) statements on variables that appear to be causing an issue. Then, when you re-run the program you can see what those values were leading up to the issue. If the program doesn’t stop at the issue, I’ll sometimes add an error() call (maybe within an if statement, if I need it to go through a few passes first) right after to stop the program from burying the part I care about. I guess it’s a bit like a crude Infiltrator except that you need to pick what values you will inspect in advance.
I think this is one of the techniques people would call “REPL-based debugging.” I won’t say it’s “nice” or profoundly ergonomic (and it takes a little practice to figure out what/when is best to print), but it’s a rather common technique in languages that have underwhelming debugging faculties. For example, I do the same thing in C++.
2 Likes
I’ll frequently insert global dbg=(some_local_variable, some_other_local) inside a function I care about. Then at the REPL I’ll look at ThatPkg.dbg. In some ways it’s a poor-man Infiltrator.@exfiltrate, but it’s dead simple to see how it works.
Revise.jl really was the best thing to happen to Julia.
5 Likes
But isn’t the problem of ALL_MODULES_EXCEPT_MAIN that it fails to do what you want as soon as you use map, broadcasting or any other function which is not in Main but gets a function from Main as an argument?
Maybe the docs should emphasize @run and @enter for debugging. They are quite fast once most of the modules are compiled. Clicking on the run and debug button on the other hand is very slow and degrades the experience.
I think I’m running it through the REPL in debugging mode now?
I was able to step from the first line, but I am once again unable to step by the csv.load line it is simply stuck on that.
Uh, sure, but now you’re doing this in a non-VS Code IDE (and apparently through Debugger.jl), which I can’t help you with. My advice was very specific to VS Code.
@PatrickHaecker yes. You need to explicitly set those as interpreted (which was the point of the default list we had in the extension previously, but I don’t have time to maintain that for different Julia versions – it’s surprisingly annoying to find all of the, sometimes internal, higher order functions in Base).
1 Like
I have the following recipe in my startup file which enables to use @infiltrate as exported symbol from Base:
@eval Base begin
import Infiltrator: @infiltrate
export @infiltrate
end
5 Likes
I should of course have tried what you were suggesting in VS code.
The REPL is able to run the code. But it does not stop at break points when I run line 14 through the REPL (by pressing shift+enter)
Am I still doing something wrong? I don’t see anything else in the debugging in VS guide.
My impression is that your time is too valuable to manually maintain such function lists. However, we have a lot of brilliant people reading here. Does anyone have an idea how we can automatically come up with a list of all higher order functions in Base?
I think it would be a great default if the user could have everything in Base compiled except the higher order functions to not be surprised that breakpoints in their own code are ignored in the debugger only because the code is called via a higher order function deep down in the call stack.
I also wanted to use the opportunity to explicitly thank you for your great work, @pfitzseb! It might not be obvious in this thread, but I think I am far from alone when I state that the problem is not you maintaining the VS Code plugin, but that the problem is that we up so far failed to clone you, or, short of that, that more people would need to step up to maintain the VS Code plugin. So thanks again for all your work, @pfitzseb!
4 Likes
Try putting the breakpoint on the println line, or more generally on a function call, not a statement.
Yeah, that’s a good idea. I’m reasonably sure I generated the original list somehow, but it’s been a few years, so let’s see if I can find it again.
1 Like
Try putting the breakpoint on the
printlnline, or more generally on a function call, not a statement.
It still does not stop, but good call that the line I added the breakpoint to was one that could have been optimized out.
Not sure what’s going on then. It’s possible that having the breakpoint on the last line of the function causes issues, or something is weird about your config. Can you post a screenshot with the debugger panel shown? And maybe try matching the breakpoint placement/code that I had above.
I didn’t, but GitHub - pfitzseb/julia-debugger-heuristics: Heuristics to find higher-order-functions in Julia Base seems to produce something useful. I’ll look into integrating this with the extension in same way next week.
Then why not merge my docs PR from 2023 for that page to stop suggesting that approach first?