-
Notifications
You must be signed in to change notification settings - Fork 130
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
R session background connections #440
Comments
I've tried adding similar functionality to the debugger in ManuelHentschel/VSCode-R-Debugger#94. To use it, start an R session (any terminal works), create some variables etc., and then run {
"type": "R-Debugger",
"request": "attach",
"name": "Attach to R process",
"splitOverwrittenOutput": true
} This will allow you to view the current workspace, the callstack (if you called .vsc.listen while inside a function), and evaluate arbitrary code in the debug console (autocomplete should work here, but seems to be a bit unstable). If the R session was launched inside a VSCode terminal, it will also allow settings breakpoints and using the flow control buttons to a limited extent. (Edit: the strike through parts are mostly not true...)
This would be possible using
Since this is independent of each R session, we could achieve this by spawning a separate helper process, similar to the languageserver. |
Hi @ManuelHentschel, thank you for your comment, and also thank you more generally for all your contributions to the VS Code R space recently! As a proof of concept, I put together a small demo: https://github.com/andycraig/r-websocket-repl-demo/tree/main/demo It uses the My example of querying data frame names wasn't the best since it already is implemented by the session watcher. |
Thanks @andycraig and @ManuelHentschel for sharing your thoughts on this. I have some thoughts on the pro and cons in practice on this and will post later today. |
The demo works quite nicely, I wasn't aware of that package/functionality. I guess most of what I said above is not accurate then. |
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 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. |
In the implementation of R session watcher, I deliberately chose not to use socket-connection based communication between editor and R session because I had poor experience working with RStudio Server in the following scenarios:
Then using the task callback is a simple way to extract some information from R session while keep the session "safe" from such connections that could make it unstable especially under parallel computing or high-loading scenarios and keep the dependency minimal. However, the price is obvious too: querying data on demand and two-way communication would be not easy. @andycraig's demo starting a WebSocket server is just like what I did in #394 implementing the server side of R notebook but in an interactive session so that it could handle WebSocket connections in the background while the main event loop is idle. @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. One notable difference is that the R notebook session uses In vscode-R's case, personally I need a REPL that could communicate with the editor but should be kept
Therefore, if we are to enhance the REPL experiece, the best choice here might be we implement a WebSocket backend of session watcher and let user's interactive session to start a background server to communicate. |
It would be very helpful in resolving a number of issues sending code to terminal:
but it will produce new issues like if the session is busy, then it cannot handle messages timely, then looks like we need to handle some queuing problem? Not sure about this.
If we could use
This is actually cool if not fancy as a non-REPL experience. But I'm not sure if it is useful when working with complex code and large datasets where I need to do a lot of interactive, back-and-forth evaluation. |
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 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?). |
@renkun-ken Thank you for your thoughts on this!
I agree 100% with these requirements. For me one of the key features of vscode-R is that it gives us access to a 'raw' REPL with all the benefits you mentioned.
Sounds good to me. As you've noted there are a number of technical details that will need some consideration (queuing if session is busy etc.). If I start working on an experimental implementation I'll post here. |
This issue is stale because it has been open for 365 days with no activity. |
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:Run Selection/Line
, potentially using R instead of TypeScript to choose which lines to send (allowing use of R's parse functions)@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.The text was updated successfully, but these errors were encountered: