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. 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 >> >> >> > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
