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.
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.
Duncan Murdoch
Kasper
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel