World age warning on debugger

Tooling VS Code
1

I’m quite new to VS Code. I just started to use it several days ago. I’m already comfortable in editing Julia code on it. I use the official Julia extension.

When I run the debugger on a module, however, it warns about world-age issues on all my functions, even when the module includes only function statements and using statements for standard modules. There is absolutely no global variables, include statements, or any function calls at the module top level.

But then, searching this forum, I found only old threads about the VS Code Julia debugger. So, I wonder what’s going on.

2

What does that mean exactly?

FWIW, I’d always recommend running very specific code in the debugger, e.g. with @run/@enter.

3

Thank you for your question, which by itself shows that “the debugger” (to me) isn’t well known in the Julia community!

  1. Install the official Julia extension (author: julialang).
  2. Open your Julia program/module.
  3. Click on the “Run and Debug” button in the left-most side strip > The “Run and Debug” pane shows up to the left of the editor tab.
  4. Click on the “create launch.json file” link and save launch.json file which is automatically generated.
  5. Come back to your Julia program (activate your Julia source code tab).
  6. Click on the “play” :play_button: button at the top of the “Run and Debug” pane.

Then, the debug session starts. If your code includes an error, the line is highlighted and a popup shows a detailed error diagnosis.

I thought that this is how debugging works on VS Code.

4

Yeah, that’s one way to to run the debugger.

I would typically recommend running a specific function in the debugger instead of your whole codebase though, mostly because of the slowness of the debugger and the overhead of having to start a new Julia session.

Take a look at Debugging · Julia in VS Code for a more REPL-centric approach, which crucially doesn’t run all your top-level code through the debugger and therefore shouldn’t cause any world age issues.

5

Thanks. At the top of the webpage you linked actually shows what I described in my previous post! So, it’s known and it’s not something obscure that nobody uses. Good.

Can you elaborate on that? Currently my code looks like this:

module MyModule
using SomeStandardModule
function myfunc1(x, y, z)
   # . . . 
end
function myfunc2(a, b, c)
   # . . .
end
# . . . some more funcs . . .
function testing()
   # . . . do something meaningful with myfunc1(), myfunc2(), . . .
end
testing() # do the test
end # module MyModule

When I’m satisfied, I’ll comment out the function call testing() and use the module from other programs of mine.

The only advantage of the REPL method you mention is that it’s much faster than the debugger, is it?

6

That, and it doesn’t require you to comment stuff out that shouldn’t be there anyways.

The typical pattern in a case like yours is to remove the top-level testing() call and run something like

  • using MyModule
  • julia> testing()
  • make changes, apply via Revise or inline evaluation
  • julia> testing()
  • make changes, apply via Revise or inline evaluation
  • debug via julia> @run testing() after setting some breakpoints
1 Like