-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore built-in "variable explorer" notebook functionality #165445
Comments
Request for showing the same data that the variables viewer shows in extra columns, but in normal debugging: #146748 |
Some notes from conversation with @DonJayamanne
|
Hi @davidanthoff @jonsequitur @claudiaregio, I wanted to call this out to you that we have started to investigate how to add a built-in variable explorer with API that notebook extensions can drive. For Jupyter, this would replace the variables viewer that we currently have. I've written some thoughts on the UI experience at the top of this issue, and #166296 covers API. Is this something that you would be interested in using? If so, what would you like to see in it? |
We'd definitely be interested in using it for Polyglot Notebooks. One of most important distinctions we have is the need to say which subkernel a variable is located in:
Notice in the screenshot that we have an action button for sharing variables with other kernels. This doesn't open a viewer. It adds a cell with generated code:
Agreed. For this reason, we're working on making our inline object displays into expandable trees similar to what we do for JSON: |
I don't see it mentioned here but when would the variables in this view be refreshed? Our current implementation is a bit chattier than necessary and we're thinking through how to improve that. |
Is it important that this data be immediately visible for every variable? What if you could see this info by hovering, or expanding the variable value?
I'm imagining that extensions will be able to contribute arbitrary commands, the same way other menu contributions work.
That will likely be up to the extension |
Yes, I think this is critical to help people understand polyglot workflows and variable sharing. |
I'm imagining that as a shortcut, maybe the extension could return the kernel name as part of the variable name. e.g., it returns Can you also tell me about the behavior of the filter box? |
The column header helps people understand what's in the column, so concatenating them would be less intuitive. Another thing that would be very useful is a type name column. Our inline output always renders types with a link to documentation, and having that facility would be very helpful here as well. Given these two considerations, the ability to add custom columns seems like it would let us bring our own specific scenarios as appropriate. Sorting by kernel would be helpful. We don't currently support sorting. The filter box currently filters across the string values in all columns, so you can use it to filter by kernel name or variable name or values. |
YES! We currently have a full variable viewer/inspector in the Julia extension, but I'd love to get rid of our custom implementation and reuse something that ships as part of VS Code itself. Maybe I can provide a quick overview of how we do this right now in the Julia extension, and what features would be important for us to replace our custom implementation with something in the core product. This is how things look at the moment: Couple of random observations:
So that is where we are with Julia at the moment. Some reactions to questions that came up above:
We haven't gotten any request for that from our users so far. I think having that info in a tooltip would be nice. The reason we don't have it right now is that the tree view doesn't really support columns, but of course the main VS has a tree/column type UI element, if that could be used I'd say that would be a win.
Completely agreed, I think sorting is not important.
I think not :) I'd say if we had inline tree views in addition to something that is similar to the current Julia workspace it would be great (Juno, the Atom based Julia extension had expandable, inline tree views), but in my mind this couldn't replace a separate pane like we have right now. Some other random thoughts:
Also pinging @pfitzseb for his thoughts. |
@flying-sheep, I hope you are aware of the other options for where the debug toolbar appears ( Re your third point I suggest you try the current 1.84 Insider, as you can now drag the "Run and Debug" icon off the Activity Bar and drop it onto the Panel. An example layout (docked toolbar, justified panel): |
Oh wow, thank you! I wasn’t aware, and I’m trying to follow the release announcements closely. With the two changes you mentioned, my debug experience should shift from “frustrating” to “nice”. If it gets the the variable viewer from this issue that I so inconsiderably hijacked, and a few small changes, there’s potential for greatness. |
For anyone interested, there is a preview version of this available! |
The new variable view is used for Jupyter extension kernels, and the Python extension's native REPL. |
The Jupyter extension has a variable explorer as a webview in a panel. This should be moved into vscode core as part of common workbench UI. Things to explore:
The Jupyter extension creates a "fake" debug session to show variables in the debug UIThe text was updated successfully, but these errors were encountered: