The R debugger cannot “step through” operations written in C, and anything but those is slow anyway, in or out of the debugger. When Julia is interpreted by the debugger everything is implemented in Julia, so everything becomes slower. That’s why it’s much harder to make a “fast enough” debugger in Julia—because so much Julia code is performance critical, whereas no performance critical code is written in R. A corresponding behavior in Julia would be to run code that ships with Julia itself in compiled mode, which is indeed, exactly what VS Code does when using the Julia debugger, so maybe give that a try.
3 Likes
You should be able to add e.g. CSV to the list of compiled modules in VS Code, after which stepping over calls to CSV.read should basically have native performance (or toggle Compiled Mode manually before stepping over a call you know is slow when interpreted).
6 Likes
That sounds absolutely terrific. It would solve my problem. Of course I am going to do some research on how to do that but if you have some spare time please send me some hints on how to do it.
I believe this is what pfitzseb just recommended, although I believe he was referring only to the CSV package and not to all the code that ships with Julia. (Actually I am not sure if the CSV package classifies as “ships with Julia” since I have to add it before using it. It is registered, for sure.). In any case, I think this will solve my problem, but this is my third or fourth (twelve-hour) day with Julia and also with VSCode, so at this point I do not know yet how to run the code that ships with Julia in compiled code. Any tips would be greatly appreciated. I really like Julia. Python is great but the Julia language is even more logical. The debugging issue was bugging me (pun intended) and hopefully will soon be over. If after that I manage to get rid of the dependencies hell (I keep getting messages that one dependency was “errored”) I will be in good shape. Thanks for creating such a wonderful language, a benefit to the whole of humankind.
Also check out Infiltrator.jl: it can be of immense value, and leads to no slowdown of the code at all.
4 Likes
Where can I find how to do that?
1 Like
I have tried Infiltrator.jl. It worked for a while but now I am getting compilation errors. After debugging understantding better packages is my next step.
I just discovered that on the left sidebar of Visual Studio Code there is an icon for Run and Debug (Ctrl+Shft+D). Clicking there the Run and Debug window opens. It is subdivided into two windows. The upper one is labeled Run. The lower one is labeled Julia: Compiled Code. This seems to be the one related to compiling Base packages. It contains a list of Compiled Packages that does not include some packages I installed like CSV and DataFrames. I have not yet played with it for lack of time to search the documentation.
1 Like
Yes, this is the correct section to choose which modules to run in Compiled mode. You can choose whether to run any module in compiled or interpreted, not just Base modules. In order for modules to show up there, they must have already been loaded (either directly or indirectly).
You want to click the (+) next to the CSV module. It appears on hover-over:
4 Likes
Thanks. That is very helpful. I see there is an option to switch all to compiled. That option is another (+) just to the right to the (+) you mentioned. Is there any disadvantage from switching all packages to run in compiled mode? (I have not created any packages myself)
Would you have references to some of these books?
I only wanted that it stop at the breakpoints 
1 Like
I finally had the time to try your suggestion. Results were mixed.
Before switching to compiled mode I had never been able to run past a CSV.read() line dealing with a large spreadsheet. I waited for 18 minutes.
After switching to compiled code that line of code executed in less than one minute, not significantly different from running without debugging.
However, there were problems down the road. A few lines down the program stopped and the following message appeared:
Exception has occurred: MethodError MethodError: no method matching (::var"#1#2")(::String) The applicable method may be too new: running in world age 29737, while current world is 29738. Closest candidates are: (::var"#1#2")(::Any) at c:\Dropbox\Code\Julia\demo\src\DataPreparation.jl:86 (method too new to be called from this world context.)
This is the code in line 86:
slot_names = filter((x) -> contains(x, "Slot"), names(df_astro))
I tried to comment out this line to see if the same problem would happen further down. Indeed it happened at line 91:
decades = [Dates.year(x) - Dates.year(x) % 10 for x in df_astro[!, :Date]]
However, some lines with println statements and other simple things were run without problems.
The program runs without problems under “Run Without Debugging” (Ctrl+F5 in VSCode).
I hope this “world age” problem is not too hard to handle.
Another strange thing that happened was that when I started playing with this the All section in Julia Compiled Code showed quite a few packages and now it is empty. I had to add the CSV and DataFrames packages to the compiled list by clicking on the big + sign to the right of Julia Compiled Code and then writing the package name on a pop-up dialog above the editor pane.
I managed to get rid of the World Age problem. It looks like it happens if I click on the the red ball to the right of Julia: Compiled Code, which makes the ball become black. When the ball is black Hovering over the red ball one sees Julia: Enable Compiled Mode for the Debugger.
Paradoxically this must not be done. I added CSV to the list of compiled packages by clicking on the big + sign to the right of Julia: Compiled Code (and just to the left of the red ball) and then typing CSV on the dialog that popped up.
After all this:
- My code is running very fast.
- Reading the CSV file is no longer a problem, it happens about as fast as when I am not debugging.
- The code stops on breakpoints even if they are on other modules.
Given 1-3) above I think all the fuss about Julia’s debugging is wildly exaggerated. I confess I was on the verge of quitting Julia after spending many hours facing barriers and finding minimal information.
One problem remains: to the best of my knowledge this information is not easily available. I spent many hours and counted with the help of kind people in this and other forums before I could make this work. Given the importance of debugging for many programmers (myself included) it would be helpful if more info about the interaction between Visual Studio Code and debugging were available.
There is also one remaining mystery. What happened to the files under All that appear in your post? They initially appeared on my screen but now are missing.
5 Likes
If you have any suggestions for documentation, a pull request (or blog) would be much appreciated! New users generally write the best docs since they are more aware of the pain points.
2 Likes
This is a general sentiment — eg Chapter 3 of Clean Code by Robert C Martin starts with a section titled Small!, which says
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
However, note that many people disagree because historically this meant that one had to fight the language and sacrifice performance, code clarity, or reuse. The suggestion is easiest to follow in well-designed languages, especially with multiple dispatch, eg Julia.
7 Likes
Hello Oscar. It is a good suggestion but there are a few problems with it. 1) Although I managed to make things work in my Windows machine I am not sure my recipe would work in other systems, 2) Even in my system I have a great sense of fragility: I do not know if things will be working as they are tomorrow, 3) I do not know how to do pull requests and even if I did I would not dare tampering with the code of people who know much more than I do, 4) A blog could be a good idea. But I am afraid no one would read it. I have a blog called Economic Illusions and it is not a success (I stopped blogging a while ago but I think it is still around). The idea I like most is suggestions for documentation. I can safely say I am good at explaining things, but I would need a contact to send my suggestions to.
I respectfully disagree. People have multiple styles/practices for writing code. Maybe your style is well suited for not having a debugger, but clearly, there are others whose styles would benefit from having a debugger, otherwise this would not be a topic of conversation.
8 Likes
It could be a topic of conversation because people come from languages where using a debugger is a must (C, C++, Matlab, …). If I was brought up thinking I had to walk on stilts, finding that it was possible without might be a shock. But I think one I could get used to.
2 Likes