Closed ManuelHentschel closed 4 years ago
Update:
The last changes add basic flow control for attached R processes that run in integrated terminals. In order to send commands (n
, c
, ...) to R's stdin, the WriteToStdinEvents
mentioned above are sent to a different port and handled in the vscode extension.
In order to send the commands to the correct terminal, these events now include the pid of the R process, the pid of R's parent process (only works on unix like systems), and the value of the environment variable VSCODE_R_DEBUGGER_TERMINAL_ID
(fallback for non unix like systems, i.e. windows), which is set by the following vscode setting and updated after a terminal is created.
"terminal.integrated.env.windows": {
"VSCODE_R_DEBUGGER_TERMINAL_ID": "1"
}
Current situation: The debugger always starts a new R process for each debug session and has direct access to its stdin/stdout/stderr.
This is ideal to make the debugger as powerful as possible, but can be a problem when users want to e.g. view the variables in an externally running R process or need more direct access to the stdio of the process.
Intended improvement: Add an "attached" debug mode, where the debug adapter is started from within a running R session and handles DAP-messages received through a tcp socket. When disconnecting from the debug adapter, the R session resumes and can be controlled via stdio again.
WIP: The branches VSCode-R-Debugger/attach and vscDebugger/attach include basic support for attach requests. To use this mode, start an R session and run the command
vscDebugger::.vsc.listenForDAP()
.Then launch the debug config entry
to start debugging. Use
continue
/disconnect
to return control to the stdio of the R process.Open questions: