Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

[Henrik Bengtsson]

On Fri, Mar 3, 2017 at 9:55 AM, Hadley Wickham  wrote:
>> But, how you propose a warning-to-error transition should be made
>> without wreaking havoc?  Just flip the switch in R-devel and see CRAN
>> and Bioconductor packages break overnight?  Particularly Bioconductor
>> devel might become non-functional (since at times it requires
>> R-devel).  For my own code / packages, I would be able to handle such
>> a change, but I'm completely out of control if one of the package I'm
>> depending on does not provide a quick fix (with the only option to
>> remove package tests for those dependencies).
>
> Generally, a package can not be on CRAN if it has any warnings, so I
> don't think this change would have any impact on CRAN packages.  Isn't
> this also true for bioconductor?

Having a tests/warn.R file with:

warning("boom")

passes through R CMD check --as-cran unnoticed.  Same with:

if (sample(2) == 1) message("It's your lucky day today!")

/Henrik

PS. Does testthat signal that?

>
> Hadley
>
> --
> http://hadley.nz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Trouble installing packages when history mechanism is modified by user profile

[Henrik Bengtsson]

Using

if (interactive()) utils::loadhistory(file = "~/.Rhistory")

should solve your problem.  The reason is that install.packages() in
turn launches a non-interactive child R process that installs the
package.  When that process loads your startup file, it fails, because
that function can only be used in interactive mode.  Here's an
example:

$ Rscript -e "utils::loadhistory()"
Error in .External2(C_loadhistory, file) : no history mechanism available

/Henrik

On Fri, Mar 3, 2017 at 5:51 AM, Hugo Raguet  wrote:
> I tried installing the 'ks' package from my interactive R session, it
> failed with the following
>
> Erreur dans .External2(C_loadhistory, file) :
>   aucun mécanisme d'historique des commandes disponible
> Calls: 
> Exécution arrêtée
>
> second line is french for "no command history mechanism available", fouth
> is "execution stopped".
> This does not happen when I comment out the following line from my
> .Rprofile:
> utils::loadhistory(file = "~/.Rhistory")
>
> On Stack Overflow, someone else has similar trouble with another package,
> which seems to be also related to command history:
> http://stackoverflow.com/questions/18240863/installing-packages-on-r-fails-when-loading-rprofile#18256224
>
> Is this a bug in R, or in the concerned packages?
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

[Hadley Wickham]

> But, how you propose a warning-to-error transition should be made
> without wreaking havoc?  Just flip the switch in R-devel and see CRAN
> and Bioconductor packages break overnight?  Particularly Bioconductor
> devel might become non-functional (since at times it requires
> R-devel).  For my own code / packages, I would be able to handle such
> a change, but I'm completely out of control if one of the package I'm
> depending on does not provide a quick fix (with the only option to
> remove package tests for those dependencies).

Generally, a package can not be on CRAN if it has any warnings, so I
don't think this change would have any impact on CRAN packages.  Isn't
this also true for bioconductor?

Hadley

-- 
http://hadley.nz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

[Henrik Bengtsson]

On Fri, Mar 3, 2017 at 9:22 AM, Martin Maechler
 wrote:
