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

[Simon Urbanek]

On Aug 21, 2010, at 8:46 AM, Laurent wrote:

> 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).
> 

Well, that doesn't help with the issue we raised since you still cannot use R connections. It's trivial to modify any of the existing devices (e.g. Cairo as I said) to support in-memory storage as they already support that internally - certainly much easier that to mess with Python etc. Nonetheless, yes, it is another way along the lines of xGD, JavaGD etc.

Cheers,
Simon



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