Debugging Pane with Non-Functions

Tooling Juno
,
1

Hello,

Coming from a MATLAB background, I was a little surprised that Juno does not allow for the debugging of non-functions. Most of my work is done within simple scripts that import data, perform analysis on that data, and then plot results. I’d like to have the freedom to perform debugging with scripts themselves while not having to define functions, else this requires me to place my entire script within functions, which is often unnecessary due to the simplicity. Am I missing something, or is this not supported?

Thanks.

2

You need to put your operations in a function to speed up your code. Global variables are not inferable and so you don’t use Julia’s power of compiling. No need to be a separate file though, local functions work too!

For debugging, I recommend Infiltrator.jl. It is very similar to Matlab. Just add it and put @infiltrate in where ever you want. Run your program in the usual way, and it will hit this breakpoint (no need to use @enter or something). Use @locals for getting local variables in the workspace.

In a near future, Infiltrate will be integrated to Atom so you can just use normal breakpoints

3

Thanks for the info- so even if I’m just reading in a CSV and plotting the result after manipulating the data I should wrap this inside a function and then call it? That being said, my variables won’t go into my workspace, so I suppose this is what you meant about using @local to transfer my in-function local variables to my workspace?

Just so I understand- the LLVM JIT compiling isn’t able to optimize outside of the function? Is there more documentation on this? I’d like to make sure I’m not missing any other obvious misuses of a JIT language.

4

This is the full performance tips documentation
https://docs.julialang.org/en/v1/manual/performance-tips/
However, you will learn it over time, and if you only consider these two important things you’re good to go:

  1. Wrap your operations inside a function. Or define your global variables as const.
    (Not doing so, for the compiler, means that your global variable’s type can change at any time, and so it is slower!)

  2. Don’t change type of a variable in the middle of the program.

@locals doesn’t transfer anything. It just prints local workspace of the function