On 21/08/10 23:31, Simon Urbanek wrote:
On Aug 21, 2010, at 8:46 AM, Laurent wrote:
On 21/08/10 12:00, r-devel-requ...@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.
I do think it will in the use-case proposed: have R serve graphics
without having to worry about writing temp files.
Python is somewhat used in the web applications world, and what is
proposed allows serving graphics without a temp file in sight.
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.
I have been neck-deep in R C-level code for devices when working on
that, and ended up with the exact opposite opinion.
Nonetheless, yes, it is another way along the lines
of xGD, JavaGD etc.
Thanks for the pointer. I did not know about them.
JavaGD might well be the most helpful thing then (if Donald had in mind
to do the web handling made in Java).
Best,
Laurent
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
