Recommendations for debugging and accessing variable definitions within procedures in notebooks

[AvijeetPrasad]

Typically when running IDL from the terminal, I use a stop statement before the end of my procedure, so that I can still access the variables, which are cleared out when the routine 'ends'. For example, I would write something like the following:

pro teststop 
compile_opt idl2
a = 1
stop
end

In a terminal session, this will allow me to access the variable a and check if the values are as expected, which could be very useful for debugging. Now, within the IDL notebooks, this throws up an error. So, I was wondering if there are any recommendations on what could be an equivalent of the stop statement here?

[znorman-harris]

We don't support debugging with notebooks at this point in time. In fact, we always execute retall after we run any notebook cell to make sure you are not stuck in the scope of a routine somewhere.

I'm on the fence about us ever adding debugging into notebooks considering we have some technical hurdles we would also have to cross and I'm unsure about the user experience in VSCode if you are debugging a notebook and have the debug console open at the same time.

Right now I think we have two concepts for user experience:

1. Writing and debugging code: Launch a session of IDL that uses the VSCode debug console. This is where you can set breakpoints and have the "live" IDL programming experience that we have always had.
2. Creating a sandbox to try out new routines: IDL Notebooks

With notebooks, if you just use main level programs, you can always access variables after-the-fact. We also just added some indicators to tell you where you stopped in cells, but you aren't in that scope for IDL since we execute retall.

After we get a new debugger for IDL, we might be able to revisit this. But it will also depend on the VSCode UI interactions as well since we have two use cases right now that both need the debug toolbar and it might cause confusion with two of them open.