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