On 12/02/2010 3:50 AM, Barry Rowlingson wrote:
On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson
<b.rowling...@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. 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>
If you're storing hex, why not just use the binary save() format? (Or
the save(ascii=TRUE) format.) What is the advantage of XML?
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...
I see two ways such a thing might be used: everything run at startup, or
just running things as needed. Running everything at startup has the
disadvantage that it requires all sorts of diverse packages to be
loaded, so running things as needed makes more sense. But do you really
want to make it so granular that it depends on the kind of task
(accessing CRAN, ...)? Wouldn't it be good enough to have one user init
file per package, and have it executed when the package is loaded?
Duncan
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
