On Wed, 14 Dec 2005, Martin Maechler wrote: > >>>>> "Kjetil" == Kjetil Brinchmann Halvorsen <[EMAIL PROTECTED]> > >>>>> on Wed, 14 Dec 2005 08:59:24 -0400 writes: > > Kjetil> Philippe Grosjean wrote: > >> Martin Maechler wrote: > >>>>>>>> "Trevor" == Trevor Hastie <[EMAIL PROTECTED]> > >>>>>>>> on Tue, 13 Dec 2005 12:51:34 -0800 writes: > >>> > Trevor> It would be nice to have a date stamp on an object. > > Kjetil> Following up on my post of a few minutes ago, I tried to write an > Kjetil> timestamp function > > Kjetil> timestamp <- function(obj, moretext){ > Kjetil> comment(obj) <<- paste(Sys.time(), moretext, sep="\n") > Kjetil> } > > Kjetil> but this does'nt work. > > >> myobj <- 1:10 > >> timestamp(myobj, "test") > Kjetil> Error in timestamp(myobj, "test") : object "obj" not found > >> > > Instead, I'd **strongly** recommend to define *two* functions, > one "constructor" and one "inspector" : > > "timestamp<-" <- function(obj, value) { > stamp <- paste(Sys.time(), value) > ## attr(obj,"timestamp") <- stamp > comment(obj) <- stamp > obj > }
This does treat any existing comment rather brutally, could stamp rather be: stamp <- paste(Sys.time(), comment(obj), value) probably enhanced with some field separators to let the inspector grab just its chunk? Something like DCF? > > ## and > > timestamp <- function(obj) { > ## attr(obj,"timestamp") > comment(obj) > } > > ## and the usage (shown with output) > > myobj <- 1:9 > timestamp(myobj) <- "as an example" > > myobj > ## 1 2 3 4 5 6 7 8 9 > timestamp(myobj) > ## "2005-12-14 14:57:33 as an example" > > ------- > > we had mentioned recently here that "good programming style" > works with functions that do *not* modify other objects but > rather *return*.. > > > > >>> > Trevor> In S/Splus this was always available, because objects were files. > >>> > >>> [are you sure about "always available"? > >>> In any case, objects were not single files anymore for a > >>> long time, at least for S+ on windows, and AFAIK also on > >>> unixy versions recently ] > >>> > >>> This topic has come up before. > >>> IIRC, the answer was that for many of us it doesn't make sense > >>> most of the time: > >> > >> I remember it was discussed several times. I don't remember why it was > >> considered too difficult to do. > >> > >>> If you work with *.R files ('scripts') in order to ensure > >>> reproducibility, you will rerun -- often source() -- these files, > >>> and the age of the script file is really more interesting. > >>> Also, I *always* use the equivalent of q(save = "no") and > >>> almost only use save() to particularly save the results of > >>> expensive computations {often, simulations}. > >> > >> OK, now let me give examples where having such an information would > ease > >> the work greatly: you have a (graphical) view of the content of an > >> object (for instance, the one using the "view" button in R commander), > >> or you have a graphical object explorer that has a cache to speed up > >> display of information about objects in a given workspace (for > instance, > >> the SciViews-R object explorer). What a wonderful feature it will be > to > >> tell if an object was changed since last query. In the view, one could > >> have a visual clue if it is up-to-date or not. In the object explorer, > I > >> could update information only for objects that have changed... > >> > Trevor> I have looked around, but I presume this information is not > available. > >>> > >>> I assume you will get other answers, more useful to you, which > >>> will be based on a class of objects which carry an > >>> 'creation-time' attribute. > >> > >> Yes, but that would work only for objects designed that way, and only > if > >> the methods that manipulate that object do the required housework to > >> update the 'last-changed' attribute (the question was about last > access > >> of an object, not about its creation date, so 'last-changed' is a > better > >> attribute here). If you access the object directly with, let's say, > >> [EMAIL PROTECTED] <- newvalue, that attribute is not updated, isn't it? > >> > >> Best, > >> > >> Philippe Grosjean > >> > >>> Martin Maechler, ETH Zurich > >>> > > ______________________________________________ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: [EMAIL PROTECTED] ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html