From hb at stat.berkeley.edu  Fri Feb 12 16:27:35 2010
From: hb at stat.berkeley.edu (Henrik Bengtsson)
Date: Fri, 12 Feb 2010 16:27:35 +0100
Subject: [Rd] R Startup configuration file
In-Reply-To: <0D56D7F5-1509-4296-A8FA-637DB08E221D@r-project.org>
References: <d8ad40b51002100123s4b1d77bmc27ece9686106ef@mail.gmail.com>
	<4B729C0F.3030301@stats.uwo.ca>
	<d8ad40b51002100706t5869535av162a43a6362d6c6b@mail.gmail.com>
	<d8ad40b51002120050o74e12ad2pb0423c8017f90350@mail.gmail.com>
	<0D56D7F5-1509-4296-A8FA-637DB08E221D@r-project.org>
Message-ID: <59d7961d1002120727w281c1038jcfd69711f89b18e1@mail.gmail.com>

FYI,

a while ago I was looking into the "problem" with generic settings
files.  I didn't find an omnibus/perfect solution, but have a look at
the Settings class in the R.utils package (R/Settings.R in the source
code).  It tries to deal with automatic loading and saving of settings
(robust detection of the quiting of an R session etc), finding the
settings file and so.  You can use this to load package specific
settings as well.  (We make use of this in the aroma.* framework
(aroma.core, aroma.affymetrix etc), but I'll leave there for now).

My $.02

/Henrik

On Fri, Feb 12, 2010 at 3:22 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
>
> 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
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] R Startup configuration file
Henrik Bengtsson