[Rd] how to store package options over sessions?
spencer.graves at structuremonitoring.com
Sat Nov 20 19:42:32 CET 2010
If you want the information to be kept within a specific working
directory, and forgotten when the user changes the working directory,
then you can store the results in getwd() using something like the
save(object1toSave, object2toSave, ...,
When the package is loaded, e.g., library(MyPackageName), you can use
something like the following to restore it:
I haven't tried it, but it looks like it should work AND be
platform independent (AND would not require SQLite).
Dirk's solution seems better if you do NOT want the saved
information to be lost when the user executes library(MyPackageName)
within a different working directory.
Hope this helps.
On 11/20/2010 9:51 AM, Dirk Eddelbuettel wrote:
> On 20 November 2010 at 17:12, Mark Heckmann wrote:
> | Hi,
> | I posted this a week ago on r-help but did not get an answer. So I hope that someone here can help me:
> | I want to define some options for my package the user may change.
> | It would be convenient if the changes could be saved when terminating
> | an R session and recovered automatically on the next package load.
> | Is that possible and if yes, is the standard way to implement this?
> First off:
> R> fortunes:::fortune("yoda")
> Evelyn Hall: I would like to know how (if) I can extract some of the
> information from the summary of my nlme.
> Simon Blomberg: This is R. There is no if. Only how.
> -- Evelyn Hall and Simon 'Yoda' Blomberg
> R-help (April 2005)
> Secondly, what you ask is necessarily rather OS-dependent. So of course it
> can be done, but probably in way that depend on your local circumstance.
> Thirdly, and to make this a little more helpful, I frequently use the RSQLite
> package to cache data across sessions and invocations. For a large example,
> consider the CRANberries feed (http://dirk.eddelbuettel.com/cranberries/)
> which stores in SQLite what the the state of the (CRAN) world was the last it
> got woken up by crontab. I also have a few smaller ad-hoc things at work
> that do similar things.
> Depending on your local circumstances you may make this 'cache' of stateful
> information read or read/write, make it a file on NFS or CIFS or WebDAV, make
> it a database that can be read as file or over sockets and so.
> And Yoda still rules.
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
More information about the R-devel