Skip to content

Utilizing the internet module

6 messages · Jeffrey Horner, Brian Ripley

Original
Jeffrey Horner
# 
Hello all,

I'd like to utilize the R_Sock* functions from R_ext/R-ftp-http.h in my 
R package. The intent is to use these in conjunction with R_serialize() 
  to store R objects in a remote data store. I'm aware that version 
2.2.1 of "Writing R extensions" explains that these may be undocumented 
and unstable, but I have a couple of questions:

1) are they platform independent? I presume they are...

2) What's the appropriate way to link against them? On Linux x86, I can 
do this with the Makevars:

PKG_LIBS=$(R_HOME)/modules/internet$(SHLIB_EXT)

but that doesn't work on Mac OS X 10.3.9 powerpc G4:

gcc -bundle -flat_namespace -undefined suppress -L/sw/lib 
-L/usr/local/lib -o rmemcache.so rmemcache.o 
/Users/hornerjr/src/R-2.2.1/modules/internet.so -lcc_dynamic 
-L/Users/hornerjr/src/R-2.2.1/lib -lR
ld: /Users/hornerjr/src/R-2.2.1/modules/internet.so is input for the 
dynamic link editor, is not relocatable by the static link editor again

Thanks in advance,
Brian Ripley
#
On Thu, 23 Feb 2006, Jeffrey Horner wrote:

            

      
      
      
    

        
Only in sense that they have a common interface.

            

      
      
      
    

        
You can, but that is a module and not a library and so it does not work on 
MacOS X and may well not work on Windows (you would be lucky prior to R 
2.3.0).

I wonder why you need a C interface at all.  There is serialize() and 
socket connections are available at R level.  Below that, Rsockopen etc 
are exported from R itself and underly make.socket etc.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Jeffrey Horner
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

            

      
      
      
    

        
I may not need it (or get to use it portably), but as far as using 
Rsockopen, etc. am I right in assuming that a package writer would have 
to copy the declarations from src/main/basedecl.h into his/her own code 
in order to utilize them? This seems odd when there's already an exposed 
(although undocumented) interface with R_Sock*, so what's the point of 
having R_ext/R-ftp-http.h? Is it just for some xml package?

On a related note, how do I serialize() an R object to a database table 
column of type BLOB? I've tried using RODBC but was unsuccessfully (see 
R-sig-DB in Feb archive). I've also looked into RMySQL/DBI but I don't 
think it's supported yet.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 23 Feb 2006, Jeffrey Horner wrote:

        

            

      
      
      
    

        
Yes.  It was written as an internal header.  As you have discovered, the 
interface is not actually exposed.

            

      
      
      
    

        
Since BLOB is not a standard SQL type (AFAIK), ODBC seems not to support 
it.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 23 Feb 2006, Prof Brian Ripley wrote:

        

            

      
      
      
    

        
It also does not work in R-devel on any system that supports visibility 
attributes, for example Linux systems with gcc4, and some RedHat systems 
with gcc 3.4.4.  I am removing the declarations from R_exts/R-ftp-http.c 
for R 2.3.0.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Jeffrey Horner
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

            

      
      
      
    

        
[...]

            

      
      
      
    

        
It's not standard, per se, but many ODBC drivers and many databases 
(Oracle, MS SQL Server, MySQL, Postgresql, Access, ...) support such a 
type. In fact, the structured query language standards SQL92 and SQL99 
define the type BIT and BIT VARYING to hold arbitrary bit strings, which 
I think is some sort of endorsement for this type.