Skip to content

R-devel Digest, Vol 90, Issue 20

5 messages · Laurent Gautier, Simon Urbanek

Original
Laurent Gautier
#
On 21/08/10 12:00, r-devel-request at r-project.org wrote:
(...)
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).
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
Simon Urbanek
#
On Aug 21, 2010, at 8:46 AM, Laurent wrote:

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Laurent Gautier
    

    

      
      #
    

  


  

      
On 21/08/10 23:31, Simon Urbanek wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

        
I have been neck-deep in R C-level code for devices when working on 
that, and ended up with the exact opposite opinion.

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Aug 22, 2010, at 3:32 AM, Laurent wrote:

        

            

      
      
      
    

        
Actually I have completely forgotten that I have implemented that in Cairo already -- you can fetch the current image from any image Cairo device (without even closing it) using the .image() function.

So for example you could use something like:

Cairo(640, 480, "/dev/null", "png")
## the file is actually not used in this case at all so you can use anything

plot(...)

## get the image (as a reference)
i=Cairo:::.image(dev.cur())

## if your code can take direct pointer (RGBA), you're done. If you want to further convert it to RAW and more, then:
r=Cairo:::.ptr.to.raw(i$ref,0,i$width*i$height*4)
dim(r) = c(4, i$width, i$height)
p=writePNG(r, raw())
## p is now the raw PNG content - ready to be served to the client as image/png -- no files involved

            

      
      
      
    

        
Somewhat is the key word ;) but nonetheless I'm not sure I understand how you plan to do that because you'd have to embed R for this which will cause you to have to initialize R which is simply too slow for any serious web processing .. If you go the other way round (like starting with Rserve) then you don't have Python as a starting point so you'd have to load Python for that in the first place which seems like an overkill.

Cheers,
Simon

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Laurent Gautier
    

    

      
      #
    

  


  

      
On 22/08/10 17:55, Simon Urbanek wrote:

            

      
      
      
    

        
That's handy for serving graphics.
(But "Yuk ! Hack !" about having to open a device in /dev/null).

            

      
      
      
    

        
If considering R to serve graphics, there are two main strategies: fire 
up an R process each time, or keep an R process alive to answer request. 
Both will likely have to be done by something else than R (<put your 
language of choice for web development here>), and if R can be embedded 
in that language this will likely be easier (no need to work out a 
communication interface) and possibly faster (depends on the language 
discussed and of the quality of the embedding).

            

      
      
      
    

        
In that scenario, you do not need RServe at all: Python is handling 
everything. For example, the combo Django (web framework in Python) + 
rpy2 has been used to deliver R results (including graphics) through the 
web.
Fancy strategies such as managing a pool of R instances if talking heavy 
web traffic, persistent sessions, etc... can also be implemented.


Best,


Laurent