Debug REPL frame navigation

[slishak]

I have a few questions about the REPL window while debugging Python code. I'm on VS 2015 with PTVS 2.2.

I often used to use the commands $frame, $where, $u and $d to navigate between frames in the REPL while debugging. However, I have recently noticed that all of these options have disappeared from the $help text, and $u and $d no longer work. I'm not sure when they were removed or if it was intentional, but was hoping someone could shed some light on this!

When debugging, if I want to change the scope of the debug REPL window using the dropdown box (that usually says <CurrentFrame>), code in my own projects never appears in the list (I can use $mod to change to it though), sometimes the list is empty except for <CurrentFrame> even after many modules have been imported, and sometimes the dropdown disappears entirely. Unfortunately I haven't yet been able to reliably reproduce the situations in which each of the latter two problems occur.

Finally, I'm aware that there are some exciting changes coming up to improve the interactive experience in PTVS. As part of #81, will the debug REPL frame keep up with the stack frame selection in the editor window?

[zooba]

We identified the broken commands recently and our next update will include a fix for it.

The debug REPL is already supposed to keep up with stack frame selections from the Call Stack window, so that sounds like a bug. I don't believe we can let you switch the frame from the REPL itself, and I don't recall whether we are supposed to offer modules in the debug REPL, so that could be a bug in either direction ("can't always select modules"/"can sometimes select modules").

As we are looking to make changes here, could you expand a bit on how you're using this and what you are trying to achieve? It will help us immensely with planning.

[slishak]

As far as I'm aware, the debug REPL has never kept up with stack frame selections. It mentions as much in the documentation here https://github.com/Microsoft/ptvs/wiki/Debugging in the second last paragraph.

The reason it would be useful is that when I'm debugging through an application, I want to be able to quickly and easily inspect variables in different levels of the call stack. The best way of doing this for me is the Stack Frame dropdown (or the Call Stack window), and this will currently allow me to hover over variables to inspect them, or use the Locals window, but the REPL doesn't update with the selected frame. I need to use $frame to keep them in sync.

Using the modules dropdown isn't usually that important to me, and personally I'd even suggest removing it as it would be best to have the frame of the REPL to be always the same as the frame of everything else to avoid confusion. I only reported the issue because I noticed it was behaving strangely.

The way I would like to use PTVS debugging is basically the same way as the Matlab UI is used, assuming you're familiar with that. The features mentioned in #751 will be very useful for me, especially being able to hit a breakpoint in a function when calling the function from the interactive window.

I'm not sure if this is covered by the discussion in #751 already, but it would be especially useful to be able to hit a breakpoint in my code, step through the code to a new location, switch to another frame, call a function from the debug REPL which has another breakpoint in it (or even the original breakpoint I'm stopped at) and have it stop there again (and even be able to repeat the process from that second breakpoint). If I then press F5, it will continue running until control is returned to the REPL where I originally called the function. This is achieved very nicely in Matlab, although I understand it's some quite complicated behaviour and might not be feasible in PTVS. At the very least I'd hope to be able to hit a breakpoint in a function called in the REPL while stopped at a different breakpoint.

That, in conjunction with performance improvements to debugging and the proposals to allow data visualisation in #747 and #748, is exactly how I'd like to be able to use PTVS.

In Matlab you also have the advantage of being able to edit files while in a debug session (as long as they aren't currently in the stack frame) and have those modifications take effect in that session, but I guess it wouldn't be so easy in Python as you'd have to reload the whole module containing that function. This one is more of an "in an ideal world" suggestion...

It should go without saying, but despite all of the above I am currently very happy with the experience of debugging code in PTVS - it's way ahead of anything else in Python as far as I know. Thanks for all your good work!

[zooba]

As far as I'm aware, the debug REPL has never kept up with stack frame selections. It mentions as much in the documentation here https://github.com/Microsoft/ptvs/wiki/Debugging in the second last paragraph.

You are absolutely correct. I suspect this means there is no way for us to determine which frame is currently selected in the call stack window, but possibly we can use some trick to determine it.

Thank you for the other feedback. We are familiar with MATLAB's approach and are definitely hoping to provide something more familiar for MATLAB users.

(As an aside:

In Matlab you also have the advantage of being able to edit files while in a debug session (as long as they aren't currently in the stack frame) and have those modifications take effect in that session

We have some ideas about how this may be possible, but it would require changes to each Python interpreter to support it, or at least some very magic code. It's not a high priority, simply because we have so many other things that we can do and will benefit all of our users, not just those who are able to use the latest versions of Python.)