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: >>> >>> Aren't you the guy who created Rserve? >>> >>> I'd like to develop a web app so clients can perform exploratory data >>> analysis with their browser with no installed software, not even java (I >>> don't like applets). I thought R would be excellent for this but I need >>> some issues cleared up before I invest a lot of time working with it. >>> >> >> Well, Simon is the one who create Rserve. However, if you have questions >> about Rserve it may be best to start a new thread or at least change the >> subject header of your message. This discussion was about creating >> stand-alone executables that use R code for deployment on a desktop. >> >> >> 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. > > 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 ... ;) Cheers, Simon >> I have plans to write a device that forwards the plotting commands to a >> socket connection that allows another program to execute them. In my case, >> an Erlang backbone is used to route the results back to web clients using >> websockets. The idea is to have the plot rendered directly in the client's >> browser using a JavaScript library like RaphealJS. However, the school year >> is upon me and the project will probably remain on the drawing board until >> next summer. >> >> >> Donald Paul Winston wrote: >>> >>> Is REngine.jar and REngineRserve.jar all I need in my web app? >>> >> >> I can't comment on REngine as I have not used it. >> >> >> Donald Paul Winston wrote: >>> >>> Also, how come their is no shutdown command from the command line for >>> Rserve. I see one in the java client api. Do I have to write my own? >>> >> >> I find that on UNIX a SIGTERM, SIGSTOP or SIGKILL signal broadcast using a >> command line utility such as kill does the job. >> >> -Charlie >> >> ----- >> Charlie Sharpsteen >> Undergraduate-- Environmental Resources Engineering >> Humboldt State University > > -- > Matthew S. Shotwell > Graduate Student > Division of Biostatistics and Epidemiology > Medical University of South Carolina > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
