On Wed, Sep 5, 2012 at 11:41 AM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > On 12-09-04 8:19 PM, Kasper Daniel Hansen wrote: >> >> On Tue, Sep 4, 2012 at 6:02 PM, Duncan Murdoch <murdoch.dun...@gmail.com> >> wrote: >>> >>> On 04/09/2012 5:42 PM, Dirk Eddelbuettel wrote: >>>> >>>> >>>> On 4 September 2012 at 17:26, Duncan Murdoch wrote: >>>> | On 04/09/2012 5:14 PM, Dirk Eddelbuettel wrote: >>>> | > An add-on argument to the already established option --as-cran may >>>> be >>>> the >>>> | > best. >>>> | > >>>> | > And to iterate, what bugs me is that for _me_ on _my_ machine >>>> developing _my_ >>>> | > package I have remember how to enable what is now (as per CRAN's >>>> decree) >>>> | > "non-standard behaviour" of full testing. I fully agree with what >>>> Terry had >>>> | > said: more tests are better (when we develop). I want the full >>>> suite >>>> at my >>>> | > end; that is after all why we wrote it! >>>> | >>>> | You don't have to remember that, you need to figure it out once, write >>>> a >>>> | script that sets the environment variables that enable it, and then >>>> you >>>> | can forget it. >>>> >>>> "In theory, theory and practice are the same. In practice, they are >>>> not." >>>> >>>> The main test script long had exactly such a setting; I wrote what I >>>> wrote >>>> because it is _still the wrong way around_ and as I happen to have added >>>> to >>>> unit tests this weekend _having suffered through precisely this >>>> setting_. >>>> >>>> But we are on different wavelengths here and I evidently do not get my >>>> point >>>> across to you. And as you are the one who could make a change where it >>>> matters, I have no choice but to rest my case in frustration. >>> >>> >>> >>> If you want to give up, then give up, but then don't complain about the >>> current behaviour. If you want to fix it, then continue the discussion. >>> >>> You're right that we're on different wavelengths. If you want some tests >>> to >>> run at home but not on CRAN, then somewhere there has to be a >>> conditional. >>> I'm suggesting that the conditional should be "if there's a tight time >>> limit, skip this". >>> >>> I don't remember if this was your suggestion, but someone has suggested >>> "if >>> we're running with the --as-cran option, skip this" and others have >>> suggested "if we're running on CRAN, skip this". I don't see why you >>> find >>> my suggestion so objectionable. If you want, I'll repeat why I find the >>> other two suggestions objectionable. >> >> >> I agree with Duncan that having an option long/short makes more sense >> than with/without cran, as long as cran sets that option to be short. > >> >> >> I would also prefer a command line switch to R CMD check to an >> environment variable, but I'll be very happy with a standardized >> environment variable. > > > I honestly don't see the need for a standardized variable. I've told you > how to detect that you are running --as-cran; if that isn't sufficient > information, then you, the package author, need to set up something more > elaborate, and assume that if it's not set up, then someone else (maybe > CRAN) is running the test.
So maybe documenting that (_R_CHECK_TIMINGS_) more formally in R-exts would be sufficient? -Deepayan > I asked the CRAN powers-that-be about the possibility of querying the amount > of time remaining before a timeout; since the different platforms all use > different mechanisms to enforce a timeout, that's not really practical. So > the best you could hope for is to know that a timeout is in effect. Before > I wrote any code, I'd need to hear why --as-cran detection isn't sufficient. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
