Replies: 4 comments 3 replies
-
Since you mention that you can get something going with processx, I wonder if it would be worth looking into supporting this in future.callr, which uses callr that uses processx internally. To add support for it in |
Beta Was this translation helpful? Give feedback.
-
I can get some of it to work using stock fun <- function() {
options(browserNLdisabled = TRUE)
print(R.version)
browser()
1
}
r2 <- callr::r_bg(
fun, arch="/opt/homebrew/opt/dtach/bin/dtach",
# libpath = c("/Users/r2/Library/R/4.3","/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library"),
cmdargs=c("-c", "/Users/r2/dtach_session_0.sock", "/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/bin/R", "--no-save", "--interactive"),
stdout=NULL, stderr=NULL, stdin=NULL, pty=TRUE)
r2$read_output()
# [1] "\033[H\033[J"
r2$is_alive()
# [1] TRUE
r2$read_output()
# [1] "\r\nR version 4.4.2 (2024-10-31) -- \"Pile of Leaves\"\r\nCopyright (C) 2024 The R Foundation for Statistical Computing\r\nPlatform: aarch64-apple-darwin20\r\n\r\nR is free software and comes with ABSOLUTELY NO WARRANTY.\r\nYou are welcome to redistribute it under certain conditions.\r\nType 'license()' or 'licence()' for distribution details.\r\n\r\n Natural language support but running in an English locale\r\n\r\nR is a collaborative project with many contributors.\r\nType 'contributors()' for more information and\r\n'citation()' on how to cite R or R packages in publications.\r\n\r\nType 'demo()' for some demos, 'help()' for on-line help, or\r\n'help.start()' for an HTML browser interface to help.\r\nType 'q()' to quit R.\r\n\r\n"
r2$write_input("pi\n")
r2$read_output()
# [1] "> [1] 3.141593\r\n> "
r2$write_input("q('no')\n")
r2$read_output()
# [1] "\033[999H\r\n[EOF - dtach terminating]\r\n"
r2$read_output()
# [1] "\033[?25h"
Sys.sleep(1)
r2$is_alive()
# [1] FALSE Unfortunately ...
I think what I'm aiming to do requires
So while the notion of using We can't use
Can you think of a way to combine the Otherwise, we need to bypass some of (To be fair, my test/demo using |
Beta Was this translation helpful? Give feedback.
-
An alternative route is to implement a new type of PSOCK cluster in parallelly that would spin up local workers using > cl <- parallelly::makeClusterPSOCK(1L, dryrun = TRUE)
----------------------------------------------------------------------
Manually, start worker #1 on local machine 'localhost' with:
'/home/henrik/shared/software/CBI/_ubuntu22_04/R-4.4.2-gcc11/lib/R/bin/Rscript' --default-packages=datasets,utils,grDevices,graphics,stats,methods -e 'options(socketOptions="no-delay")' -e 'workRSOCK<-tryCatch(parallel:::.workRSOCK,error=function(e)parallel:::.slaveRSOCK);workRSOCK()' MASTER=localhost PORT=11718 OUT=/dev/null TIMEOUT=2592000 XDR=FALSE SETUPTIMEOUT=120 SETUPSTRATEGY=sequential This is mostly set up by |
Beta Was this translation helpful? Give feedback.
-
Frankly, I've never been a fan of |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The default behavior of parallel nodes is good, I'm not questioning the headless default of the child processes.
Is there an ability to setup the stdin/stdout of the R processes so that they could be connected to if need be? In unix-land, the
dtach
utility is similar totmux
/screen
in that it allows disconnection from a terminal (often/typically over ssh) and reconnection. Thedtach
intent is much simpler: it does not aim to address multi-plexing, it just handles the terminal connection.I'm considering how best to handle long-running background R processes. The use of
multisession
works, I can start a long-running process in the background and it works fine. I could even usecallr::r_bg
for this purpose, tbh. However, in both cases, if somebody happens to either interrupt/pause the child process (occasionally I have an embeddedbrowser()
for many reasons), it would be really great to be able to interact with it live, optionally continuing if the issue is resolved. While it could be argued that a long-running headless process should either run fine or quit, never pausing ... I don't disagree, but let's sideline that for the moment, since I think there are times when it may be acceptable to rely on momentary user intervention.For instance, if I start a process using
then I can write commands to it, read the output, etc. Granted, now I need to parse the output (such as removing the
"\n> "
and reacting if I see a trailing"\n+ "
"continue" indication), and that's overhead I'd like to avoid :-). One technique is usingdtach
instead, withUsing emacs/ess, I can then attach to that using
M-x shell
dtach -a ~/dtach_session_1
M-x ess-remote
andR
for the dialectAt this point, I have full visibility and control over the session. (Other than
C-c C-k
to kill the shell process, I haven't found how to usedtach
's native escape to disconnect, a minor inconvenience.)I recognize this may not be a common use-case for others. Is there any room in
multisession
-implementation to allow this kind of functionality, either natively or indirectly by callingdtach
instead ofR
?Beta Was this translation helpful? Give feedback.
All reactions