Debugging in Julia for newbies

Is there any tutorial about how to use a debugger in Julia for newbies (using Juno, VsCode, etc.)? Maybe something in video, similar to Intro to Julia.

http://docs.junolab.org/latest/man/debugging/ is pretty close to a tutorial. Be sure you actually try the examples you can see in the screenshots.

6 Likes

Is there any “idiot-proof” installation guide to support that tutorials? i.e. what exactly should I put in the startup.jl, do I have to using a particular package each time I want to debug, etc.

I’m not sure there’s anything you have to do—if it doesn’t work for you without some magical step, it would be great to spell it out (please submit PR here). Upon reflection, it’s possible/likely that you need to be using Revise or configure it to run automatically. I always have it running so I may have not even considered that step. Try it and see! (and if something special is required, please submit that PR…)

2 Likes

OK, so as far as we know, installing and using Revise is the only thing necessary? No using Debugger in the startup or prior to trying to debug is needed?

using Debugger is definitely not necessary.

Whether Revise is needed, I’m not sure. Perhaps try working through the tutorial without it, and report back?

I can confirm that the example works without Revise in startup.jl.

2 Likes

Does vscode have the same level of debugging integration with Debugger as Juno yet? I know a few people who would really appreciate that.

3 Likes

It does not.

How to use debugger on Juno

Step 1. create file myjuliaprog.jl
make sure there is a function called main() which runs your entire program. Just like the main() in the C language. For debugging purposes, make sure the initial call to main() is commented out otherwise the program will run when you includet it in step 3

Step 2. start REPL and type
using Revise
println(“the above is not necessary if you auto start Revise in your startup.jl”)

Step 3. on the REPL type
includet(“myjuliaprog.jl")
println(“Please note!!! There is a T at the end of the word include”)

Step 4. on Juno set your breakpoint clicking the mouse cursor on left of the linenumber. You can set as many breakpoints as you want

Step 5. on REPL type
Juno.@enter main() or Juno.@run main()

2 Likes

I don’t understand the need of a main() function to debug myjuliaprog.jl.

You can name it whatever you want. If it’s foo(), then the last step should be Juno.@enter foo() or Juno.@run foo().

Normally I do Juno.@enter foo(arg1, arg2) to debug a function and then I use the command Debug: next line. How can I see the values that are assumed by the variables, for example inside a loop?

I understand that the objective of using main() is to debug not only a function but the entire program. Is that right?

How can I see the values that are assumed by the variables, for example inside a loop?

The tutorial covers that explicitly (twice :smile:). Check both red annotations in the bottom section of the first image.

1 Like

main is just an example. In an interactive language the definition of “whole program” is a little tricky. Is split("Hello world", isspace) typed at the REPL a whole program or not? There was literally nothing special about instructing users to define main, it was just needed for consistency with the last step in @StevenSiew’s instructions.

I meant a (simple :slight_smile: ) jl file.

1 Like

hmm I think that Juno should have much better integration with the debugger -the every beforementioned step can be done (and as the matter of fact should be done ) implicitly (by the IDE).

What is the trick? It is naturally for Juno (in debug mode) to wrap CURRENTLY executed script in a function definition and to proceed with debuggin / Is not it?

The requirement for Revise will not be in the next version of Juno anymore, so you only need to make sure the code you want to debug is

  • in a function, and
  • prefix the evaluation with Juno.@run or Juno.@enter

We could indeed lift the second requirement with creating a new “REPL mode” which interprets your code by default, but I’m not sure if that is a good idea – imho it’s good to be explicit about what you want.
The first requirement could be worked around as well, but, considering that you can evaluate a line of code with Ctrl-Enter, I’m not sure how worthwhile it would be to build a nice interface for that.

1 Like

What is the ballpark timeline for that version? (e.g are we talking June or September)?