From hin-tak.leung at cimr.cam.ac.uk  Mon Aug 27 01:53:11 2007
From: hin-tak.leung at cimr.cam.ac.uk (Hin-Tak Leung)
Date: Mon, 27 Aug 2007 00:53:11 +0100
Subject: [Rd] RData File Specification?
In-Reply-To: <0E49B2DD-8E31-4924-8A76-C21EE601626B@r-project.org>
References: <A312DAB4DB8DC34D86C006C5D8199D466BBB1C@ssvlexmb2.amd.com>
	<46CF1E3C.8000408@cimr.cam.ac.uk>
	<0E49B2DD-8E31-4924-8A76-C21EE601626B@r-project.org>
Message-ID: <46D21267.8080907@cimr.cam.ac.uk>

Simon Urbanek wrote:
> 
> On Aug 24, 2007, at 2:06 PM, Hin-Tak Leung wrote:
> 
>> I was going to write 'Use the source, Luke', but it seems that you have
>> alreday found the relevant source files. I wrote a Python baed Rdata
>> writer and a reader sometimes ago just using that info and I am not
>> away of any file spec, so I know those two files are sufficient. For
>> what you want to do, I think you'll have to write some fairly
>> substantial code to process the Rdata as just XDR stream (as my python
>> scripts do, using the python built-in xdrlib),
> 
> 
> Unfortunately the format is not true XDR (it is not padded properly - 
> CHARs (incl. symbols etc.) and raw vectors violate the padding rules), 
> so you have to fall back to low-level access for some parts. It effect, 
> the only part of XDR used is the storage of int and double (which is 
> quite trivial), so IMHO any language (even without XDR) will do ...
> 
> Cheers,
> Simon

Yes, I found out about the char not-padding-to-multple-of-4-byte part 
the "hard" way. Still, the python xdrlib library saved me a bit of 
hassle abstracting away from endian issues - since I work mostly on
small endian machines and xdr-based data being bigendian -, even though
I had to "backtrack" my file pointers in the cases of padding
char/raw's...

Anyway, "the source is your guide"...

<snipped>



[Rd] RData File Specification?
Hin-Tak Leung