thr3ads.net - R devel - [Rd] if(--as-cran)? [Sep 2012]

If this information is useful, please help other people find it:
Share via:

Spencer Graves

2012-Sep-03 05:43 UTC

[Rd] if(--as-cran)?

Hello, All:


       The fda package has tests that run too long for CRAN's current 
rules.  I'd like to wrap some examples in a construct like the following:


if(!CRAN()){
...
}


       I tried the following:


CRAN <- function(x='_R_CHECK_CRAN_INCOMING_'){
     x. <- Sys.getenv(x)
     xl <- as.logical(x.)
     notCRAN <- is.na(xl) || xl
#
     return(!notCRAN)
}


       The companion help page included the following example:


if(CRAN()){
   stop('CRAN')
} else {
   stop('NOT CRAN')
}


       This reported "NOT CRAN" even with "R CMD check
--as-cran".


       Suggestions?
       Thanks,
       Spencer

 > sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: i386-pc-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods base

other attached packages:
[1] sos_1.3-5  brew_1.0-6

loaded via a namespace (and not attached):
[1] tools_2.15.1

Henrik Bengtsson

2012-Sep-03 07:49 UTC

head link

[Rd] if(--as-cran)?

Hi, see thread "[Rd] Proposal: Mechanism for controlling the amount of
testing 'R CMD check' performs" on April 8, 2012:

  https://stat.ethz.ch/pipermail/r-devel/2012-April/063809.html

/Henrik


