R devel - Jan 2006 - R plot display problem under windows when using python rpy module.

Dear list,

Rpy is a python module that provides python interface to R. The
following simple commands
>>> from rpy import *
>>> r.plot(0)
is supposed to create a window that displays the result of plot(0).

However, we observe that
1. Under *nix, rpy+R+python  work as expected
2. Under windows, python + pythonWin32 (a python GUI provided by the
pywin32 module), work as expected
3. Under windows, if we run the commands from command line or IDLE (a
simple python IDE), a window will be created, but the figure will not
be drawn. Then, if we run r.plot(2), the result of plot(0) will be
drawn. plot(2) will be displayed when the next drawing command is
executed.

Since R works well in most cases, I do not think this is a R problem.
However, can anyone tell me what *might* block the figures from being
displayed? In other word, what might PythonWin have provided to enable
correct rendering of the figures? If I have to trace to the sources,
what portion of the R code should I have a look at? (It is good that
python/R/rpy are all open source).

Many thanks in advance.
Bo

How is Rpy calling R?  Presumably R is running single-threaded, and the 
problem is likely to be that Rpy is using blocking I/O on the R process 
and hence blocking the GUI callbacks that drive the window.

The not-so-simple answer is not to do it that way.  It might be well
sufficient to turn windows() buffering off -- see its help page.

On Mon, 9 Jan 2006, Bo Peng wrote:
> Dear list,
>
> Rpy is a python module that provides python interface to R. The
> following simple commands
>
>>>> from rpy import *
>>>> r.plot(0)
>
> is supposed to create a window that displays the result of plot(0).
>
> However, we observe that
> 1. Under *nix, rpy+R+python  work as expected
> 2. Under windows, python + pythonWin32 (a python GUI provided by the
> pywin32 module), work as expected
> 3. Under windows, if we run the commands from command line or IDLE (a
> simple python IDE), a window will be created, but the figure will not
> be drawn. Then, if we run r.plot(2), the result of plot(0) will be
> drawn. plot(2) will be displayed when the next drawing command is
> executed.
>
> Since R works well in most cases, I do not think this is a R problem.
> However, can anyone tell me what *might* block the figures from being
> displayed? In other word, what might PythonWin have provided to enable
> correct rendering of the figures? If I have to trace to the sources,
> what portion of the R code should I have a look at? (It is good that
> python/R/rpy are all open source).
>
> Many thanks in advance.
> Bo
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

On 1/9/06, Prof Brian Ripley <ripley at stats.ox.ac.uk>
wrote:
> How is Rpy calling R?  Presumably R is running single-threaded, and the
> problem is likely to be that Rpy is using blocking I/O on the R process
> and hence blocking the GUI callbacks that drive the window.
>
> The not-so-simple answer is not to do it that way.  It might be well
> sufficient to turn windows() buffering off -- see its help page.
Using
>>> from rpy import *
>>> r.options(windowsBuffered=False)
>>> r.plot(0)
solves the problem.

Thank you very much! I will suggest that rpy developers address this problem.

Bo

Hi,
(off topic slightly, and a slight flame-bait...).
I don't have an answer or clue to your question, but I have played with
PSPython briefly and it did work somewhat for me (and I have not heard 
of rpy until reading this through r-devel), and I was wondering
what is the difference between rpy and RSPython. According to the rpy page:
============  This code is inspired by RSPython from the Omegahat project. The
main
goals of RPy are:

     * to have a very robust interface for using R from Python
     * the interface should be as transparent and easy to use as possible
     * it should be usable for real scientific and statistical computations
============
But "a very robust interface" is self-proclaimed and unsubstantiated; 
"transparent", "easy to use", "usable for real
scientific..." are
subjective, so what it amounts to is a case of "not-invented-here" 
symptom (i.e. wheels...). This might be flame-bait... but since I
have used PSPython very very briefly and I don't think it suffers
from the above 3 (and even if it does, it is open-source, one can
always add/modify/patch without starting new), I do wonder...

So I have a question for you - why rpy instead of RSPython? Have you 
tried both, and can you give a comparison of pros and cons?

In fact, the most obvious superficial difference I can see is that 
RSPython is written by an R-biased person (it uses "R CMD build"),
where
as rpy is written by a Python-biased person (it builds with
"python setup.py ...")... there is nothing wrong with having a bias,
but the goals listed imply that it might be "better" in those areas...
which may or may not be true.

(To answer one question you might have, I was trying to invoke Python 
code from inside R and was doing it the opposite direction from you).

HTL

Bo Peng wrote:
> Dear list,
> 
> Rpy is a python module that provides python interface to R. The
> following simple commands
> 
> 
>>>>from rpy import *
>>>>r.plot(0)
> 
> 
> is supposed to create a window that displays the result of plot(0).
> 
> However, we observe that
> 1. Under *nix, rpy+R+python  work as expected
> 2. Under windows, python + pythonWin32 (a python GUI provided by the
> pywin32 module), work as expected
> 3. Under windows, if we run the commands from command line or IDLE (a
> simple python IDE), a window will be created, but the figure will not
> be drawn. Then, if we run r.plot(2), the result of plot(0) will be
> drawn. plot(2) will be displayed when the next drawing command is
> executed.
> 
> Since R works well in most cases, I do not think this is a R problem.
> However, can anyone tell me what *might* block the figures from being
> displayed? In other word, what might PythonWin have provided to enable
> correct rendering of the figures? If I have to trace to the sources,
> what portion of the R code should I have a look at? (It is good that
> python/R/rpy are all open source).
> 
> Many thanks in advance.
> Bo
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel