[Got stuck in the mail filter: "Too many recipients". Cancelled and resending.]
Duncan Temple Lang <[EMAIL PROTECTED]> writes: > In addition to what and how to associate time information > with an object, I imagine Trevor was also expecting that > it would be done automatically rather than require > the user to set the timestamp explicitly. > To that end, the addTaskCallback() function allows > one to register a function that will be invoked at the > end of each top-level task. In that function > call, one can update the timestamp on any (obviously) newly > assigned value. That will give the same behaviour as in S-Plus > as there only top-level assignments are written to disk and so have > a file modification time. It's certainly not doable without some notion of "committing". If every change to every object needs to be preceded by a lookup of the current date+time, performance would vanish. A similar, yet different, idea could be to have certain environments flagged as "timestamped" and have assignment into that environment check the flag and set the stamp. The obvious candidate for a timestamped environment is .GlobalEnv, but there could be others. The semantics of things like for() loops would require careful attention, though. > D. > > Henrik Bengtsson wrote: > > If R would have timestamps telling when any object was last modified, we > > could extend R with a 'GNU make'-style functionality (or syntax) > > together with some fancy caching to persistent storage (files, data > > bases, ...). That would really nice! As B.R. and M.M. writes, > > timestamping is most suited for higher level data structures and not > > simple data types, because the over head would be too large. > > > > /Henrik > > > > > > 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. > >>> > >>> 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 > >>> > >>> > >> > >> > >>______________________________________________ > >>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 > >> > >> > > > > > > ______________________________________________ > > 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 > > ______________________________________________ > 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 > -- O__ ---- Peter Dalgaard Ă˜ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 ______________________________________________ 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