|
>>>>> "Trevor" == Trevor Hastie <[hidden email]>
>>>>> 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: 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}. 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. Martin Maechler, ETH Zurich ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
Martin Maechler wrote:
>>>>>>"Trevor" == Trevor Hastie <[hidden email]> >>>>>> 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, myobject@myslot <- newvalue, that attribute is not updated, isn't it? Best, Philippe Grosjean > Martin Maechler, ETH Zurich > > ______________________________________________ > [hidden email] mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > > ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Martin Maechler
>>>>> "Trevor" == Trevor Hastie <[hidden email]> >>>>> on Tue, 13 Dec 2005 12:51:34 -0800 writes: Trevor> It would be nice to have a date stamp on an object. Indeed it would. If I had a better brain and memory, and didn't have to run so many projects in parallel I could probably cope OK. But when trying to pick up the threads of a project from several weeks/months ago the date-stamping in Splus together with facilities like objects.summary( order = "dataset.date" , data.class='function' ) makes it much quicker and easier to work out exactly what I did and in what order. It would be great to have similar facilities in R. Bob Kinley ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Philippe Grosjean
On Sat, 14 Jan 2006, Philippe Grosjean wrote:
> Martin Maechler wrote: >>>>>>> "Trevor" == Trevor Hastie <[hidden email]> >>>>>>> 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. Because R does not store objects. Rather R has a workspace, containing a collection of Ncells and Vcells which are pointed to by a look-up table of names (what people think of as objects) and with extensive cross-linking. Suppose 'A' is a data frame. What date is 'A'? 'A' consists of a list with elements the columns, and attributes including row.names. All those columns and attributes can be shared with other objects, and it is possible to update them without copying the list. So if you wanted the modification date of any part of the object you would need to tag every bit of it and do a search. Adding a date to each bit would be a considerable overhead (remember R stores each string as a separate sub-object), and people are whining about the storage requirements already. It would be possible to have a creation date on objects, but that is not what Philippe wants below. Even that would need considerable surgery to deal with back-compatibility (saved objects would not have such a date). >> 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... Well, only if you believe objects have a separate existence, and perhaps the issue is one of mindset, as Martin Maechler has hinted. I have to wonder why people who want S do not use it. >> 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, > myobject@myslot <- newvalue, that attribute is not updated, isn't it? -- Brian D. Ripley, [hidden email] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Philippe Grosjean
Philippe Grosjean wrote:
> Martin Maechler wrote: >>>>>>> "Trevor" == Trevor Hastie <[hidden email]> >>>>>>> on Tue, 13 Dec 2005 12:51:34 -0800 writes: >> >> Trevor> It would be nice to have a date stamp on an object. One way to do this with important objects is to use the comment function (in package base) comment(myobj) <- "made last sunday of 2005" Kjetil >> >> 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, > myobject@myslot <- newvalue, that attribute is not updated, isn't it? > > Best, > > Philippe Grosjean > >> Martin Maechler, ETH Zurich >> >> ______________________________________________ >> [hidden email] mailing list >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >> >> > > ______________________________________________ > [hidden email] mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Philippe Grosjean
Philippe Grosjean wrote:
> Martin Maechler wrote: >>>>>>> "Trevor" == Trevor Hastie <[hidden email]> >>>>>>> on Tue, 13 Dec 2005 12:51:34 -0800 writes: >> >> Trevor> It would be nice to have a date stamp on an object. Following up on my post of a few minutes ago, I tried to write an timestamp function timestamp <- function(obj, moretext){ comment(obj) <<- paste(Sys.time(), moretext, sep="\n") } but this does'nt work. > myobj <- 1:10 > timestamp(myobj, "test") Error in timestamp(myobj, "test") : object "obj" not found > Kjetil >> >> 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, > myobject@myslot <- newvalue, that attribute is not updated, isn't it? > > Best, > > Philippe Grosjean > >> Martin Maechler, ETH Zurich >> >> ______________________________________________ >> [hidden email] mailing list >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >> >> > > ______________________________________________ > [hidden email] mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
>>>>> "Kjetil" == Kjetil Brinchmann Halvorsen <[hidden email]>
>>>>> on Wed, 14 Dec 2005 08:59:24 -0400 writes: Kjetil> Philippe Grosjean wrote: >> Martin Maechler wrote: >>>>>>>> "Trevor" == Trevor Hastie <[hidden email]> >>>>>>>> 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 } ## 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, >> myobject@myslot <- newvalue, that attribute is not updated, isn't it? >> >> Best, >> >> Philippe Grosjean >> >>> Martin Maechler, ETH Zurich >>> ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Philippe Grosjean
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 <[hidden email]> >>>>>>> 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, > myobject@myslot <- newvalue, that attribute is not updated, isn't it? > > Best, > > Philippe Grosjean > > >>Martin Maechler, ETH Zurich >> >>______________________________________________ >>[hidden email] mailing list >>https://stat.ethz.ch/mailman/listinfo/r-help >>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >> >> > > > ______________________________________________ > [hidden email] mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > > ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Martin Maechler
On Wed, 14 Dec 2005, Martin Maechler wrote:
> >>>>> "Kjetil" == Kjetil Brinchmann Halvorsen <[hidden email]> > >>>>> on Wed, 14 Dec 2005 08:59:24 -0400 writes: > > Kjetil> Philippe Grosjean wrote: > >> Martin Maechler wrote: > >>>>>>>> "Trevor" == Trevor Hastie <[hidden email]> > >>>>>>>> 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, > >> myobject@myslot <- newvalue, that attribute is not updated, isn't it? > >> > >> Best, > >> > >> Philippe Grosjean > >> > >>> Martin Maechler, ETH Zurich > >>> > > ______________________________________________ > [hidden email] 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: [hidden email] ______________________________________________ [hidden email] 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
Department of Economics NHH Norwegian School of Economics Helleveien 30 N-5045 Bergen, Norway |
|
In reply to this post by Henrik Bengtsson-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 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. 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 <[hidden email]> >>>>>>>> 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, >>myobject@myslot <- newvalue, that attribute is not updated, isn't it? >> >>Best, >> >>Philippe Grosjean >> >> >> >>>Martin Maechler, ETH Zurich >>> >>>______________________________________________ >>>[hidden email] mailing list >>>https://stat.ethz.ch/mailman/listinfo/r-help >>>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >>> >>> >> >> >>______________________________________________ >>[hidden email] mailing list >>https://stat.ethz.ch/mailman/listinfo/r-help >>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >> >> > > > ______________________________________________ > [hidden email] 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 [hidden email] 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) iD8DBQFDoCzy9p/Jzwa2QP4RAqwUAJ9MCR4cJjX2zPbAnNL4EZnPr8koFQCfa3k1 CBKAtF8BZjipTDBsEzlmHSg= =27z6 -----END PGP SIGNATURE----- ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Roger Bivand
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Roger Bivand wrote: > On Wed, 14 Dec 2005, Martin Maechler wrote: > > >>>>>>>"Kjetil" == Kjetil Brinchmann Halvorsen <[hidden email]> >>>>>>> on Wed, 14 Dec 2005 08:59:24 -0400 writes: >> >> Kjetil> Philippe Grosjean wrote: >> >> Martin Maechler wrote: >> >>>>>>>> "Trevor" == Trevor Hastie <[hidden email]> >> >>>>>>>> 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, >> >> myobject@myslot <- newvalue, that attribute is not updated, isn't it? >> >> >> >> Best, >> >> >> >> Philippe Grosjean >> >> >> >>> Martin Maechler, ETH Zurich >> >>> >> >>______________________________________________ >>[hidden email] 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 [hidden email] 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----- ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Roger Bivand
>>>>> "Roger" == Roger Bivand <[hidden email]>
>>>>> on Wed, 14 Dec 2005 15:14:47 +0100 (CET) writes: Roger> On Wed, 14 Dec 2005, Martin Maechler wrote: >> >>>>> "Kjetil" == Kjetil Brinchmann Halvorsen <[hidden email]> >> >>>>> on Wed, 14 Dec 2005 08:59:24 -0400 writes: >> Kjetil> Philippe Grosjean wrote: >> >> Martin Maechler wrote: >> >>>>>>>> "Trevor" == Trevor Hastie <[hidden email]> >> >>>>>>>> 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 >> } Roger> This does treat any existing comment rather brutally, could stamp rather Roger> be: Roger> stamp <- paste(Sys.time(), comment(obj), value) Roger> probably enhanced with some field separators to let the inspector grab Roger> just its chunk? Something like DCF? Sure (and hence Duncan TL's answer). My main point was to define a "timestamp<-" function and use timestamp(......) <- .... [instead of using functions that silently modify their arguments..] Martin ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Roger Bivand
On 14 Dec 2005, [hidden email] wrote:
> 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? This does treat the structure of any existing comments rather brutally, could stamp rather be: stamp <- c(comment(obj), paste(Sys.time(), value)) :-) ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Duncan Temple Lang
[Got stuck in the mail filter: "Too many recipients". Cancelled and
resending.] Duncan Temple Lang <[hidden email]> 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 <[hidden email]> > >>>>>>>> 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, > >>myobject@myslot <- newvalue, that attribute is not updated, isn't it? > >> > >>Best, > >> > >>Philippe Grosjean > >> > >> > >> > >>>Martin Maechler, ETH Zurich > >>> > >>>______________________________________________ > >>>[hidden email] mailing list > >>>https://stat.ethz.ch/mailman/listinfo/r-help > >>>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > >>> > >>> > >> > >> > >>______________________________________________ > >>[hidden email] mailing list > >>https://stat.ethz.ch/mailman/listinfo/r-help > >>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > >> > >> > > > > > > ______________________________________________ > > [hidden email] 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 [hidden email] > 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 > > ______________________________________________ > [hidden email] 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 ~~~~~~~~~~ - ([hidden email]) FAX: (+45) 35327907 ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Martin Maechler
This would be extraordinarily helpful, but I have not thought of a
graceful way to do it. Everything in R now has a class attribute, but a timestamp for such simple things as vectors seems like overkill. On the other hand, those of us writing packages could implement this pretty easily for complex objects we produce. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email [hidden email] Montana State University Bozeman, MT 59717-3460 Trevor Hastie wrote: > It would be nice to have a date stamp on an object. > In S/Splus this was always available, because objects were files. > > I have looked around, but I presume this information is not available. > > -------------------------------------------------------------------- > Trevor Hastie [hidden email] > Professor, Department of Statistics, Stanford University > Phone: (650) 725-2231 (Statistics) Fax: (650) 725-8977 > (650) 498-5233 (Biostatistics) Fax: (650) 725-6951 > URL: http://www-stat.stanford.edu/~hastie > address: room 104, Department of Statistics, Sequoia Hall > 390 Serra Mall, Stanford University, CA 94305-4065 > > ______________________________________________ > [hidden email] mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > > ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Martin Maechler
Trevor Hastie <[hidden email]> wrote:
> It would be nice to have a date stamp on an object. > In S/Splus this was always available, because objects were files. The "g.data" package on CRAN stores R objects in individual files, like the (old) S-Plus model. The timestamp on a file tells you the last time "g.data.save()" was invoked on that object. Its primary purpose is to make objects available (as promises) without filling up memory until an object is actually used. -- David Brahm ([hidden email]) ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
|
In reply to this post by Kjetil Halvorsen
On Wed, 14-Dec-2005 at 08:37AM -0400, Kjetil Brinchmann Halvorsen wrote:
|> Philippe Grosjean wrote: |> > Martin Maechler wrote: |> >>>>>>> "Trevor" == Trevor Hastie <[hidden email]> |> >>>>>>> on Tue, 13 Dec 2005 12:51:34 -0800 writes: |> >> |> >> Trevor> It would be nice to have a date stamp on an object. |> |> One way to do this with important objects is to use the comment function |> (in package base) |> |> comment(myobj) <- "made last sunday of 2005" That's the beginning of the approach I used to produce a view of a working directory that looks like this: Object Mode Rows Cols Len Date 1 lme.gca.testB function -- -- 1 05/12/2005 2 lme.gca.testB2 function -- -- 1 05/12/2005 3 last.warning list -- -- 1 01/12/2005 4 lme.gca.testB3 function -- -- 1 01/12/2005 5 pedigree.gold function -- -- 1 01/12/2005 6 kin.mat numeric 44 44 1936 17/11/2005 7 kin.matrix numeric 13 13 169 17/11/2005 8 pedigree.goldA function -- -- 1 15/11/2005 9 goldPed.df dataframe 44 6 6 11/11/2005 10 plot.pedigree function -- -- 1 11/11/2005 11 Plot.pedigree2 function -- -- 1 11/11/2005 12 every character -- -- 43 10/11/2005 13 femaleTree character -- -- 1596 10/11/2005 14 lme.gca.test2 function -- -- 1 10/11/2005 15 maleTree character -- -- 2084 10/11/2005 I keep a file that I can source one line at a time using ESS to rerun any of the objects. Typically, there will be data entry error repairs to text files used to produce dataframes (no change to the script), or I'll update a function with better thinking. That date can be useful information months or years later. Some of my local functions are nearly 10 years old and the date on them gives me an idea of how knowledgable I might have been at the time I last updated it. For me, it's extremely useful and I find it cumbersome to work on a system that doesn't have that functionality (particularly if it doesn't have ESS either). My approach does quite a bit more than adding a date and might be boring to most of the list since it is somewhat involved and convoluted, so I won't go into how it works here. I'm sure it could be made more elegant (say, using some of the ideas Duncan and Martin mentioned). If anyone is keen to develop something along these lines, I'll gladly provide ideas. best -- Patrick Connolly HortResearch Mt Albert Auckland New Zealand Ph: +64-9 815 4200 x 7188 ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ I have the world`s largest collection of seashells. I keep it on all the beaches of the world ... Perhaps you`ve seen it. ---Steven Wright ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html |
| Powered by Nabble | Edit this page |
