'R path not working: /usr/local/bin/R (Can be changed in setting r.rpath.XXX)' #155
Comments
|
Maybe the R start up takes unusually long? You can change the config |
Got the same error too. Increasing the timeout startup setting works. |
|
I was having this problem as well (same OS and R version) and increasing the timeout startup setting did not work in my case. I ran the extension in debug mode and threw a breakpoint here: VSCode-R-Debugger/src/debugRuntime.ts Line 166 in d413046 I could see that I added some breakpoints at the stdout and stderr handlers but they never seem to be hit. So just not getting any response from the R session. In addition, I am able to get it to run with the default attach configuration. (Followed instruction here: https://github.com/ManuelHentschel/VSCode-R-Debugger#attach-mode) Any suggestions for where to check? I'm happy to help debug further. |
|
I have the same issue. |
|
I'm having the same issue, also with M1 MacBook. Increasing the startup timeout had no effect. |
|
Can you please post the content of the output channel ( |
|
Sure. Here is testing with default settings: One thing I notice is that When I set that executable as Running that binary directly from the shell also gives a similar error message: "Fatal error: R home directory is not defined". So my conclusions so far is that we need a way to start the R process from the shell script, but then identify the correct binary to attach to later. Does that seem right? |
|
I seemed to have fixed it, but honestly, I have no clue how- I uninstalled R, the debugger, the Visual Studio Code extension, and reinstalled them a couple of times- the first time, I got new errors, however the second time, it all worked okay. Seemingly random, and not very useful, but glad to get it working nonetheless 😅 it might have something to do with installing via homebrew versus installing with a pkg downloaded from R's website maybe? As with @THargreaves, before doing the above, I had tried increasing the timeout a bunch of times, to larger and larger numbers, but none of them worked. |
|
Nevermind about the shell vs executable idea. I tested on an Intel Mac (OSX 11.6, R 4.0.2) and it works just fine with default settings. I'll do some more testing to see what's different on the M1 mac vs Intel and post what I find. For comparison, here's the successful log output: |
|
Thanks for the logs! I don't have a mac available, so I can't really debug this any further, but a quick google search seems to indicate that you are not the only one having problems with R and M1. So I'd hope that some of the future R updates (or node/vscode/whatever) fixes this, if not I'll have to try and get my hands on a mac... I noticed that the shell script you linked seems to check the cpu architecture to some extent, but no idea if that has any effect in this case. If you want to play around a bit to get the binary working, you could also try setting relevant environment variables yourself, using the |
|
It seems like vscdebugger doesn't support arm64. Maybe it is caused by this reason? |
|
@xiajunwen1007 I don't think the build architecture of vscdebugger is the root cause. I've tried to compile an arm64 native version of vscdebugger on my m1 mbp and now vscdebugger can be loaded correctly. However, the VS Code still throws me the same error saying cannot find the R executable. |
|
After spending one day investigating this issue, I noticed one thing on the arm64 build of the R executable for macOS M1 chip, version 4.1.2 (potentially a bug). The arm64 build seems to have some trouble picking up the data piped in when the For example, try to run the following command: echo "base::cat('Hello\\\\n')\\n" | R --no-save --interactive > test.txtAnd when you examine the I've tested on the intel build (4.1.2), and I can get the expected behavior with a valid output. Could anyone maybe confirm the issue? |
|
It seems the same output. (I've tested on Docker containers on amd64 WSL2 and arm64 Raspberry Pi 4) $ echo "base::cat('Hello\\\\n')\\n" | R --no-save --interactive > /tmp/test.txt
Error: unexpected '\\' in "base::cat('Hello\\n')\"
$ ls /tmp/
test.txt
$ cat /tmp/test.txt
R version 4.1.2 (2021-11-01) -- "Bird Hippie"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> base::cat('Hello\\n')\n
>$ echo "base::cat('Hello\\\\n')\\n" | R --no-save --interactive > /tmp/test.txt
Error: unexpected '\\' in "base::cat('Hello\\n')\"
$ ls /tmp/
test.txt
$ cat /tmp/test.txt
R version 4.1.2 (2021-11-01) -- "Bird Hippie"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: aarch64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> base::cat('Hello\\n')\n
> |
|
@eitsupi Sorry, I didn't mention I was referring to the build for the macOS M1 chip. I guess this issue is specific for the macOS M1 arm64 build instead of all arm64 builds. Also, it seems macOS takes the strings (with escaping) in a different way. echo "base::cat('Hello\\\\n')\\n"I am using zsh with echo, and it can correctly feed this line to the R console without any warning like |
Great investigation. I can definitely confirm the issue. After running |
|
I am using M1 processor, and also with R 4.1.2, encountering the same |
I tried starting debug with "attach to R process", which fails. I got the message So both |
|
|
@milanglacier Based on the confirmation from @PaulKeydel (thanks Paul!) above, I guess this issue is kind of beyond our reach here. And if you can also reproduce the same behavior as I mentioned above, then "delete and reinstall and hope" is definitely not gonna work. Is anyone here a member of the R Bugzilla? We probably have to file a bug report to the R dev team to investigate this issue. |
Hi! Yeah, I can reproduce it.
|
|
@milanglacier It really seems like the arm64 build for M1 (only the build for M1) is quite broken for piping from stdin when |
|
I've insufficiently tested this extension with the In the meantime, you might also need to increase the wait time by following this, as I noticed my R session took quite some time to respond. I was using 4000 ms to make it work. But BE CAREFUL, this is neither a solution nor a valid workaround; it's more like an "ad-hoc make it work" solution, as without the |
Nice that this works for you :-) I already tried this, but for me it produces some other problems which I couldn't solve quickly. So I decided to not continue this, especially because it's a dirty solution, anyway. Instead you could use the Intel-based build of R together with Rosetta on your arm-Mac. Or just another IDE... As @totoroyyb said, it would be nice if anyone here is in the R Bugzilla team or if anyone has experiences with them. If not I could submit a short bug report. |
|
Good and bad news so far: The above issue that R ignores input from stdin when the --interactive flag is set, is still fixed in newer versions of R. You could find these patches (including installer packages) here: https://mac.r-project.org However, after the installation I got some new problems concerning the R-package "vscDebugger", which is necessary for debugging. Up to now, this package is not supported by newer R versions. So the installation via install.packages("vscDebugger") results in an error: I think we have to wait until the next official version of R is released... |
|
The You may install the latest version by |
Yeah, that was the missing link :-) So, following @eitsupi and using the current R patches from https://mac.r-project.org/ should finally solve the initial issue! |
Description
R Debugger doesn't see the R executable, even though the correct R path has been given?
To Reproduce
Your R code
test.R
Your Launch config
If applicable, the launch config that causes the bug. E.g.:
{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "type": "R-Debugger", "name": "Launch R-Workspace", "request": "launch", "debugMode": "workspace", "workingDirectory": "${workspaceFolder}" }, { "type": "R-Debugger", "name": "Debug R-File", "request": "launch", "debugMode": "file", "workingDirectory": "${workspaceFolder}", "file": "${file}" }, { "type": "R-Debugger", "name": "Debug R-Function", "request": "launch", "debugMode": "function", "workingDirectory": "${workspaceFolder}", "file": "${file}", "mainFunction": "main", "allowGlobalDebugging": false }, { "type": "R-Debugger", "name": "Debug R-Package", "request": "launch", "debugMode": "workspace", "workingDirectory": "${workspaceFolder}", "includePackageScopes": true, "loadPackages": [ "." ] }, { "type": "R-Debugger", "request": "attach", "name": "Attach to R process", "splitOverwrittenOutput": true } ] }Expected behavior
Run
Actual behavior
Throws an error
Desktop (please complete the following information):
Additional context
I'm new to VS Code, coming from RStudio, so I may have messed something up here, however, I've tried installing it three times now (reinstalling VSCode, with no luck!). Don't know what I'm doing wrong.
The path to R is the one in the title, I've double checked! I've added the path to both the rterm and rpath options in settings, and it doesn't work, nor does removing both. VS Code can see the R binary for the terminal, but the debugger seemingly cannot see it
The text was updated successfully, but these errors were encountered: