Workspace viewer similar to vscode-julia

Is your feature request related to a problem? Please describe. It is time-consuming having to individually examine objects through the View() command. View(globalenv()) does not update automatically so cannot be used for this purpose.

Describe the solution you’d like

I understand that this has been around about brought up in a few issues, such as #15, #23, and #47. However, I think that with the session viewer having access to the current R environment, it would be neat to do something similar to what vscode-julia has semi-recently implemented here.

Considering that the session viewer currently examines the R environment, I think exposing what it shows in the sidebar would be helpful. This exists in vscode-julia, and in R Studio (i.e. the environment viewer). We currently sort of have this through the View(globalenv()) call (which is great!), but the returned dataframe is not interactive, doesn’t update without reloading the object, and takes up a pane in the workspace.

At the moment, we are able to access objects, graphs, etc. with the View() command when we have the session viewer enabled. In vscode-julia, when you click on, for example, a dataframe, it opens up the dataframe in the active panel. I think we could have a similar thing, where objects can be opened by clicking them in the “workspace viewer”, so that we can easily and quickly move between examining objects, functions, etc. It could be it calls a View() command in the active R terminal when you click on the object.

Overall, I think what is missing right now is:

• Workspace viewer that updates without reload
  • It could be that when a variable is defined (or re-defined), the workspace viewer is updated
• Ability to preview environment objects by clicking them in the workspace viewer
• Workspace viewer contained within sidebar area to not take up space

Describe alternatives you’ve considered If the dataframe from the View(globalenv() was updated following an object being defined, it could act as a simple environment viewer.

The View() command can be bound to a keybind in order to offset typing, and can be used with objects selected in order to speed this up even more. However, it does not offset the fact that it must be run at all, as a live workspace would remove this step.

Additional context

Here is the julia workspace preview, indicated by the red arrow:

Here is a small mockup I made for example:

[ElianHugh]

I have now implemented view, manual refresh, and environment clearing. I wanted to add memory allocation like RStudio has, but I don’t think that it’s a necessity. Below is how it is currently functioning:

Once I’m happy with it, I could set up a PR? I currently have it on a fork (https://github.com/ElianHugh/vscode-R), which seems to be working on Windows. I’m not sure how this would interact with remote setups (I have yet to test WSL), presumably a globalenv file exists for these?

Aside from that, are there any features that people think is missing?

[ElianHugh]

I’ve made some significant progress that I thought might be interesting.

Workspace is tied into globalenv so it updates on the fly. I’m not 100% what information should be displayed, so I’ve settled for the key and str output for the time being.

I’ve yet to add the View() on click command but that should be easy enough (I hope).

No idea, if you upload the code I could take a look

Turns out there was a tiny typo breaking the whole thing… 😃 Thank you though!

I ran a small test with a file tmp.R containing the following:

N <- 1e8

t0 <- as.numeric(Sys.time())

for(i in 1:N){}

t1 <- as.numeric(Sys.time())
print(t1-t0)

Results are:

D:\Documents\Projekte\vscode\RTools\vscDebugger>R --silent
> source('tmp.R') # no websocket at all:
[1] 0.7214899

> vscDebugger::.vsc.startWebsocket()
Starting server on port: 18721

> source('tmp.R') # no debug session attached:
[1] 0.9104981

> source('tmp.R') # with an attached debug session:
[1] 5.061661

> source('tmp.R') # after disconnecting the debug session again:
[1] 5.072534
Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") : # will have to fix this...
  [tcl] can not find channel named "sock000000002140E440".

There definitely is some very significant overhead in this example, though I don’t know how more realistic computations behave. The disconnect doesn’t seem to work properly yet, but it should be possible to get back to the performance of the second run (running websocket, no debug session)

Interesting! Perhaps it would be useful for unobtrusive command calls, e.g. the IDE calling View() without littering the terminal?