Many thanks to the R core team for their work on R connections. I was delighted
to discover that it is now possible to remote-control R-1.3.0 via a socket
connection - something which Brian Ripley noted was not yet possible with
R-1.2.0 back in January 2001 in the first R News newsletter. How? Just
substitute source() for readLines() in last few lines of the example for a
socket connection given in the R-1.3.0 help(connection) - the following works
fine on a Red Hat Linux 6.2 system - under Windows the while(isIncomplete())
loop exits immediately for some reason, although the socket connection as a
source for source() works fine:
## two R processes communicating via non-blocking sockets
# R process 1
con1 <- socketConnection(port = 6011, server=TRUE)
writeLines("plot(rnorm(100))", con1)
writeLines("plot(rnorm(1000))", con1)
writeLines("plot(rnorm(10000))", con1)
close(con1)
# R process 2
con2 <- socketConnection(Sys.info()["nodename"], port = 6011)
# as non-blocking, may need to loop for input
source(con2)
while(isIncomplete(con2)) {source(con2)}
close(con2)
However, in the above example, the R "server" is on the client side of
the socket connection. Logically, it should be possible to reverse this and have
the R server session acting as the socket server, but I have been unable to get
this to work:
## two R processes communicating via non-blocking sockets
# R process 1
con1 <- socketConnection(port = 6011, server=TRUE)
source(con1)
while(isIncomplete(con1)) {source(con1)}
close(con1)
# R process 2
con2 <- socketConnection(Sys.info()["nodename"], port = 6011)
writeLines("plot(rnorm(100))", con2)
writeLines("plot(rnorm(1000))", con2)
writeLines("plot(rnorm(10000))", con2)
close(con2)
Playing with various combinations of the blocking and open modes have been to no
avail. Can anyone suggest some alternative strategies? BTW, my ultimate aim is
to use Python to control the R "server". Substituting a Python script
for "R process 1" in the first example above works a treat - you can
type R commands at the Python prompt and they execute in an R session on a
machine on the other side of the room. The only problem is that with R as the
socket client the Python process can't connect and disconnect from it as it
could if R were the socket server. As it is I think this capability is already
very exciting, and the prospect of an R socket server daemon seems tantalisingly
close. I don't have enough experience with socket programming to try this
myself but I would be very happy to collaborate with anyone who wanted to attack
this problem.
Tim Churches
*********************************************************************
This message is intended for the addressee named and may
contain confidential information. If you are not the intended
recipient, please delete it and notify the sender. Views
expressed in this message are those of the individual sender,
and are not necessarily the views of NSW Health.
*********************************************************************
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
