R session background connections

In #394, notebook.R runs a socket connection that the notebook communicates with. Would it be worth extracting part of this out so that a socket connection is available for each R session started by the user? This would make the following possible:

• Sending VS Code’s R commands to the session invisibly, rather than having to send them as text to the console
• Querying the session, for example to get the names of data frames
• For Run Selection/Line, potentially using R instead of TypeScript to choose which lines to send (allowing use of R’s parse functions)
• Inline evaluation (sending user code to the session invisibly, and displaying the results in the editor) - this one’s not really necessary but some other languages/IDE’s have it and it’s kind of cool

@renkun-ken You wrote notebook.R and the session watcher, which has some overlap with this proposal, so you’re definitely the best person to comment. Does this sound practical? Let me know if I need to clarify anything.

[ManuelHentschel]

@ManuelHentschel’s implementation is similar with R notebook session in that both debugger and notebook session are fully managed and the user does not directly work with the session but through a protocol.

In the branch linked above (vscDebugger/websocket) the debugger attaches to a tcp port that is run in the background (in a separate tcl thread apparently, not entirely sure myself…). After attaching, you need to enter any command in the R console to view the Global Workspace, but after that the session is surprisingly robust when dealing with parallel execution etc.

E.g. while running

> f <- function(x){Sys.sleep(x); print(x); x}
> l <- parallel::mclapply(1:10, f)

the debug console is responsive and it’s even possible to change the value of variables in the gloabl env in the variables window.

Same seems to apply e.g. here:

> x <- 1
> Sys.sleep(10); print(x)
# in the debug console: x <- 99 
[1] 99

Using the debugger in this mode seems to be semi-barebone (the commands entered into the R terminal itself are, the ones entered in the debug console definitely not), persistent (the R process can be started in an external terminal independent of vscode), and seems to be at least somewhat parallel-safe (see examples above?).

[ManuelHentschel]

Thanks @andycraig for your proof of concept! I tried integrating this functionality in the debugger, using svSocket instead of a websocket.

This required some changes to the svSocket package which I commited here, but seems to work ok on windows and WSL. To try these out, install the branch vscDebugger/websocket and the modified version of svSocket. Then start an R session, call vscDebugger::.vsc.startWebsocket() and launch the debugger in the example config Attach to R process.

This mode is still a bit unstable, but you should be able to view the current workspace in the variable window and run commands in the debug console (autocomplete seems to be broken here for some reason), without blocking the user from using the normal terminal input.

This approach is of course somewhat limited by the fact that it can only be accessed through the debugger. But I think it would e.g. be possible to write a custom DAP-client that sends only the requests/commands you are interested in and displays the info in a custom interface.