I have just installed R 2.6.2, Rpy 1.02 and the PyWin32 package, and reliably experience the following problem when driving R from Python - if I create a plot in R, the portion of the plot window that lies under the IDLE window in which I type my Python code remains blank. So if I type
from rpy import *
x = range(10)
y = [i ** 2 for i in x]
r.plot(x,y)
I get a plot of y vs. x, but only the top right portion of the plot shows any points, axes etc. The bottom left corner (the portion that lay under the IDLE window) is blank.
Anonymous
Logged In: YES
user_id=1623918
Originator: NO
There have been on and off problems with interactive graphic devices (the C stack infamous problem, for example).
R-2.7 is introducing changes (improvements) with them, and although they are mostly for X11 and Quartz devices
(so UNIX and MacOS X) it could be worth trying what is happening with that version of R.
I have a similar problem (lack of redraw) using X11 under Linux.
I should say that I am using rpy2 2.0.1 and R 2.8.1.
The root of the issue seems to be that the refresh of interactive plots is currently not properly handled (neither by rpy or rpy2).
There is something planned to address the issue, but in the meanwhile you may want to plot your graphics to a pdf file and have PDF viewer opened on the side.
I think you have to call "R_ProcessEvents" while the plot window is shown (therefore, provide it as an API call from python).
To juneaftn: I just added a wrapper to R_ProcessEvents, but this does not seem to help (you can check by yourself, it's in the Mercurial repository.
You have to calling R_ProcessEvents repeatedly.
Looking at the following python session:
The default R_ProcessEvents appears to be somewhat different according to platforms.
Calling it does not not on work on Linux/ MacOS X (being the systems I have at hand presently).
Looking at R's gnuwin32/system.c, doevent() seems likely to be what is triggering a refresh on win32.
It is called by R_ProcessEvent only on win32.
(I am tempted to close this, as the bug report is on win32 and June Kim proposes a workaround on that platform).
I should've added that you have to save the return value of win32api.LoadLibrary( Rlib ) from rinterface/init.py somewhere(in my example rlib_) in the global in order to access the handle of R.dll.