From simon.urbanek at r-project.org  Fri Feb 12 15:22:53 2010
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Fri, 12 Feb 2010 09:22:53 -0500
Subject: [Rd] R Startup configuration file
In-Reply-To: <d8ad40b51002120050o74e12ad2pb0423c8017f90350@mail.gmail.com>
References: <d8ad40b51002100123s4b1d77bmc27ece9686106ef@mail.gmail.com>
	<4B729C0F.3030301@stats.uwo.ca>
	<d8ad40b51002100706t5869535av162a43a6362d6c6b@mail.gmail.com>
	<d8ad40b51002120050o74e12ad2pb0423c8017f90350@mail.gmail.com>
Message-ID: <0D56D7F5-1509-4296-A8FA-637DB08E221D@r-project.org>


On Feb 12, 2010, at 3:50 , Barry Rowlingson wrote:

> On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson
> <b.rowlingson at lancaster.ac.uk> wrote:
>
>>  But I agree that writing a saveable options package is the first  
>> step
>> - then making that a default in R is the second so people don't have
>> to edit profiles and R packages and applications can expect an API  
>> for
>> savable state.
>
> More thinking about this has turned it into a problem of being able
> to serialize R objects to XML.


This is getting OT, but, please, no XML. It's entirely useless in this  
context IMHO (as it is in others, but that's another story) and we  
already have reliable support for storing R objects (more than one in  
fact). Despite the fact that some used to claim human readability of  
XML in practice it turns out to be false, so I don't see any real  
benefits of XML in this context.

Cheers,
Simon



> The most reliable way I can find of
> doing that is to use serialize, then rawToChar, and put a big old hex
> string in the XML. Hardly the most user-friendly format, but then
> users aren't supposed to edit XML anyway. I have also considered
> having encoding types for objects, something like:
>
> <object encoding="raw" name="foo">66f6e.....a7726</object>
> <object encoding="numeric" name="bar">3.141</object>
> <object encoding="numeric" size="2"
> name="baz"><item>3.14</item><item>6.28</item></object>
>
> at which point I remembered that R objects can also have attributes
> which can be any other R objects too. At which point I realized life's
> too short for this...
>
> ..and had a rethink. Lots of software these days has a configuration
> directory, and runs all the scripts or configs within - think
> /etc/cron.daily/ or /etc/init.d on a unix system. This has the
> advantage that components of the system can manage their own startup
> files there, and not worry about stomping on others. So you'd have a
> .Rprofile.d/ folder with, say, a cran.R file that could be sourced by
> anything that used CRAN, for example to set the default mirror. I'd
> insist that each file in .Rprofile.d/ started with a "# do not edit
> this file" warning...
>
> I'll think some more over coffee until I realise why this is another
> of my dumb ideas...
>
> Barry
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



[Rd] R Startup configuration file
Simon Urbanek