as-cran issue

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

as-cran issue

R devel mailing list
Where can I find out (and replicate) what options as-cran turns on?

The issue: the following lines generate an error in R CMD check --as-cran  for coxme.  But
there is no error without as-cran nor is there one when I run the code in a terminal window.

ismat <- function(x)  inherits(x, "matrix") || inherits(x, "bdsmatrix") || inherits(x,
"Matrix")
if (ismat(kmat)  ) ....

(The second line is repeated multiple times for multiple arguments.  The ismat function is
defined simply to save typing.)

The check log contains multiple instances of the lines below:

< Warning message:
< In if (ismat(kmat)) { :
<   the condition has length > 1 and only the first element will be used

I don't see how the error could arise, but if I know what as-cran is doing perhaps I can
replicate it.

 >sessionInfo()
R Under development (unstable) (2020-01-13 r77659)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.3 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=C
  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
  [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

loaded via a namespace (and not attached):
[1] compiler_4.0.0 tools_4.0.0
 >



        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue

Dirk Eddelbuettel

On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel wrote:
| Where can I find out (and replicate) what options as-cran turns on?

See the file src/library/tools/R/check.R in the R sources, and grep for
as_cran which is the internal variable controlled by the --as-cran option

[...]

| The check log contains multiple instances of the lines below:
|
| < Warning message:
| < In if (ismat(kmat)) { :
| <   the condition has length > 1 and only the first element will be used
|
| I don't see how the error could arise, but if I know what as-cran is doing perhaps I can
| replicate it.

This was widely discussed on this list and should also be in the NEWS file.

The change is about what the message says: the if () tests a scalar logical,
it appears that ismat(kmat) returns more than a scalar.

There has always been an opt-in for this to error -- cf many messages by Henrik
over the years as he tried to convince us all to use it more.


Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue

R devel mailing list
Thanks for the feedback Dirk.   I sent my follow-up before I saw it.

Looking at the source code, it appears that there is no options() call to turn this on.
Nor does "R --help" reveal a command line option.
How then does a user turn this on outside of the R CMD check envirionment, so as to chase
things like this down?

The fact that 1. renaming my function makes the error go away, 2. my function is just a
wrapper to inherits(), and 3. its a new error in code that hasn't changed, all point me
towards some oddity with the check function.

Terry


On 1/13/20 10:22 AM, Dirk Eddelbuettel wrote:

>
> On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel wrote:
> | Where can I find out (and replicate) what options as-cran turns on?
>
> See the file src/library/tools/R/check.R in the R sources, and grep for
> as_cran which is the internal variable controlled by the --as-cran option
>
> [...]
>
> | The check log contains multiple instances of the lines below:
> |
> | < Warning message:
> | < In if (ismat(kmat)) { :
> | <   the condition has length > 1 and only the first element will be used
> |
> | I don't see how the error could arise, but if I know what as-cran is doing perhaps I can
> | replicate it.
>
> This was widely discussed on this list and should also be in the NEWS file.
>
> The change is about what the message says: the if () tests a scalar logical,
> it appears that ismat(kmat) returns more than a scalar.
>
> There has always been an opt-in for this to error -- cf many messages by Henrik
> over the years as he tried to convince us all to use it more.
>
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue

bbolker
  From R NEWS (changes in 3.6.0)

Experimentally, setting environment variable _R_CHECK_LENGTH_1_LOGIC2_
will lead to warnings (or errors if the variable is set to a ‘true’
value) when && or || encounter and use arguments of length more than one.

On 2020-01-13 11:46 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:

> Thanks for the feedback Dirk.   I sent my follow-up before I saw it.
>
> Looking at the source code, it appears that there is no options() call
> to turn this on. Nor does "R --help" reveal a command line option.
> How then does a user turn this on outside of the R CMD check
> envirionment, so as to chase things like this down?
>
> The fact that 1. renaming my function makes the error go away, 2. my
> function is just a wrapper to inherits(), and 3. its a new error in code
> that hasn't changed, all point me towards some oddity with the check
> function.
>
> Terry
>
>
> On 1/13/20 10:22 AM, Dirk Eddelbuettel wrote:
>>
>> On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel wrote:
>> | Where can I find out (and replicate) what options as-cran turns on?
>>
>> See the file src/library/tools/R/check.R in the R sources, and grep for
>> as_cran which is the internal variable controlled by the --as-cran option
>>
>> [...]
>>
>> | The check log contains multiple instances of the lines below:
>> |
>> | < Warning message:
>> | < In if (ismat(kmat)) { :
>> | <   the condition has length > 1 and only the first element will be
>> used
>> |
>> | I don't see how the error could arise, but if I know what as-cran is
>> doing perhaps I can
>> | replicate it.
>>
>> This was widely discussed on this list and should also be in the NEWS
>> file.
>>
>> The change is about what the message says: the if () tests a scalar
>> logical,
>> it appears that ismat(kmat) returns more than a scalar.
>>
>> There has always been an opt-in for this to error -- cf many messages
>> by Henrik
>> over the years as he tried to convince us all to use it more.
>>
>>
>> Dirk
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue

Duncan Murdoch-2
In reply to this post by R devel mailing list
On 13/01/2020 11:02 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:

> Where can I find out (and replicate) what options as-cran turns on?
>
> The issue: the following lines generate an error in R CMD check --as-cran  for coxme.  But
> there is no error without as-cran nor is there one when I run the code in a terminal window.
>
> ismat <- function(x)  inherits(x, "matrix") || inherits(x, "bdsmatrix") || inherits(x,
> "Matrix")
> if (ismat(kmat)  ) ....
>
> (The second line is repeated multiple times for multiple arguments.  The ismat function is
> defined simply to save typing.)
>
> The check log contains multiple instances of the lines below:
>
> < Warning message:
> < In if (ismat(kmat)) { :
> <   the condition has length > 1 and only the first element will be used
>
> I don't see how the error could arise, but if I know what as-cran is doing perhaps I can
> replicate it.
>
>   >sessionInfo()
> R Under development (unstable) (2020-01-13 r77659)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.3 LTS
>
> Matrix products: default
> BLAS:   /usr/local/src/R-devel/lib/libRblas.so
> LAPACK: /usr/local/src/R-devel/lib/libRlapack.so
>
> locale:
>    [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>    [3] LC_TIME=en_US.UTF-8        LC_COLLATE=C
>    [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>    [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>    [9] LC_ADDRESS=C               LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.0.0 tools_4.0.0

You have ismat() defined in two places in the package.  In the
definition in coxme.R, you've got a typo:

     ismat <- function (x) {
         inherits(x, "matrix") || inherits(x, "bdsmatrix") | inherits(x,
"Matrix")
     }

Notice the "|" instead of "||".  I can't see how this would lead to the
issue you saw, but it should be fixed.

It's not easy to say what --as-cran does, other than to look at the
function that implements R CMD check.  That function is the huge
tools:::.check_packages.  You can run it in an R session using

   options(warn = 2, error = recover)
   tools:::.check_packages(c("--as-cran", "coxme_2.2-14.tar.gz"))

When I do that I get a different error report; it reports this test instead:

    if(class(varlist) == "coxmevar")

That appears in a number of places in the coxme source, and clearly
needs to be updated to use inherits().

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Martin Maechler
In reply to this post by bbolker
>>>>> Ben Bolker
>>>>>     on Mon, 13 Jan 2020 11:49:09 -0500 writes:

    > From R NEWS (changes in 3.6.0)
    > Experimentally, setting environment variable _R_CHECK_LENGTH_1_LOGIC2_
    > will lead to warnings (or errors if the variable is set to a ‘true’
    > value) when && or || encounter and use arguments of length more than one.

Indeed,  thank you, Ben.

Note (Dirk) this is not just something
  "by Henrik (..) as he tried to convince us all to use it more"

I've activated this (and the other
  _R_CHECK_LENGTH_1_CONDITION_ ! )
for years (maybe not many years, it just feels like it), and *EVERY TIME*
it triggers, it's been revealing a programmeR's thinko / bug / ..,
something where the code was clearly suboptimal and should've been improved.
(Unfortunately, the bug has often been in packages, and sometimes I had to
 disable the setting when I wanted that "buggy" package to work ..)

Occasionally being puristic, let me state this:
   __________________________________________________________________
  /------------------------------------------------------------------\
  |                                                                  |
  | Every careful R programmer should use (something like "true",    |
  | "verbose", or even package=... )                                 |
  |                                                                  |
  | export _R_CHECK_LENGTH_1_CONDITION_=true                         |
  | export _R_CHECK_LENGTH_1_LOGIC2_=verbose                         |
  |                                                                  |
  | in her/his ~/.profile equivalent (*)                             |
  \__________________________________________________________________/


*) well assuming a careful R programmer would never develop on
   Windows anyway (where you need different means to set such
   environment variables).



    > On 2020-01-13 11:46 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:
    >> Thanks for the feedback Dirk.   I sent my follow-up before I saw it.
    >>
    >> Looking at the source code, it appears that there is no options() call
    >> to turn this on. Nor does "R --help" reveal a command line option.
    >> How then does a user turn this on outside of the R CMD check
    >> envirionment, so as to chase things like this down?
    >>
    >> The fact that 1. renaming my function makes the error go away, 2. my
    >> function is just a wrapper to inherits(), and 3. its a new error in code
    >> that hasn't changed, all point me towards some oddity with the check
    >> function.
    >>
    >> Terry
    >>
    >>
    >> On 1/13/20 10:22 AM, Dirk Eddelbuettel wrote:
    >>>
    >>> On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel wrote:
    >>> | Where can I find out (and replicate) what options as-cran turns on?
    >>>
    >>> See the file src/library/tools/R/check.R in the R sources, and grep for
    >>> as_cran which is the internal variable controlled by the --as-cran option
    >>>
    >>> [...]
    >>>
    >>> | The check log contains multiple instances of the lines below:
    >>> |
    >>> | < Warning message:
    >>> | < In if (ismat(kmat)) { :
    >>> | <   the condition has length > 1 and only the first element will be
    >>> used
    >>> |
    >>> | I don't see how the error could arise, but if I know what as-cran is
    >>> doing perhaps I can
    >>> | replicate it.
    >>>
    >>> This was widely discussed on this list and should also be in the NEWS
    >>> file.
    >>>
    >>> The change is about what the message says: the if () tests a scalar
    >>> logical,
    >>> it appears that ismat(kmat) returns more than a scalar.
    >>>
    >>> There has always been an opt-in for this to error -- cf many messages
    >>> by Henrik
    >>> over the years as he tried to convince us all to use it more.
    >>>
    >>>
    >>> Dirk
    >>>
    >>
    >> ______________________________________________
    >> [hidden email] mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Avraham Adler
Those of us stuck on Windows but who attempt to develop properly are
wounded to the quick, sir!

:)

Avi

On Mon, Jan 13, 2020 at 12:24 PM Martin Maechler <[hidden email]>
wrote:

> >>>>> Ben Bolker
> >>>>>     on Mon, 13 Jan 2020 11:49:09 -0500 writes:
>
>     > From R NEWS (changes in 3.6.0)
>     > Experimentally, setting environment variable
> _R_CHECK_LENGTH_1_LOGIC2_
>     > will lead to warnings (or errors if the variable is set to a ‘true’
>     > value) when && or || encounter and use arguments of length more than
> one.
>
> Indeed,  thank you, Ben.
>
> Note (Dirk) this is not just something
>   "by Henrik (..) as he tried to convince us all to use it more"
>
> I've activated this (and the other
>   _R_CHECK_LENGTH_1_CONDITION_ ! )
> for years (maybe not many years, it just feels like it), and *EVERY TIME*
> it triggers, it's been revealing a programmeR's thinko / bug / ..,
> something where the code was clearly suboptimal and should've been
> improved.
> (Unfortunately, the bug has often been in packages, and sometimes I had to
>  disable the setting when I wanted that "buggy" package to work ..)
>
> Occasionally being puristic, let me state this:
>    __________________________________________________________________
>   /------------------------------------------------------------------\
>   |                                                                  |
>   | Every careful R programmer should use (something like "true",    |
>   | "verbose", or even package=... )                                 |
>   |                                                                  |
>   | export _R_CHECK_LENGTH_1_CONDITION_=true                         |
>   | export _R_CHECK_LENGTH_1_LOGIC2_=verbose                         |
>   |                                                                  |
>   | in her/his ~/.profile equivalent (*)                             |
>   \__________________________________________________________________/
>
>
> *) well assuming a careful R programmer would never develop on
>    Windows anyway (where you need different means to set such
>    environment variables).
>
>
>
>     > On 2020-01-13 11:46 a.m., Therneau, Terry M., Ph.D. via R-devel
> wrote:
>     >> Thanks for the feedback Dirk.   I sent my follow-up before I saw it.
>     >>
>     >> Looking at the source code, it appears that there is no options()
> call
>     >> to turn this on. Nor does "R --help" reveal a command line option.
>     >> How then does a user turn this on outside of the R CMD check
>     >> envirionment, so as to chase things like this down?
>     >>
>     >> The fact that 1. renaming my function makes the error go away, 2. my
>     >> function is just a wrapper to inherits(), and 3. its a new error in
> code
>     >> that hasn't changed, all point me towards some oddity with the check
>     >> function.
>     >>
>     >> Terry
>     >>
>     >>
>     >> On 1/13/20 10:22 AM, Dirk Eddelbuettel wrote:
>     >>>
>     >>> On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel
> wrote:
>     >>> | Where can I find out (and replicate) what options as-cran turns
> on?
>     >>>
>     >>> See the file src/library/tools/R/check.R in the R sources, and
> grep for
>     >>> as_cran which is the internal variable controlled by the --as-cran
> option
>     >>>
>     >>> [...]
>     >>>
>     >>> | The check log contains multiple instances of the lines below:
>     >>> |
>     >>> | < Warning message:
>     >>> | < In if (ismat(kmat)) { :
>     >>> | <   the condition has length > 1 and only the first element will
> be
>     >>> used
>     >>> |
>     >>> | I don't see how the error could arise, but if I know what
> as-cran is
>     >>> doing perhaps I can
>     >>> | replicate it.
>     >>>
>     >>> This was widely discussed on this list and should also be in the
> NEWS
>     >>> file.
>     >>>
>     >>> The change is about what the message says: the if () tests a scalar
>     >>> logical,
>     >>> it appears that ismat(kmat) returns more than a scalar.
>     >>>
>     >>> There has always been an opt-in for this to error -- cf many
> messages
>     >>> by Henrik
>     >>> over the years as he tried to convince us all to use it more.
>     >>>
>     >>>
>     >>> Dirk
>     >>>
>     >>
>     >> ______________________________________________
>     >> [hidden email] mailing list
>     >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>     > ______________________________________________
>     > [hidden email] mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Sent from Gmail Mobile

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue, SOLVED

R devel mailing list
In reply to this post by Duncan Murdoch-2
Thank you to all who replied with helpful suggestions.   I had to run off to meetings and
talks for a bit so am now processing it all.

1. It turns out that the issue was not with coxme, but with bsdmatrix, a package that
coxme calls.  It just happens to have a function ismat() with the same general purpose and
some similar variable names, which led me down the rabbit hole.   That package contained a
"class(x) == " flaw, now fixed.   (The fact that bdsmatrix has been stable and unchanged
for nearly a decade helped with the deception.)

2. As pointed out by Duncan and Kurt, the coxme function also had a class(x)== flaw.  None
of my test cases triggered this, but since 'x' is an argument that can be supplied by a
user, it certainly would have happened in package use.  Good catch.

3. Dirk gave good input about the flags in R CMD check and how to find them.   One more
line in the "Writing R Extensions" manual would have been helpful, namely that many of the
options are NOT available in the options() command nor as arguments to R.    As near as I
can tell, there is no way to turn on these logic checks within a standard R session.   A
desire to do this is where I started: I would have set options(warn=2, error=recover) and
found the actual offender in a few minutes; and never had to bother all you worthy readers.

4. I agree completely with Martin that errors like this should not be ignored.  In fact,
except for  "variable may be used before initialized" messages from the C compiler, I have
become grateful for EVERY complaint that comes out R CMD check.   Notice the verb "have
become" -- I did not start out so enthusiastic.

Again, thanks for the help.

Terry T.




        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue, SOLVED

Dirk Eddelbuettel
In reply to this post by Duncan Murdoch-2

On 13 January 2020 at 14:51, Therneau, Terry M., Ph.D. wrote:
| 3. Dirk gave good input about the flags in R CMD check and how to find them.   One more
| line in the "Writing R Extensions" manual would have been helpful, namely that many of the
| options are NOT available in the options() command nor as arguments to R.    As near as I
| can tell, there is no way to turn on these logic checks within a standard R session.   A

Section 8 of R Internals:

   8 Tools
   *******

   The behavior of 'R CMD check' can be controlled through a variety of
   command line arguments and environment variables.

   [...]


or online at

   https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools


Also, if I may, and as I may not have been clear enough earlier (as it
confused at least Martin): these "rolling" tightenings of "standards" and
tests are IMHO one the many rather clever "devices" R Core and CRAN use to
keep improving the quality of the code we all produce.  It's a good thing.

That said, and just like Terry, I have also searched many times for these
variables, and part of me thinks that it a crime that the material is spread
over (at least) three different manuals but _c'est la vie_. Until we get a
dedicated volunteer editor, or, deity forbid we decide to spend some
(collective) money on professional documentation.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Martin Maechler
In reply to this post by Avraham Adler
>>>>> Avraham Adler
>>>>>     on Mon, 13 Jan 2020 14:38:12 -0500 writes:

    > Those of us stuck on Windows but who attempt to develop properly are
    > wounded to the quick, sir!

    > :)

    > Avi

Indeed, you had a ' :) ' , but others have perceived this as an insult.
I'm really really sorry for that and do want to apologize to all
of you affected.

Indeed, on one hand, not everybody has a choice, and even then,
I'm (and 100s of 1000s of others) are very grateful to those
among you who develop and test R (and other free software, say,
Emacs, or Rstudio) on Windows.

I do want to entice people to have a long look beyond closed
source OS into the world of Free Software where not only R is
FOSS (Free and Open Source Software) but (all / almost) all the
tools you use are of that same spirit.

Best,
Martin



    > On Mon, Jan 13, 2020 at 12:24 PM Martin Maechler <[hidden email]>
    > wrote:

    >> >>>>> Ben Bolker
    >> >>>>>     on Mon, 13 Jan 2020 11:49:09 -0500 writes:
    >>
    >> > From R NEWS (changes in 3.6.0)
    >> > Experimentally, setting environment variable
    >> _R_CHECK_LENGTH_1_LOGIC2_
    >> > will lead to warnings (or errors if the variable is set to a ‘true’
    >> > value) when && or || encounter and use arguments of length more than
    >> one.
    >>
    >> Indeed,  thank you, Ben.
    >>
    >> Note (Dirk) this is not just something
    >> "by Henrik (..) as he tried to convince us all to use it more"
    >>
    >> I've activated this (and the other
    >> _R_CHECK_LENGTH_1_CONDITION_ ! )
    >> for years (maybe not many years, it just feels like it), and *EVERY TIME*
    >> it triggers, it's been revealing a programmeR's thinko / bug / ..,
    >> something where the code was clearly suboptimal and should've been
    >> improved.
    >> (Unfortunately, the bug has often been in packages, and sometimes I had to
    >> disable the setting when I wanted that "buggy" package to work ..)
    >>
    >> Occasionally being puristic, let me state this:
    >> __________________________________________________________________
    >> /------------------------------------------------------------------\
    >> |                                                                  |
    >> | Every careful R programmer should use (something like "true",    |
    >> | "verbose", or even package=... )                                 |
    >> |                                                                  |
    >> | export _R_CHECK_LENGTH_1_CONDITION_=true                         |
    >> | export _R_CHECK_LENGTH_1_LOGIC2_=verbose                         |
    >> |                                                                  |
    >> | in her/his ~/.profile equivalent (*)                             |
    >> \__________________________________________________________________/
    >>
    >>
    >> *) well assuming a careful R programmer would never develop on
    >> Windows anyway (where you need different means to set such
    >> environment variables).
    >>
    >>
    >>
    >> > On 2020-01-13 11:46 a.m., Therneau, Terry M., Ph.D. via R-devel
    >> wrote:
    >> >> Thanks for the feedback Dirk.   I sent my follow-up before I saw it.
    >> >>
    >> >> Looking at the source code, it appears that there is no options()
    >> call
    >> >> to turn this on. Nor does "R --help" reveal a command line option.
    >> >> How then does a user turn this on outside of the R CMD check
    >> >> envirionment, so as to chase things like this down?
    >> >>
    >> >> The fact that 1. renaming my function makes the error go away, 2. my
    >> >> function is just a wrapper to inherits(), and 3. its a new error in
    >> code
    >> >> that hasn't changed, all point me towards some oddity with the check
    >> >> function.
    >> >>
    >> >> Terry
    >> >>
    >> >>
    >> >> On 1/13/20 10:22 AM, Dirk Eddelbuettel wrote:
    >> >>>
    >> >>> On 13 January 2020 at 10:02, Therneau, Terry M., Ph.D. via R-devel
    >> wrote:
    >> >>> | Where can I find out (and replicate) what options as-cran turns
    >> on?
    >> >>>
    >> >>> See the file src/library/tools/R/check.R in the R sources, and
    >> grep for
    >> >>> as_cran which is the internal variable controlled by the --as-cran
    >> option
    >> >>>
    >> >>> [...]
    >> >>>
    >> >>> | The check log contains multiple instances of the lines below:
    >> >>> |
    >> >>> | < Warning message:
    >> >>> | < In if (ismat(kmat)) { :
    >> >>> | <   the condition has length > 1 and only the first element will
    >> be
    >> >>> used
    >> >>> |
    >> >>> | I don't see how the error could arise, but if I know what
    >> as-cran is
    >> >>> doing perhaps I can
    >> >>> | replicate it.
    >> >>>
    >> >>> This was widely discussed on this list and should also be in the
    >> NEWS
    >> >>> file.
    >> >>>
    >> >>> The change is about what the message says: the if () tests a scalar
    >> >>> logical,
    >> >>> it appears that ismat(kmat) returns more than a scalar.
    >> >>>
    >> >>> There has always been an opt-in for this to error -- cf many
    >> messages
    >> >>> by Henrik
    >> >>> over the years as he tried to convince us all to use it more.
    >> >>>
    >> >>>
    >> >>> Dirk
    >> >>>
    >> >>
    >> >> ______________________________________________
    >> >> [hidden email] mailing list
    >> >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>
    >> > ______________________________________________
    >> > [hidden email] mailing list
    >> > https://stat.ethz.ch/mailman/listinfo/r-devel
    >>
    >> ______________________________________________
    >> [hidden email] mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>
    > --
    > Sent from Gmail Mobile

    > [[alternative HTML version deleted]]

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Abby Spurdle
> I do want to entice people to have a long look beyond closed
> source OS into the world of Free Software where not only R is
> FOSS (Free and Open Source Software) but (all / almost) all the
> tools you use are of that same spirit.

And while everyone is talking about operating systems...

Recently, I tried to install R on Fedora.
However, it only gave me the option of downloading and installing R
3.6.1, when the current release is/was R 3.6.2.
I decided to wait, and may try again later, over the next week.

Is it possible for things to be free *and* simple?

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Dirk Eddelbuettel

On 15 January 2020 at 09:29, Abby Spurdle wrote:
| Recently, I tried to install R on Fedora.
| However, it only gave me the option of downloading and installing R
| 3.6.1, when the current release is/was R 3.6.2.
| I decided to wait, and may try again later, over the next week.
|
| Is it possible for things to be free *and* simple?

Sure.

Look at the Dockerfile (== "recipe", like shell) for the r-base container.

  https://github.com/rocker-org/rocker/blob/master/r-base/Dockerfile

Starts from vanilla Debian testing, and installs R. Takes no time, is fully
automated and has been running that way for years.  You can build up from
there, my blog has examples, as have many many other sites by other people.


One other recent-ish example is the r-apt Rocker image. Sets the repo for
current R (based on builds that Michael Rutter looks after based on my
official Debian package), then adds info for the PPAs Michael looks after and
you got over 4,000 CRAN packages ready to install as binaries -- just like
that.  The link is for 'disco' aka 19.04, we have the others too (but I need
to add 19.10 now).

  https://github.com/rocker-org/rocker/blob/master/r-apt/disco/Dockerfile

Both meet free *and* simple. And you don't have to build either. Just 'docker
pull'. There is more at the Rocker Project for you.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

R devel mailing list
In reply to this post by Abby Spurdle
> On Jan 14, 2020, at 3:29 PM, Abby Spurdle <[hidden email]> wrote:
>
>> I do want to entice people to have a long look beyond closed
>> source OS into the world of Free Software where not only R is
>> FOSS (Free and Open Source Software) but (all / almost) all the
>> tools you use are of that same spirit.
>
> And while everyone is talking about operating systems...
>
> Recently, I tried to install R on Fedora.
> However, it only gave me the option of downloading and installing R
> 3.6.1, when the current release is/was R 3.6.2.
> I decided to wait, and may try again later, over the next week.
>
> Is it possible for things to be free *and* simple?

Abby,

Which version of Fedora are you on?

The Fedora RPM build system for R:

  https://koji.fedoraproject.org/koji/packageinfo?packageID=1230

would seem to suggest that R 3.6.2 may not be available for Fedora 29 or earlier, which is not a surprise, given the rapid update cycle used on Fedora.

R 3.6.2 is available for Fedora 30, 31 and 32 per the above page.

If you are on Fedora >=30, you might check your yum repo to see if it has been properly updated.

Otherwise, if you are on Fedora <=29, you should think about updating your Fedora installation.

You may or may not be aware that there is a dedicated list for R on Fedora/RHEL and derivatives:

  https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Tom Callaway, who is the RH/Fedora maintainer for R is on that list, so you can pose queries to him via that list for any issues with R on Fedora.

Regards,

Marc Schwartz

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Henrik Bengtsson-5
On Tue, Jan 14, 2020 at 1:32 PM Marc Schwartz via R-devel
<[hidden email]> wrote:

>
> > On Jan 14, 2020, at 3:29 PM, Abby Spurdle <[hidden email]> wrote:
> >
> >> I do want to entice people to have a long look beyond closed
> >> source OS into the world of Free Software where not only R is
> >> FOSS (Free and Open Source Software) but (all / almost) all the
> >> tools you use are of that same spirit.
> >
> > And while everyone is talking about operating systems...
> >
> > Recently, I tried to install R on Fedora.
> > However, it only gave me the option of downloading and installing R
> > 3.6.1, when the current release is/was R 3.6.2.
> > I decided to wait, and may try again later, over the next week.
> >
> > Is it possible for things to be free *and* simple?
>
> Abby,
>
> Which version of Fedora are you on?
>
> The Fedora RPM build system for R:
>
>   https://koji.fedoraproject.org/koji/packageinfo?packageID=1230
>
> would seem to suggest that R 3.6.2 may not be available for Fedora 29 or earlier, which is not a surprise, given the rapid update cycle used on Fedora.
>
> R 3.6.2 is available for Fedora 30, 31 and 32 per the above page.
>
> If you are on Fedora >=30, you might check your yum repo to see if it has been properly updated.
>
> Otherwise, if you are on Fedora <=29, you should think about updating your Fedora installation.
>
> You may or may not be aware that there is a dedicated list for R on Fedora/RHEL and derivatives:
>
>   https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
> Tom Callaway, who is the RH/Fedora maintainer for R is on that list, so you can pose queries to him via that list for any issues with R on Fedora.

We inquired about R 3.6.1 on CentOS 7 EPEL, which is currently stuck
on R 3.6.0, and go the following reply
(https://bugzilla.redhat.com/show_bug.cgi?id=1727281#c19):

>>> Tom "spot" Callaway 2019-11-12 19:41:25 UTC
>>>
>>>  The challenge is this:
>>>
>>> R 3.6.1 cannot build with the stock EL-7 toolchain, due to the C++ support level required. In order to build it, we need to use devtoolset-8-toolchain. When R 3.6.1 is built, it assumes that same level of C++ support is available, and any EL-7 setups using it which do not have devtoolset-8-toolchain will not successfully build modules from CRAN which depend on that C++ support (which is not a small number these days). Thus, I made the R-3.6.1 build for EL-7 depend on devtoolset-8-toolchain, but this is not acceptable (apparently).
>>>
>>> So, I'm caught between either:
>>>
>>> 1. Dropping the dependency on devtoolset-8-toolchain and having bugs flow in which I'm forced to close as CANTFIX
>>>
>>> or
>>>
>>> 2. Leaving R in EL-7 at the last release which did not depend on devtoolset-8-toolchain
>>>
>>> I'm really unwilling to do #1.

It sounds odd to me that R would update hard requirements during R
3.6.x releases; I'd except them to be optional (OTH, it might
something I just made up).  I meant to find time to look into this,
but there's this thing called time so it never happened.  Maybe
someone else with more knowledge can comment on this.

/Henrik

>
> Regards,
>
> Marc Schwartz
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Abby Spurdle
In reply to this post by R devel mailing list
> Which version of Fedora are you on?

I've got Fedora 31.
I just checked, and R 3.6.2 is available now.

Progress...
...however, there's another problem.

From the dependencies:
R-java                   x86_64 3.6.2-1.fc31           updates  10 k
R-java-devel             x86_64 3.6.2-1.fc31           updates 9.9 k
java-1.8.0-openjdk       x86_64 1:1.8.0.232.b09-0.fc31 updates 281 k
java-1.8.0-openjdk-devel x86_64 1:1.8.0.232.b09-0.fc31 updates 9.3 M
java-1.8.0-openjdk-headless
                         x86_64 1:1.8.0.232.b09-0.fc31 updates  32 M

So, Linux's R (or at least Fedora's R) is dependent on Java.
-> Bad idea...

I'm using OpenJ9, so I can't install R like this without causing
significant problems.
(But please someone correct me if I'm wrong).

I will allocate some time to investigate Dirk's suggestions, however, I'm
thinking the best option is to continue using *Windows* as my primary OS,
and build Linux versions of R from source.

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Ralf Stubner-2
On Wed, Jan 15, 2020 at 5:45 AM Abby Spurdle <[hidden email]> wrote:

> ...however, there's another problem.
>
> From the dependencies:
> R-java                   x86_64 3.6.2-1.fc31           updates  10 k
> R-java-devel             x86_64 3.6.2-1.fc31           updates 9.9 k
> java-1.8.0-openjdk       x86_64 1:1.8.0.232.b09-0.fc31 updates 281 k
> java-1.8.0-openjdk-devel x86_64 1:1.8.0.232.b09-0.fc31 updates 9.3 M
> java-1.8.0-openjdk-headless
>                          x86_64 1:1.8.0.232.b09-0.fc31 updates  32 M
>
> So, Linux's R (or at least Fedora's R) is dependent on Java.
> -> Bad idea...

You could install R-core (and probably R-core-devel) to get R without
the Java dependency.

cheerio
ralf

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Iñaki Ucar
In reply to this post by Abby Spurdle
A bit off-topic, but...

On Wed, 15 Jan 2020 at 05:45, Abby Spurdle <[hidden email]> wrote:
>
> > Which version of Fedora are you on?
>
> I've got Fedora 31.
> I just checked, and R 3.6.2 is available now.

R 3.6.2 was submitted a month ago for testing and reached stable 19
days ago [1]. At any time, you can see which version is available in
stable (updates repo) and in testing for all supported Fedora and EPEL
versions in [2].

> Progress...
> ...however, there's another problem.
>
> From the dependencies:
> R-java                   x86_64 3.6.2-1.fc31           updates  10 k
> R-java-devel             x86_64 3.6.2-1.fc31           updates 9.9 k
> java-1.8.0-openjdk       x86_64 1:1.8.0.232.b09-0.fc31 updates 281 k
> java-1.8.0-openjdk-devel x86_64 1:1.8.0.232.b09-0.fc31 updates 9.3 M
> java-1.8.0-openjdk-headless
>                          x86_64 1:1.8.0.232.b09-0.fc31 updates  32 M
>
> So, Linux's R (or at least Fedora's R) is dependent on Java.
> -> Bad idea...

(Not so) fresh news: R officially supports Java [3], and many packages
on CRAN use Java (at least 170 by my count). So if you simply install
"R", you are requesting a *full* R installation, which of course
includes Java. However, if you don't want Java nor any of these
packages, R-core and R-core-devel do not depend on Java, as Ralf
pointed out.

> I'm using OpenJ9, so I can't install R like this without causing
> significant problems.
> (But please someone correct me if I'm wrong).

Note though that the R-java bits do not depend on any specific version
of Java. Several versions of Java can coexist, and then you can switch
between them using alternatives [4].

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-3d6f517d22
[2] https://src.fedoraproject.org/rpms/R
[3] https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Java-support
[4] https://fedoraproject.org/wiki/Java

--
Iñaki Úcar

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Abby Spurdle
In reply to this post by Martin Maechler
> I do want to entice people to have a long look beyond closed
> source OS into the world of Free Software where not only R is
> FOSS (Free and Open Source Software) but (all / almost) all the
> tools you use are of that same spirit.
>
> Best,
> Martin

I've reconsidered.
You're 100% correct.

I'm planning to try ReactOS.
(Hope it works...)

Thanks Martin, great advice...

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

Martin Maechler
>>>>> Abby Spurdle
>>>>>     on Tue, 21 Jan 2020 09:15:39 +1300 writes:

    >> I do want to entice people to have a long look beyond closed
    >> source OS into the world of Free Software where not only R is
    >> FOSS (Free and Open Source Software) but (all / almost) all the
    >> tools you use are of that same spirit.
    >>
    >> Best,
    >> Martin

    > I've reconsidered.
    > You're 100% correct.

Thank you.

    > I'm planning to try ReactOS.
    > (Hope it works...)

    > Thanks Martin, great advice...

Well, to choose ReactOS ()
instead of a version of Linux (there
have some Linux distributions that have aimed for being close to
Windows in their "look and feel") is  much braver and more
risky, but then, your learning experience, including possibly being the
first one to run R there (?) ((possibly even learning how to
*build* R there from the sources ??)),  will feel more
frontier-like and self determined than just following the Linux
crowd ;-) ;-) :-)

Martin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel