Local processes not launched when using Visual Studio Code on macOS
uhkeller opened this issue · comments
Running the "Quickstart" example from the Readme fails when R is running in Visual Studio Code with the vscode-R extension.
library(mirai)
m <- mirai(
{
res <- rnorm(x) + y ^ 2
res / rev(res)
},
x = 10,
y = runif(1)
)
m$data The output is always 'unresolved' logi NA. There is no error message or any other indication that something has gone wrong. Watching the process list it appears that the worker process is not even created.
This happens both with radian and the standard R binary when run in VS Code. With RStudio and R or radian running in a terminal, there is no problem.
I realize that this probably is a bug or an incompatibility in vscode-R , but an issue I created in their repo a while ago got no response, so I was hoping you could help me with diagnosing what's going wrong so I can provide the vscode-R devs with some actionable information.
macOS 14.2.1 (M1)
R 4.3.2 (CRAN binary)
mirai 0.12.0
vscode-R 2.8.2
I do not encounter this issue with vscode using the same extension version under Ubuntu 22.04.
Try the following code, see if it returns any errors rather than the expected output:
library(mirai)
daemons(url = local_url(), output = TRUE)
#> [1] 1
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> abstract://eb2637d3f92c30d292ce3c4d 1 0 0 0 0
launch_local(1)
Sys.sleep(1)
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> abstract://eb2637d3f92c30d292ce3c4d 1 1 1 0 0
daemons(0)
#> [1] 0Created on 2024-01-18 with reprex v2.1.0
Thanks for you reply. This is my output:
library(mirai)
daemons(url = local_url(), output = TRUE)
#> [1] 1
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> ipc:///tmp/2040528e697d96a8c70a3f1b 1 0 0 0 0
launch_local(1)
Sys.sleep(1)
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> ipc:///tmp/2040528e697d96a8c70a3f1b 1 0 0 0 0
daemons(0)
#> [1] 0Created on 2024-01-18 with reprex v2.1.0
How very interesting... it seems dispatcher launches and connects but not the daemon.
If you run the mirai example prior to resetting daemons with daemons(0), does it stay unresolved? If you then call daemons(0) does it now resolve to an 'errorValue'? If so then I don't think there is any fundamental issue with mirai.
Just to confirm that individual daemons have issues, if you try
daemons(1, dispatcher = FALSE, output = TRUE)
Sys.sleep(2)
status()
does connections show as 0? Do you get any error messages print to the console?
The only difference that would allow dispatcher to work is that it calls Rscript with --vanilla flags, but explicitly passing in the path to the package library. Given crew also doesn't work, and it uses processx as the local launcher, I think you'll find you have the same problem with other packages as well. It strongly suggests that your instance of vscode is somehow messing with the R startup configuration files.
If you run the mirai example prior to resetting daemons with
daemons(0), does it stay unresolved? If you then calldaemons(0)does it now resolve to an 'errorValue'? If so then I don't think there is any fundamental issue withmirai.
Not 100% sure I undestand what you mean. This?
library(mirai)
daemons(url = local_url(), output = TRUE)
#> [1] 1
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> ipc:///tmp/e793d52e892454b09eea1d15 1 0 0 0 0
launch_local(1)
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> ipc:///tmp/e793d52e892454b09eea1d15 1 0 0 0 0
m <- mirai(
{
res <- rnorm(x) + y ^ 2
res / rev(res)
},
x = 10,
y = runif(1)
)
Sys.sleep(1)
m$data
#> 'unresolved' logi NA
status()
#> $connections
#> [1] 1
#>
#> $daemons
#> i online instance assigned complete
#> ipc:///tmp/e793d52e892454b09eea1d15 1 0 0 0 0
daemons(0)
#> [1] 0Created on 2024-01-18 with reprex v2.1.0
Just to confirm that individual daemons have issues, if you try
daemons(1, dispatcher = FALSE, output = TRUE) Sys.sleep(2) status()does connections show as
0? Do you get any error messages print to the console?The only difference that would allow dispatcher to work is that it calls Rscript with
--vanillaflags, but explicitly passing in the path to the package library. Givencrewalso doesn't work, and it usesprocessxas the local launcher, I think you'll find you have the same problem with other packages as well. It strongly suggests that your instance of vscode is somehow messing with the R startup configuration files.
Connections show as 0. Plus the first time (only) I run this in a new R session I get this error after the daemons() call:
Error in loadNamespace(x) : there is no package called ‘mirai’
Calls: loadNamespace -> withRestarts -> withOneRestart -> doWithOneRestart
Execution halted
So it does seem that something goes wrong with finding the package library (which is in a non-standard location set in .Rprofile). I've used callr and future (with plan(multisession)) in vscode-R without problems.
I've just started with a fresh VS Code installation (by renaming ~/Library/Application Support/Code, ~/.vscode, and ~/.vscode-R), installed only vscode-R without changing any settings, and tried the Readme example again. Same result.
I've also tried deleting everything from my .Rprofile except .libPaths("~/.R-pkgs", include.site = FALSE). Same result.
So it seems that something about your vscode setup is masking the libpaths set in your ~/.Rprofile or causing the Rprofile not to be processed.
See ?Startup, could it be the below or something similar:
If you want ~/.Renviron or ~/.Rprofile to be ignored by child R processes (such as those run by R CMD check and R CMD build), set the appropriate environment variable R_ENVIRON_USER or R_PROFILE_USER to (if possible, which it is not on Windows) "" or to the name of a non-existent file.
R_ENVIRON_USER and R_PROFILE_USER are "" in my R sessions – but that's true irrespective of where they run (VS code, R, radian, RStudio), and it's only VS Code where mirai does not work. In fact, it seems like any unset environment variable is "".
BUT. If I set R_PROFILE_USER to "~/.Rprofile" mirai and crew work in VS Code! No idea why this would be necessary only in VS Code, but I now have a solution to my problem, and some information I can take back to the vscode-R issue. Thank you very much!
Great! Another way might be under settings > extensions > R > Lib Paths see if adding the path works.
There are so many options - I am not sure what the 'correct' answer is. Just noting that there have been a few historical issues with setting libpaths in startup files for vscode (just googling).
mirai really just respects the default and doesn't try to do anything special in this regard. As it does work outside of vscode, it does imply that it is vscode masking the default behaviour.
Does vscode respect other contents of your .Rprofile? That might help narrow things down.
In any case, I don't think there is anything I can do here, noting in particular that {crew} has its own launchers so even if I implement something for mirai here, it may not be propagated.
@uhkeller are you ok to close this?
vscode-R respects everything in my .Rprofile I think, and if I explicitly set R_PROFILE_USER there the problem goes away. It's just that without explicitly setting it the workers spawned by both crew and mirai don't know about my libPaths when using vscode-R. I agree that this would probably have to be fixed in vscode-R – unfortunately the last commit over there was three months ago so I begin to fear the project is dead.
Anyway, thanks again for you help! I'm closing the issue with this comment.