R-devel Digest, Vol 90, Issue 20

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 at 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