-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roger Bivand wrote: > 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? Why not use a regular named vector/list rather than pasting things into and then back from a string, relying on conventions and losing information. current <- comment(obj) current[["timeStamp"]] <- Sys.time() comment(x) <- current and then the individual elements can be accessed in the usual manner comment(x)[["timeStamp"]] and the original value can be be maintained (with a little more tinkering for old-style cases without named elements). > > >>## 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 >> > > - -- Duncan Temple Lang [EMAIL PROTECTED] Department of Statistics work: (530) 752-4782 371 Kerr Hall fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDoC4n9p/Jzwa2QP4RAiJUAJ9nCsmUSEuUwnssgwfcl+qdJ/oDlACeK6jw r6QsjGFUtuPhKCd31dZX5Iw= =jCmV -----END PGP SIGNATURE----- ______________________________________________ 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