>> Henrik Bengtsson 
>> on Fri, 3 Mar 2017 00:52:16 -0800 writes:
>
> > I'd like to propose that the whenever the length of condition passed
> > to an if or a while statement differs from one, an error is produced
> > rather than just a warning as today:
>
> >> x <- 1:2
> >> if (x == 1) message("x == 1")
> > x == 1
> > Warning message:
> > In if (x == 1) message("x == 1") :
> > the condition has length > 1 and only the first element will be used
>
> > There are probably legacy reasons for why this is accepted by R in the
> > first place, but I cannot imagine than anyone wants to use an if/while
> > statement this way on purpose.  The warning about this misuse, was
> > introduced in November 2002 (R-devel thread 'vector arguments to
> > if()'; 
> https://stat.ethz.ch/pipermail/r-devel/2002-November/025537.html).
>
> yes, before, there was *no* warning at all and so the problem existed
> in several partly important R packages.
>
> Now is a different time, I agree, and I even tend to agree we
> should make this an error... probably however not for the
> upcoming R 3.4.0 (in April which is somewhat soon) but rather
> for the next version.
>
>
> > Below is patch (also attached) that introduces option
> > 'check.condition' such that when TRUE,
>
> ouch ouch ouch!   There are many sayings starting with
>   "The way to hell "
>
> Here:
>
> The way to R hell starts (or "widens", your choice) by
> introducing options() that influence basic language semantics
>
> !!
>
> For robust code you will start to test all code of R for all
> different possible combinations of these options set  I am
> sure you would not want this.

You only want to test with check.condition = TRUE.  No new code,
package updates etc should be allowed to only pass if they have to use
check.condition = FALSE.

>
> No --- don't even think of allowing an option for something such basic!

But, how you propose a warning-to-error transition should be made
without wreaking havoc?  Just flip the switch in R-devel and see CRAN
and Bioconductor packages break overnight?  Particularly Bioconductor
devel might become non-functional (since at times it requires
R-devel).  For my own code / packages, I would be able to handle such
a change, but I'm completely out of control if one of the package I'm
depending on does not provide a quick fix (with the only option to
remove package tests for those dependencies).

My idea is that with this option, then this can be tested at runtime
locally by users and developers (cf. warnPartialMatchArgs), but also
via R CMD check.  It would also provide CRAN with a way to check it on
incoming submissions as on the test farm - eventually all CRAN
packages pass without errors.  This option would only exist for a
number of R releases (first default to FALSE, then TRUE) and then
eventually be deprecated and removed.  Does this clarify my design?

As an alternative to an option, one could use an environment variable
R_CHECK_CONDITION that is a bit "hidden" from misuse.

/Henrik

>
> Martin Maechler
> ETH Zurich (and R Core)
>
> > it will generate an error
> > rather than a warning (default).  This option allows for a smooth
> > migration as it can be added to 'R CMD check --as-cran' and developers
> > can give time to check and fix their packages.  Eventually,
> > check.condition=TRUE can become the new default.
>
> > With options(check.condition = TRUE), one gets:
>
> >> x <- 1:2
> >> if (x == 1) message("x == 1")
> > Error in if (x == 1) message("x == 1") : the condition has length > 1
>
> > and
>
> >> while (x < 2) message("x < 2")
> > Error in while (x < 2) message("x < 2") : the condition has length > 1
>
>
> > Index: src/library/base/man/options.Rd
> > ===
> > --- src/library/base/man/options.Rd (revision 72298)
> > +++ src/library/base/man/options.Rd (working copy)
> > @@ -86,6 +86,11 @@
> > vector (atomic or \code{\link{list}}) is extended, by something
> > like \code{x <- 1:3; x[5] <- 6}.}
>
> > +\item{\code{check.condition}:}{logical, defaulting to 
> \code{FALSE}.  If
> > +  \code{TRUE}, an error is produced whenever the condition to an
> > +  \code{if} or a \code{while} control statement is of length 
> greater
> > +  than one.  If \code{FALSE}, a \link{warning} is produced.}
> > +
> > \item{\code{CBoundsCheck}:}{logical, controlling whether
> > \code{\link{.C}} and \code{\link{.Fortran}} make copies to check for
> > array over-runs on the atomic vector arguments.
> > @@ -445,6 +450,7 @@
> > \tabular{ll}{
> > \code{add.smooth} \tab \code{TRUE}\cr
> > \code{check.bounds} \tab \code{FALSE}\cr
> > +\code{check.condition} \tab \code{FALSE}\cr
> > \code{continue} \tab \code{"+

[Rd] Trouble installing packages when history mechanism is modified by user profile

[Hugo Raguet]

I tried installing the 'ks' package from my interactive R session, it
failed with the following

Erreur dans .External2(C_loadhistory, file) :
  aucun mécanisme d'historique des commandes disponible
Calls: 
Exécution arrêtée

second line is french for "no command history mechanism available", fouth
is "execution stopped".
This does not happen when I comment out the following line from my
.Rprofile:
utils::loadhistory(file = "~/.Rhistory")

On Stack Overflow, someone else has similar trouble with another package,
which seems to be also related to command history:
http://stackoverflow.com/questions/18240863/installing-packages-on-r-fails-when-loading-rprofile#18256224

Is this a bug in R, or in the concerned packages?

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

[Martin Maechler]

> Henrik Bengtsson 
> on Fri, 3 Mar 2017 00:52:16 -0800 writes:

> I'd like to propose that the whenever the length of condition passed
> to an if or a while statement differs from one, an error is produced
> rather than just a warning as today:

>> x <- 1:2
>> if (x == 1) message("x == 1")
> x == 1
> Warning message:
> In if (x == 1) message("x == 1") :
> the condition has length > 1 and only the first element will be used

> There are probably legacy reasons for why this is accepted by R in the
> first place, but I cannot imagine than anyone wants to use an if/while
> statement this way on purpose.  The warning about this misuse, was
> introduced in November 2002 (R-devel thread 'vector arguments to
> if()'; https://stat.ethz.ch/pipermail/r-devel/2002-November/025537.html).

yes, before, there was *no* warning at all and so the problem existed
in several partly important R packages.

Now is a different time, I agree, and I even tend to agree we
should make this an error... probably however not for the
upcoming R 3.4.0 (in April which is somewhat soon) but rather
for the next version.


> Below is patch (also attached) that introduces option
> 'check.condition' such that when TRUE, 

ouch ouch ouch!   There are many sayings starting with
  "The way to hell "

Here:

The way to R hell starts (or "widens", your choice) by
introducing options() that influence basic language semantics

!!

For robust code you will start to test all code of R for all
different possible combinations of these options set  I am
sure you would not want this.

No --- don't even think of allowing an option for something such basic!

Martin Maechler
ETH Zurich (and R Core)

> it will generate an error
> rather than a warning (default).  This option allows for a smooth
> migration as it can be added to 'R CMD check --as-cran' and developers
> can give time to check and fix their packages.  Eventually,
> check.condition=TRUE can become the new default.

> With options(check.condition = TRUE), one gets:

>> x <- 1:2
>> if (x == 1) message("x == 1")
> Error in if (x == 1) message("x == 1") : the condition has length > 1

> and

>> while (x < 2) message("x < 2")
> Error in while (x < 2) message("x < 2") : the condition has length > 1


> Index: src/library/base/man/options.Rd
> ===
> --- src/library/base/man/options.Rd (revision 72298)
> +++ src/library/base/man/options.Rd (working copy)
> @@ -86,6 +86,11 @@
> vector (atomic or \code{\link{list}}) is extended, by something
> like \code{x <- 1:3; x[5] <- 6}.}

> +\item{\code{check.condition}:}{logical, defaulting to \code{FALSE}.  
If
> +  \code{TRUE}, an error is produced whenever the condition to an
> +  \code{if} or a \code{while} control statement is of length greater
> +  than one.  If \code{FALSE}, a \link{warning} is produced.}
> +
> \item{\code{CBoundsCheck}:}{logical, controlling whether
> \code{\link{.C}} and \code{\link{.Fortran}} make copies to check for
> array over-runs on the atomic vector arguments.
> @@ -445,6 +450,7 @@
> \tabular{ll}{
> \code{add.smooth} \tab \code{TRUE}\cr
> \code{check.bounds} \tab \code{FALSE}\cr
> +\code{check.condition} \tab \code{FALSE}\cr
> \code{continue} \tab \code{"+ "}\cr
> \code{digits} \tab \code{7}\cr
> \code{echo} \tab \code{TRUE}\cr
> Index: src/library/utils/R/completion.R
> ===
> --- src/library/utils/R/completion.R (revision 72298)
> +++ src/library/utils/R/completion.R (working copy)
> @@ -1304,8 +1304,8 @@
> "plt", "ps", "pty", "smo", "srt", "tck", "tcl", "usr",
> "xaxp", "xaxs", "xaxt", "xpd", "yaxp", "yaxs", "yaxt")

> -options <- c("add.smooth", "browser", "check.bounds", "continue",
> - "contrasts", "defaultPackages", "demo.ask", "device",
> +options <- c("add.smooth", "browser", "check.bounds", 
"check.condition",
> +"continue", "contrasts", "defaultPackages", "demo.ask", "device",
> "digits", "dvipscmd", "echo", "editor", "encoding",
> "example.ask", "expressions", "help.search.types",
> "help.try.all.packages", "htmlhelp", "HTTPUserAgent",
> Index: src/main/eval.c
> ===
> --- src/main/eval.c (revision 72298)
> +++ src/main/eval.c (working copy)
> @@ -1851,9 +1851,13 @@
> Rboolean cond = NA_LOGICAL;

> if (length(s) > 1) {
> + int check = asInteger(GetOption1(install("check.condition")));
> PROTECT(s); /* needed as per PR#15990.  call gets protected by
> warningcall() */
> - warningcall(call,
> -_("the condition has length > 1 and only the first element will be 
used"));
> + 

Re: [Rd] Bug in nlm()

[Martin Maechler]

> Boehnstedt, Marie 
> on Fri, 3 Mar 2017 10:23:12 + writes:

> Dear all,
> I have found a bug in nlm() and would like to submit a report on this.
> Since nlm() is in the stats-package, which is maintained by the R Core 
team, bug reports should be submitted to R's Bugzilla. However, I'm not a 
member of Bugzilla. Could anyone be so kind to add me to R's Bugzilla members 
or let me know to whom I should send the bug report?

Dear Marie,

I can do this ... but  are you really sure?  There is
 https://www.r-project.org/bugs.html
which you should spend some time reading if you haven't already.

I think you would post a MRE (Minimal Reproducible Example) here
{or on stackoverflow or ...} if you'd follow what the 'R bugs' web
page (above) recommends and only report a bug after some
feedback from "the public".

Of course, I could be wrong.. and happy if you explain / tell me why.

Best,
Martin Maechler

> Thank you in advance.

> Kind regards,
> Marie B�hnstedt


> Marie B�hnstedt, MSc
> Research Scientist
> Max Planck Institute for Demographic Research
> Konrad-Zuse-Str. 1, 18057 Rostock, Germany
> www.demogr.mpg.de




> --
> This mail has been sent through the MPI for Demographic ...{{dropped:9}}


> --
> __
> 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

[Rd] Bug in nlm()

[Boehnstedt, Marie]

Dear all,

I have found a bug in nlm() and would like to submit a report on this.
Since nlm() is in the stats-package, which is maintained by the R Core team, 
bug reports should be submitted to R's Bugzilla. However, I'm not a member of 
Bugzilla. Could anyone be so kind to add me to R's Bugzilla members or let me 
know to whom I should send the bug report?
Thank you in advance.

Kind regards,
Marie B�hnstedt


Marie B�hnstedt, MSc
Research Scientist
Max Planck Institute for Demographic Research
Konrad-Zuse-Str. 1, 18057 Rostock, Germany
www.demogr.mpg.de




--
This mail has been sent through the MPI for Demographic ...{{dropped:9}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

[Henrik Bengtsson]

I'd like to propose that the whenever the length of condition passed
to an if or a while statement differs from one, an error is produced
rather than just a warning as today:

> x <- 1:2
> if (x == 1) message("x == 1")
x == 1
Warning message:
In if (x == 1) message("x == 1") :
  the condition has length > 1 and only the first element will be used

There are probably legacy reasons for why this is accepted by R in the
first place, but I cannot imagine than anyone wants to use an if/while
statement this way on purpose.  The warning about this misuse, was
introduced in November 2002 (R-devel thread 'vector arguments to
if()'; https://stat.ethz.ch/pipermail/r-devel/2002-November/025537.html).

Below is patch (also attached) that introduces option
'check.condition' such that when TRUE, it will generate an error
rather than a warning (default).  This option allows for a smooth
migration as it can be added to 'R CMD check --as-cran' and developers
can give time to check and fix their packages.  Eventually,
check.condition=TRUE can become the new default.

With options(check.condition = TRUE), one gets:

> x <- 1:2
> if (x == 1) message("x == 1")
Error in if (x == 1) message("x == 1") : the condition has length > 1

and

> while (x < 2) message("x < 2")
Error in while (x < 2) message("x < 2") : the condition has length > 1


Index: src/library/base/man/options.Rd
===
--- src/library/base/man/options.Rd (revision 72298)
+++ src/library/base/man/options.Rd (working copy)
@@ -86,6 +86,11 @@
   vector (atomic or \code{\link{list}}) is extended, by something
   like \code{x <- 1:3; x[5] <- 6}.}

+\item{\code{check.condition}:}{logical, defaulting to \code{FALSE}.  If
+  \code{TRUE}, an error is produced whenever the condition to an
+  \code{if} or a \code{while} control statement is of length greater
+  than one.  If \code{FALSE}, a \link{warning} is produced.}
+
 \item{\code{CBoundsCheck}:}{logical, controlling whether
   \code{\link{.C}} and \code{\link{.Fortran}} make copies to check for
   array over-runs on the atomic vector arguments.
@@ -445,6 +450,7 @@
   \tabular{ll}{
 \code{add.smooth} \tab \code{TRUE}\cr
 \code{check.bounds} \tab \code{FALSE}\cr
+\code{check.condition} \tab \code{FALSE}\cr
 \code{continue} \tab \code{"+ "}\cr
 \code{digits} \tab \code{7}\cr
 \code{echo} \tab \code{TRUE}\cr
Index: src/library/utils/R/completion.R
===
--- src/library/utils/R/completion.R (revision 72298)
+++ src/library/utils/R/completion.R (working copy)
@@ -1304,8 +1304,8 @@
   "plt", "ps", "pty", "smo", "srt", "tck", "tcl", "usr",
   "xaxp", "xaxs", "xaxt", "xpd", "yaxp", "yaxs", "yaxt")

-options <- c("add.smooth", "browser", "check.bounds", "continue",
- "contrasts", "defaultPackages", "demo.ask", "device",
+options <- c("add.smooth", "browser", "check.bounds", "check.condition",
+"continue", "contrasts", "defaultPackages", "demo.ask", "device",
  "digits", "dvipscmd", "echo", "editor", "encoding",
  "example.ask", "expressions", "help.search.types",
  "help.try.all.packages", "htmlhelp", "HTTPUserAgent",
Index: src/main/eval.c
===
--- src/main/eval.c (revision 72298)
+++ src/main/eval.c (working copy)
@@ -1851,9 +1851,13 @@
 Rboolean cond = NA_LOGICAL;

 if (length(s) > 1) {
+ int check = asInteger(GetOption1(install("check.condition")));
  PROTECT(s); /* needed as per PR#15990.  call gets protected by
warningcall() */
- warningcall(call,
-_("the condition has length > 1 and only the first element will be used"));
+ if(check != NA_INTEGER && check > 0)
+errorcall(call, _("the condition has length > 1"));
+ else
+warningcall(call,
+ _("the condition has length > 1 and only the first element will be used"));
  UNPROTECT(1);
 }
 if (length(s) > 0) {
Index: src/main/options.c
===
--- src/main/options.c (revision 72298)
+++ src/main/options.c (working copy)
@@ -65,6 +65,7 @@
  * "timeout" ./connections.c

  * "check.bounds"
+ * "check.condition"
  * "error"
  * "error.messages"
  * "show.error.messages"
@@ -248,9 +249,9 @@
 char *p;

 #ifdef HAVE_RL_COMPLETION_MATCHES
+PROTECT(v = val = allocList(22));
+#else
 PROTECT(v = val = allocList(21));
-#else
-PROTECT(v = val = allocList(20));
 #endif

 SET_TAG(v, install("prompt"));
@@ -289,6 +290,10 @@
 SETCAR(v, ScalarLogical(0)); /* no checking */
 v = CDR(v);

+SET_TAG(v, install("check.condition"));
+SETCAR(v, ScalarLogical(0)); /* no checking */
+v = CDR(v);
+
 p = getenv("R_KEEP_PKG_SOURCE");
 R_KeepSource = (p && (strcmp(p, "yes") == 0)) ? 1 : 0;


I'm happy to file this via https://bugs.r-project.org, if preferred.

/Henrik
Index: src/library/base/man/options