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.urba...@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.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. > > > 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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