On Sun, Sep 2, 2012 at 10:43 PM, Spencer Graves
<spencer.graves at prodsyse.com> wrote:> Hello, All:
>
>
>       The fda package has tests that run too long for CRAN's current
rules.
> I'd like to wrap some examples in a construct like the following:
>
>
> if(!CRAN()){
> ...
> }
>
>
>       I tried the following:
>
>
> CRAN <- function(x='_R_CHECK_CRAN_INCOMING_'){
>     x. <- Sys.getenv(x)
>     xl <- as.logical(x.)
>     notCRAN <- is.na(xl) || xl
> #
>     return(!notCRAN)
> }
>
>
>       The companion help page included the following example:
>
>
> if(CRAN()){
>   stop('CRAN')
> } else {
>   stop('NOT CRAN')
> }
>
>
>       This reported "NOT CRAN" even with "R CMD check
--as-cran".
>
>
>       Suggestions?
>       Thanks,
>       Spencer
>
>> sessionInfo()
> R version 2.15.1 (2012-06-22)
> Platform: i386-pc-mingw32/i386 (32-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods base
>
> other attached packages:
> [1] sos_1.3-5  brew_1.0-6
>
> loaded via a namespace (and not attached):
> [1] tools_2.15.1
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Duncan Murdoch

2012-Sep-03 11:41 UTC

head link

[Rd] if(--as-cran)?

On 12-09-03 1:43 AM, Spencer Graves wrote:> Hello, All:
>
>
>         The fda package has tests that run too long for CRAN's current
> rules.  I'd like to wrap some examples in a construct like the
following:
>
>
> if(!CRAN()){
> ...
> }
>
>
>         I tried the following:
>
>
> CRAN <- function(x='_R_CHECK_CRAN_INCOMING_'){
>       x. <- Sys.getenv(x)
>       xl <- as.logical(x.)
>       notCRAN <- is.na(xl) || xl
> #
>       return(!notCRAN)
> }
>
>
>         The companion help page included the following example:
>
>
> if(CRAN()){
>     stop('CRAN')
> } else {
>     stop('NOT CRAN')
> }
>
>
>         This reported "NOT CRAN" even with "R CMD check
--as-cran".
There's no user-visible setting for --as-cran, because it just sets a 
number of other options.  You could query one of those.  The settings 
that are visible are

_R_CHECK_TIMINGS_  (which seems most relevant to you)
_R_CHECK_INSTALL_DEPENDS_
_R_CHECK_NO_RECOMMENDED_
_R_SHLIB_BUILD_OBJECTS_SYMBOL_TABLES_

So I'd check the value in _R_CHECK_TIMINGS_, or maybe just its existence.

Duncan Murdoch

Terry Therneau

2012-Sep-04 12:20 UTC

head link

[Rd] if(--as-cran)?

On 09/04/2012 05:00 AM, r-devel-request at r-project.org
wrote:> The issue is not just about "CRAN" vs "off CRAN".
> It is good to think about a more general scheme of
> "light testing" vs "normal testing" vs "extensive
testing",
> e.g.,  for the situation where the package implements
> (simulation/bootstrap/ ..) based inference, and the developer
> (but not only) should be able to run the extensive tests.
>
> Martin
I agree with Martin.  A mechanism to specify testing level would be the best.
Then CRAN can choose to set that variable to "3" say, with level 1 for
extensive and 2 for
usual.
   I'm quite willing to put up with the nuisance of print() enclosures.  I
prefer it to
having yet another way to subvert the evaluation model.

   I'm a believer in testing everything possible in my packages, and wear it
it as a badge
of honor that the survival package has 4 lines of R code in the tests directory
for every
3 in the R directory.  But CRAN only needs to run a small subset of this.

Terry T

Martin Maechler

2012-Sep-05 07:48 UTC

head link

[Rd] if(--as-cran)?

>>>>> Kasper Daniel Hansen <kasperdanielhansen at
gmail.com>
>>>>>     on Tue, 4 Sep 2012 17:41:38 -0400 writes:
    > On Tue, Sep 4, 2012 at 5:32 PM, Duncan Murdoch <murdoch.duncan at
gmail.com> wrote:
    >> On 04/09/2012 5:21 PM, John Fox wrote:
    >>> 
    >>> Dear all,
    >>> 
    >>> I'd like to second this fairly simple request. I currently
enclosed some
    >>> of
    >>> the examples in the effects package in \donttest{} blocks to
satisfy the
    >>> CRAN timing requirements for examples. It would be nice to have
something
    >>> like a \donttestcran{} block that suppresses the tests when
--as-cran is
    >>> set
    >>> (and on CRAN itself).
    >>> 
    >>> I'm sure that I've missed many of the nuances in this
discussion, but this
    >>> seems like a simple solution to me.
    >> 
    >> 
    >> That would work for examples, but not tests.  Many packages have
scripts
    >> that are in the tests directory, not just test code in the .Rd
files.  What
    >> I think you should use is my suggested
HowMuchTimeLeftBeforeTimeout()
    >> function, but if that's not writeable, then simply having a
TIMELIMIT
    >> environment variable or similar, so your code could see if the
there's a
    >> timeout pending.

    > I don't like this idea, because then I need to think about the
order
    > in which the tests are run.

    > You are right that we could simulate this by having an environment
    > variable, and if that variable is set, we could do the full tests.
    > Like Dirk is mentioning, the (sensible, I might add) requirement that
    > the tests should be "quick" suddenly makes the quick testing
the
    > default.

    > What I - and I think a lot of other people - would like, is to do this
    > in a standard way so it would be uniform across packages.  I don't
    > think it would be good if I start using R_LONG_TESTS and Dirk starts
    > to use __NON_CRAN_TESTS or whatever.  Then all of us need to know the
    > package-specific variables when we test other people packages (and
    > that happens occasionally, for example when you have a package that
    > other packages depend upon).

    > In this use case, standardization would be hugely beneficial in my
    > opinion.  In my reading of the discussion, this is really what all of
    > us are saying.

    > Kasper

Yes!  

... plus the idea to go one  step further:

Instead of just two levels  ( quick tests / extensive tests ),
one could use 3 or 4 (or 5) such levels, e.g.,
   1: very quick 
   2: CRAN-ok-quick
   3: package-developer-usual
   4: extensive

   *and* the CRAN maintainers would say which level is the one
   that runs daily on CRAN and hence needs to meet Duncan's
   TIMELIMIT.

   So instead of just setting an environment variable to
   non-zero length, or "true" (as in my example), one could set
   that environment variable to an  1, 2, ...

Martin


    >>> > -----Original Message-----
    >>> > From: r-devel-bounces at r-project.org
[mailto:r-devel-bounces at r-
    >>> > project.org] On Behalf Of Kasper Daniel Hansen
    >>> > Sent: Tuesday, September 04, 2012 5:12 PM
    >>> > To: Warnes, Gregory
    >>> > Cc: Terry Therneau; r-devel at r-project.org
    >>> > Subject: Re: [Rd] if(--as-cran)?
    >>> >
    >>> > On Tue, Sep 4, 2012 at 4:53 PM, Warnes, Gregory
    >>> > <gregory.warnes at novartis.com> wrote:
    >>> > >
    >>> > > On 9/4/12 3:58 PM, "Duncan Murdoch"
<murdoch.duncan at gmail.com> wrote:
    >>> > >
    >>> > >>On 04/09/2012 3:44 PM, Terry Therneau wrote:
    >>> > >>>ly in
    >>> > >>> On 09/04/2012 01:57 PM, Duncan Murdoch wrote:
    >>> > >>> > On 04/09/2012 2:36 PM, Warnes, Gregory
wrote:
    >>> > >>> >> On 9/4/12 8:38 AM, "Duncan
Murdoch" <murdoch.duncan at gmail.com>
    >>> > wrote:
    >>> > >>> >>
    >>> > >>> >>
    >>> > >>> >> >On 04/09/2012 8:20 AM, Terry
Therneau wrote:
    >>> > >>> >> >>
    >>> > >>> >> >> On 09/04/2012 05:00 AM, M
    >>> > >>><mailto:r-devel-request at
r-project.org>artin wrote:
    >>> > >>> >> >> > The issue is not just
about "CRAN" vs "off CRAN".
    >>> > >>> >> >> > It is good to think
about a more general scheme of
    >>> > >>> >> >> > "light
testing" vs "normal testing" vs "extensive testing",
    >>> > >>> >> >> > e.g., for the
situation where the package implements
    >>> > >>> >> >> > (simulation/bootstrap/
..) based inference, and the
    >>> > developer
    >>> > >>> >> >> > (but not only) should
be able to run the extensive tests.
    >>> > >>> >> >> >
    >>> > >>> >> >> > Martin
    >>> > >>> >> >>
    >>> > >>> >> >> I agree with Martin. A
mechanism to specify testing level
    >>> > would
    >>> > >>>be the
    >>> > >>> >> >> best. Then CRAN can choose
to set that variable to "3" say,
    >>> > with
    >>> > >>>level
    >>> > >>> >> >> 1 for extensive and 2 for
usual.
    >>> > >>>>> >>
    >>> > >>>
    >>> > >>>[snip]
    >>> > >
    >>> > >>The testingLevel() function is supposed to be a
way to know that a
    >>> > >>certain level of testing is being done, to allow
such tailoring.
    >>> > >>However, I don't think it's practical.  I
think you can ask whether a
    >>> > >>specific test is being run (my "D" %in%
tests() example), but you
    >>> > can't
    >>> > >>reasonably convert the set of tests chosen by a
tester into a single
    >>> > >>number.
    >>> > >>
    >>> > >>What I think you and Greg are talking about is
something different.
    >>> > You
    >>> > >>are asking that we set up more suites of tests,
corresponding to
    >>> > >>numerical levels.  Currently we have two suites: 
the default, and the
    >>> > >>--as-cran suite.  But we also have completely
customized suites, set
    >>> > by
    >>> > >>users who want to check specific things.  They can
do that the way you
    >>> > >>do (by calling the tests explicitly), or by
setting environment
    >>> > >>variables (as described in the Tools chapter of
the R Internals
    >>> > manual).
    >>> > >
    >>> > > No!  We're not asking for the r-core to create
more test suites, or
    >>> > even
    >>> > > to do anything different based on the test intensity
level.
    >>> > >
    >>> > > We're just asking for a standard way to control
the intensity of the
    >>> > tests
    >>> > > *we* write to prevent us from duplicating this
functionality in our
    >>> > own
    >>> > > packages, probably in incompatible ways.
    >>> >
    >>> > And given that CRAN recently put down timing requirements
(and
    >>> > Bioconductor has had them for a long time), it could be
extremely
    >>> > useful to have one system.  It is not clear to me whether
it needs
    >>> > more than 2 levels ("slow" and
"fast"), but I'll leave that up to
    >>> > people who have thought longer about this.
    >>> >
    >>> > I could certainly use it in several packages to
differentiate between
    >>> > slow and quick tests.
    >>> >
    >>> > Kasper
    >>> >
    >>> > ______________________________________________
    >>> > R-devel at r-project.org mailing list
    >>> > https://stat.ethz.ch/mailman/listinfo/r-devel
    >>> 
    >>

Maybe Matching Threads

Search for more maybe matching threads

R devel - Sep 2012 - if(--as-cran)?

[Rd] if(--as-cran)?

[Rd] if(--as-cran)?

[Rd] if(--as-cran)?

[Rd] if(--as-cran)?

[Rd] if(--as-cran)?

Maybe Matching Threads