For the first problem, I would route all of the graphical output to files to
look at after running the program. For the second one, I would add the results
to the R environment after the subprocess completes. Would something like this
work for you?
import sys, os
from multiprocessing import Process, Queue
import rpy2.robjects as robs
from rpy2.robjects.packages import importr
grdevices = importr("grDevices")
def r_command(q, obj, cmd):
grdevices.pdf(file="{0}.pdf".format(obj))
q.put((obj,robs.r(str(cmd))))
print "Process %s output:" % os.getpid()
print robs.r.ls()
grdevices.dev_off()
if __name__ == "__main__":
q = Queue()
cmd = "c(1,2,3,4,5)"
obj = "test"
p = Process(target=r_command, args=(q, obj, cmd,))
p.start()
p.join()
res = q.get()
robs.globalenv[res[0]] = res[1]
print "Process %s output:" % os.getpid()
print robs.r[res[0]]
print robs.r.ls()
cmd = "plot(c(1,2,3,4,5))"
obj = "test2"
p = Process(target=r_command, args=(q, obj, cmd,))
p.start()
p.join()
res = q.get()
robs.globalenv[res[0]] = res[1]
print "Process %s output:" % os.getpid()
print robs.r[res[0]]
print robs.r.ls()
cmd = "plot(c(3,4,5,6,7))"
obj = "test3"
p = Process(target=r_command, args=(q, obj, cmd,))
p.start()
p.join()
res = q.get()
robs.globalenv[res[0]] = res[1]
print "Process %s output:" % os.getpid()
print robs.r[res[0]]
print robs.r.ls()
Cheers,
Brandon Invergo
----- Original Message ----
From: Carson Farmer <carson.far...@gmail.com>
To: Laurent Gautier <lgaut...@gmail.com>
Cc: "RPy help, support and design discussion list"
<rpy-list@lists.sourceforge.net>
Sent: Wed, March 31, 2010 2:02:13 AM
Subject: Re: [Rpy] py2 and threading
Thanks Laurent,
> Multiprocessing is way to go (pickling was implemented to make it easier,
> and there a google SoC project out bring storage-based arrays in).
I think you're likely right...
> R GUI builders could clearly and immediately benefit from having the GIL
> released, but in the meanwhile adopting a client-server strategy is the
> recommended way to go. That has limitations but also advantages; building a
> minimal server can be done in less than 20 lines of code (less than 10 lines
> if no comments).
> http://rpy.sourceforge.net/rpy2/doc-2.1/html/server.html#simple-socket-based-server-and-client
>
> Hoping this helps,
Indeed it has: I have experimented with both Multiprocessing and the
client-server implementation.
The multiprocessing route seems to work quite well, however, I'm
running into two problems, and I'm wondering if anyone else has
managed to get this working:
1) As expected, if a plot is generated in a separate process, it is
immediately destroyed once the process completes. I have tested this,
and basically I get a plot for about half a second, then it
disappears. Does anyone know of a way to get around this?
2) Assignments do not seem to span process' (again this is probably
expected, and I'm just simply doing something wrong). If I do
something like 'robjects.r("test <- c(1,2,3,4,5)")' in a subprocess,
then 'test' is *not* available in the parent process (whereas it *is*
obviously available in the subprocess). Does anyone know what I need
to do to make this work properly?
Here is a minimal example to illustrate issue 2 above (issue 1 can
similarly be tested by changing 'cmd' to "plot(c(1,2,3,4,5))") :
# -*- coding: utf-8 -*-
import sys, os
from multiprocessing import Process, Queue
import rpy2.robjects as robs
def r_command(q, cmd):
q.put(robs.r(str(cmd)))
print "Process %s output:" % os.getpid()
print robs.r.ls()
if __name__ == "__main__":
q = Queue()
cmd = "test <- c(1,2,3,4,5)"
p = Process(target=r_command, args=(q,cmd,))
p.start()
p.join()
print "Process %s output:" % os.getpid()
robs.r['print'](q.get())
print robs.r.ls()
--
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Ireland, Maynooth,
http://www.carsonfarmer.com/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
