[Rd] R-devel Digest, Vol 90, Issue 20

[Laurent]

On 21/08/10 12:00, r-devel-request at r-project.org wrote:
>
> On Aug 20, 2010, at 1:59 PM, Matt Shotwell wrote:
>
>> >  On Fri, 2010-08-20 at 12:58 -0400, Sharpie wrote:
>>> >>
>>> >>  Donald Paul Winston wrote:
(...)
>>> >>
>>> >>  Donald Paul Winston wrote:
>>>> >>>
>>>> >>>  It appears R insists on directing plot output to a file. Is their a
>>>> >>>  graphics device that keeps the output in memory so it can be returned to
>>>> >>>  my java app as a stream of bytes? If I have to wait for it to write to a
>>>> >>>  "unique file" and then read it back again then I don't think that's going
>>>> >>>  to work. My web app needs to support hundreds of concurrent clients.
>>>> >>>
>>> >>
>>> >>  As far as I know all R graphics output that does not go to a screen device,
>>> >>  such as an X window, must be directed to some sort of file.  I am not aware
>>> >>  of a graphics device that provides output to something other than a screen
>>> >>  or a file, but there very well may be such a device in existence.

For experimentation purpose, the rpy2 project is finalizing a system to 
allow Python-written graphical devices (no C-level R extensions, just 
Python). Beside other niceties, it will allow working around the lack of
connection API in R for graphics.
Since Python makes the use of file-like objects straightforward, we plan 
providing devices that are streams (nice for serving graphics from web 
applications without having to worry about temp files).


>> >  This was essentially the conclusion of Donald's earlier thread...
>> >
>>> >>  The functionality you could describe could be implemented by writing a R
>>> >>  graphics device that forwards the R plotting commands to... well anywhere
>>> >>  you want, really.  As the author of an R graphics device, I can say the
>>> >>  trickiest part of such an undertaking will be calculating font metrics so
>>> >>  that R can properly position text in the graphics.  Everything else is very
>>> >>  straight-forward.
>> >
>> >  I believe Donald wants the_rendered_  output. That is, a stream of bytes
>> >  that represent a png, jpeg, etc. Toward this end, we have already
>> >  discussed using an OS-level fifo to avoid disk I/O, and I think this is
>> >  the easiest route for Donald.
>> >
>> >  Alternatively, Donald might look into the X11 graphics driver, where
>> >  Cairo is used to write pngs. In particular, the in_do_saveplot function
>> >  (src/main/modules/X11/devX11.c) calls cairo_surface_write_to_png, in
>> >  order to save a png to file. Cairo also provides the
>> >  cairo_surface_write_to_png_stream function, which might be used to send
>> >  png data to a memory buffer (i.e. a raw vector). I don't think it would
>> >  be too difficult to modify in_do_saveplot to accommodate this.
>> >
> That is all nice, it will require you to hack R (well, there is the Cairo device so you could make the change outside of R instead).
>
> As always, the reason is buried deep inside -- the lack of connection API. If we had that, devices would take a connection instead of the file name and all would be well since you could use in-memory connections instead of files ...;)

May I dare asking about what happened to past offers to alleviate the 
problem ?

There is at least one patch (contributed 4 years ago)
http://rwiki.sciviews.org/doku.php?id=developers:r_connections_api
that remained seemingly ignored, and subsequent requests for updates (or 
patch submission policies) remained similarly unanswered.

A recent thread showed unexpected progress, with the eventual 
possibility of accepting a patch being worded.
http://www.mail-archive.com/r-devel@r-project.org/msg20276.html
Unfortunately the thread drifted into legalese invocations, and despite 
the author of the patch complying to all demands regarding the licensing 
flavour for his contribution the patch seems to have joined (all ?) 
other submitted patches. (I don't get anything when running:
svn log -r {2010-04-27}:HEAD | grep -i Shotwell
).

Are there such patches included in the Revolution R sources, or are 
there plans to do so ?



Laurent




> Cheers,
> Simon
>
>
>