Re: [R-pkg-devel] Warning when the --as-cran flag is used, not otherwise.

[Sebastian Meyer]

There is a note on your help page that says

These data are **not** immediately available in the `eglhmm` package.

which seems to be in line with the check warning.

Best wishes,
Sebastian Meyer

Am 16. Januar 2024 23:13:22 MEZ schrieb Rolf Turner :
>
>In a package that I am updating, I have a data documentation file
>monoCyteSim.Rd.  In this file, two data sets are documented: bivarSim
>and ccSim.  The usage section is;
>
>> \usage{
>> bivarSim
>> ccSim
>> }
>
>Since the data are lazy-loaded I *don't* wrap the names of the data
>sets in "data()".
>
>I do this in another data documentation file (SydColDat.Rd) without
>problem. However when I check the package using --as-cran I get a
>warning:
>
>> * checking for code/documentation mismatches ... WARNING
>> Variables with usage in documentation object 'monoCyteSim' but not in
>> code: ‘bivarSim’ ‘ccSim’
>
>No such warning seems to arise in respect of SydColDat.Rd.
>
>Can anyone explain what is going on, and what if anything I can do
>about it?  I would be grateful for any insight.
>
>I have attached the two help files, the one that triggers the
>warning and the one that doesn't.  I have changed the extension from
>.Rd to .txt so that (I hope!) the mailer doesn't strip them away.
>
>The complete package, as it currently stands (if this is of any
>interest), is available from my web page:
>
>https://www.stat.auckland.ac.nz/~rolf/
>
>Scroll to near the bottom and click on "Eglhmm".
>
>Thanks.
>
>cheers,
>
>Rolf Turner
>

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

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

[Sebastian Meyer]

This is a known issue already reported to the Rdpack maintainer. In some 
cases, the Rd code generated by Rdpack's macros contains unnecessary 
braces that trigger the check note because they match the pattern 
"text{text}" that detects common mistakes like "code{x}" (missing an 
escape for the macro name).


Rdpack's fork of tools::deparseLatex() is being updated to drop the 
braces that cause the note. I have modified the check code to ignore 
these cases for now (r85491).


Best regards,

    Sebastian Meyer


Am 07.11.23 um 17:13 schrieb Martin Becker:

Dear developers,

while preparing to submit a package to CRAN, I noticed that a check for
lost braces in Rd files (which is enabled in the current r-devel when
checking with the '--as-cran' option) seems to return false positives.

More specifically, a 'Lost braces' NOTE is issued (at least sometimes)
when using the \insertRef{...}{...} command from the Rdpack package.

Since the corresponding changes in r-devel seem to be quite recent
(apparently as of r85196), I hope this sketchy report is sufficient to
track down the problem. If not, I will try to create a reproducible example.

Best regards and many thanks,
Martin




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

Re: [R-pkg-devel] A replacement idiom for \value{\item{\var{...}}{}}

[Sebastian Meyer]

Am 10.07.23 um 16:30 schrieb Ivan Krylov:

Hello R-package-devel,

I've got a function that returns a data.frame. The columns (and their
names) of the return value are parametrised by the arguments of the
function. See, for example, the following function:

foo <- function(n = 10, out.M = c(2, 3, 5))
  as.data.frame(setNames(
   lapply(out.M, \(M) M * runif(n)),
   paste0('fooval.', out.M)
  ))

If I call it as foo(out.M = 1), I get a data.frame containing a column
named fooval.1. If I call it as foo(), I get columns fooval.2,
fooval.3, and fooval.5 instead.

I would like to document this relationship between the arguments and
the output value like so:

\arguments{
  \item{out.M}{Return the foo vectors for every M value given here.}
  % more arguments that behave in a similar manner
}
% ...
\value{
  A \code{data.frame} containing the following columns:

  \item{fooval.\var{m}}{
   The foo values, for every \var{m} in \code{out.M}.
  }
  % more parametrised output columns to follow
}

It turns out that \value{} description lists now escape their \item{}
arguments, preventing me from using \var{} markup there, but only in
plain text and HTML outputs. I think that the change occurred in the
last year or so; old versions of R process markup in \item{} arguments
even in \value{} description lists, but they have other Rd problems. I
understand the motivation of the change: in \arguments{} and \value{}
environments, it makes sense to typeset \item{} headings as \code{}.


Thank you for the report. AFAICS, this only affects HTML conversion in R 
>= 4.3.0. It is an "internally" known limitation (see corresponding 
source code comment in Rd2HTML).


OTOH, WRE does not clearly specify that \item labels in \arguments or 
\value could actually contain any markup. That said, the referenced 
"Parsing Rd files" document 
(<https://developer.r-project.org/parseRd.pdf>) does tell us that 
\item{}{} arguments are parsed as LaTeX-like text, \dots probably being 
the most common example.




Should I try to fix Rd2latex (or at least file a ticket) to escape the
\item{...} arguments in \value{} (but not \describe{}!) environments
too?


Yes, I think this belongs to "R-devel" and a problem report in Bugzilla 
would be useful; the problem being that Rd markup in \item labels is 
handled inconsistently by the Rd converters. It is currently unclear to 
me, however, which one is at fault here. Your example at least provides 
one (admittedly quiet special) use case for LaTeX-like content in an 
\item label of the \value section.




What would be a better Rd idiom for such function argument — output
component relationships?



I think a workaround that currently works for your use case is to use 
\code{fooval.\var{m}} as the label (i.e., wrapped inside \code).


Best regards,

Sebastian Meyer

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

Re: [Rd] numeric_version doesn't like numeric versions anymore?

[Sebastian Meyer]

Please see <https://bugs.r-project.org/show_bug.cgi?id=18548> for the 
background. The documentation has always said that the input needs to be 
a character vector. Implicit conversion of numeric input to character is 
affected by R options (OutDec and scipen), but it is also error-prone in 
this context:


R> package_version("1.3") > 1.20
[1] TRUE

This now warns for a good reason in my opinion.

Best regards,

    Sebastian Meyer


Am 06.07.23 um 08:37 schrieb Dipterix Wang:

Dear R devs,

I installed the recent devel R to test a package error when I intercept this 
warning when loading packages:

```
Warning in .make_numeric_version(x, strict, 
.standard_regexps()$valid_numeric_version) :
   invalid non-character version specification 'x' (type: double)
```

After a long debugging, I realize that `numeric_version` in base does not 
support numerical input x by default now.

A reproducible example:

R 4.4

```

numeric_version(1.5)

Warning in .make_numeric_version(x, strict, 
.standard_regexps()$valid_numeric_version) :
   invalid non-character version specification 'x' (type: double)
[1] ‘1.5’
```


R 4.3.1

```

numeric_version(1.5)

[1] ‘1.5’
```

According to help document, `strict=TRUE` should result in errors, then the 4.3 
behavior was actually incorrect. According to pkgload maintainer, Kurt has sent 
him an email to fix this, suggesting this on-going change is intentional.
  
May I ask is there any benefit of changing the behavior?


Thanks,
- D
[[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] Strange error in R CMD check --timings

[Sebastian Meyer]

Am 02.07.23 um 18:01 schrieb Duncan Murdoch:

This SO post: https://stackoverflow.com/q/76583828 describes a strange R
CMD check error.  Depending on the contents of a comment in one of the
examples sections of a help page, an error like this could be triggered:

> base::assign(".dptime", (proc.time() - get(".ptime", pos =
"CheckExEnv")), pos = "CheckExEnv")
> base::cat("read_net", base::get(".format_ptime", pos =
'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n",
file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
> ### * 
> ###
> cleanEx()
> options(digits = 7L)
> base::cat("Time elapsed: ", proc.time() - base::g
+ Error: unexpected end of input
Execution halted

The code without the offending comment is available here:

https://github.com/rob-ward-psych/iac

at revision c2f3529.  To add the offending comment, change line 318 of
R/iac_networks.R to

#' # Ken is a burglar in the Sharks, what is retrieved from his name

and run roxygen on the package, so the long comment ends up in the
examples section of man/read_net.Rd instead of the empty comment that is
there on Github.

At first it appeared to require devtools::check(), but in fact the error
comes from R CMD check --timings .  One thing that may be related is
that an earlier example had this code:

file.edit(iac_example("what_where.yaml"))


I could reproduce the check error on Ubuntu for some settings of EDITOR.

- For EDITOR="nano", the output below file.edit() in iac-Ex.Rout showed 
content from the first few lines of the yaml file and then

Too many errors from stdin

- For EDITOR="vi", iac-Ex.Rout showed
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal
Press ENTER or type command to continue
... some content from the yaml file ...
Vim: Error reading input, exiting...

OTOH,
EDITOR="nonexistent" resulted in a successful check run with file.edit() 
output

sh: 1: nonexistent: not found
Warning: error in running command

whereas EDITOR="emacs" would open the GUI while "* checking examples 
...", waiting for me to finish editing.


I agree that the package should conditionalize a [file.]edit() example 
on the R session being interactive(). I'm wondering, however, whether R 
CMD check should itself generally set the "editor" option to a read-only 
variant, e.g., a function that just calls file.show() with a warning 
when it runs the (massaged) examples. For related reasons, I guess, it 
already sets the "pager" option on Windows to "console". Alternatively, 
if the massaged "editor" option called stop() (similar to T and F 
producing errors), such examples would really need to be conditioned on 
interactive().


Sebastian Meyer



If that line is skipped (by conditioning on interactive()), the error
goes away.  But this might be unrelated, since deleting that comment
also makes the error go away.

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

Re: [Rd] restoring LANGUAGE env variable within an R session

[Sebastian Meyer]

Translated strings are cached.
I'd recommend to use the

• New partly experimental Sys.setLanguage() utility, solving the
  main problem of PR#18055.

introduced in R 4.2.0.

Best,

Sebastian Meyer


Am 26.06.23 um 15:15 schrieb Ben Bolker:

I was playing around with the setting of the LANGUAGE variable and am
wondering whether I'm missing something obvious about resetting the
value to its original state once it's been set.  I seem to be able to
reset the language for warnings/errors once, but not to change it a
second time (or reset it) once it's been set ... ??

## default (no LANGUAGE set, English locale)
  > sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced
## no complaints, doesn't change (as expected)
  > Sys.setenv(LANGUAGE = "en")
  > sqrt(-1)
[1] NaN
Warning message:
In sqrt(-1) : NaNs produced

## change to German
  > Sys.setenv(LANGUAGE = "de")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## try to change to Spanish - no luck
## (this does work in a clean session)

  > Sys.setenv(LANGUAGE = "es")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## try resetting to blank
  > Sys.setenv(LANGUAGE = "")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt

## or back to English explicitly?
  > Sys.setenv(LANGUAGE = "en")
  > sqrt(-1)
[1] NaN
Warnmeldung:
In sqrt(-1) : NaNs wurden erzeugt
  >

__
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] transform.data.frame() ignores unnamed arguments when no named argument is provided

[Sebastian Meyer]

Note that ?transform.data.frame says arguments need to be named, so you 
are testing unspecified behaviour. I guess this falls in a similar 
category as the note


 If some of the values are not vectors of the appropriate length,
 you deserve whatever you get!

Experiments for a related Problem Report 
(<https://bugs.r-project.org/show_bug.cgi?id=17890>) showed that 
packages bravely ignore the caveats mentioned on the help page, 
including to assume recycling the rows of the input data frame. I didn't 
yet see any uses of unnamed arguments, though.


That said, I agree that transform.data.frame() should be improved. Maybe 
unnamed arguments should always be ignored with a warning. My feeling is 
that these would more often be usage errors than intentional, e.g.:


> data.frame(a = 1) |> transform(b = 2, a + 2)  # "forgetting" a=
  a b X3
1 1 2  3

I also think the implicit check.names=TRUE behaviour should be disabled. In

> list2DF(list(`A-1` = 1)) |> transform(B = 2)
  A.1 B
1   1 2

transforming B should not touch the other columns.

I'm less sure about some other forms of undocumented behaviour as 
described in Comment 6 of the linked PR.


Sebastian Meyer


Am 02.03.23 um 18:49 schrieb Antoine Fabri:

Dear r-devel,

See below:


transform(data.frame(a = 1), 2, 3)

#>   a

#> 1 1


transform(data.frame(a = 1), b=2, 3)

#>   a b X3

#> 1 1 2  3


We need a small modification to make it work consistently, see below:


transform.data.frame <- function (`_data`, ...) {

   e <- eval(substitute(list(...)), `_data`, parent.frame())

   tags <- names(e)

   ## NEW LINE ---

   if (is.null(tags)) tags <- character(length(e))

   inx <- match(tags, names(`_data`))

   matched <- !is.na(inx)

   if (any(matched)) {

 `_data`[inx[matched]] <- e[matched]

 `_data` <- data.frame(`_data`)

   }

   if (!all(matched))

 do.call("data.frame", c(list(`_data`), e[!matched]))

   else `_data`

}


transform(data.frame(a = 1), 2, 3)

#>   a X2 X3

#> 1 1  2  3

transform(data.frame(a = 1), b=2, 3)

#>   a b X3

#> 1 1 2  3


Thanks,


Antoine

[[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] Documentation bug?

[Sebastian Meyer]

Thanks. The note is indeed outdated since at least R 2.9.0 with NEWS

o   predict.lm() now works correctly when the fit had more than
one offset (possibly specified both in the formula and as an
argument).  This function is called by predict.glm(), so the
same isses are corrected there.

It has now been removed from ?lm in r83832 in the trunk (ported to 
R-patched).


Sebastian Meyer


Am 14.02.23 um 09:31 schrieb GILLIBERT, Andre via R-devel:

Dead R developers,

In R-devel  2023-02-11 and older R versions, there is a note in the "lm 
{stats}" help page specifying that:

Offsets specified by offset will not be included in predictions by 
predict.lm<http://127.0.0.1:12534/library/stats/help/predict.lm>, whereas those 
specified by an offset term in the formula will be.


However, the source code as well as basic tests seem to show that both types of 
offset terms are always used in predictions.
a<-data.frame(off=1:4, outcome=4:1)
mod<-lm(data=a, outcome~1, offset=off)
coef(a) # intercept is zero
predict(mod) # returns 1:4, which uses offset
predict(mod, newdata=data.frame(off=c(3,2,5))) # returns c(3,2,5) which uses 
the new offset

When looking at the history of R source code, this note seems to exist from R 
1.0.0 while the source code of predict.lm already called 
eval(object$call$offset, newdata)
https://github.com/SurajGupta/r-source/blob/1.0.0/src/library/base/R/lm.R
https://github.com/SurajGupta/r-source/blob/1.0.0/src/library/base/man/lm.Rd

Version 0.99.0 did not contain the note, but already had the call to 
eval(object$call$offset, newdata)
https://github.com/SurajGupta/r-source/blob/0.99.0/src/library/base/man/lm.Rd
https://github.com/SurajGupta/r-source/blob/0.99.0/src/library/base/R/lm.R

The actual behavior of R seems to be sane to me, but unless I miss something, 
this looks like a documentation bug.
It seems to have bugged someone before:
https://stackoverflow.com/questions/71264495/why-is-predict-not-ignoring-my-offset-from-a-poisson-model-in-r-no-matter-how-i

Digging deeper in R history, it seems that this note was also found in "glm {stats}" in R 
1.0.0 but was removed in R 1.4.1. Maybe somebody forgot to remove it in "lm {stats}" too.

--
Sincerely
Andr� GILLIBERT

[[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] R2HTML doesn't split paragraphs originating from \Sexpr[results=rd]

[Sebastian Meyer]

I can confirm this is a bug, more specifically, a regression in R >= 
3.6.0. I think a report in R's Bugzilla would be useful.


A possible workaround seems to be to start the Rd-generating \Sexpr in 
column 1 of the Rd file, so to remove the indentation before \Sexpr.


AFAICS, fixing this will require tools:::processRdChunk() to keep two 
types of source references for dynamically generated Rd code: the 
effective "srcref" from parsing the Rd fragment, and the one that refers 
to the source Sexpr block (possibly called "wholeSrcref"), to be used by 
checkRd() in preference to "srcref" when reporting the location of Rd 
problems.


Sebastian Meyer


Am 05.02.23 um 14:04 schrieb Ivan Krylov:

Hello,

Here's an example that renders correctly using Rd2txt / Rd2latex / R
CMD Rd2pdf, but has problems under Rd2HTML:

\name{foo}
\title{foo}
\section{foo}{
   This should be on a separate paragraph

   This should be on a separate paragraph

   This should be on a separate paragraph

   \Sexpr[stage=render,results=rd]{
 paste(
   rep('Sexpr: This should be on a separate paragraph', 3),
   collapse = '\n\n'
 )
   }
}

For the text I've typed manually, there are ... tags splitting
the text separated by empty lines into paragraphs. The \Sexpr return
value only has newlines, which joints the paragraphs together:

This should be on a separate paragraph

This should be on a separate paragraph

This should be on a separate paragraph

Sexpr: This should be on a separate paragraph

Sexpr: This should be on a separate paragraph

Sexpr: This should be on a separate paragraph


addParaBreaks() is prevented from closing the paragraph tag because
tools:::isBlankLineRd() returns FALSE for blank lines produced by a
\Sexpr. This happens because utils:::getSrcByte() not 1 for these blank
lines. That, in turn, is because the source reference for \Sexpr values
is the whole \Sexpr tag:

# blank line from a \Sexpr
Rd[[3]][[2]][[9]][[2]]
# [1] "\n"
# attr(,"Rd_tag")
# [1] "TEXT"
getSrcref(Rd[[3]][[2]][[9]][[2]])
# \Sexpr[stage=render,results=rd]{
#   paste(
# rep('Sexpr: This should be on a separate paragraph', 3),
# collapse = '\n\n'
#   )
# }

# artisanal hand-crafted blank line
Rd[[3]][[2]][[7]]
# [1] "\n"
# attr(,"Rd_tag")
# [1] "TEXT"
summary(getSrcref(Rd[[3]][[2]][[7]]))
# 

I think I understand that tools:::isBlankLineRd requires
utils:::getSrcByte(x) == 1L because it may be called on things like
"\\eqn{0}\n" where the terminal "\n" might otherwise be considered a
"blank line". How to reconcile isBlankLineRd with blank lines not
directly originating from Rd source?

Rd2latex might have a similar problem (its addParaBreaks() checks for
isBlankLineRd()), but then it works anyway because Rd rules for
paragraph breaks on blank lines are the same as in LaTeX.



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

Re: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack

[Sebastian Meyer]

Am 10.01.23 um 21:28 schrieb Duncan Murdoch:

On 10/01/2023 2:05 p.m., Ivan Krylov wrote:

On Tue, 10 Jan 2023 16:27:53 +
RICHET Yann  wrote:


In facts, 10 threads are asked by armadillo for some LinAlg, which
backs to two threads as warned.


I think you're right about your tests de-facto using two threads, but
it might be a good idea to _default_ to up to two threads in tests and
examples. This is especially valuable for third-party developers who
have to mass-test packages (one of which could be rlibkriging) in
parallel.


- is there any reason that could explain that fedora-*-devel is so
slow for this package or compilation of Rcpp/testthat ?


Compilation time is definitely not the reason. Something in tests/*
actually runs for 30 minutes by itself.


- is there any chance that I can get a deeper log of what happened ?


If you split your tests into separate files under tests/*.R instead of
using a single tests/testthat.R calling the rest of the tests, R will
be able to show you the individual test file that hung and maybe the
line where it happened. (Also, you'll get per-file timing.) But that
is potentially a huge investment: you may have to rewrite the tests to
work outside the testthat harness, and you'd also have to prepare
another CRAN submission just to have those tests run. It's also against
CRAN policy to knowingly submit a package with unfixed ERRORs.

(Currently, R can only tell you that the tests hung in the
test_check('rlibkriging') call in the tests/testthat.R, which isn't
precise enough.)


You can specify a different "reporter" in the test_check() call, and it 
will print more useful information.  I don't think there's a perfect 
one, but


   test_check('rlibkriging', reporter = "progress")

should at least show you the tests that finished running before the 
timeout.  


I had similar problems with testthat and timeouts when mass-checking 
packages on patched R versions. My notes say



## testthat's 'LocationReporter' does cat() after each expectation
## so we can see results even if timeout is reached
options(testthat.default_check_reporter = c("Location", "Check"))


The help("LocationReporter") says: "This reporter simply prints the 
location of every expectation and error. This is useful if you're trying 
to figure out the source of a segfault, or you want to figure out which 
code triggers a C/C++ breakpoint"


HTH!

Sebastian Meyer

You could possibly also write your own custom reporter that 
could give timings for each of the tests as they run, but the documents 
for how to do that don't seem to exist.  Maybe someone else has done it?


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

Re: [R-pkg-devel] debugging remote vignette build failure

[Sebastian Meyer]

Am 14.03.22 um 11:32 schrieb Duncan Murdoch:

On 13/03/2022 8:11 p.m., Ben Bolker wrote:

    After switching some vignette elements of the form

https://doi.org/10.1214/09-AOAS306

to

\doi{10.1214/09-AOAS306}

    in the glmmTMB package,

GitHub Actions under Ubuntu 20.04 is throwing an error of the form

Running 'texi2dvi' on 'glmmTMB.tex' failed.
LaTeX errors:
! Undefined control sequence.
l.172 doi:\nobreakspace{}\Rhref
{[https://doi.org/10.32614/RJ-2017-066}{10.326...](https://doi.org/10.32614/RJ-2017-066%7D%7B10.326...) 


The control sequence at the end of the top line
of your error message was never \def'ed. If you have


 This does **not** happen with rhub::check_on_ubuntu, which tests
with R-release under Ubuntu Linux 20.04.1 LTS

 It would be nice to fix our GH Actions workflow.  Has anyone seen
this before/have suggestions for where to start looking for problems?


Are you sure this is coming from a vignette?  It looks like it would be 
from an Rd file or DESCRIPTION:


The \Rhref macro is defined in Rd.sty.  There's a LaTeX \doi macro in 
jss.cls, but it doesn't use \Rhref.  On the other hand, the automatic 
conversion of the DESCRIPTION file uses it in the 
tools:::.DESCRIPTION_to_latex function.




I think this comes from the glmmTMB vignette doing


print(citation("glmmTMB"),style="latex")


which produces LaTeX code via Rd2latex(). This uses Rd's \Rhref, 
wrapping either \href from hyperref.sty, or, as a fallback, \url from 
url.sty. In addition, the default tools::bibstyle() will also output the 
volume number in \bold, another LaTeX command from Rd.sty.


I can see the vignette already accounts for \bold via


%% need this for output of citation() below ...
\newcommand{\bold}[1]{\textbf{#1}}


To fix the missing \Rhref definition you could similarly do

\NewCommandCopy\Rhref\href

after including hyperref (\NewCommandCopy needs LaTeX >= 2020-10-01).

Best,

Sebastian

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

Re: [R-pkg-devel] Failing Valgrind Passing R CMD check

[Sebastian Meyer]

Am 08.03.22 um 17:23 schrieb Dirk Eddelbuettel:


On 8 March 2022 at 18:46, Ivan Krylov wrote:
| On Sun, 6 Mar 2022 11:00:43 -0600
| Dirk Eddelbuettel  wrote:
|
| > ==1485886== LEAK SUMMARY:
| > ==1485886==definitely lost: 32 bytes in 1 blocks
|
| > ==1485886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0
| > from 0)
|
| R CMD check only looks at the exit code of the process.
|
| Valgrind crashes the process on invalid memory access, but doesn't
| consider leaks to be errors, unless you turn on --leak-check=full, and

That is a related problem I did not stress. We can pass debugger arguments to
the debugger used (here: valgrind) when we call R, but we cannot for R CMD 
check.
That should be added.


Not an expert here, but that does seem to be possible, according to WRE 
(Section 4.3.2):



It is possible to run all the examples, tests and vignettes covered by R CMD 
check under valgrind by using the option --use-valgrind. If you do this you 
will need to select the valgrind options some other way, for example by having 
a ~/.valgrindrc file containing

--leak-check=full
--track-origins=yes

or setting the environment variable VALGRIND_OPTS. As from R 4.2.0, --use-valgrind also uses valgrind when re-building the vignettes. 


Best,

Sebastian



| even then still returns the exit code of the child process by default,
| i.e. zero:
|
| $ cat leak.c
| #include 
|
| int main(void) {
| malloc(42);
| return 0;
| }
| $ cc -o leak -g -O0 leak.c
| $ valgrind ./leak; echo exitcode=$?
| ...
| ==14675==definitely lost: 42 bytes in 1 blocks
| ...
| ==14675== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
| exitcode=0
| $ valgrind --leak-check=full ./leak; echo exitcode=$?
| ...
|
| ==14688==definitely lost: 42 bytes in 1 blocks
| ...
| ==14688== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
| exitcode=0
| $ valgrind --leak-check=full --error-exitcode=42 ./leak; \
|  echo exitcode=$?
| ...
| ==14729==definitely lost: 42 bytes in 1 blocks
| ...
| ==14729== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
| exitcode=42
|
| R CMD check could be patched to run
| R -d 'valgrind --leak-check=full --error-exitcode=255' instead of just
| R -d valgrind to produce warnings on Valgrind-detected leaks.
|
| The problem with this approach is the need for Valgrind suppression
| files. I've run an interactive example of a pure R package under R -d
| 'valgrind --leak-check=full --error-exitcode=255' (a relatively fresh
| SVN build) and got "definitely lost: 15,744 bytes in 41 blocks", mostly
| in plot-related code, allocations originating in Pango and GObject.

I have setup a CI setting using valgrind via R CMD check (and hence lacking
'--leak-check=full' though one could add a wrapper...) and it is a little
frustrating to not have it fail.

But of course it looks like it is a missing feature and we all could work
towards adding it.  All always that would require cooperation by R Core.

Dirk



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

Re: [R-pkg-devel] R package not passing automatic checks

[Sebastian Meyer]

Am 16.12.21 um 15:22 schrieb Lucas Godoy:

Hello everyone,

I'm trying to submit an R package to CRAN. First of all, when I ran "R CMD
check --as-cran" or "devtools::check()" locally I get no notes, warnings,
or errors at all. The same is valid for CI using Github Actions. However,
when I submit the package to CRAN, I get the following message
---

* using log directory 'd:/RCompile/CRANincoming/R-devel/smile.Rcheck'
* using R Under development (unstable) (2021-12-15 r81383 ucrt)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: UTF-8
* checking for file 'smile/DESCRIPTION' ... OK
* this is package 'smile' version '1.0.0'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Lucas da Cunha Godoy '

Status: 1 NOTE
---

I am clueless about what this NOTE means and have no idea on how to fix it.

Any suggestions?


The "maintainer" line is no issue. But have you looked closely at the 
remaining part of the CRAN incoming check that you have snipped ("") 
in the above copy? Sometimes there are


Possibly misspelled words in DESCRIPTION:

which you need to fix or quote as appropriate (see 
https://CRAN.R-project.org/web/packages/submission_checklist.html), or 
explain that the listed words were wrongly flagged (if that is the case, 
by replying to the auto-check e-mail).


Best regards,

Sebastian Meyer



Thank you in advance,

Lucas.

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

[Sebastian Meyer]

Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:

Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

https://cran.r-project.org/web/checks/check_results_string2path.html

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

 available_fonts <- systemfonts::system_fonts()$path

 # string2path supports only TrueType or OpenType formats
 ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$", available_fonts)]



This would be an empty character vector on my Alpine Linux server as 
well. The system_fonts() there only contain ".pcf.gz" files from 
"/usr/share/fonts/misc/".


Note that the "systemfonts" package on which you rely currently also 
fails on that CRAN check flavour for a similar reason 
(https://cran.r-project.org/web/checks/check_results_systemfonts.html).
On my Alpine Linux system, from example("register_font", 
package="systemfonts"):


fonts <- system_fonts()
plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
##   invalid first argument

(as there are no italic fonts).

HTH,

Sebastian Meyer


I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

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



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

Re: [Rd] Dropping RHS of a formula using NULL assignment

[Sebastian Meyer]

Am 14.12.21 um 21:57 schrieb Prof Brian Ripley:

On 14/12/2021 20:26, Blackwell, Matthew wrote:

Hello all,

In attempting to create a one-sided formula from a two-sided formula,
I discovered that the following syntax will successfully complete this
operation:


f <- y ~ x + z
f[2] <- NULL
f

~x + z

str(f)

Class 'formula'  language ~x + z
   ..- attr(*, ".Environment")=

In searching through the formula documentation, I couldn't find this
technique as documented and wondered whether or not it is expected and
if it makes sense to develop a package against the behavior. I'm using
R 4.1.0, but I see the same on R-devel (r81303). I asked on Twitter,
but someone thought this list might be a better venue.

Apologies if I missed some documentation and thanks in advance.


See ?"~", which says

  A formula has mode ‘call’.  It can be subsetted by ‘[[’: the
  components are ‘~’, the left-hand side (if present) and the
  right-hand side _in that order_.

That would suggest that

f <- y ~ x + z
f[[2]] <- NULL

was the documented way (and the one I would have used).   


I'd also mention delete.response() here. It takes a "terms" object (a 
formula with attributes) and uses the same technique internally to 
remove the response -- if there is one... I.e., be sure that 
length(f)==3 before dropping the second element.


Best regards,

Sebastian Meyer

However, ?"[" 
says


  ‘[’ and ‘[[’ are sometimes applied to other recursive objects such
  as calls and expressions.  Pairlists are coerced to lists for
  extraction by ‘[’, but all three operators can be used for
  replacement.




Cheers,
Matt

~~
Matthew Blackwell
Associate Professor of Government
Harvard University
https://www.mattblackwell.org




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

Re: [Rd] How is the environment variable "R_USER" defined?

[Sebastian Meyer]

Just a quick thought.
R for Windows FAQ 2.14 talks about the home directory:

https://cran.r-project.org/bin/windows/base/rw-FAQ.html#What-are-HOME-and-working-directories_003f

So maybe HOMEDRIVE and HOMEPATH are involved?

Hope this helps.

Sebastian Meyer


Am 22.11.21 um 17:46 schrieb Jiefei Wang:

Hi, I have a new win system and try to install R as usual. Somehow,
the environment variable "R_LIBS_USER" is incorrectly pointed to a
Onedrive folder. Since "R_LIBS_USER" depends on "R_USER", the root
problem then becomes why "R_USER" is the path to the Onedrive. I did
an exhausting search in the R directory and the only related message I
can find is from EnvVar.html, which states

R_USER: The user's ‘home’ directory. Set by R. (HOME will be set to
the same value if not already set.)

I guess that's another way to say "no document is available yet". I
also took a look at my system environment variables but there are only
two variables related to Onedrive, they are

OneDrive=C:\Users\wangj\OneDrive

OneDriveConsumer=C:\Users\wangj\OneDrive

so everything looks pretty normal, I know I can correct this issue by
manually adding Renviron but I just wonder where this default behavior
comes from...

Best,
Jiefei

__
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] Bug (?) in vignette handling

[Sebastian Meyer]

Am 30.10.21 um 20:28 schrieb Duncan Murdoch:

On 29/10/2021 5:52 a.m., Martin Maechler wrote:

Duncan Murdoch
 on Thu, 28 Oct 2021 13:18:54 -0400 writes:


 > This StackOverflow post:  
https://stackoverflow.com/q/69756236/2554330
 > points out that objects created in one vignette are available 
in a later
 > vignette.  I don't think this should be happening:  vignettes 
should be

 > self-contained.

I strongly agree.

 > The current answer there, 
https://stackoverflow.com/a/69758025/2554330,
 > suggests that "R CMD check" will detect this.  However, 
sometimes one
 > vignette can replace a standard function with a custom version, 
and then
 > both will work without generating an error, but the second 
vignette

 > won't do the same thing if run independently.

 > For example, try these pure Sweave vignettes:

 > -
 > aaa3.Rnw:
 > -
 > \documentclass{article}
 > %\VignetteIndexEntry{Sweave aaa3}
 > \begin{document}

 > <<>>=
 > mean <- function(x) "I am the Sweave mean"
 > @

 > \end{document}

 > 
 > aaa4.Rnw:
 > 

 > \documentclass{article}
 > %\VignetteIndexEntry{Sweave aaa4}
 > \begin{document}

 > <<>>=
 > mean(1:5)
 > @

 > \end{document}

 > Put these in a package, build and install the package, and 
you'll see

 > that the mean() function in aaa4.Rnw prints the result from the
 > redefined mean in aaa3.Rnw.

Is it because R is *not* run with  --no-save --no-restore
accidentally?
Without looking, I would not expect that the vignettes are run
inside the same running R (even though that may speedup things)



I think for R CMD build they are run in one process, while for R CMD 
check they are in separate processes.  R CMD build runs 
tools::buildVignettes(), which runs code that's part of the vignette 
build engine.


Thankfully R CMD check has been building the vignettes in separate R 
processes already since R 3.6.0, so has hopefully identified most 
problems until now. The corresponding env var is 
_R_CHECK_BUILD_VIGNETTES_SEPARATELY_.


The standard (and exported!) buildVignettes() has been weaving all 
vignettes in the same session ever since it was added back in 2002. This 
approach is probably more efficient (avoiding repetitive package 
loading), but carry-over effects seem both likely and undesirable 
(thinking of vignettes as separate and independently reproducible 
manuscripts about different aspects of a package). AFAICS, it is not 
explicitly documented that buildVignettes() runs all vignettes in the 
same R session, so at least this is no advertised feature.


The Sweave engine evaluates things in .GlobalEnv, so any leftover 
objects will be visible there for the next vignette.  I think it's up to 
the writer of each vignette engine whether there's any cleanup, but it 
appears that neither Sweave nor knitr does any.


I think this is by design and also useful in interactive sessions to 
investigate the environment after weaving.


One possible fix would be for buildVignettes() to make a snapshot of 
what's in .GlobalEnv before processing any vignettes, and restoring it 
after each one.  I've tried a weaker version of this:  it records the 
names in .GlobalEnv at the start, and deletes anything new before 
processing each vignette.  So vignettes could modify or delete what's 
there, but not add anything.


I think you don't want to completely clear out .GlobalEnv, because 
people might choose to run buildVignettes() in an R session and expect 
the vignettes to see the contents there.


"make check" in R-devel doesn't complain about this change, but I'll let 
R Core decide whether it's a good idea or not.  A patch is below.


Clearing the workspace would be an improvement, but I think it would be 
even better for R CMD build to produce each vignette in a clean R 
session, especially with regard to loaded packages. Changing 
buildVignettes() to use clean R processes by default (I'd say even if 
there is only one vignette) should be considered. I'd appreciate seeing 
this report in Bugzilla to investigate further (and not forget).


Best regards,

   Sebastian Meyer




Duncan Murdoch

Index: src/library/tools/R/Vignettes.R
===
--- src/library/tools/R/Vignettes.R    (revision 81110)
+++ src/library/tools/R/Vignettes.R    (working copy)
@@ -560,7 +560,11 @@
  sourceList <- list()
  startdir <- getwd()
  fails <- character()
+    # People may build vignettes from a session and expect
+    # to see some variables, so we won't delete these
+    existingVars <- ls(.GlobalEnv, all = TRUE)
  for(i in seq_along(vig

Re: [Rd] Environment setting _R_CHECK_DEPENDS_ONLY_='true'

[Sebastian Meyer]

(this should have been posted to R-package-devel, not R-devel)

Am 20.10.21 um 00:17 schrieb John Maindonald via R-devel:

Setting
Sys,setenv('_R_CHECK_DEPENDS_ONLY_'=‘true’)
or Sys,setenv('_R_CHECK_DEPENDS_ONLY_’=TRUE)

(either appear to be acceptable) appears to have no effect when I do, e.g.


If you set the environment variable inside a running R process, it will 
only affect that process and child processes, but not an independent R 
process launched from a shell like you seem to be doing here:




$R CMD check qra_0.2.4.tar.gz
* using log directory ‘/Users/johnm1/pkgs/qra.Rcheck’
* using R version 4.1.1 (2021-08-10)
* using platform: x86_64-apple-darwin17.0 (64-bit)
* using session charset: UTF-8
. . .

(This should have failed.)


How to set environment variables is system-specific. On a Unix-like 
system, you could use the command


_R_CHECK_DEPENDS_ONLY_=true  R CMD check qra_0.2.4.tar.gz

to set the environment variable for this R process.
See, e.g., https://en.wikipedia.org/wiki/Environment_variable.

Best regards,

Sebastian Meyer




I’d have expected that the "On most systems . . .” mentioned in the Writing R 
extensions
manual (1.1.3.1 Suggested packages) would include my setup.

Any insight on what I am missing will be welcome.

John Maindonald email: john.maindon...@anu.edu.au




__
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] R 4.1.x make check fails, stats-Ex.R, step factor reduced below minFactor

[Sebastian Meyer]

For what it's worth, make check runs OK for me with sessionInfo()

R version 4.1.1 Patched (2021-09-30 r80997)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.6 LTS

Matrix products: default
BLAS:   /home/smeyer/R/base/release/build/lib/libRblas.so
LAPACK: /home/smeyer/R/base/release/build/lib/libRlapack.so

The output of these examples is:


try(nlm1 <- update(nlmod, control = list(tol = 1e-7))) # where central diff. 
work here:

Warning in nls(formula = y ~ Const + A * exp(B * x), algorithm = "default",  :
  No starting values specified for some parameters.
Initializing ‘Const’, ‘A’, ‘B’ to '1.'.
Consider specifying 'start' or using a selfStart model
Error in nls(formula = y ~ Const + A * exp(B * x), algorithm = "default",  : 
  step factor 0.000488281 reduced below 'minFactor' of 0.000976562

   (nlm2 <- update(nlmod, control = list(tol = 8e-8, nDcentral=TRUE), 
trace=TRUE))

Warning in nls(formula = y ~ Const + A * exp(B * x), algorithm = "default",  :
  No starting values specified for some parameters.
Initializing ‘Const’, ‘A’, ‘B’ to '1.'.
Consider specifying 'start' or using a selfStart model
1017460.306(4.15e+02): par = (1 1 1)
758164.7503(2.34e+02): par = (13.42031396 1.961485 0.05947543745)
269506.3537(3.23e+02): par = (51.75719817 -13.09155958 0.8428607712)
68969.21891(1.03e+02): par = (76.0006985 -1.93522675 1.0190858)
633.3672224(1.29e+00): par = (100.3761515 8.624648408 5.104490252)
151.4400170(9.39e+00): par = (100.6344391 4.913490999 0.2849209664)
53.08739445(7.24e+00): par = (100.6830407 6.899303393 0.4637755095)
1.344478582(5.97e-01): par = (100.0368306 9.897714144 0.5169294926)
0.9908415908   (1.55e-02): par = (100.0300625 9.9144191 0.5023516843)
0.9906046057   (1.84e-05): par = (100.0288724 9.916224018 0.5025207336)
0.9906046054   (9.94e-08): par = (100.028875 9.916228366 0.50252165)
0.9906046054   (5.00e-08): par = (100.028875 9.916228377 0.5025216525)
Nonlinear regression model
  model: y ~ Const + A * exp(B * x)
   data: parent.frame()
  Const   A   B 
100.0288750   9.9162284   0.5025217 
 residual sum-of-squares: 0.9906046


Running with example(nls) in an interactive session gives the extra output

Number of iterations to convergence: 11 
Achieved convergence tolerance: 4.996813e-08


(when the "show.nls.convergence" option is not set to FALSE. It is set 
to FALSE in SSasymp.Rd but not reset at the end.)


Best regards,

Sebastian


Am 01.10.21 um 11:01 schrieb Andrew Piskorski:

I recently built R 4.1.1 (Patched) from source, as I have many older
versions over the years.  This version, on Ubuntu 18.04.4 LTS:

   R 4.1.1 (Patched), 2021-09-21, svn.rev 80946, x86_64-pc-linux-gnu

Surprisingly, "make check" fails, which I don't recall seeing before.
The error is in from stats-Ex.R, which unfortunately terminates all
further testing!  This particular error, "step factor ... reduced
below 'minFactor'" does not seem very serious, but I can't figure out
why it's happening.

I installed with "make install install-tests" as usual, which seemed
to work fine.  Running the same tests after install, I'm able to get
more coverage by using errorsAreFatal=FALSE.  However, it seems the
rest of the 'stats' tests after the bad one still do not run.

I'm confused about the intent of this particular test.  The comment
above it seems to says that it's SUPPOSED to throw this error, yet
getting the error still terminates further testing, which seems
strange.  What's supposed to happen here?

Any ideas on why this error might be occurring, and how I should debug
it?  What's the right way for me to disable this one failing test, so
the ones after it can run?

Thanks for your help!


## "make check" output:
make[1]: Entering directory 
'/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
make[2]: Entering directory 
'/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
make[3]: Entering directory 
'/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests/Examples'
Testing examples for package 'base'
Testing examples for package 'tools'
   comparing 'tools-Ex.Rout' to 'tools-Ex.Rout.save' ... OK
Testing examples for package 'utils'
Testing examples for package 'grDevices'
   comparing 'grDevices-Ex.Rout' to 'grDevices-Ex.Rout.save' ... OK
Testing examples for package 'graphics'
   comparing 'graphics-Ex.Rout' to 'graphics-Ex.Rout.save' ... OK
Testing examples for package 'stats'
Error: testing 'stats' failed
Execution halted
Makefile:37: recipe for target 'test-Examples-Base' failed
make[3]: *** [test-Examples-Base] Error 1
make[3]: Leaving directory 
'/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests/Examples'
../../tests/Makefile.common:198: recipe for target 'test-Examples' failed
make[2]: *** [test-Examples] Error 2
make[2]: Leaving directory '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
../../tests/Makefile.common:184: recipe for target 'test-all-basics' failed
make[1]: *** [test-all-basics] Error 1
make[1]: Leaving 

Re: [R-pkg-devel] 'rlang' win-builder error for package without rlang dependency

[Sebastian Meyer]

Am 12.09.21 um 19:25 schrieb Konrad Rudolph:

Hi,

My recent CRAN package submission failed with a win-builder error during
the tests and vignette building *of the previously submitted version* [1]:

```
 Error in library.dynam(lib, package, package.lib) :
   DLL 'rlang' not found: maybe not installed for this architecture?
```

(The log also shows another testing error with the new version which I can
make neither heads nor tails of, but that’s a separate issue.)

My package does not directly depend on 'rlang' (though it is a transitive
'Suggests' (build time) dependency via 'testthat'). I’m at a loss how to
fix this issue. The closest I could find was [2], where the error is caused
by tests being run for a mismatching architecture. In my case, the error
seems to be caused by 'testthat' not being able to load the rlang DLL for
x64 (weirdly the tests run to completion for the [mismatching] i386
architecture). Given that I don’t control (a) which architecture is tested
on win-builder, nor (b) how 'testthat' loads its dependencies, how can I
fix this?

… or was this error included in the win-builder output of the new
submission as a simple FYI and can be safely ignored?


Yes, the current CRAN status of the package is appended just FYI / for 
comparison.


These appended check results in the Debian pre-test output regularly 
confuse package developers. I am suggesting (to R-core) to simply add 
more empty lines before "current CRAN status" and maybe it should also 
say something like "(for comparison)" to clarify that these results are 
not the reason for the failure of the automatic pretest.


Best regards,

    Sebastian Meyer



[1]
https://win-builder.r-project.org/incoming_pretest/box_1.0.3_20210912_125241/Debian/00check.log
[2] https://github.com/r-hub/rhub/issues/476

--
Konrad Rudolph // @klmr

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] FW: [EXTERNAL] [CRAN-pretest-archived] CRAN submission surfaltr 1.0.0.9000

[Sebastian Meyer]

Packages on CRAN can depend on released packages from both CRAN and 
Bioconductor.


I don't know why "msa" is missing on the Debian check machine. The check 
results of another CRAN package that suggests "msa" indicate that this 
package is currently unavailable on all Linux, Solaris and macOS 
machines of the CRAN check farm: 
https://cran.r-project.org/web/checks/check_results_bio3d.html


Maybe this is a temporary problem? You could try resubmitting in a few days.

I think you should remove the automatic package installation from your 
functions; they should not write to the user's home filespace without 
consent.

You should probably also avoid this NOTE when submitting to CRAN:

> Version contains large components (1.0.0.9000)

Best regards,

Sebastian Meyer


Am 16.08.21 um 17:37 schrieb Pooja Gangras via R-package-devel:

Hi all,

PFA the pre-check results for my package surfaltr from CRAN. I am having 
troubles with a package dependency on Debian that I am not able to fix. 2 
functions in my package require a Bioconductor package msa 
(https://bioconductor.org/packages/release/bioc/html/msa.html). To deal with 
this error, I tried the following solution of adding a call to BiocManager and 
also including a code for msa installation but it did not help:

#' @importFrom BiocManager install
#' @import msa
.
.
.
Foo() {
if (!requireNamespace("msa", quietly = TRUE)){
 BiocManager::install("msa")}
}

How do I solve the problem so that I don't generate this error with Debian?

Thank you,
Pooja


Pooja Gangras, Ph.D.
Postdoctoral Research Scientist - RNA Therapeutics
Eli Lilly and Company
Lilly Corporate Center, Indianapolis IN 46285 U.S.A.
Office phone number: (317) 651-0589
Cellphone number: (614) 906-0940
gangras_po...@lilly.com | www.lilly.com


CONFIDENTIALITY NOTICE: This email message (including all attachments) is for 
the sole use of the intended recipient(s) and may contain confidential 
information. Any unauthorized review, use, disclosure, copying or distribution 
is strictly prohibited. If you are not the intended recipient, please contact 
the sender by reply email and destroy all copies of the original message.

-Original Message-
From: lig...@statistik.tu-dortmund.de 
Sent: Monday, August 16, 2021 10:32 AM
To: Pooja Gangras 
Cc: cran-submissi...@r-project.org
Subject: [EXTERNAL] [CRAN-pretest-archived] CRAN submission surfaltr 1.0.0.9000

EXTERNAL EMAIL: Use caution before replying, clicking links, and opening 
attachments.

Dear maintainer,
  
package surfaltr_1.0.0.9000.tar.gz does not pass the incoming checks automatically, please see the following pre-tests:

Windows: 
<https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.9000_20210816_162209/Windows/00check.log>
Status: 1 NOTE
Debian: 
<https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.9000_20210816_162209/Debian/00check.log>
Status: 1 ERROR, 1 NOTE
  

  
Please fix all problems and resubmit a fixed version via the webform.

If you are not sure how to fix the problems shown, please ask for help on the 
R-package-devel mailing list:
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
If you are fairly certain the rejection is a false positive, please reply-all 
to this message and explain.
  
More details are given in the directory:

<https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.9000_20210816_162209/>
The files will be removed after roughly 7 days.
  
No strong reverse dependencies to be checked.
  
Best regards,

CRAN teams' auto-check service


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



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

Re: [R-pkg-devel] Using parallel:::sendMaster despite warnings

[Sebastian Meyer]

Am 23.07.21 um 13:19 schrieb David Norris:

Because parallelized progress reporting in the futureverse.org incurs latencies 
too great for my application 
(https://github.com/HenrikBengtsson/progressr/issues/118), I have found it 
necessary to implement my own progress reporting using some of the non-exported 
functionality from `parallel`. (I do appreciate that Windows lacks the fork() 
system call, and will not support this. But am willing to make this an OS_type: 
unix-only package.)

Of course, I get a WARNING for this:

── R CMD check results  precautionary 0.2.6 
Duration: 6m 41.8s

❯ checking dependencies in R code ... WARNING
   Unexported objects imported by ':::' calls:
 ‘parallel:::readChild’ ‘parallel:::selectChildren’
 ‘parallel:::sendMaster’
 See the note in ?`:::` about the use of this operator.
 Including base/recommended package(s):
 ‘parallel’

Is this warning an absolute deal-killer on CRAN? Is there a 'correct' way to do 
`:::` that avoids the warning altogether?


The 'parallel' functions your package intends to access seem to be 
intentionally unexported. Their help page says: "They are not available 
on Windows, and not exported from the namespace", and "This is a very 
low-level interface for expert use only: it not regarded as part of the 
R API and subject to change without notice."


Correspondingly, the CRAN Repository Policy says


Also, ::: should not be used to access undocumented/internal objects in base 
packages (nor should other means of access be employed). Such usages can cause 
packages to break at any time, even in patched versions of R.


which kind of answers both of your questions. The policy thus implicitly 
advises against using getFromNamespace().


Best regards,

    Sebastian Meyer



Kind regards,
David Norris

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



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

Re: [R-pkg-devel] Spelling and manual CRAN inspection

[Sebastian Meyer]

Note that the spell checks are not run by default in R CMD check. To 
trigger these, you need to set the (undocumented) environment variable


_R_CHECK_CRAN_INCOMING_USE_ASPELL_=TRUE

and have aspell (or alternatives) installed.

No worries about a potential pain of rechecking the same flagged words 
multiple times: Flagged words from the current CRAN version of the 
package are automatically filtered out (by default) if remote checks are 
enabled, i.e., if the environment variable


_R_CHECK_CRAN_INCOMING_REMOTE_=TRUE

(if unset it is TRUE for --as-cran). I'm sure the CRAN team takes care 
of that.


Anyway, if you would like to setup a dedicated dictionary for your 
package, this is also possible, see the "Watch Your Spelling!" R Journal 
article by Kurt Hornik and Duncan Murdoch 
(https://journal.r-project.org/archive/2011/RJ-2011-014/RJ-2011-014.pdf) 
and the details section in help("aspell-utils").


Best regards,

    Sebastian Meyer


Am 16.07.21 um 18:08 schrieb Kevin R. Coombes:

Hi,

   I have been updating a couple of R packages this morning. One of them
triggered a manual inspection for "possibly mis-spelled words in
DESCRIPTION" for my last name (Coombes) --- even though none of the
other 20 packages that I maintain has ever triggered that particular
NOTE. A second package also triggered a manual inspection for
mis-spelled words including "Proteomics". (These flags only arose on the
debian CRAN machine, not the Windows CRAN machine, and not on my home
machines. And let's ignore how many spelling corrections I had to make
while typing this email)

*My question, however, is: why should this NOTE ever trigger a manual
inspection?* That makes more work for the CRAN maintainers, who I am
sure have better things to do than evaluate spelling. Anything that
would actually stop the package from working (mis-spelling a keyword, or
mis-spelling the name of package that is imported) is going to cause an
automatic ERROR and a rejection of the submission without making more
work for the CRAN maintainers. The other mis-spellings may reflect
poorly on the package author, but since they are NOTEs, it is easy
enough to get them fixed for the next round without making human
eyeballs look at them.

Best,
    Kevin

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


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

Re: [R-pkg-devel] package submission NOTE : Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’

[Sebastian Meyer]

I think you got caught by a common misinterpretation of the auto-check 
output from the Debian machine. It **appends** the


Current CRAN status

at the bottom of the check log. So you see the check results for your 
submitted version and then, below, for comparison, the results for the 
package version currently on CRAN (which indeed gives the NOTE from 
checking compiled code).


Best regards,

Sebastian Meyer


Am 15.07.21 um 11:39 schrieb Ronan GRIOT:

  Dear R developpers,
I submitted my package on the CRAN and had this NOTE :

Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’


In my package, called APIS, I wrote 4 .c functions all included in one file
: APIS.c

To avoid that NOTE message, I ran the command
tools::package_native_routine_registration_skeleton("."), copy the output
and paste it in a mypackage_init.c file.
Here is the output of the function :

#include  // for NULL
#include 

/* FIXME:
Check these declarations against the C/Fortran source code.
*/

/* .C calls */
extern void get_individual_mendelian_probability_2n(void *, void *, void *,
void *, void *, void *, void *, void *, void *, void *);
extern void get_individual_mendelian_probability_3n(void *, void *, void *,
void *, void *, void *, void *, void *, void *, void *);
extern void get_mendelian_probability_2n(void *, void *, void *, void *,
void *, void *, void *, void *, void *, void *, void *);
extern void get_mendelian_probability_3n(void *, void *, void *, void *,
void *, void *, void *, void *, void *, void *, void *);

static const R_CMethodDef CEntries[] = {
 {"get_individual_mendelian_probability_2n", (DL_FUNC)
_individual_mendelian_probability_2n, 10},
 {"get_individual_mendelian_probability_3n", (DL_FUNC)
_individual_mendelian_probability_3n, 10},
 {"get_mendelian_probability_2n",(DL_FUNC)
_mendelian_probability_2n,11},
 {"get_mendelian_probability_3n",(DL_FUNC)
_mendelian_probability_3n,11},
 {NULL, NULL, 0}
};

void R_init_APIS(DllInfo *dll)
{
 R_registerRoutines(dll, CEntries, NULL, NULL, NULL);
 R_useDynamicSymbols(dll, FALSE);
}

--
then, I changed all the @useDynLib APIS by @useDynLib APIS, .registration =
TRUE as recommended in
https://stackoverflow.com/questions/42313373/r-cmd-check-note-found-no-calls-to-r-registerroutines-r-usedynamicsymbols

On my computer, it solved the problem and I do not have the NOTE message
anymore. However, during the CRAN submission process, I had this NOTE
message twice.
I do not know how to fix this as I cannot get the NOTE message on my
computer.

Regards,
Ronan

[[alternative HTML version deleted]]

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



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

Re: [Rd] unicode in R documentation

[Sebastian Meyer]

Am 13.07.21 um 17:37 schrieb Frederick Eaton:

Dear R Team,

I am running R from the terminal command line (not RStudio). I've 
noticed that R has been using Unicode quotes in its documentation for 
some time, maybe since before I started using it.


I am wondering if it is possible to compile the documentation to use 
normal quotes instead.



Not sure if this is more of an R-help topic. I use

options(useFancyQuotes = FALSE)

in my .Rprofile.

Best regards,

Sebastian


I find it useful to be able to search documentation for strings with 
quotes, for example when reading "?options" I might search for "'dev" to 
find an option starting with the letters "dev". Without the single-quote 
at the front, there would be a lot of matches that I'm not interested 
in, but the single-quote at the front helps narrow it down to the 
parameters that are being indexed in the documentation. However, I can't 
actually search for "'dev" in "?options" because it is written with 
curly quotes "‘device’" and "'" does not match "‘" on my machine.


Similarly, when I read manual pages for commands on Linux, I sometimes 
search for "-r" instead of "r" because "-r" is likely to find 
documentation for the option "-r", while searching for "r" will match 
almost every line.


I'm wondering what other people do when reading through documentation. 
Do you search for things at all or just read it straight through? Is 
there a hyperlinked version that just lets you jump to the "device" 
entry in "?options" or do you have to type out a search string? What 
search string do you use? Do you have a way to enter Unicode quotes when 
doing this, or does your pager provide a special regular expression 
syntax which makes it easier to match them?


Thanks,

Frederick

__
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] Small Fix: Greatly Increase Clarity/Utility of R Package Help/Manual Overview Pages

[Sebastian Meyer]

Just in case others (like me) don't instantly know what this is about.

This only affects the html help.
Compare the HTML index page for the base package "graphics"

https://stat.ethz.ch/R-manual/R-patched/library/graphics/html/00Index.html

with the index page for the base package "grDevices"

https://stat.ethz.ch/R-manual/R-patched/library/grDevices/html/00Index.html

The latter is split by first letter, the former isn't as it only lists
98 <= 100 help pages.

I don't really have a preference for either (but I also rarely use the
html help system). Using a threshold seems reasonable to avoid blowing
up the index of a small package like "splines" but provide some anchors
for a large package like "stats". 50 may be too low as a threshold.
Looking at package "parallel" with its 45 entries

https://stat.ethz.ch/R-manual/R-patched/library/parallel/html/00Index.html

the listing doesn't seem long enough to benefit from alphabetic
sectioning. Probably a matter of taste.

Best regards,

Sebastian


Am 29.06.21 um 13:07 schrieb Marsh, Samuel:
> ?Hi,
> 
> 
> I would like to suggest a single line (2 characters) fix that I feel would 
> greatly improve the readability and usefulness of the overview R package 
> help/manual pages.  Currently the overall help/manual page for a package is 
> organized into alphabetized table of contents with linked headers by letter 
> only if the package contains more than 100 functions, otherwise the functions 
> are simply listed with no line breaks.  This makes for a more difficult user 
> experience with moderately sized packages 50-99 functions that could be 
> improved.  I would suggest changing the threshold for creating this 
> alphabetized table of contents to 50 instead of 100.
> 
> 
> I've provided info on the current code that specifies this parameter below:
> 
> It would appear that all that needs to be changed is the "> 100" parameter on 
> this line:
> https://github.com/wch/r-source/blob/80a7ca3b605b34d207ed3465c942f39a37e89f6e/src/library/tools/R/install.R#L2770
> 
> 
> Or to list the code directly:
> 
> In the .writePkgIndices function the line is:
> use_alpha <- (nrow(M) > 100)?
> 
> 
> It appears to me the only change needed would be to set "nrow(M) > 50".  I 
> believe this very small fix would greatly improve user experience for a 
> growing number of moderately-sized packages whose manual/help pages would 
> still greatly benefit from greater readability/organization.
> 
> 
> Thank you!
> 
> Sam
> 
> 
> --
> Samuel E. Marsh, Ph.D.
> Postdoctoral Fellow
> Laboratory of Dr. Beth Stevens
> F.M. Kirby Neurobiology Research Center
> Boston Children's Hospital
> Harvard Medical School
> samuel.ma...@childrens.harvard.edu
> 
>   [[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: [R-pkg-devel] How to communicate WARNINGS fixed from *last* CRAN version of a package

[Sebastian Meyer]

Am 22.06.21 um 10:11 schrieb Alberto Garre:
> Hi,
> 
> I submitted yesterday a new version of the biogrowth package (
> https://cran.r-project.org/package=biogrowth). In the automatic response, I
> got the following message:
> 
> The auto-check found additional issues for the *last* version released on
> CRAN:
>   donttest <https://www.stats.ox.ac.uk/pub/bdr/donttest/biogrowth.out>
>   M1mac <https://www.stats.ox.ac.uk/pub/bdr/M1mac/biogrowth.out>
> CRAN incoming checks do not test for these additional issues.
> Hence please reply-all and explain: Have these been fixed?
> 
> I resubmitted mentioning in cran-comments.md that these problems had been
> resolved, but I got again the same automatic response. Then, I answered
> directly to the automatic email with no effect.
> 
> How should I communicate these issues have been fixed? Is there any
> additional issue I am not seeing?

The auto-check e-mail said "Hence please reply-all and explain". If you
followed these instructions, you will just need some more patience. You
submitted only yesterday evening and these checks require manual
inspection by the CRAN team. I can see your submission in the "inspect"
folder of the incoming queue (https://CRAN.R-project.org/incoming/).

Best regards,

Sebastian Meyer

> 
> Thank you,
> Alberto
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [Rd] R CMD INSTALL warning for S4 replacement functions on R 4.1.0-alpha

[Sebastian Meyer]

I can confirm this Rd warning in R-devel (2021-04-23 r80216), but not in
R 4.0.5. It happens when installing the static help (INSTALL option --html).

The following R code reproduces the warning by creating a tiny test
package and then calling relevant internal functions from 'tools':

```R

## create test package
dir.create(pkgdir <- tempfile())
tools:::.write_description(  # need a DESCRIPTION
unlist(head(packageDescription("tools"), -1)),
file.path(pkgdir, "DESCRIPTION"))
dir.create(file.path(pkgdir, "man"))
cat(r"(\name{test-package}
\title{Test Package}
\alias{\%/\%}
\description{Test alias.}
)", file = file.path(pkgdir, "man", "test-package.Rd"))

## build HTML help
dir.create(outDir <- tempfile())
tools:::.install_package_description(pkgdir, outDir)
tools:::.writePkgIndices(pkgdir, outDir)
tools:::.convertRdfiles(pkgdir, outDir, types = "html")


```

The output is

  converting help for package ‘tools’
finding HTML links ... done
test-packagehtml
REDIRECT:topic   %/% -> test-package.html [ FAIL ]
REDIRECT:filetest-package.html -> test-package.html [ SUCCESS ]
Rd warning: cannot open file
'/tmp/RtmpasTPyq/fileb3d72f4ea1cf/help/%/%.html': No such file or directory


A workaround (if needed) is to set the environment variable
_R_HELP_LINKS_TO_TOPICS_ to a false value.

Best regards,

Sebastian


Am 23.04.21 um 19:01 schrieb Felix Ernst:
> Hi all,
> 
> Since R 4.1, R CMD INSTALL throws warning during building the man pages, when 
> installing from source.
> 
> We noticed this first on Windows for man pages involving S4 replacement 
> function:
> 
>   *   
> http://bioconductor.org/checkResults/devel/bioc-LATEST/Modstrings/riesling1-checksrc.html
>   *   
> http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicAlignments/riesling1-checksrc.html
> 
> However, it's also showing up on linux with a slight twist (file not found 
> instead of invalid argument) for other functions:
> 
>   *   https://cran.r-project.org/web/checks/check_results_Matrix.html (right 
> at the end)
> 
> From the messages and the involved offending filenames, we hypothesize that 
> this is triggered by invalid filenames specific to the OS.
> Please note, that the warning is not issued during R CMD CHECK for a given 
> package.
> 
> Can anyone comment on this? Is more information needed? If it is a bug, I am 
> happy to post on the bug tracker.
> 
> Thanks for any advice.
> 
> Best regards,
> Felix
> 
>   [[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: [R-pkg-devel] Skipping tests on CRAN

[Sebastian Meyer]

Am 21.04.21 um 08:35 schrieb Mark van der Loo:
> Hi Ott,
> 
> There is no documented way to detect whether you are running on CRAN. So
> there is nothing to rely on, on that side.
> 
> You can only make your own machine detectable by the test code. For example
> by setting an environment variable that identifies your machine and make
> test execution depend on the value of that environment variable. This is
> what tinytest does under the hood.

You could add the following at the start of a script containing slow tests:

if (!identical(Sys.getenv("NOT_CRAN"), "true")) {
message("skipping slow tests")
q("no")
}
## slow tests follow here ...

Of course, you could use a different name for the environment variable,
e.g., "R_PKGNAME_ALL_TESTS", or test with as.logical() to allow both
"TRUE" and "true" values:

if (!isTRUE(as.logical(Sys.getenv("R_PKGNAME_ALL_TESTS" q("no")

Quitting from test scripts as above is frequently used in R's own test
suite, for example in the regression tests for message translations:

if (!capabilities("NLS")) {
message("no natural language support")
q("no")
}

Don't run such code in an interactive session if you don't want to quit
R. ;)

An alternative is the R CMD check --test-dir=inst/slowTests approach
mentioned in the WRE manual at
https://CRAN.R-project.org/doc/manuals/r-devel/R-exts.html#Checking-packages
.

Best regards,

Sebastian

> 
> Best,
> Mark
> 
> 
> 
> 
> 
> On Wed, Apr 21, 2021 at 7:17 AM Ott Toomet  wrote:
> 
>> Hi packagers,
>>
>> what is the best way to skip certain tests on CRAN?  So far I have included
>> certain test files in .Rbuildignore and run the tests on the package
>> directory.  But now when moving to Authors@R format, I get errors about
>> missing maintainer etc.
>>
>> I know there are options in testthat, tinytest and such, are these the best
>> options with least dependencies and assumptions built in?
>>
>> I sort of remember something in base R but cannot find anything when
>> looking for it now.
>>
>> Cheers,
>> Ott
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] checking LazyData ... WARNING

[Sebastian Meyer]

Am 14.04.21 um 13:11 schrieb Rafael CM:
> Dear all,
> I am having the following warning when loading my rpackage:
> 
> * checking LazyData ... WARNING
>   LazyData DB of 62.1 MB without LazyDataCompression set
> 
> 
> I can't get to fix this problem. I have tried the tools option to optimize
> saving. I used different types of compressions. I also have set LazyDate:
> true to my DESCRIPTION file.
> Any ideas?

Have you already tried also setting LazyDataCompression as the warning
suggests?

You should try all of bzip2, xz and gzip in turn and look at the size of
the installed lazy-loading database to find the best compression format.
The development version of the WRE manual at

https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Data-in-packages

gives a function CheckLazyDataCompression, which can be used to do that.

Best regards,

Sebastian


> Thank you in advance,
> Rafael
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] R CMD build --resave-data not working

[Sebastian Meyer]

This is a bug in R 4.0.0 - R 4.0.4 affecting packages using LazyData.

Two possible workarounds:

- Manually run tools::resaveRdaFiles() on your data directory before
building the package.

- Use a current development version of R (4.0.4-patched >= r80069 or
R-devel >= r79573)

Best regards,

    Sebastian Meyer


PS: This is a duplicate of a recent discussion on this list, see
https://stat.ethz.ch/pipermail/r-package-devel/2021q1/006643.html



Am 11.03.21 um 21:57 schrieb Jonathan Callahan:
> I am building a package using R 4.0.4 on OS X 10.15.7.
> 
> In a terminal I type:
> 
> R CMD build --resave-data AirSensor
> 
> Then, I check with:
> 
> R CMD check --as-cran AirSensor_1.0.8.tar.gz
> 
> Everything is fine until I see:
> 
> 
> * checking data for ASCII and uncompressed saves ... WARNING
> 
> 
> 
>   Note: significantly better compression could be obtained
> 
> by using R CMD build --resave-data
> 
> old_size new_size compress
> 
>   example_pas.rda  1.6Mb1.1Mb   xz
> 
>   example_pas_raw.rda  114Kb 86Kb   xz
> 
>   example_pat.rda  965Kb444Kb   xz
> 
>   example_pat_failure_A.rda527Kb259Kb   xz
> 
>   example_pat_failure_B.rda411Kb198Kb   xz
> 
>   example_sensor_scaqmd.rda108Kb 76Kb   xz
> 
> I get the same WARNING if I submit to win-builder.R-project.org.
> 
> I've built many packages in the past and am currently stumped as to what
> might be happening.
>

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

Re: [R-pkg-devel] Warning for failed attempt to rebuild the vignette of the previous version of a package

[Sebastian Meyer]

The Debian check log appends the check status of the current CRAN
version just for comparison.
[
Indeed, these old problems are sometimes mistaken to cause a rejection
and I think it would help if there were a few more empty lines between
the new and the old check results and if the first two lines said
something like
For comparison, current CRAN status: 
From: <https://CRAN>
]

Maybe the problem with your submission simply is that the spell check
results hinder automatic processing of your package and you need to
reply to CRAN-submissions that these words are spelled correctly?

Otherwise I guess you may have overlooked another issue somewhere in the
check log. If you included a link to the pre-test results (or a copy of
the check logs) you will likely receive more sophisticated replies.

Best regards,

    Sebastian Meyer


Am 04.03.21 um 14:56 schrieb Thierry Denoeux:
> Hi,
> 
> I am trying to submit a revised version of a package to CRAN and for the 
> second time it does not pass the incoming checks. I can’t figure out why.
> 
> The new version is numbered 2.0.0, the previous one was 1.1.0.
> 
> - The Windows report gives me one note:
> 
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: 'Thierry Denoeux mailto:tdeno...@utc.fr>>'
> 
> Possibly mis-spelled words in DESCRIPTION:
>   BPEC (15:41)
>   Bootclus (14:77)
>   CEVCLUS (13:41)
>   NN (16:7)
> These are just acronyms that can be easily removed. I don’t think it 
> motivated the rejection.
> 
> - The Debian report has the same note and the following warning:
> 
> Current CRAN status: WARN: 1, OK: 11
> See: <https://CRAN.R-project.org/web/checks/check_results_evclust.html 
> <https://cran.r-project.org/web/checks/check_results_evclust.html>>
> 
> Version: 1.1.0
> Check: re-building of vignette outputs, Result: WARNING
>   Error(s) in re-building vignettes:
> ...
>   --- re-building ‘Introduction.Rmd’ using rmarkdown
>   Quitting from lines 112-113 (Introduction.Rmd) 
>   Error: processing vignette 'Introduction.Rmd' failed with diagnostics:
>   argument is of length zero
>   --- failed re-building ‘Introduction.Rmd’
>   
>   SUMMARY: processing the following file failed:
> ‘Introduction.Rmd’
>   
>   Error: Vignette re-building failed.
>   Execution halted
> I don’t understand why the system is trying to rebuild the vignette of the 
> previous version. It was built using Markdown, but in the new version I 
> completely rewrote it using Sweave. The new vignette was rebuilt 
> successfully, and there is no trace of the old vignette (the file 
> ‘Introduction.Rmd’) in the new version. 
> 
> Thanks for any tips.
> 
> Best regards,
> 
> Thierry Denoeux
> 
> --
> Prof. Thierry Denoeux
> Université de technologie de Compiègne
> Institut universitaire de France
> Rue Roger Couttolenc, CS 60319
> 60203 Compiègne cedex, France
> https://www.hds.utc.fr/~tdenoeux
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Note: significantly better compression could be obtained ...

[Sebastian Meyer]

Am 04.03.21 um 10:24 schrieb Rolf Turner:
> 
> On Thu, 4 Mar 2021 08:44:31 +0100
> Sebastian Meyer  wrote:
> 
>> Am 04.03.21 um 01:41 schrieb Rolf Turner:
>>>
>>> ... by using R CMD build --resave-data
>>>
>>> But I *did* use that flag with my build command!!!  And yet "R CMD
>>> check" seems to think that I didn't!
>>
>> Just to be sure: Are you running R CMD check on that freshly built
>> tarball or is devtools::check() involved?
> 
> The former.  I have never used devtools::check().
>>
>>>
>>> I have done "R CMD build --resave-data kanova"  (where "kanova" is
>>> the name of the package in question), to make sure that I didn't
>>> fumble-finger somewhere, but there's no change.  I always get that
>>> NOTE.
>>>
>>> How on earth can I track down what's going wrong?
>>
>> - Does the R CMD build log actually show "re-saving image files" or
>> "re-saving sysdata.rda"?
> 
> Dunno what you mean by the "R CMD build log".  I could grepped
> "re-saving" on all files and came up empty handed.

I meant the standard output of R CMD build.
With --resave-data, it should show something like

* checking for empty or unneeded directories
* re-saving image files
* building '.tar.gz'

> 
>> - Have you set the BuildResaveData field in your DESCRIPTION file?
> 
> No.
> 
>> This would take precedence over the --resave-data command line switch.
>>
>> - Have you tried running ) on your source data
>> directory before building the package? Does that reduce the size of
>> your data files?
> 
> Never heard of that.  Tried it just now and it reduced the size from
> 285607 bytes to 161743 bytes.  That's substantial I guess.
> 
> 
> 
>> You'll get the NOTE when R CMD check finds that running
>> tools::resaveRdaFiles() on the data directory would reduce a file's
>> size by more than 10% with a different type of compression (if the
>> original size is >10KB).
> 
> Now that I have applied tools::resaveRdaFiles(), I no longer get
> the NOTE from R CMD check.  So I guess my problem is solved.  Thanks.
> 
> But this still leaves the question:  Why the  is
> R CMD check telling me to use the flag --resave-data, when I *just did
> that*???

Yes, indeed! I've investigated further and found that in R 4.0.0-4.0.4
the --resave-data option of R CMD build was ineffective for packages
using LazyData. This bug has recently been fixed in R-devel (c79573) and
I think the fix should also be ported to R-patched and appear in the NEWS.

Thank you for reporting!

Best regards,

Sebastian

> 
> cheers,
> 
> Rolf
>

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

Re: [R-pkg-devel] Note: significantly better compression could be obtained ...

[Sebastian Meyer]

Am 04.03.21 um 01:41 schrieb Rolf Turner:
> 
> ... by using R CMD build --resave-data
> 
> But I *did* use that flag with my build command!!!  And yet "R CMD
> check" seems to think that I didn't!

Just to be sure: Are you running R CMD check on that freshly built
tarball or is devtools::check() involved?

> 
> I have done "R CMD build --resave-data kanova"  (where "kanova" is
> the name of the package in question), to make sure that I didn't
> fumble-finger somewhere, but there's no change.  I always get that
> NOTE.
> 
> How on earth can I track down what's going wrong?

- Does the R CMD build log actually show "re-saving image files" or
"re-saving sysdata.rda"?

- Have you set the BuildResaveData field in your DESCRIPTION file? This
would take precedence over the --resave-data command line switch.

- Have you tried running tools::resaveRdaFiles() on your source data
directory before building the package? Does that reduce the size of your
data files?

> 
> There is only one file "stomata.rda" in kanova/data.  The
> file was created using:
> 
> save(stomata,file="stomata.rda",version=2)
> 
> The file stomata.rda is a *bit* on the large size; 285607 bytes
> according to "ls -l", 279Kb according to the NOTE from R CMD check.
> But that's not all that big, is it?  And anyway I *did* ask
> R CMD build to re-save it!

You'll get the NOTE when R CMD check finds that running
tools::resaveRdaFiles() on the data directory would reduce a file's size
by more than 10% with a different type of compression (if the original
size is >10KB).

Hope this helps.
Best regards,

Sebastian Meyer

> 
> When I load stomata.rda, object.size() says that stomata uses 1611312 bytes
> of memory.
> 
> I'm running Ubuntu 20.04.2 and R version 4.0.4.
> 
> Has anyone else ever been confronted with this bizarre phenomenon?
> 
> Thanks for any tips.
> 
> cheers,
> 
> Rolf Turner
>

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

Re: [R-pkg-devel] Citation in DESCRIPTION file

[Sebastian Meyer]

Am 24.02.21 um 12:22 schrieb Uwe Ligges:
> 
> 
> On 24.02.2021 10:30, Knut Krueger wrote:
>> Am 24.02.21 um 10:05 schrieb Sebastian Meyer:
>>
>> Yes I realized  that it is a problem in various packages
>> The question was, whether there is a mistake or a limitation.
>> I was wondering because the CRAN PDF also is not formatting the doi in
>> HTTP:\\... , but the URL
> 
> Limitation:
> The intention always was to provide links from the packages' CRAN pages.
> And that works.
> 
> We may work on the PDF versions.

Good idea. I have submitted a bug report for this at

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=18065

and will work on a patch when time permits and if not taken up by
someone else.

Best regards,

Sebastian Meyer

> 
> Best,
> Uwe Ligges
> 
> 
> 
>>
>> Regards Knut
>>> I think you need to be more specific. Which "downloaded package"? Which
>>> viewer? As the list info says: "We can't help if we don't know what the
>>> problem is."
>>>
>>> FWIW, this format is used by many packages that I have installed on my
>>> machine and is rendered as a link on the CRAN package website, see
>>> https://CRAN.R-project.org/package=colorspace, for example.
>>>
>>> I can confirm that this format is not recognized in all HTML versions of
>>> package descriptions out there, maybe most prominently at
>>> https://rdrr.io/cran/colorspace/ and
>>> https://www.r-pkg.org/pkg/colorspace . The former does not even convert
>>> full URLs in the description text (such as the R-Forge URL).
>>>
>>> However, the lack of clickable DOIs seems to be a limitation of these
>>> websites not of your package description or the CRAN policy. The
>>> required  format is officially documented at
>>> https://www.doi.org/doi_handbook/2_Numbering.html#2.6.1
>>>
>>> Finally, again citing the list info: "Please note that while
>>> R-package-devel contributors will do their best to provide you accurate
>>> and authoritative information, the final arbiters of CRAN submission is
>>> the CRAN team." ;)
>>>
>>> Best regards,
>>>
>>> Sebastian Meyer
>>>
>>>
>>> Am 24.02.21 um 09:25 schrieb Knut Krueger:
>>>> Am 22.02.21 um 14:58 schrieb Uwe Ligges:
>>>>
>>>>> Write it inline as in:
>>>>>
>>>>> See Author 1 (2021)  and Author 2 (2004) .
>>>>
>>>> I see at the downloaded package that the urls are not usable by
>>>> clicking.
>>>> means the doi   has not been converted to
>>>> https://doi.org/xyz/1234567
>>>> Any chance to fix this in the description file?
>>>>
>>>>
>>>> Regards Knut
>>>>
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Citation in DESCRIPTION file

[Sebastian Meyer]

I think you need to be more specific. Which "downloaded package"? Which
viewer? As the list info says: "We can't help if we don't know what the
problem is."

FWIW, this format is used by many packages that I have installed on my
machine and is rendered as a link on the CRAN package website, see
https://CRAN.R-project.org/package=colorspace, for example.

I can confirm that this format is not recognized in all HTML versions of
package descriptions out there, maybe most prominently at
https://rdrr.io/cran/colorspace/ and
https://www.r-pkg.org/pkg/colorspace . The former does not even convert
full URLs in the description text (such as the R-Forge URL).

However, the lack of clickable DOIs seems to be a limitation of these
websites not of your package description or the CRAN policy. The
required  format is officially documented at
https://www.doi.org/doi_handbook/2_Numbering.html#2.6.1

Finally, again citing the list info: "Please note that while
R-package-devel contributors will do their best to provide you accurate
and authoritative information, the final arbiters of CRAN submission is
the CRAN team." ;)

Best regards,

Sebastian Meyer


Am 24.02.21 um 09:25 schrieb Knut Krueger:
> Am 22.02.21 um 14:58 schrieb Uwe Ligges:
> 
>> Write it inline as in:
>>
>> See Author 1 (2021)  and Author 2 (2004) .
> 
> I see at the downloaded package that the urls are not usable by clicking.
> means the doi   has not been converted to
> https://doi.org/xyz/1234567
> Any chance to fix this in the description file?
> 
> 
> Regards Knut
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Citation in DESCRIPTION file

[Sebastian Meyer]

Am 22.02.21 um 11:06 schrieb Knut Krueger:
> I was suggested: "A citation in the Description file is typically a good
> idea because people can think  whether your package is appropriate
> before reading all docs and installing the package, just from reading
> the CRAN overview page."
> 
> but I do not find hints how to implement the doi and the references in
> the DESCRIPTION file
> 
> Thank's in advance Knut


If you are submitting to CRAN, the relevant guidelines can be found in
the repository policies at
https://CRAN.R-project.org/web/packages/policies.html:

> Citations in the ‘Description’ field of the DESCRIPTION file should be in 
> author-year style, followed by a DOI or ISBN for published materials, or a 
> URL otherwise. Preferably, the year and identifier would be enclosed, 
> respectively, in parentheses and angle brackets. 


Example: Einstein et al. (1935) .


Best regards,

Sebastian Meyer

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

Re: [R-pkg-devel] cannot xtfrm data frames WARNING with R-devel

[Sebastian Meyer]

You should be able to reproduce and trace back the error by setting the
environment variable

_R_STOP_ON_XTFRM_DATA_FRAME_=TRUE

while running your vignette code.

This is not a false positive. You are probably trying to
order(data.frame) somewhere. I think this will be disallowed in future
versions of R, following an R-devel thread from last year:

https://stat.ethz.ch/pipermail/r-devel/2020-May/079500.html

Best regards,

Sebastian Meyer


Am 06.02.21 um 19:08 schrieb J. Aravind via R-package-devel:
> Dear R developers,
> I am facing an issue while submitting update to my package PGRdup 
> (https://github.com/aravind-j/PGRdup).
> With R-devel Debian (2021-02-05 r7994) on submission a WARNING was reported 
> as follows. .
> .
> .
> .Quitting from lines 536-542 (Introduction.Rmd) 
> Error: processing vignette ‘Introduction.Rmd’ failed with diagnostics:
> cannot xtfrm data frames
> --- failed re-building ‘Introduction.Rmd’
> .
> .
> .
> .
> 
> I am unable to replicate the same locally with the same version (2021-02-05 
> r79941) in Ubuntu 18.
> Is this a false positive ? How to resolve this issue for successful 
> submission.
> 
> 
> Best Regards
> J. Aravind
> 
> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [Rd] R 4.0.4 scheduled for February 15

[Sebastian Meyer]

Am 21.01.21 um 13:51 schrieb Iñaki Ucar:
> Minor question: wouldn't the new pipe syntax be worth a minor version
> bump? 

Yes. The NEWS mention the pipe syntax for R-devel not for R-patched.

See the section "CHANGES IN R 4.0.3 patched" in

https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html

for what is currently included for R 4.0.4.

Cheers,

Sebastian


> A package planning to drop magrittr would end up depending on R
> 4.0.4, which sounds suboptimal. And (I don't find any reference to
> this in the manual or in CRAN policies, but) if I remember correctly,
> depending on a patch version was discouraged.
> 
> Iñaki
> 
> 
> On Thu, 21 Jan 2021 at 11:59, Peter Dalgaard via R-devel
>  wrote:
>>
>> Full schedule is available on https://developer.r-project.org (or 
>> https://svn.r-project.org/R-dev-web/trunk/index.html for the impatient).
>>
>> --
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk  Priv: pda...@gmail.com
>>
>> __
>> 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
> 
> 
>

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

Re: [R-pkg-devel] Accessing features in R4.0.

[Sebastian Meyer]

Am 16.12.20 um 18:00 schrieb Neal Fultz:
> IIRC some packages use get() instead of double-colon to suppress the NOTE.

I'd discourage from using get() because you could (accidentally) access
even unexported objects from another namespace. There is

getExportedValue(ns, name)

to avoid that. However, its help page describes it as an internal
function, so I'm not sure if that would be any better. "::" access is
also faster, especially as of the next version of R.

Of course, such workarounds should be used with great care as these
checks are usually very valuable to guard against coding errors or warn
about potential changes in the other package's API.

> I would probably ignore it myself.

Yes. FWIW, conditional use of tools::R_user_dir() is allowed according
to the CRAN repository policy:

> For R version 4.0 or later (hence a version dependency is required or only 
> conditional use is possible), packages may store user-specific data, 
> configuration and cache files in their respective user directories obtained 
> from tools::R_user_dir(), provided that by default sizes are kept as small as 
> possible and the contents are actively managed (including removing outdated 
> material). 

Best regards,

Sebastian Meyer


> 
> On Wed, Dec 16, 2020 at 8:29 AM Colin Gillespie  wrote:
>>
>> Hi,
>>
>> I'm planning on using the tools::R_user_dir function in a package. But
>> for obvious reasons, I don't want to set the dependency on R 4.
>>
>> My code is basically
>>
>> if (as.numeric(R.version$major) < 4) # do something
>> else tools::R_user_dir("oysteR", which = "cache")
>>
>> When checking on win-builder R3.6 I get the note
>>
>> * checking dependencies in R code ... NOTE
>> Missing or unexported object: 'tools::R_user_dir'
>>
>> ## Question
>>
>> Is my code correct and can I ignore this note?
>>
>> Thanks
>>
>> Colin
>>
>>
>> Dr Colin Gillespie
>> http://www.mas.ncl.ac.uk/~ncsg3/
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0

[Sebastian Meyer]

In the check log, I see

> * package encoding: UTF-8
> [...]
> * checking PDF version of manual ... WARNING
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> ! Package inputenc Error: Unicode char ‐ (U+2010)
> (inputenc)not set up for use with LaTeX.

I can reproduce this warning with a minimal test package with an Rd file
containing the Unicode hyphen "‐" (U+2010), which is different from
ASCII-compatible hyphen-minus "-" (U+002D), though not visibly ...
>From Wikipedia (https://en.wikipedia.org/wiki/Hyphen):

> In Unicode, the hyphen-minus is encoded as U+002D - so that Unicode remains 
> compatible with ASCII. Unicode also encodes the hyphen and minus separately, 
> as U+2010 ‐ and U+2212 − respectively.

The problematic hyphen probably arose from copy-pasting text from the
browser (which I just did for testing) or an office application into the
package documentation.

You can find non-ASCII characters in your Rd files using, e.g.,
tools::showNonASCIIfile("file.Rd"). For my test file, this gives:

> tools::showNonASCIIfile("test.Rd")
7: \description{test <80><90> test}

In many text editors, the character between "test" and "test" is
displayed just like a standard ASCII hyphen-minus. In my Emacs it is
shown in red, though, and in RStudio it looks slightly different than
the ASCII minus (but hard to recognize if you don't know).

You could apply the above function to all of "man" using, e.g.,

lapply(list.files("man", full.names=TRUE), tools::showNonASCIIfile)

at the root of your package and look for "<80><90>" in the result.

Hope this helps.
Best regards,

Sebastian Meyer


Am 16.12.20 um 08:12 schrieb Kristin Piikki:
> Dear R package developers,
> I have been trying a lot but I do not seem to find a solution to the problems 
> with this new package (please see below and attached). It seems related to 
> the building of the vignette. I would be very grateful if anyone could 
> provide some advice.
> Kind regards,
> Kristin
> 
> -Original Message-
> From: lig...@statistik.tu-dortmund.de 
> Sent: den 15 december 2020 16:21
> To: Kristin Piikki 
> Cc: cran-submissi...@r-project.org
> Subject: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0
> 
> Dear maintainer,
> 
> package valmetrics_1.0.0.tar.gz does not pass the incoming checks 
> automatically, please see the following pre-tests:
> Windows: 
> <https://win-builder.r-project.org/incoming_pretest/valmetrics_1.0.0_20201215_155420/Windows/00check.log>
> Status: 1 ERROR, 1 WARNING, 1 NOTE
> Debian: 
> <https://win-builder.r-project.org/incoming_pretest/valmetrics_1.0.0_20201215_155420/Debian/00check.log>
> Status: 1 NOTE
> 
> 
> 
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on the 
> R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please reply-all 
> to this message and explain.
> 
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/valmetrics_1.0.0_20201215_155420/>
> The files will be removed after roughly 7 days.
> 
> No strong reverse dependencies to be checked.
> 
> Best regards,
> CRAN teams' auto-check service
> ---
> När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
> personuppgifter. För att läsa mer om hur detta går till, klicka här 
> <https://www.slu.se/om-slu/kontakta-slu/personuppgifter/>
> E-mailing SLU will result in SLU processing your personal data. For more 
> information on how this is done, click here 
> <https://www.slu.se/en/about-slu/contact-slu/personal-data/>
> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [Rd] New pipe operator

[Sebastian Meyer]

Am 04.12.20 um 15:05 schrieb Duncan Murdoch:
> On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote:
>>>   Error: function '::' not supported in RHS call of a pipe
>>
>> To me, this error looks much more friendly than magrittr's error.
>> Some of them got too used to specify functions without (). This
>> is OK until they use `::`, but when they need to use it, it takes
>> hours to figure out why
>>
>> mtcars %>% base::head
>> #> Error in .::base : unused argument (head)
>>
>> won't work but
>>
>> mtcars %>% head
>>
>> works. I think this is a too harsh lesson for ordinary R users to
>> learn `::` is a function. I've been wanting for magrittr to drop the
>> support for a function name without () to avoid this confusion,
>> so I would very much welcome the new pipe operator's behavior.
>> Thank you all the developers who implemented this!
> 
> I agree, it's an improvement on the corresponding magrittr error.


Thank you for this example. I agree but think that the new base R pipe
might trigger some initial confusion as well:

mtcars |> function(x) dim(x)[1L]
#> [1] 32

mtcars |> nrow
#> Error: The pipe operator requires a function call or an anonymous
function expression as RHS

The RHS evaluates to the same thing in both cases (bar attributes and
environments), but only the anonymous variant is supported. I admit that
I haven't used %>% before; maybe the above discrepancy is less
irritating for those who have. The error message is clear though!

That said, I think the code is very readable when piping explicitly into
an anonymous function and I also prefer

mtcars |> nrow()

over mtcars |> nrow, because we are visibly calling something.

IMO, readability is lost when using the cryptic short-hand notation

mtcars |> \(x) dim(x)[1L]

which really only saves 7 letters.


> I think the semantics of not evaluating the RHS, but treating the pipe
> as purely syntactical is a good decision.
> 
> I'm not sure I like the recommended way to pipe into a particular argument:
> 
>   mtcars |> subset(cyl == 4) |> \(d) lm(mpg ~ disp, data = d)
> 
> or
> 
>   mtcars |> subset(cyl == 4) |> function(d) lm(mpg ~ disp, data = d)
> 
> both of which are equivalent to
> 
>   mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = d))()
> 
> It's tempting to suggest it should allow something like
> 
>   mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .)
> 
> which would be expanded to something equivalent to the other versions:
> but that makes it quite a bit more complicated.  (Maybe _ or \. should
> be used instead of ., since those are not legal variable names.)


I guess "_" as a placeholder would be difficult to implement precisely
because it currently is a syntax error.

Best regards,

Sebastian Meyer


> I don't think there should be an attempt to copy magrittr's special
> casing of how . is used in determining whether to also include the
> previous value as first argument.
> 
> Duncan Murdoch
> 
> 
>>
>> Best,
>> Hiroaki Yutani
>>
>> 2020年12月4日(金) 20:51 Duncan Murdoch :
>>>
>>> Just saw this on the R-devel news:
>>>
>>>
>>> R now provides a simple native pipe syntax ‘|>’ as well as a shorthand
>>> notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as
>>> ‘function(x) x + 1’. The pipe implementation as a syntax transformation
>>> was motivated by suggestions from Jim Hester and Lionel Henry. These
>>> features are experimental and may change prior to release.
>>>
>>>
>>> This is a good addition; by using "|>" instead of "%>%" there should be
>>> a chance to get operator precedence right.  That said, the ?Syntax help
>>> topic hasn't been updated, so I'm not sure where it fits in.
>>>
>>> There are some choices that take a little getting used to:
>>>
>>>   > mtcars |> head
>>> Error: The pipe operator requires a function call or an anonymous
>>> function expression as RHS
>>>
>>> (I need to say mtcars |> head() instead.)  This sometimes leads to error
>>> messages that are somewhat confusing:
>>>
>>>   > mtcars |> magrittr::debug_pipe |> head
>>> Error: function '::' not supported in RHS call of a pipe
>>>
>>> but
>>>
>>> mtcars |> magrittr::debug_pipe() |> head()
>>>
>>> works.
>>>
>>> Overall, I think this is a great addition, though it's going to be
>>> disruptive for a while.
>>>
>>> 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
>>
> 
> __
> 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] Some packages have non-POSIX-compliant shell scripts. Implement a CRAN check for bashisms?

[Sebastian Meyer]

Your report underlines the importance of the checks implemented by CRAN.

In fact, checkbashisms has become an optional part of R CMD check in R
4.0.0, whose NEWS say

> R CMD check now optionally checks configure and cleanup scripts for 
> non-Bourne-shell code ('bashisms').

The R Internals manual at
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html reveals that
the corresponding environment variable is called "_R_CHECK_BASHISMS_".
It is false by default but true for CRAN submission checks (--as-cran),
except on Windows. The check is probably not enabled for the routine
checks on the CRAN check farm.


Am 05.11.20 um 11:15 schrieb Kocken, I.J. (Ilja):
> Dear R-devel,
> 
> Recently I ran into trouble installing two separate packages, nloptr and 
> ncdf4, both due to the same issue: they have scripts that have the shebang 
> `#! /bin/sh', but have bashisms in them, i.e. non-POSIX-compliant bash 
> scripts.
> 
> I use dash [1] as my shell environment, since it's about 4x as fast as bash. 
> It looks like it's recently also become the default shell for Debian (and 
> thus Ubuntu).
> 
> It took quite a while to figure out what the issue was in great collaboration 
> with the author of ncdf4 (CC).
> 
> Perhaps it would be good to implement the utility checkbashisms [2] into the 
> CRAN make pipeline to help discover these kinds of issues? Running 
> `checkbashisms -f pkg/configure` on files that have the `#! /bin/sh` shebang 
> gives useful information about which lines of code are secretly bash code, 
> with some hints on how to make them POSIX-compliant. The alternative would of 
> course be to change the shebang into `#! /bin/bash`.
> 
> Kind regards,
> 
> Ilja Kocken
> 
> 
> 
> [1]: http://gondor.apana.org.au/~herbert/dash/
> [2]: https://packages.qa.debian.org/d/devscripts.html
> __
> 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: [R-pkg-devel] import with except(ion)

[Sebastian Meyer]

No need to reinvent the wheel. Göran, you already use the "specials"
feature of terms.formula to find strata():

> specials: which functions in the formula should be marked as special in
>   the 'terms' object?  A character vector or 'NULL'.

I think you can do the same for frailty(), for example:

> formula <- Surv(time, status) ~ age + frailty(inst)
> 
> Terms <- terms(formula, specials = "frailty")
> frailties <- attr(Terms, "specials")$frailty
> if (length(frailties)) warning("frailty() is not supported by coxreg")


Best regards,

Sebastian


Am 31.10.20 um 14:30 schrieb Gabor Grothendieck:
> coxreg could search for frailty and issue a warning or error if found.  This
> returns TRUE if frailty is used in the formula argument as a function but
> not otherwise.  That would allow implementation of a nicer message than
> if it were just reported as a missing function.
> 
> find_frailty <- function(e) {
> if (is.logical(e)) return(e)
> if (length(e) > 1) {
> if (identical(e[[1]], as.name("frailty"))) return(TRUE)
> for (i in 1:length(e)) if (isTRUE(Recall(e[[i]]))) return(TRUE)
> }
> FALSE
> }
> find_frailty(frailty ~ frailty)
> ## [1] FALSE
> fo <- Surv(time, status) ~ age + frailty(inst)
> find_frailty(fo)
> ## [1] TRUE
> 
> On Fri, Oct 30, 2020 at 2:46 PM Göran Broström  wrote:
>>
>> My CRAN package eha depends on the survival package, and that creates
>> problems with innocent users: It is about the 'frailty' function
>> (mainly). While (after 'library(eha)')
>>
>> f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)
>>
>> produces what you would expect (a frailty survival analysis), the use of
>> the coxreg function from eha
>>
>> f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)
>>
>> produces (almost) nonsense. That's because the survival::frailty
>> function essentially returns its input and coxreg is happy with that,
>> treats it as an ordinary numeric (or factor) covariate, and nonsense is
>> produced, but some users think otherwise. (Maybe it would be better to
>> introduce frailty in a separate argument?)
>>
>> I want to prevent this to happen, but I do not understand how to do it
>> in the best way. I tried to move survival from Depends: to Imports: and
>> adding import(survival, except = c(frailty, cluster)) to NAMESPACE. This
>> had the side effect that a user must qualify the Surv function by
>> survival::Surv, not satisfactory (similarly for other popular functions
>> in survival).
>>
>> Another option I thought of was to define my own Surv function as
>> Surv <- survival::Surv in my package, but it doesn't feel right.
>> It seems to work, though.
>>
>> As you may understand from this, I am not very familiar with these
>> issues. I have used Depends: survival for a long time and been happy
>> with that.
>>
>> Any help on this is highly appreciated.
>>
>> Göran
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
>

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

Re: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[Sebastian Meyer]

Hi Iago,

I think the unlist behaviour is expected. If the list contains a mixture
of character and integer elements, the unlisted object will be a
character vector, similar to what happens when you c()oncatenate
components of different types (see the details in ?c for the hierarchy).
If you only need the numeric POSIXlt components anyway, you could do

unlist("$<-"(x, "zone", NULL))

to ensure that you get a numeric vector.
Alternatively, you can nicely do

as.data.frame(unclass(x))

to get all components in a data frame.

Concerning your second observation: Yes, the documentation of the
"tzone" attribute was wrong until very recently; I stumbled over this
exact trap one week ago and reported to R-core members. It has been
fixed in the development version (c79351) a few days ago and now says:

>   a character vector of length 3 giving the time zone name (from the 'TZ'
>   environment variable or argument 'tz' of functions creating
>   '"POSIXlt"' objects; '""' marks the current time zone)


Best regards,

Sebastian


Am 23.10.20 um 19:27 schrieb IAGO GINÉ VÁZQUEZ:
> ​Hi again,
> 
> I take advantage of my previous mail to ask you a question for which I was 
> looking  for an answer when detected the behaviour I previously told. In the 
> help of DataTimeClasses one can read:
> "POSIXlt" objects will often have an attribute "tzone", a character vector of 
> length 3 giving the time zone name from the TZ environment variable and the 
> names of the base time zone and the alternate (daylight-saving) time zone. 
> Sometimes this may just be of length one, giving the time zone name.
> Then, I asked myself if the element `zone` of POSIXlt could be different of 
> the attribute `tzone`. But I do not get that. I am not sure of understanding 
> what the "time zone name from the TZ environment variable" is if not what I 
> set through `Sys.setenv(TZ = "")`. But the next example does not behave as I 
> would expect:
> 
>> Sys.setenv(TZ = "EDT")
>> x <- as.POSIXlt(Sys.time(), "CET")
> 
>> x[1,"zone"]
> [1] "CEST"
> 
>> attributes(x) $names  [1] "sec""min""hour"   "mday"   "mon"
>> "year"   "wday"   "yday"   "isdst"  "zone"   "gmtoff" $class [1] "POSIXlt" 
>> "POSIXt" $tzone [1] "CET"  "CET"  "CEST"
> 
> So `x[1,"zone"]` is what I expect, but I would expect `attributes(x)$tzone` 
> would be related to `TZ = "EDT"`, and not to `tz = "CET"`. So, what am I 
> understanding wrongly?
> 
> Thank you!
> Stay safe,
> 
> 
> Iago
> 
> 
> De: R-devel  de part de IAGO GINÉ VÁZQUEZ 
> 
> Enviat el: divendres, 23 d’octubre de 2020 19:03
> Per a: r-devel@r-project.org 
> Tema: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone 
> as a cause of possible inconsistences?
> 
> Dear all,
> 
> I have just detected what seems a minor inconsistence with data types. If one 
> unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt 
> list has no `zone` element, while if one unlists a POSIXlt time with a non 
> GMT zone (also non specifying tz if the Sys.timezone is not GMT) gets a 
> character vector due to including the `zone` element.
> 
>> x <- as.POSIXlt(Sys.time(), "GMT")
>> (y <- unlist(x))
>   sec   min  hour  mday   mon  year  wday  
> yday isdst
>  54.99715  26.0  16.0  23.0   9.0 120.0   5.0 
> 296.0   0.0
>> str(y)
>  Named num [1:9] 55 26 16 23 9 ...
>  - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...
> 
>> x <- as.POSIXlt(Sys.time(), "CET")
>> (y <- unlist(x))
>secmin   hour   mday   
>  mon   year   wday   yday
> "19.5111262798309"   "27"   "18"   "23"   
>  "9"  "120""5"  "296"
>  isdst   zone gmtoff
>"1" "CEST" "7200"
>> str(y)
>  Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
> "

Re: [Rd] timezone tests and R-devel

[Sebastian Meyer]

Yes, you are absolutely right and I'm pretty sure this will be fixed in
one way or another.

IMO, the failing test should simply use all.equal.POSIXt's new argument
check.tzone=FALSE.

Two simple alternatives modifying all.equal.POSIXt behaviour:

- make check.tzone=FALSE the default: this is inconsistent with other
arguments of all.equal methods, always defaulting to stricter checks

- let all.equal.POSIXt generally ignore the tzone difference if tzone is
unset for one of the objects (similar to check_tzones): I think this is
a bad idea because tzone affects how POSIXt objects are printed, and
under check.tzone=TRUE, two objects shouldn't be considered "nearly
equal" if they print differently.

Best regards,

Sebastian


Am 23.10.20 um 10:28 schrieb Kasper Daniel Hansen:
> So let me try to raise this issue once more, and perhaps be more clear
> about what I think the issue is..
> 
> In my opinion there is now a bug in 
>   make check
> in R-development (tested today with r79361). As I see it, I specify a
> reasonable TZ environment variable and this leads to make check emitting
> an error.
> 
> Best,
> Kasper
> 
> On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen
> mailto:kasperdanielhan...@gmail.com>> wrote:
> 
> Yes, the potential issue I see is that 
>   make check 
> fails when I explicitly set TZ. However, I set it to be the same as
> what the system reports when I login.
> 
> Details: The system (RHEL) I am working on has
> $ strings /etc/localtime | tail -n 1
> EST5EDT,M3.2.0,M11.1.0
> $ date +%Z
> EDT
> $ echo $TZ
> US/Eastern
> 
> 
> 
> On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  <mailto:seb.me...@fau.de>> wrote:
> 
> Thank you for the report. In R-devel, all.equal.POSIXt() by default
> reports inconsistent time zones. Previously,
> 
> > x <- Sys.time()
> > all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
> 
> would return TRUE. To ignore the time zone attributes in
> R-devel, the
> argument 'check.tzone = FALSE' needs to be used.
> 
> That said, I can reproduce the 'make check' failure in R-devel
> on Ubuntu
> Linux when TZ is set, even if it is set to the system time zone:
> 
> $ export TZ=Europe/Berlin
> $ make check
> [...]
> > running code in '../../tests/reg-tests-2.R' ... OK
> >   comparing 'reg-tests-2.Rout' to
> '../../tests/reg-tests-2.Rout.save' ...7335c7335
> > < [1] "'tzone' attributes are inconsistent ('' and
> 'Europe/Berlin')"
> > ---
> >> [1] TRUE
> 
> 
> Compare the following two sessions:
> 
> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
> Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] TRUE
> 
> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e
> 'Sys.timezone(); x <- Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
> 
> 
> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
> behaviour is not new. Even with old R 3.6.3, I see
> 
> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()),
> "tzone")'
> [1] ""     "CET"  "CEST"
> 
> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
> 'attr(as.POSIXlt(Sys.time()), "tzone")'
> [1] "Europe/Berlin" "CET"           "CEST"
> 
> This might be system-specific.
> 
> I suggest to modify the test as attached for make check to pass
> in this
> setting.
> 
> Best regards,
> 
>         Sebastian
> 
> 
> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
> > The return value of Sys.time() today with a timezone of
> US/Eastern is
> > unchanged between 4.0.3-patched and devel, but on devel the
> following test
> > fails
> >   all.equal(x, as.POSIXlt(x))
> > with
> >   x = Sys.time()
> >
> > This means that devel does not complete make tests (failure on
> > tests/reg-tests-2.R)
> >
> > It is entirely possible that it is an error on my end, I use
> >   export TZ="US/Eastern"
> > but I have been using this for a while, and 

Re: [Rd] timezone tests and R-devel

[Sebastian Meyer]

Thank you for the report. In R-devel, all.equal.POSIXt() by default
reports inconsistent time zones. Previously,

> x <- Sys.time()
> all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))

would return TRUE. To ignore the time zone attributes in R-devel, the
argument 'check.tzone = FALSE' needs to be used.

That said, I can reproduce the 'make check' failure in R-devel on Ubuntu
Linux when TZ is set, even if it is set to the system time zone:

$ export TZ=Europe/Berlin
$ make check
[...]
> running code in '../../tests/reg-tests-2.R' ... OK
>   comparing 'reg-tests-2.Rout' to '../../tests/reg-tests-2.Rout.save' 
> ...7335c7335
> < [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
> ---
>> [1] TRUE


Compare the following two sessions:

> R-devel --vanilla --no-echo -e 'Sys.timezone(); x <- Sys.time(); all.equal(x, 
> as.POSIXlt(x))'
[1] "Europe/Berlin"
[1] TRUE

> TZ='Europe/Berlin' R-devel --vanilla --no-echo -e 'Sys.timezone(); x <- 
> Sys.time(); all.equal(x, as.POSIXlt(x))'
[1] "Europe/Berlin"
[1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"


So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
behaviour is not new. Even with old R 3.6.3, I see

> R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()), "tzone")'
[1] "" "CET"  "CEST"

> TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()), 
> "tzone")'
[1] "Europe/Berlin" "CET"   "CEST"

This might be system-specific.

I suggest to modify the test as attached for make check to pass in this
setting.

Best regards,

Sebastian


Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
> The return value of Sys.time() today with a timezone of US/Eastern is
> unchanged between 4.0.3-patched and devel, but on devel the following test
> fails
>   all.equal(x, as.POSIXlt(x))
> with
>   x = Sys.time()
> 
> This means that devel does not complete make tests (failure on
> tests/reg-tests-2.R)
> 
> It is entirely possible that it is an error on my end, I use
>   export TZ="US/Eastern"
> but I have been using this for a while, and R-4.0.3-patched built today
> passes make tests.
> 
> Details below, and I am happy to provide more information.
> 
> Build platform: inside a conda environment on linux. I have been doing this
> for a while, but it is certainly a non-standard setup. GCC 7.3
> 
> Best,
> Kasper
> 
> On R version 4.0.3 beta (2020-10-01 r79286) I get
> 
>> x = Sys.time()
>> attributes(x)
> $class
> [1] "POSIXct" "POSIXt"
> 
>> attributes(as.POSIXlt(x))
> $names
>  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"   "yday"
>  [9] "isdst"  "zone"   "gmtoff"
> 
> $class
> [1] "POSIXlt" "POSIXt"
> 
> $tzone
> [1] "US/Eastern" "EST""EDT"
> 
>> all.equal(x, as.POSIXlt(x))
> [1] TRUE
> 
> On R Under development (unstable) (2020-10-01 r79286) I get
>> x = Sys.time()
>> all.equal(x,x)
> [1] TRUE
>> attributes(as.POSIXlt(x))
> $names
>  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"   "yday"
>  [9] "isdst"  "zone"   "gmtoff"
> 
> $class
> [1] "POSIXlt" "POSIXt"
> 
> $tzone
> [1] "US/Eastern" "EST""EDT"
> 
>> all.equal(x, as.POSIXlt(x))
> [1] "'tzone' attributes are inconsistent ('' and 'US/Eastern')"
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
Index: tests/reg-tests-2.R
===
--- tests/reg-tests-2.R	(revision 79287)
+++ tests/reg-tests-2.R	(working copy)
@@ -2838,7 +2838,7 @@
 ## all.equal datetime method
 x <- Sys.time()
 all.equal(x,x)
-all.equal(x, as.POSIXlt(x))
+all.equal(x, as.POSIXlt(x), check.tzone = FALSE)
 all.equal(x, as.numeric(x))  # errored in R <= 4.0.2
 all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
 all.equal(x, x+1e-4)
Index: tests/reg-tests-2.Rout.save
===
--- tests/reg-tests-2.Rout.save	(revision 79287)
+++ tests/reg-tests-2.Rout.save	(working copy)
@@ -7368,7 +7368,7 @@
 > x <- Sys.time()
 > all.equal(x,x)
 [1] TRUE
-> all.equal(x, as.POSIXlt(x))
+> all.equal(x, as.POSIXlt(x), check.tzone = FALSE)
 [1] TRUE
 > all.equal(x, as.numeric(x))  # errored in R <= 4.0.2
 [1] "'current' is not a POSIXt"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Error in CHECK caused by dev.off()

[Sebastian Meyer]

Back to the original topic: graphics.off() is probably not what you
want. It shuts down *all* open graphics devices, not just the current
one. Example code or your plotting functions should not do that.

Calling graphics.off() in example code will also disturb standard R CMD
check. Before running the examples, R CMD check opens a pdf device to
store any graphics output [1]. You will find the resulting pdf file in
{PACKAGE}.Rcheck/{PACKAGE}-Ex.pdf after R CMD check. [BTW, the plots
therein will be usefully annotated with the names of the originating
help pages.]

R CMD check will eventually fail from trying to close this pdf device
after running the examples [2], if you have already closed all graphics
devices (including this pdf device) through code in your examples. This
is where the

Error in grDevices::dev.off() :
  cannot shut down device 1 (the null device)
Execution halted

actually came from.

Finally, many of the graphics devices are platform-specific and the png
device may not even be available. So it is reasonable to condition on
capabilities("png") or to put such examples in \donttest. The latter is
also used in the example code for grDevices::png, at least in the Unix
version of the man page [3].

HTH!

Sebastian


[1]: file.path(R.home("share"), "R", "examples-header.R")
[2]: file.path(R.home("share"), "R", "examples-footer.R")
[3]:
https://github.com/r-devel/r-svn/blob/15253534aa1f4e91d33d9b0e3f035daedfe750bb/src/library/grDevices/man/unix/png.Rd#L249-L259

BTW, on Unix-alikes, example(png) writes to files myplot.png,
myplot1.jpeg, and myplot2.jpeg in the current working directory. This
should be fixed.



Am 22.07.20 um 19:25 schrieb Helmut Schütz:
> Hi Serguei,
> 
> Serguei Sokol wrote on 2020-07-22 15:51:
>> Hmm... I see 2 possibilities for still getting an error while the
>> concerned part of code is not supposed to be run:
>>
>>  - either you are running not updated version of your package;
> 
> I _can_ built the package and it runs as intended. Only the CHECK throws
> the error.
> 
>>  - or the error comes from some other place of the code.
> 
> Closing the device is required only _once_ in the entire package.
> In my NAMESPACE I have (and had in all previous versions):
> importFrom(grDevices, png, graphics.off, dev.list, dev.off)
> 
>> Sorry but without a minimal reproducible example I cannot help more.
> 
> The problem is that I cannot reproduce it as well. Only CHECK laments
> about dev.off() which I changed to graphics.off() in the meantime.
> 
> library(grDevices)
> foo <- TRUE   # shall we plot?
> png.path <- "~/" # user's home folder
> png.path <- normalizePath(png.path)
> if (foo) {
>   png(paste0(png.path, "test.png"), width = 480, height = 480, pointsize
> = 12)
> }
> plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
> if (foo) {
>   graphics.off()
> }
> 
> Best,
> Helmut
>

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

Re: [R-pkg-devel] import 'as' from another package

[Sebastian Meyer]

Following WRE 1.5.6 (Namespaces with S4 classes and methods), you should
have "Depends: methods" in your DESCRIPTION, and "import(methods)" or a
more selective "importFrom(methods, ...)" directive in your NAMESPACE.

Then you would usually use the NAMESPACE directive

importMethodsFrom(package, generic)

to explicitly import S4 methods exported from another package.
However, the raster package does not do

exportMethods(coerce)

so if you try

importMethodsFrom(raster, coerce)

you will get

> Error: object ‘coerce’ is not exported by 'namespace:raster'

when trying to install your package (also during R CMD check, of course).

To solve this problem, you could either

- import raster's entire NAMESPACE via import(raster)

- or ask maintainer("raster") to exportMethods(coerce)

- or do

importClassesFrom(raster, RasterLayer)

which will magically make the corresponding coerce methods available as
well.

HTH!

Sebastian Meyer


Am 21.07.20 um 00:41 schrieb Tim Keitt:
> Thanks for pointing to the bug.
> 
> Now I am finding I cannot use the 'as' definitions from 'raster' without
> loading the package. Do I need an @import directive that specifies the
> definitions in the 'raster' package? My understanding is that the
> 'setAs' function generates a 'coerce,...' signature but I'm not sure how
> to import it to my package.
> 
> Thanks again.
> 
> THK
> 
> On Mon, Jul 20, 2020 at 2:25 PM Sebastian Meyer  <mailto:seb.me...@fau.de>> wrote:
> 
> Yes, indeed, it is confusing. You don't need to file a new bug
> report, though. There is one already:
> 
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17179
> 
> Please feel free to comment there. This thread could serve as
> another confirmation. :-)
> 
> Best regards,
> Sebastian
> 
> Am 20. Juli 2020 18:36:21 MESZ schrieb Ben Bolker  <mailto:bbol...@gmail.com>>:
> >    I think this is a classic confusing R message.  Try adding methods
> >to the Imports: statement in your DESCRIPTION file and see if that
> >helps. (Maybe I should file a bug report about that error message - it
> >confuses me every time.)
> >
> >On 7/20/20 12:34 PM, Tim Keitt wrote:
> >> It works but "check" gives
> >>
> >> > checking package dependencies ... ERROR
> >>   Namespace dependency not required: ‘methods’
> >>
> >> THK
> >>
> >> On Mon, Jul 20, 2020 at 11:24 AM Ben Bolker  <mailto:bbol...@gmail.com>
> >> <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
> >>
> >>     @importFrom methods as
> >>
> >>     ?
> >>
> >>     On 7/20/20 12:06 PM, Tim Keitt wrote:
> >>     > I have
> >>     >
> >>     >    if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")
> >>     >
> >>     > in a package and its not finding the coerce definition from the
> >>     raster
> >>     > package. I know I need to add an @import roxygen2 directive of
> >>     some kind,
> >>     > but I'm not sure the correct syntax. My first try generated a
> >>     warning that
> >>     > it was not needed.
> >>     >
> >>     > What is the correct way to do this? Or does raster need to
> >>     export this
> >>     > definition?
> >>     >
> >>     > THK
> >>     >
> >>     >       [[alternative HTML version deleted]]
> >>     >
> >>     > __
> >>     > R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org>
> >>     <mailto:R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org>> mailing list
> >>     > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >>     __
> >>     R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org>
> >>     <mailto:R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org>> mailing list
> >>     https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >       [[alternative HTML version deleted]]
> >
> >__
> >R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] import 'as' from another package

[Sebastian Meyer]

Yes, indeed, it is confusing. You don't need to file a new bug report, though. 
There is one already:

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17179

Please feel free to comment there. This thread could serve as another 
confirmation. :-)

Best regards,
Sebastian

Am 20. Juli 2020 18:36:21 MESZ schrieb Ben Bolker :
>    I think this is a classic confusing R message.  Try adding methods 
>to the Imports: statement in your DESCRIPTION file and see if that 
>helps. (Maybe I should file a bug report about that error message - it 
>confuses me every time.)
>
>On 7/20/20 12:34 PM, Tim Keitt wrote:
>> It works but "check" gives
>>
>> > checking package dependencies ... ERROR
>>   Namespace dependency not required: ‘methods’
>>
>> THK
>>
>> On Mon, Jul 20, 2020 at 11:24 AM Ben Bolker > > wrote:
>>
>> @importFrom methods as
>>
>> ?
>>
>> On 7/20/20 12:06 PM, Tim Keitt wrote:
>> > I have
>> >
>> >    if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")
>> >
>> > in a package and its not finding the coerce definition from the
>> raster
>> > package. I know I need to add an @import roxygen2 directive of
>> some kind,
>> > but I'm not sure the correct syntax. My first try generated a
>> warning that
>> > it was not needed.
>> >
>> > What is the correct way to do this? Or does raster need to
>> export this
>> > definition?
>> >
>> > THK
>> >
>> >       [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org
>>  mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> __
>> R-package-devel@r-project.org
>>  mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Sebastian Meyer]

Has the discussion about potential updates to Rd2HTML come to an end?
Should I be prepared to fix non-file package-anchored links in
(non-roxygen) packages I maintain, i.e., look up the help file structure
of the referenced packages?

I don't yet believe that R has really given up on supporting
developer-friendly, direct and simple links to

 _topic_   rather than_file_

\link[rgeos]{gIntersection} -> \link[rgeos]{topo-bin-gIntersection}

\link[colorspace]{heat_hcl} -> \link[colorspace]{rainbow_hcl}

\link[RColorBrewer]{brewer.pal} -> \link[RColorBrewer]{ColorBrewer}

\link[gridExtra]{grid.arrange}  -> link[gridExtra]{arrangeGrob}

\link[ggplot2]{geom_line}   -> \link[ggplot2]{geom_path}

for pointing to other packages which are only in Suggests and thus not
necessarily installed at install-time of the referencing package.

Topic-based links to external functions are so much more intuitive. I do
not understand why there should be a penalty for clearly identifying the
target package as opposed to just writing \link{topic} and hoping that
the intended package will be found by the help system at run time.

Sebastian


Am 02.07.20 um 11:20 schrieb Gábor Csárdi:
> You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
> use R-devel.
> 
> Alternatively, and you don't need R-devel for this, you can run R CMD
> --html INSTALL on your package, and then look for messages that
> contain "treated as a topic", e.g.
> 
> curl_fdshtml
> Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
> link ‘multi_fdset’ in package ‘curl’ does not exist and so has been
> treated as a topic
> 
> Gabor
> 
> 
> On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki  wrote:
>>
>> Hi,
>> What is the recommended way to test for those issues locally?
>> If it is tested during cran submission, then seems reasonable to be enabled 
>> just by --as-cran switch. Is it?
>> Thanks
>>
>> On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford,  wrote:
>>>
>>> Thank you!
>>>
>>> -Original Message-
>>> From: Gábor Csárdi 
>>> Date: Tuesday, June 16, 2020 at 4:32 PM
>>> To: Wayne Oldford 
>>> Cc: List r-package-devel 
>>> Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
>>> package-anchored link(s)
>>>
>>> This is how to look up the filename. The first "sp" is the topic name,
>>> the second is the package name.
>>>
>>> > help("sp", "sp")[[1]]
>>> [1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
>>>
>>> So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}
>>>
>>> Gabor
>>>
>>> On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford  
>>> wrote:
>>> >
>>> > Hi
>>> >
>>> > I got caught by this new test this week in trying to push an updated 
>>> release of the loon package to CRAN.
>>> >
>>> > By following this thread, I corrected my cross-references to external 
>>> packages but I got stymied by
>>> > the one I hoped to give to the  "sp" package for Spatial data
>>> >
>>> > _
>>> >
>>> > Here is the history:
>>> >
>>> > I tried
>>> >\link[sp:sp]{sp}
>>> > which failed here:
>>> > Debian: 
>>> 
>>> > Status: 1 WARNING
>>> >
>>> >
>>> > That was meant to correct an earlier attempt (it did for other links 
>>> to "scales" for example) where I had tried
>>> >   \link[sp]{sp}
>>> > and  failed here:
>>> > Debian: 
>>> 
>>> > Status: 1 WARNING
>>> >
>>> >
>>> > So to complete the possibilities as I understand them,  I just now 
>>> tried
>>> >\link{sp}
>>> > which, as might be expected, failed here:
>>> > Debian: 
>>> 
>>> > Status: 1 WARNING
>>> > As expected, error here was different:  "Missing  link"  as opposed 
>>> to "Non-file package-anchored link"
>>> >
>>> > _
>>> >
>>> >
>>> > I am not sure whether I have missed a subtlety in WRE or that the 
>>> peculiar circumstance
>>> > where the package, the topic, and the file name are all identical 
>>> (sp) is some weird boundary case.
>>> >
>>> > Without further advice, I think I am just going to remove the link to 
>>> "sp".
>>> > It really is just a courtesy link to the package description for "sp".
>>> >
>>> > Thanks in advance for your thoughts.
>>> >
>>> > Wayne
>>> >
>>> >
>>> >
>>> >
>>> > -Original Message-
>>> > From: R-package-devel  on 
>>> behalf of Georgi Boshnakov 
>>> > Date: Tuesday, June 16, 2020 at 9:27 AM
>>> > To: Gábor Csárdi , Duncan Murdoch 
>>> 
>>> > Cc: List r-package-devel 
>>> > Subject: Re: 

Re: [R-pkg-devel] S4 methods

[Sebastian Meyer]

This is a new check in R-devel. The NEWS say:

> R CMD check etc now warn when a package exports non-existing S4 classes or 
> methods, also in case of no "methods" presence

In your case, the NAMESPACE contains

> exportClasses(classify)

> exportClasses(gonad_mature)

> exportClasses(morphMat)

but your package does not define these S4 classes.

You seem to instruct roxygen2 to create these invalid directives using
@exportClass tags manually instead of just @export. Simply remove these
wrong @exportClass tags from your source files and regenerate your
NAMESPACE.

Best regards,

Sebastian Meyer


Am 02.06.20 um 10:01 schrieb Edgar Josymar Torrejón-Magallanes:
> Dear members
> 
> I just finished some minor updates to an R package (sizeMat) I've had on
> CRAN (haven't had to update in a month). My package passes Check on my
> local machine, but it just bounced back from CRAN with the message
> 
> Warning: S4 exports specified in 'NAMESPACE' but not defined in package
> 'sizeMat'
> 
> I use roxygen2 to build my package NAMESPACE and don't have any S4 exports
> that I'm aware of.
> 
> Perhaps this might be related to changes in R version 4.0.0?
> How could I fix this problem?
> 
> Thanks.
>

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

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

[Sebastian Meyer]

This is a new check in R-devel. The NEWS say:

> R CMD check etc now warn when a package exports non-existing S4 classes or 
> methods, also in case of no "methods" presence

In your case, the NAMESPACE contains

> exportClasses("bujar")
> exportMethods("show")

but the package neither defines an S4 class "bujar" nor methods for the
S4 generic "show". You should remove these two lines from your NAMESPACE.

Best regards,

Sebastian Meyer


Am 01.06.20 um 18:34 schrieb Wang, Zhu:
> Dear All,
> 
> I received warnings regarding a package:
> 
> https://cran.r-project.org/web/checks/check_results_bujar.html
> 
> The warning still occurred after I changed export(bujar, gcv.enet) to 
> export(bujar) in NAMESPACE. The function bujar was defined in the package, so 
> I probably missed something in Sec 1.5.6 in Writing R Extensions.
> 
> Could somebody kindly advise how to address the warning?
> 
> Thanks,
> 
> Zhu Wang
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Sebastian Meyer]

I can confirm this changed behaviour. I just compared R-3.6.3 with
yesterday's R-devel. Using R-devel, the tempfile opened by the editor
(Emacs for me, but shouldn't matter) contains doubled backslashes.

This could be related to

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17800

Best regards,

Sebastian


Am 15.05.20 um 03:50 schrieb William Dunlap via R-devel:
> Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
> double all the backslashes when options(keep.source=TRUE)?  E.g.,
> 
>> options(keep.source=TRUE)
>> f <- function(x) { cat("\t", x, "\n", sep="") }
>> edit(f) # exit the editor without making any changes
> The editor (vi or notepad) shows doubled backslashes
> function(x) { cat("\\t", x, "\\n", sep="") }
> as does the return value of edit().
> 
> If I set options(keep.source=FALSE) before defining 'f' or remove t's
> 'srcref' attribute then the backslashes are left alone.
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
> 
>   [[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] S3 method dispatch for methods in local environments

[Sebastian Meyer]

Dear Wolfgang,

I think this new behaviour is related to the following R 4.0.0 NEWS item:

> S3 method lookup now by default skips the elements of the search path between 
> the global and base environments. 

Your environment "myenv" is attached at position 2 of the search() path
and thus now skipped in S3 method lookup.

I have just noticed that

attr(methods(class="myclass"), "info")
getS3method("print", "myclass")

both still find your function in myenv although the generic's
UseMethod() won't. I find this a bit confusing.

A solution to make R >= 4.0.0 find your method is to register the S3
method using the new function .S3method (intended for R scripts, not
packages). After running

.S3method("print", "myclass", myenv$print.myclass)

your method will be found from the generic.

Best regards,

Sebastian


Am 12.05.20 um 20:05 schrieb Viechtbauer, Wolfgang (SP):
> Dear All,
> 
> In R 3.6.3 (and earlier), method dispatch used to work for methods stored in 
> local environments that are attached to the search path. For example:
> 
> myfun <- function(y) {
>out <- list(y=y)
>class(out) <- "myclass"
>return(out)
> }
> 
> print.myclass <- function(x, ...) print(formatC(x$y, format="f", digits=5))
> 
> myfun(1:4)
> 
> # prints: [1] "1.0" "2.0" "3.0" "4.0"
> 
> rm(print.myclass)
> myenv <- new.env()
> myenv$print.myclass <- local(function(x, ...) print(formatC(x$y, format="f", 
> digits=5)), myenv)
> attach(myenv)
> myfun(1:4)
> 
> # still prints: [1] "1.0" "2.0" "3.0" "4.0"
> 
> But since R 4.0.0, this no longer words and the above prints:
> 
> $y
> [1] 1 2 3 4
> 
> attr(,"class")
> [1] "myclass"
> 
> Is this intended? And is there a way to still make this work?
> 
> Best,
> Wolfgang
> 
> __
> 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: [R-pkg-devel] Errors in r-devel (Linux) and r-patched (Solaris)

[Sebastian Meyer]

Do both of your R installations use the same version of lme4 ?

A new lme4 version has been published on CRAN yesterday and some changes
regarding default numerical tolerances in optimizations could explain
the difference in your results. See the NEWS here:
https://cran.r-project.org/web/packages/lme4/news.html

Best regards,

Sebastian Meyer


Am 08.04.20 um 13:43 schrieb Helmut Schütz:
> Dear all,
> 
> I was notified about errors:
> https://cran.r-project.org/web/checks/check_results_replicateBE.html
> 
> Since I don't have access to those operating systems, I'm a little bit
> lost.
> Here is what I get with 64bit R on Windows:
> library(replicateBE)
> x <- method.B(details = TRUE, print = FALSE,
>   data = rds30, option = 1)[c(10, 19)]
> y <- c(17.86418, 92.73371)
> d <- as.numeric(signif(abs(x - y), 7))
> 
> With R 3.6.2
> print(d)
> [1] 4.431372e-06 1.182994e-07
> 
> With R 3.6.3
> print(d)
> [1] 1.078696e-05 1.182989e-07
> 
> x[10] are Satterthwaite's degrees of freedom obtained by package
> pbkrtest. In both R-versions I use its current version (0.4-8.6 of
> 2020-02-20).
> 
> Any ideas / suggestions?
> As a workaround I could reduce the tolerance of testthat's
> expect_quivalent() from to currently 5e-7 to a higher (_which one?_)
> value. But I still want to know what might be going on the CRAN's
> linux/solaris devel/patched installations since the other R-versions on
> all operating systems passed the tests.
> 
> Cheers,
> Helmut
>

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

Re: [R-pkg-devel] CRAN error with current version

[Sebastian Meyer]

The reason that your package does not pass the incoming checks is

> * checking CRAN incoming feasibility ... NOTE
> Maintainer: ‘Cristian Quiroz-Moreno ’
> 
> Uses the superseded package: ‘snow’

You would need to explain to CRAN why you need to use "snow" rather than
base R's "parallel" package. But I guess you should actually replace
"snow" by "parallel" in your package.

Cheers,

Sebastian


Am 24.03.20 um 17:50 schrieb Daniel Quiroz Moreno:
> Dear community,
> 
> I have an issue with the current version of my package. The current CRAN
> version is 1.1.0 when it was submitted, I had no warnings. These days I
> fixed an issue and I would like to submit a minor version 1.1-1. I have no
> errors or warnings in the local check.
> 
> Even though, when I submit to CRAN, it does not pass the automatic check.
> The mail does not show any error or warning for the newest version (1.1-1)
> but it points to a warning for the current version (1.1.0). I have
> corrected this warning in the newest version but it does not pass the CRAN
> check.
> 
> Please, can you help me how to fix this? I mean, how to avoid the current
> CRAN version warnings, instead of the newest version?
> 
> If you would like to see the logs, I paste the mail.
> 
> 
> package RGCxGC_1.1-1.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> Windows: <
> https://win-builder.r-project.org/incoming_pretest/RGCxGC_1.1-1_20200320_181616/Windows/00check.log
>>
> Status: 2 NOTEs
> Debian: <
> https://win-builder.r-project.org/incoming_pretest/RGCxGC_1.1-1_20200320_181616/Debian/00check.log
>>
> Status: 1 NOTE
> 
> Last released version's CRAN status: WARN: 2, NOTE: 6, OK: 5
> See: 
> 
> Last released version's additional issues:
>   donttest 
> 
> CRAN Web: 
> 
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on
> the R-package-devel mailing list:
> 
> If you are fairly certain the rejection is a false positive, please
> reply-all to this message and explain.
> 
> More details are given in the directory:
> <
> https://win-builder.r-project.org/incoming_pretest/RGCxGC_1.1-1_20200320_181616/
>>
> The files will be removed after roughly 7 days.
> 
> No strong reverse dependencies to be checked.
>

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

Re: [R-pkg-devel] RES: Possible unknown color in r

[Sebastian Meyer]

Hi Tiago,

Then it seems likely that an update of a direct or indirect dependency
of your package causes this failure on CRAN's check system.

ggplot2 currently fails with a similar error message on CRAN

> Error: Unknown colour name: NA

(https://cran.r-project.org/web/checks/check_results_ggplot2.html)

This again seems to come from an update of the "farver" package which is
an indirect dependency of ggplot2 via package "scales"...

So maybe if you update your local installation of "farver" to version
2.0.2 from CRAN, you might be able to reproduce the error.

What I find a bit strange is that the CRAN package website displays
version 2.0.1 while the newer version 2.0.2 can be found in the package
archive.

Best regards,

Sebastian


Am 10.01.20 um 14:17 schrieb Tiago Olivoto:
> Hi Joris,
> Thank you so much for your assistance.
> I've built and checked my package with:
> R CMD build /d/Desktop/metan
> R CMD check --as-cran metan_1.2.1.tar.gz
> 
> No WARNINGS were observed. Please, see the log file attached.
> Sorry for failing in providing the link to access the check results in the
> last email. You can see the link to the test that doesn't pass bellow.
> 
> Dear maintainer,
>  package metan_1.2.1.tar.gz does not pass the incoming checks automatically,
> please see the following pre-tests:
> Windows:
>  153/Windows/00check.log>
> 
> Status: 1 WARNING, 1 NOTE
> Debian:
>  153/Debian/00check.log>
> 
> It sounds strange because in the last submissions the package passed in the
> incoming checks, and the only change I've made from v1.2.0 to 1.2.1 was
> adding some references in the description file.
> Best regards,
> Tiago
> 
> -Mensagem original-
> De: Joris Meys  
> Enviada em: sexta-feira, 10 de janeiro de 2020 09:23
> Para: r-package-devel@r-project.org; tiagooliv...@gmail.com
> Assunto: Re: [R-pkg-devel] Possible unknown color in r
> 
> Hi Tiago,
> 
> Without knowing which package you're talking about or a link to the check
> results, it's impossible to know whether that warning is a proper one or a
> side effect of something else. 
> 
> In general though: it is well known that relying on devtools is not enough
> for a good CRAN submission. The guidelines for CRAN clearly state :
> 
> "Please ensure that R CMD check --as-cran has been run on the tarball to be
> uploaded before submission. This should be done with the current version of
> R-devel (or if that is not possible and explained in the submission, current
> R-patched or the current release of R.)"
> 
> So before submitting a package to CRAN and after running your devtools::
> check_etc, open a terminal and run the following commands:
> 
> R CMD build path_to_pkg_folder
> R CMD check --as-cran package_version.tar.gz
> 
> The --as-cran is important, as is doing so against a R-devel. I use devtools
> myself extensively, but these checks have to be done outside the RStudio
> ecosystem to be sure.
> 
> Kind regards
> Joris
> 
> --
> Joris Meys
> Statistical consultant
> 
> Department of Data Analysis and Mathematical Modelling Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> --
> 
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
> 
> 
> From: R-package-devel  on behalf of
> Tiago Olivoto 
> Sent: Friday, January 10, 2020 12:43 PM
> To: r-package-devel@r-project.org
> Subject: [R-pkg-devel] Possible unknown color in r
> 
> Dear all,
> 
> In the last submission of my package the CRAN team has suggested including
> some references in the description field of the DESCRIPTION file.
> When I submitted it to CRAN it did not pass the incoming checks
> automatically and I got the following WARNING.
> 
> 
> 
> Quitting from lines 108-117 (vignettes_metan.Rmd)
> 
> Error: processing vignette 'vignettes_metan.Rmd' failed with diagnostics:
> 
> Unknown colour name: transparent
> 
> 
> 
> It seems that this warning is related to a function with the argument
> 'col.segm.gen = "transparent"'.
> 
> I don't changed anything in this function and in the last submissions no
> warning was related.
> 
> For curiosity I ran:
> 
>> col2rgb("yellow")
> 
>   [,1]
> 
> red255
> 
> green  255
> 
> blue 0
> 
> 
> 
>> col2rgb("transparent")
> 
>   [,1]
> 
> red255
> 
> green  255
> 
> blue   255
> 
> 
> 
> No warnings or errors were observed while running devtools::check_rhub(),
> devtools::check_win_devel(), and devtools::check_win_release()
> 
> Any suggestion?
> 
> Best,
> 
> Tiago
> 
> 
> 
> 
> [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> =
> __
> R-package-devel@r-project.org mailing list
> 

Re: [R-pkg-devel] vignette error in debian

[Sebastian Meyer]

I forgot to mention: the code that you pasted in the email does not reproduce 
the error. The vignette actually runs different code. You need to run the code 
from the vignette to see the error (with the environment variable set).

Cheers, Sebastian

Am 28. November 2019 18:16:12 MEZ schrieb Sebastian Meyer :
>I was able to reproduce the vignette error in an R-devel session with
>this environment variable set. It came from a strange polygon() call
>with x and y arguments being matrices with list elements.
>
>I cannot test at the moment. Maybe you condition on
>class(something) == "matrix"
>somewhere in your code? This should be replaced by 
>inherits(something, "matrix")
>since in future R, matrix objects also formally belong to the array
>class, so the class vector has length two. See the corresponding blog
>post by Martin Mächler for further details:
>https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again/index.html
>
>Cheers, Sebastian
>
>Am 28. November 2019 14:56:37 MEZ schrieb Fernando Roa
>:
>>Thx Sebastian
>>I set _R_CLASS_MATRIX_ARRAY_ to true in console and also in onLoad,
>but
>>could not replicate the error in console.
>>In addition, setting _R_CLASS_MATRIX_ARRAY_ to "" in onLoad did not
>>solve the problem while checking as cran.
>>
>>I do not understand how the values I got from the debug print when
>>checking
>>as cran could result in the error.
>>
>>Any ideas?
>>
>>On Thu, Nov 28, 2019 at 3:00 AM Sebastian Meyer 
>>wrote:
>>
>>> This is most likely related to the recently changed class of
>>matrices.
>>>
>>> R> class(matrix(1))
>>>
>>> returned "matrix" but will return c("matrix", "array") in future
>>> versions of R. See the corresponding item in the R-devel NEWS
>>>
>>> https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
>>>
>>> To reproduce the error, you need a fairly recent R-devel and set the
>>> environment variable
>>>
>>> _R_CLASS_MATRIX_ARRAY_=true
>>>
>>> On CRAN, this configuration is currently only used in the two
>R-devel
>>> flavors which give warnings for your package.
>>>
>>> Happy debugging!
>>>
>>> Sebastian
>>>
>>>
>>> Am 27.11.19 um 23:16 schrieb Fernando Roa:
>>> > After Ege answer, I could replicate the error(s): list' object
>>cannot be
>>> > coerced to type 'double'
>>> > with CMD check: bash R-devel.sh CMD check --as-cran
>>> > idiogramFISH_1.9.1.tar.gz  in a vmware
>>> > debian guest with the r-devel (4.0) version of R installed after:
>>> > http://singmann.org/installing-r-devel-on-linux/
>>> >
>>> > Error does not occur in a R-devel console session installed
>>> > in /usr/local/lib/R-devel/bin
>>> >
>>> > After adding debug prints to the code, problem points to a mapply
>>> >
>>> > Here are the values I got with debug printing
>>> >
>>> > labelytoplot<-list(c(0.654545454545455, 0.654545454545455,
>>> > 0.763636363636364, 0.763636363636364), c(0.872727272727273,
>>> > 0.872727272727273, 0.981818181818182, 0.981818181818182),
>>> > c(1.09090909090909, 1.09090909090909, 1.2, 1.2),
>>c(1.30909090909091,
>>> > 1.30909090909091, 1.41818181818182, 1.41818181818182))
>>> > labelxtoplot<-list(c(42.5, 44.75, 44.75, 42.5), c(42.5, 44.75,
>>44.75,
>>> > 42.5), c(42.5, 44.75, 44.75, 42.5), c(42.5, 44.75, 44.75, 42.5))
>>> > borders<-marks<-c("green","blue","yellow","black")
>>> >
>>> > CODE producing the error in R CMD check only:
>>> > # plot(1:50)
>>> > mapply(function(x,y,z,w) graphics::polygon(x=x,
>>> >y=y,
>>> >col=z,
>>> >   
>lwd=rep(.5,length(marks)
>>)
>>> >,border=w
>>> > ),
>>> > x = labelxtoplot,
>>> > y = labelytoplot
>>> > ,z = marks
>>> > ,w = borders
>>> > )
>>> >
>>> > Grateful for any guidance ,
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Nov 27, 2019 at 8:34 AM Ege Rubak 
>>wrote:
>>> >
>&g

Re: [R-pkg-devel] vignette error in debian

[Sebastian Meyer]

I was able to reproduce the vignette error in an R-devel session with this 
environment variable set. It came from a strange polygon() call with x and y 
arguments being matrices with list elements.

I cannot test at the moment. Maybe you condition on
class(something) == "matrix"
somewhere in your code? This should be replaced by 
inherits(something, "matrix")
since in future R, matrix objects also formally belong to the array class, so 
the class vector has length two. See the corresponding blog post by Martin 
Mächler for further details:
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again/index.html

Cheers, Sebastian

Am 28. November 2019 14:56:37 MEZ schrieb Fernando Roa :
>Thx Sebastian
>I set _R_CLASS_MATRIX_ARRAY_ to true in console and also in onLoad, but
>could not replicate the error in console.
>In addition, setting _R_CLASS_MATRIX_ARRAY_ to "" in onLoad did not
>solve the problem while checking as cran.
>
>I do not understand how the values I got from the debug print when
>checking
>as cran could result in the error.
>
>Any ideas?
>
>On Thu, Nov 28, 2019 at 3:00 AM Sebastian Meyer 
>wrote:
>
>> This is most likely related to the recently changed class of
>matrices.
>>
>> R> class(matrix(1))
>>
>> returned "matrix" but will return c("matrix", "array") in future
>> versions of R. See the corresponding item in the R-devel NEWS
>>
>> https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
>>
>> To reproduce the error, you need a fairly recent R-devel and set the
>> environment variable
>>
>> _R_CLASS_MATRIX_ARRAY_=true
>>
>> On CRAN, this configuration is currently only used in the two R-devel
>> flavors which give warnings for your package.
>>
>> Happy debugging!
>>
>> Sebastian
>>
>>
>> Am 27.11.19 um 23:16 schrieb Fernando Roa:
>> > After Ege answer, I could replicate the error(s): list' object
>cannot be
>> > coerced to type 'double'
>> > with CMD check: bash R-devel.sh CMD check --as-cran
>> > idiogramFISH_1.9.1.tar.gz  in a vmware
>> > debian guest with the r-devel (4.0) version of R installed after:
>> > http://singmann.org/installing-r-devel-on-linux/
>> >
>> > Error does not occur in a R-devel console session installed
>> > in /usr/local/lib/R-devel/bin
>> >
>> > After adding debug prints to the code, problem points to a mapply
>> >
>> > Here are the values I got with debug printing
>> >
>> > labelytoplot<-list(c(0.654545454545455, 0.654545454545455,
>> > 0.763636363636364, 0.763636363636364), c(0.872727272727273,
>> > 0.872727272727273, 0.981818181818182, 0.981818181818182),
>> > c(1.09090909090909, 1.09090909090909, 1.2, 1.2),
>c(1.30909090909091,
>> > 1.30909090909091, 1.41818181818182, 1.41818181818182))
>> > labelxtoplot<-list(c(42.5, 44.75, 44.75, 42.5), c(42.5, 44.75,
>44.75,
>> > 42.5), c(42.5, 44.75, 44.75, 42.5), c(42.5, 44.75, 44.75, 42.5))
>> > borders<-marks<-c("green","blue","yellow","black")
>> >
>> > CODE producing the error in R CMD check only:
>> > # plot(1:50)
>> > mapply(function(x,y,z,w) graphics::polygon(x=x,
>> >y=y,
>> >col=z,
>> >lwd=rep(.5,length(marks)
>)
>> >,border=w
>> > ),
>> > x = labelxtoplot,
>> > y = labelytoplot
>> > ,z = marks
>> > ,w = borders
>> > )
>> >
>> > Grateful for any guidance ,
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Nov 27, 2019 at 8:34 AM Ege Rubak 
>wrote:
>> >
>> >> On 27/11/2019 00.22, Fernando Roa wrote:
>> >>> - I used a guest debian 10 in vmware in my system, and couldn't
>> replicate
>> >>> the error installing with R CMD INSTALL 
>> >>
>> >> I guess you should rather run "R CMD check ..." on the tar.gz file
>to
>> >> reproduce the error.
>> >>
>> >> Hope that helps.
>> >>
>> >> /Ege
>> >>
>> >> __
>> >> R-package-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>> >
>> >

Re: [R-pkg-devel] vignette error in debian

[Sebastian Meyer]

This is most likely related to the recently changed class of matrices.

R> class(matrix(1))

returned "matrix" but will return c("matrix", "array") in future
versions of R. See the corresponding item in the R-devel NEWS

https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html

To reproduce the error, you need a fairly recent R-devel and set the
environment variable

_R_CLASS_MATRIX_ARRAY_=true

On CRAN, this configuration is currently only used in the two R-devel
flavors which give warnings for your package.

Happy debugging!

Sebastian


Am 27.11.19 um 23:16 schrieb Fernando Roa:
> After Ege answer, I could replicate the error(s): list' object cannot be
> coerced to type 'double'
> with CMD check: bash R-devel.sh CMD check --as-cran
> idiogramFISH_1.9.1.tar.gz  in a vmware
> debian guest with the r-devel (4.0) version of R installed after:
> http://singmann.org/installing-r-devel-on-linux/
> 
> Error does not occur in a R-devel console session installed
> in /usr/local/lib/R-devel/bin
> 
> After adding debug prints to the code, problem points to a mapply
> 
> Here are the values I got with debug printing
> 
> labelytoplot<-list(c(0.654545454545455, 0.654545454545455,
> 0.763636363636364, 0.763636363636364), c(0.872727272727273,
> 0.872727272727273, 0.981818181818182, 0.981818181818182),
> c(1.09090909090909, 1.09090909090909, 1.2, 1.2), c(1.30909090909091,
> 1.30909090909091, 1.41818181818182, 1.41818181818182))
> labelxtoplot<-list(c(42.5, 44.75, 44.75, 42.5), c(42.5, 44.75, 44.75,
> 42.5), c(42.5, 44.75, 44.75, 42.5), c(42.5, 44.75, 44.75, 42.5))
> borders<-marks<-c("green","blue","yellow","black")
> 
> CODE producing the error in R CMD check only:
> # plot(1:50)
> mapply(function(x,y,z,w) graphics::polygon(x=x,
>y=y,
>col=z,
>lwd=rep(.5,length(marks) )
>,border=w
> ),
> x = labelxtoplot,
> y = labelytoplot
> ,z = marks
> ,w = borders
> )
> 
> Grateful for any guidance ,
> 
> 
> 
> 
> 
> 
> On Wed, Nov 27, 2019 at 8:34 AM Ege Rubak  wrote:
> 
>> On 27/11/2019 00.22, Fernando Roa wrote:
>>> - I used a guest debian 10 in vmware in my system, and couldn't replicate
>>> the error installing with R CMD INSTALL 
>>
>> I guess you should rather run "R CMD check ..." on the tar.gz file to
>> reproduce the error.
>>
>> Hope that helps.
>>
>> /Ege
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
> Original message:
> I got a warning only in debian after submitting package to CRAN.
> I want to replicate the vignette warning of debian in the following link to
> solve it:
> 
> Debian:
> https://win-builder.r-project.org/incoming_pretest/idiogramFISH_1.9.1_20191126_012524/Debian/00check.log
> 1 WARNING
> 
> Warning summary:
> "checking re-building of vignette outputs ... [15s/17s] WARNING
> Error(s) in re-building vignettes:
> 'list' object cannot be coerced to type 'double'" several times
> --
> 
> - I used a guest debian 10 in vmware in my system, and couldn't replicate
> the error installing with R CMD INSTALL 
> 
> - In R of host, I installed rhub and run
> rhub::check_with_sanitizers() # success
> rhub::check_on_debian() # does not work because of vignette dependencies
> not installed
> rhub::check(platform = "debian-gcc-devel") # does not work because of
> vignette dependencies not installed
> 
> https://pastebin.com/wwhbqcSw
> 
> Grateful for any guidance
> 
>

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

Re: [R-pkg-devel] Missing SystemRequirements on the build servers

[Sebastian Meyer]

Dear Philipp,

What kind of problems does the incoming check report?

If they are related to your package's vignette, a simple solution would
be to transform this toy example into a package test using
tools::buildVignette in the test script, which can be run conditionally
on specific system requirements being fulfilled (so probably not on CRAN
test machines).

Cheers,

Sebastian


Am 22.11.19 um 10:44 schrieb Angerer, Philipp:
> 
> 
> Hi, 
> 
> I first submitted my package nbconvertR in 2015. It requires the command 
> jupyter nbconvert to work. 
> 
> Since the first submission the SystemRequirements which provide that command 
> changed, which I reflected in the SystemRequirements and lately in an INSTALL 
> file: 
> https://github.com/theislab/nbconvertR/blob/f30cbe03908dcf0c9301436fa9f2c06c7028baab/INSTALL
>  
> 
> 
> My problem now is that since 2017, my submission only gets until the mail 
> “Dear maintainer, package nbconvertR_1.3.1.tar.gz does not pass the incoming 
> checks automatically”. That mail later says “If you are fairly certain the 
> rejection is a false positive, please reply-all to this message and explain” 
> which I always do. But then nobody replies and my package gets kicked out of 
> the incoming folder after 7 days or so. 
> 
> 
> What can I do? 
> 
> 
> Best, Philipp 
> 
>  
> 
> 
> Helmholtz Zentrum München
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] try() in R CMD check --as-cran

[Sebastian Meyer]

The failure stated in the R CMD check failure report is:

>  --- failure: length > 1 in coercion to logical ---

This comes from --as-cran performing useful extra checks via setting the
environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:

> check if either argument of the binary operators && and || has length greater 
> than one. 

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

The failure report also states the source of the failure:

>  --- call from context --- 
> fchk(x, benbad, trace = 3, y)
>  --- call from argument --- 
> is.infinite(fval) || is.na(fval)

The problem is that both is.infinite(fval) and is.na(fval) return
vectors of length 10 in your test case:

>  --- value of length: 10 type: logical ---
>  [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE

The || operator works on length 1 Booleans. Since fval can be of length
greater than 1 at that point, the proper condition seems to be:

any(is.infinite(fval)) || any(is.na(fval))

Best regards,

Sebastian


Am 07.06.19 um 14:53 schrieb J C Nash:
> Sorry reply not quicker. For some reason I'm not getting anything in the 
> thread I started!
> I found the responses in the archives. Perhaps cc: nas...@uottawa.ca please.
> 
> I have prepared a tiny (2.8K) package at
> http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz
> 
> R CMD check --> OK
> 
> R CMD check --as-cran --> 1 ERROR, 1 NOTE
> 
> The error is in an example:
> 
>> benbad<-function(x, y){
>># y may be provided with different structures
>>f<-(x-y)^2
>> } # very simple, but ...
>>
>> y<-1:10
>> x<-c(1)
>> cat("test benbad() with y=1:10, x=c(1)\n")
>> tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
>> print(tryfc01)
>> print(fc01)
> 
> There's quite a lot of output, but it doesn't make much sense to me, as
> it refers to code that I didn't write.
> 
> The function fchk is attempting to check if functions provided for
> optimization do not violate some conditions e.g., character rather than
> numeric etc.
> 
> JN
> 
> 
> On 2019-06-07 8:44 a.m., J C Nash wrote:
>> Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
>> Fri Jun 7 11:44:37 CEST 2019
>>
>> Previous message (by thread): [R-pkg-devel] try() in R CMD check 
>> --as-cran
>> Next message (by thread): [R-pkg-devel] using package data in package 
>> code
>> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>
>> Right, what problem are you talking about? Can you tell us which check
>> it is and what it actually complained about.
>> There is no check that looks at the sizes of x and y in exypressions
>> such as
>> (x - y)^2.
>> as far as I know.
>>
>> Best,
>> Uwe
>>
>> On 07.06.2019 10:33, Berry Boessenkool wrote:
>>>
>>> Not entirely sure if this is what you're looking for:
>>> https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R
>>> It does contain --as-cran a few times and there's the change-history:
>>> https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R
>>>
>>> Regards,
>>> Berry
>>>
>>>
>>> 
>>> From: R-package-devel  on 
>>> behalf of J C Nash 
>>> Sent: Thursday, June 6, 2019 15:03
>>> To: List r-package-devel
>>> Subject: [R-pkg-devel] try() in R CMD check --as-cran
>>>
>>> After making a small fix to my optimx package, I ran my usual R CMD check 
>>> --as-cran.
>>>
>>> To my surprise, I got two ERRORs unrelated to the change. The errors popped 
>>> up in
>>> a routine designed to check the call to the user objective function. In 
>>> particular,
>>> one check is that the size of vectors is the same in expressions like (x - 
>>> y)^2.
>>> This works fine with R CMD check, but the --as-cran seems to have changed 
>>> and it
>>> pops an error, even when the call is inside try(). The irony that the 
>>> routine in
>>> question is intended to avoid problems like this is not lost on me.
>>>
>>> I'm working on a small reproducible example, but it's not small enough yet.
>>> In the meantime, I'm looking for the source codes of the scripts for "R CMD 
>>> check" and
>>> "R CMD check --as-cran" so I can work out why there is this difference, 
>>> which seems
>>> to be recent.
>>>
>>> Can someone send/post a link? I plan to figure this out and provide 
>>> feedback,
>>> as I suspect it is going to affect others. However, it may be a few days or 
>>> even
>>> weeks if past experience is a guide.
>>>
>>> JN
>>>
>>> __
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

Re: [R-pkg-devel] Registered S3 methods from standard package

[Sebastian Meyer]

I think your package can be useful. However, I'm with CRAN here in that
I would not want my standard graphics output to be changed just because
some package ("prettyB") gets loaded, which could happen
*unintentionally* as a dependency (or a dependency of a dependency, ...)
of another package.

What about some kind of prettyB::enable_prettyB() function which does

> registerS3method("plot", "default", prettyB::plot.default, 
> asNamespace("graphics"))

similar to delayed method registration (see, e.g.,
https://github.com/r-lib/vctrs/blob/master/R/register-s3.R), so that a
user needs to switch to "prettyB" graphics explicitly ?

Resetting to graphics::plot.default should be made possible as well.

The question remains whether registerS3method() can be used at all,
since the help says:

> Internal namespace support functions.  Not intended to be called
>  directly, and only visible because of the special nature of the
>  ‘base’ namespace.

Cheers,

Sebastian


Am 13.05.19 um 09:22 schrieb Colin Gillespie:
> Dear All,
> 
> I'm developing a small package to make plotting methods a little bit
> nicer looking:
> 
> https://github.com/jumpingrivers/prettyB/
> 
> The general idea is to replace plot.default() with an alternative
> (matching all arguments) and export. This would allow users to simply
> load the package and use base graphics functions as normal, but get a
> pretty graph.
> 
> The general pattern I follow is:
> 
> https://github.com/jumpingrivers/prettyB/blob/master/R/plot.R#L23
> 
> which then includes S3method(plot,default) in my NAMESPACE file. When
> building and checking the package I get
> 
> Registered S3 methods from standard package(s) overwritten by 'prettyB':
> method  from
> plot.defaultgraphics
> 
> which CRAN does not permit.
> 
> Question: Is it possible to achieve the functionality I'm after
> (replacing the default plot.default() functions) while following the
> CRAN rules?
> 
> Thanks
> 
> Colin
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Executable file warning in CRAN check

[Sebastian Meyer]

Let's look at the check_executables() function inside
tools:::.check_packages()
[https://svn.r-project.org/R/trunk/src/library/tools/R/check.R]. If the
'file' program is available on the check system, the check for
executable files is based on what 'file' thinks about each file in the
source package. R CMD check essentially scans for the term " executable"
in the output from 'file'.

The check result therefore depends on the version of 'file' (and on the
involved "magic number file") used on the check system. On my system with

$ file --version
> file-5.25
> magic file from /etc/magic:/usr/share/misc/magic

I get

$ file src/LZ4/LICENSE
> src/LZ4/LICENSE: ASCII text

so no complaint about that file from R CMD check.

It seems that the version of 'file' used on CRAN's macOS check platforms
returns something "executable" for that ASCII file, probably because the
executable bit is set.

To answer your initial question, I don't think there's anything you need
to do on your end.

Cheers,

Sebastian


Am 09.04.19 um 00:56 schrieb Travers Ching:
> Thanks Sebastian, I'll give it a shot.  It seems weird that I can't
> replicate the warning on a mac laptop, or any other system.
> 
> Travers
> 
> On Mon, Apr 8, 2019 at 2:27 PM Sebastian Meyer  wrote:
>>
>> No false positive. This file is indeed marked as an executable file, see
>> also at https://github.com/cran/qs/blob/0.14.1/src/LZ4/LICENSE, which says
>>
>>> Executable File | 25 lines (20 sloc) | 1.28 KB
>>
>> On a Unix-based system you could do
>>
>>> chmod -x src/LZ4/LICENSE
>>
>> to remove the executable bit from that file.
>>
>> Cheers,
>>
>> Sebastian
>>
>>
>> Am 08.04.19 um 23:02 schrieb Travers Ching:
>>> I see the following warning on CRAN:
>>>
>>> Result: WARN
>>> Found the following executable file:
>>>  src/LZ4/LICENSE
>>> Source packages should not contain undeclared executable files.
>>> See section ‘Package structure’ in the ‘Writing R Extensions’ manual.
>>> https://cran.r-project.org/web/checks/check_results_qs.html
>>>
>>> This seems like a false positive since it's clearly not an executable,
>>> but I'm wondering if there's anything I should do on my end?
>>>
>>> Travers
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Executable file warning in CRAN check

[Sebastian Meyer]

No false positive. This file is indeed marked as an executable file, see
also at https://github.com/cran/qs/blob/0.14.1/src/LZ4/LICENSE, which says

> Executable File | 25 lines (20 sloc) | 1.28 KB 

On a Unix-based system you could do

> chmod -x src/LZ4/LICENSE

to remove the executable bit from that file.

Cheers,

Sebastian


Am 08.04.19 um 23:02 schrieb Travers Ching:
> I see the following warning on CRAN:
> 
> Result: WARN
> Found the following executable file:
>  src/LZ4/LICENSE
> Source packages should not contain undeclared executable files.
> See section ‘Package structure’ in the ‘Writing R Extensions’ manual.
> https://cran.r-project.org/web/checks/check_results_qs.html
> 
> This seems like a false positive since it's clearly not an executable,
> but I'm wondering if there's anything I should do on my end?
> 
> Travers
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Re :Re: package cartograflow_0.0.0.9000.tar.gz

[Sebastian Meyer]

There are probably no clairvoyants around here. So, again, without
access to the up-to-date source code of your package, nobody will be
able to help.

"there is no package called ..." means that the given package is not
installed in any of the libraries currently in use by R (see .libPaths()
for the relevant paths). Maybe you have installed "dplyr" in a library
used by your standard R installation, but not in any library used by
your R-devel installation (which you seem to use for checking the
package)? Just a wild guess.


Am 04.04.19 um 13:14 schrieb cartograf...@gmail.com:
> I follow up your recommendation and for the moment I didn't used
> "conflicted".
> 
> So, I've made the nex R CMD check and I have the problem
> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
> vI[[i]]) :
>   there is no package called ‘dplyr’
> 
> How I can  solve this issue?
> 
> Thanks in advance
> 
> Le jeudi 4 avril 2019 à 08:22:26 UTC+2, Sebastian Meyer
>  a écrit :
> 
> 
> Note that output concerning masked objects are just messages which do
> not cause your vignette to fail. So it is not stricly necessary to start
> working on these conflicts now.
> 
> However, looking closely at the win-builder check results
> (https://win-builder.r-project.org/incoming_pretest/cartograflow_0.0.0.9000_20190324_230822/Windows/00check.log),
> I see the following output below these messages
> 
>> Warning in eval(expr, envir, enclos) : NAs introduced by coercion
>> Quitting from lines 529-573 (cartograflow.Rmd)
>> Error: processing vignette 'cartograflow.Rmd' failed with diagnostics:
>> argument is of length zero
> 
> So the problem actually is in lines 529-573 of the cartograflow.Rmd
> vignette (at least in the version submitted to win-builder a few weeks ago).
> 
> Running tools::buildVignette("cartograflow.Rmd") locally, I see
> 
>> Error in if (horiz) { : argument is of length zero
> 
> and the subsequent traceback() shows that the error originates from
> 
>> layoutLayer(title = "Professional mobility in Greater Paris",
>>        coltitle = "black", author = "Cartograflow, 2019", sources =
> "Sources : data : INSEE, RP, MOBPRO, 2017 ; basemap : IGN, APUR, UMS
> 2414 RIATE, 2018.",
>>        scale = 0.2, tabtitle = TRUE, frame = TRUE, north(pos =
> "topright"),
>>        col = "grey")
> 
> So it seems to me that the unnamed argument 'north(pos = "topright")' is
> wrongly matched to the "horiz" argument of layoutLayer().
> 
> Cheers,
> 
>     Sebastian
> 
> 
> Am 04.04.19 um 07:20 schrieb cartograf...@gmail.com
> <mailto:cartograf...@gmail.com>:
>>
>> Hi,I don't know if my explanations are clear.I tried several way to
> solve this problem w/o success. Someone have an idea ?Thanks in advance 
>>
>> On 2019-04-03 2:11 p.m., cartograf...@gmail.com
> <mailto:cartograf...@gmail.com> wrote:
>>>   Hi,
>>>
>>> I come back to you  because I have always the problem with
> devtools::check of my package.
>>>
>>> I used the command to check my package with R-devel :
>>> sylvain@sylvain <mailto:sylvain@sylvain>:~/svn$ bash R-devel.sh CMD
> check --as-cran
> /home/sylvain/work/12_R_studio/package/cartograflow_0.0.0.1.tar.gz
>>>
>>> When I start the rmd file there is a warning due to package dplyr :
>>> Attaching package: 'dplyr'
>>> The following objects are masked from 'package:stats':
>>>     filter, lag
>>> The following objects are masked from 'package:base':
>>>     intersect, setdiff, setequal, union
>>>
>>> The solve this issue I added in rmd file, description file and the
> namespace the package conflicted.
>>> So, the package conflicted avoid to have this warning.
>>>
>>> But when I run R-devel CMD check I have a new issue that is Error in
> loadNamespace...no package called ‘conflicted’ (see below)
>>>
>>> Can you help me to solve this issue if tit's possible?
>>> Thanks in advance to your help !
>>> Sylvain
>>> -
>>> Below extract of 00check.log
>>> * checking whether package ‘cartograflow’ can be installed ... ERROR
>>> Installation failed.
>>> See ‘/home/sylvain/svn/cartograflow.Rcheck/00install.out’ for details.
>>> * DONE
>>> Status: 1 ERROR, 1 NOTE
>>>
>>> Below 00install.out
>>> * installing *source* package ‘cartograflow’ ...
>>> ** using staged installation
>>> ** R
>>

Re: [R-pkg-devel] Re :Re: package cartograflow_0.0.0.9000.tar.gz

[Sebastian Meyer]

Note that output concerning masked objects are just messages which do
not cause your vignette to fail. So it is not stricly necessary to start
working on these conflicts now.

However, looking closely at the win-builder check results
(https://win-builder.r-project.org/incoming_pretest/cartograflow_0.0.0.9000_20190324_230822/Windows/00check.log),
I see the following output below these messages

> Warning in eval(expr, envir, enclos) : NAs introduced by coercion
> Quitting from lines 529-573 (cartograflow.Rmd) 
> Error: processing vignette 'cartograflow.Rmd' failed with diagnostics:
> argument is of length zero

So the problem actually is in lines 529-573 of the cartograflow.Rmd
vignette (at least in the version submitted to win-builder a few weeks ago).

Running tools::buildVignette("cartograflow.Rmd") locally, I see

> Error in if (horiz) { : argument is of length zero

and the subsequent traceback() shows that the error originates from

> layoutLayer(title = "Professional mobility in Greater Paris", 
> coltitle = "black", author = "Cartograflow, 2019", sources = "Sources 
> : data : INSEE, RP, MOBPRO, 2017 ; basemap : IGN, APUR, UMS 2414 RIATE, 
> 2018.", 
> scale = 0.2, tabtitle = TRUE, frame = TRUE, north(pos = "topright"), 
> col = "grey")

So it seems to me that the unnamed argument 'north(pos = "topright")' is
wrongly matched to the "horiz" argument of layoutLayer().

Cheers,

Sebastian


Am 04.04.19 um 07:20 schrieb cartograf...@gmail.com:
> 
> Hi,I don't know if my explanations are clear.I tried several way to solve 
> this problem w/o success. Someone have an idea ?Thanks in advance 
> 
> On 2019-04-03 2:11 p.m., cartograf...@gmail.com wrote:
>>   Hi, 
>>
>> I come back to you  because I have always the problem with devtools::check 
>> of my package. 
>>
>> I used the command to check my package with R-devel : 
>> sylvain@sylvain:~/svn$ bash R-devel.sh CMD check --as-cran 
>> /home/sylvain/work/12_R_studio/package/cartograflow_0.0.0.1.tar.gz
>>
>> When I start the rmd file there is a warning due to package dplyr : 
>> Attaching package: 'dplyr'
>> The following objects are masked from 'package:stats':
>>     filter, lag
>> The following objects are masked from 'package:base':
>>     intersect, setdiff, setequal, union
>>
>> The solve this issue I added in rmd file, description file and the namespace 
>> the package conflicted. 
>> So, the package conflicted avoid to have this warning. 
>>
>> But when I run R-devel CMD check I have a new issue that is Error in 
>> loadNamespace...no package called ‘conflicted’ (see below)
>>
>> Can you help me to solve this issue if tit's possible? 
>> Thanks in advance to your help ! 
>> Sylvain
>> -
>> Below extract of 00check.log 
>> * checking whether package ‘cartograflow’ can be installed ... ERROR
>> Installation failed.
>> See ‘/home/sylvain/svn/cartograflow.Rcheck/00install.out’ for details.
>> * DONE
>> Status: 1 ERROR, 1 NOTE
>>
>> Below 00install.out 
>> * installing *source* package ‘cartograflow’ ...
>> ** using staged installation
>> ** R
>> ** inst
>> ** byte-compile and prepare package for lazy loading
>> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) : 
>>   there is no package called ‘conflicted’
>> Calls:  ... loadNamespace -> withRestarts -> withOneRestart -> 
>> doWithOneRestart
>> Exécution arrêtée
>> ERROR: lazy loading failed for package ‘cartograflow’
>> * removing ‘/home/sylvain/svn/cartograflow.Rcheck/cartograflow’
>>
>>
>>
>>
>>
>>
>>
>>     Le mardi 26 mars 2019 à 22:42:21 UTC+1, Henrik Bengtsson 
>>  a écrit :  
>>   
>>   FWIW, you should be able to reproduce at least the following NOTEs
>> with your current R 3.5.2 and R CMD check --as-cran:
>>
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: ‘cartogRaflow ’
>>
>> New submission
>>
>> Version contains large components (0.0.0.9000)
>>
>> Possibly mis-spelled words in DESCRIPTION:
>>   flowmapping (7:41)
>>
>> Author field should be Authors@R.  Current value is:
>>   c(person("Françoise", "Bahoken", email =
>> "francoise.baho...@ifsttar.fr", role = c("cre","aut")),
>>             person("Sylvain", "Blondeau", email =
>> "blondeau.sylv...@yahoo.fr", role = c("aut"))
>>
>> The Title field should be in title case. Current version is:
>> ‘thematic cartography of flows and movements’
>> In title case that is:
>> ‘Thematic Cartography of Flows and Movements’
>>
>> Those are all classical mistakes ("we've all been there").  The
>> vignette errors may or may not be specific to R devel.
>>
>> /Henrik
>>
>> On Tue, Mar 26, 2019 at 2:29 PM cartograf...@gmail.com
>>  wrote:
>>>
>>> Hi,  l've made R CMD check --as-cran on rstudio 3.5.2Why I have to use 
>>> r-devel?
>>> I confirm that I didn't received à error message when I've made 
>>> dev_tool::check.
>>> How can I solve my problem ?
>>> Thanks in advance Sylvain
>>>
>>>
>>> nvoyé depuis Yahoo Mail 

Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R

[Sebastian Meyer]

The DESCRIPTION's Author field is auto-generated from Authors@R during R
CMD build. You are right, the format has slightly changed since R 3.3.3
(e.g., support for ORCID ID).

The CRAN repository policy says:

> Uploads must be source tarballs created by R CMD build and following
> the PACKAGE_VERSION.tar.gz naming scheme. This should be done with
> current R-patched or the current release of R.

-> https://cran.r-project.org/web/packages/policies.html

Further to that, note that you are using a non-standard role ("con").
See the details in help("person") for the roles used in the context of R
packages: aut, com, ctr, ctb, cph, cre, dtc, fnd, ths, trl.

Cheers,

Sebastian


Am 06.02.19 um 13:26 schrieb Ivan Krylov:
> Hi!
> 
> I'm relying on Authors@R to generate the Author: and Maintainer:
> headers. When checking my package at win-builder using R-unstable, I
> got a NOTE that Author field differs from that derived from Authors@R:
> 
>>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'
> 
>>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>>> [cre, cph]'
> 
> Link to full check output:
> https://win-builder.r-project.org/EWz9zWS0niO3/
> 
> The actual field from DESCRIPTION now looks like this:
> 
>>> Authors@R: c(person('Miquel', 'Garriga', email =
>>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>>> c('con', 'cph')), person('Alexander', 'Semke', email =
>>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))
> 
> The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
> stable, which might explain the differences in utils:::format.person.
> 
> What should I do to avoid the NOTE?
>

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

Re: [R-pkg-devel] troubleshooting hard-to-reproduce errors

[Sebastian Meyer]

These issues originate in a change in how R looks for S3 methods, at
least on some of the CRAN machines. To reproduce locally, you currently
need to set the environnment variable

_R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_=TRUE

See the source code at
https://svn.r-project.org/R/trunk/src/main/objects.c

To fix method lookup for R >= 3.6.0, you can use delayed S3 method
registration along the lines of:

if (getRversion() >= "3.6.0") {
  S3method(pkg::gen, cls)
}

See the manual at
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Registering-S3-methods

Hope this helps!
Cheers,

Sebastian


Am 08.01.19 um 04:56 schrieb Ben Bolker:
> 
>  My colleagues and I are preparing a new submission of a package for
> CRAN (https://github.com/glmmTMB/glmmTMB/tree/master/glmmTMB).  We've
> tested it on all the platforms we have access to: Travis/Linux (devel
> and release), MacOS (release), Ubuntu 16.04 (release), win-builder
> (devel and release), without any serious problems.
> 
>  On CRAN's Debian test machine, we get an ERROR and a WARNING.
> 
> 1. Can anyone suggest the best way to test/find a platform where we can
> figure out what's going on? I haven't used R-hub: should I try that?
> 
> 2.  The specific problem is in the "downstream_methods" example:
> 
> 
> warp.lm <- glmmTMB(breaks ~ wool * tension, data = warpbreaks)
> if (require(emmeans)) {
>  emmeans (warp.lm, poly ~ tension | wool)
> }
> 
>  the error is:
> 
>  Loading required package: emmeans
>  Error in ref_grid(object, ...) :
>Can't handle an object of class  'glmmTMB'
>   Use help("models", package = "emmeans") for information on supported
> models.
>  Calls: emmeans -> ref_grid
>  Execution halted
> 
> 
>  I can imagine that this has something to do with environment/method
> loading.  If I run
> 
> example("downstream_methods", package="glmmTMB")
> 
> in an R console it works fine (even if glmmTMB isn't loaded).
> 
> I can reproduce the error if *without loading the glmmTMB package* I run
> 
> warp.lm <- glmmTMB::glmmTMB(breaks ~ wool * tension, data = warpbreaks)
> if (require(emmeans)) {
>  emmeans (warp.lm, poly ~ tension | wool)
> }
> 
> ... but I don't see why the methods from a package wouldn't be loaded
> when running its own examples ??
> 
> 3. The other problem is in vignette building (see below).  Any
> suggestions for debugging since it doesn't seem to fail locally?
> The lines indicated suggest some similar kind of method-access problem
> :
> 
> 
> Anova(owls_nb1)  ## default type II
> Anova(owls_nb1,type="III")
> 
>   Any suggestions welcome ...
> 
>  cheers
>Ben Bolker
> 
> ---
> * checking re-building of vignette outputs ... [80s/81s] WARNING
> Error(s) in re-building vignettes:
>   ...
> --- re-building ‘covstruct.rmd’ using rmarkdown
> 
> Attaching package: 'TMB'
> 
> The following object is masked from 'package:glmmTMB':
> 
> tmbroot
> 
> --- finished re-building ‘covstruct.rmd’
> 
> --- re-building ‘mcmc.rmd’ using rmarkdown
> --- finished re-building ‘mcmc.rmd’
> 
> --- re-building ‘miscEx.rmd’ using rmarkdown
> --- finished re-building ‘miscEx.rmd’
> 
> --- re-building ‘model_evaluation.rmd’ using rmarkdown
> Loading required package: carData
> lattice theme set by effectsTheme()
> See ?effectsTheme for details.
> Loading required package: mvtnorm
> Loading required package: survival
> Loading required package: TH.data
> Loading required package: MASS
> 
> Attaching package: 'TH.data'
> 
> The following object is masked from 'package:MASS':
> 
> geyser
> 
> 
> Attaching package: 'multcomp'
> 
> The following object is masked from 'package:emmeans':
> 
> cld
> 
> Note that, since v0.1.6.2, DHARMa includes support for glmmTMB, but
> there are still a few minor limitations associatd with this package.
> Please see https://github.com/florianhartig/DHARMa/issues/16 for
> details, in particular if you use this for production.
> Loading required package: ggplot2
> Quitting from lines 94-96 (model_evaluation.rmd)
> Error: processing vignette 'model_evaluation.rmd' failed with diagnostics:
> subscript out of bounds
> --- failed re-building ‘model_evaluation.rmd’
> 
> --- re-building ‘sim.rmd’ using rmarkdown
> --- finished re-building ‘sim.rmd’
> 
> --- re-building ‘troubleshooting.rmd’ using rmarkdown
> --- finished re-building ‘troubleshooting.rmd’
> 
> --- re-building ‘glmmTMB.Rnw’ using knitr
> Loading required package: stats4
> Warning in qt((1 - level)/2, df) : NaNs produced
> --- finished re-building ‘glmmTMB.Rnw’
> 
> SUMMARY: processing the following file failed:
>   ‘model_evaluation.rmd’
> 
> Error: Vignette re-building failed.
> Execution halted
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

Re: [R-pkg-devel] testing coercion

[Sebastian Meyer]

Hi Kevin,

I think using

> canCoerce(wv, "double") || getRversion() < "3.6.0"

could solve the issue of an inconsistent test result and is descriptive.

Best regards,

Sebastian


Am 06.12.18 um 16:59 schrieb Kevin Coombes:
>  Hi,
> 
> A package I recently submitted to CRAN includes an S4 class that defines a
> method to coerce from that class to a numeric vector, basically through
> 
>>  setAs("myClass", "numeric", function(from) from@psi)
> 
> Being perhaps overly compulsive about trying to test everything while
> documenting behavior, my accompanying test script includes these lines:
> 
>> try( as.numeric(wv) )# should fail
>> canCoerce(wv, "numeric")   # returns TRUE
>> canCoerce(wv, "double") # gets a complaint from CRAN incoming pretest
> 
> The complaint on the last line arises because
> + in the current version of R, the answer is FALSE
> + in the development version of R, the answer is TRUE
> The change is (probably) documented on the R-devel daily news from 04 Sept
> 2018, which lists
> 
> Bug Fix:  as(1L, "double") now does coerce (PR#17457)
> 
> So, here's my question. Do I remove this test (and thus lose my
> documentation of how the method behaves) in order to get the incoming
> precheck to stop whinging? Or do I tell the CRAN maintainers to not worry
> about the test changing, since it's due to a core bug fix, and promise to
> change my saved test results when the devel version becomes current? (Even
> though the fixed results will then show up as wrong in the "oldrel" tests.)
> 
> Best,
>   Kevin
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

[Rd] R-devel no longer supports Ubuntu 14.04 LTS (insufficient PCRE version)

[Sebastian Meyer]

Since yesterday's r69662, R no longer ./configure[s] on a standard
Ubuntu 14.04.3 installation, which ships with PCRE 8.31
(http://packages.ubuntu.com/trusty-updates/libpcre3-dev)

I get:

> checking if PCRE version >= 8.32, < 10.0 and has UTF-8 support... no
> checking whether PCRE support suffices... configure: error: pcre library and 
> headers are required

Are there any workarounds for this except for manually compiling and
installing a more recent version of PCRE from source?

Thanks!

Sebastian


-- 
University of Zurich
Sebastian Meyer
Epidemiology, Biostatistics and Prevention Institute
(Department of Biostatistics)
Hirschengraben 84
CH-8001 Zürich
Tel: +41 44 63-45485
Fax: +41 44 63-44386
www.biostat.uzh.ch
sebastian.me...@uzh.ch

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

Re: [Rd] non-differentiable evaluation points in nlminb(), follow-up of PR#15052

[Sebastian Meyer]

Thanks for the pointers to the packages optimx and maxLik.
Up to now, I actually did not spend much time in searching for elaborate
R packages specifically dealing with optimization problems, but was just
satisfied using the optim methods or nlminb. I chose nlminb, because it
can take advantage of the analytical hessian which optim cannot. In my
experience with numerical log-likelihood maximizations it works pretty
good and is more efficient (in the sense of fast and precise) in finding
an optimum than the optim methods (if both analytical derivatives are
provided).

The situation where I was confronted with non-differentiable evaluation
points involved an iterative optimization between a penalized likelihood
of regression coefficients (about 430) and a marginal likelihood of 6
variance parameters for spatio-temporal data (I won't bother you with
any more details). If the starting values of the regression coefficients
were bad, the marginal likelihood looked really irregular with multiple
local non-differentiable maxima, where my analytical gradient and
hessian were not well-defined (an implicit high-dimensional matrix which
needs inversion was (numerically) singular). However, returning NA from
the gradient or hessian function to nlminb was not helpful as
illustrated by my very simple _artificial_ example (@Ravi: I know that
the gradient is not correct, but it illustrates how nlminb might get
lost in NA's). Meanwhile I probably solved the problem by simply
continuing with the generalized inverse implemented in MASS::ginv, which
pushed the algorithm back to work in my case. A proper alternative would
be to exit from nlminb and to switch to Nelder-Mead at that point.

Best regards,
   Sebastian


On 28.09.2012 10:53, Spencer Graves wrote:
 On 9/26/2012 2:13 AM, Sebastian Meyer wrote:
 This is a follow-up question for PR#15052
 http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15052

 There is another thing I would like to discuss wrt how nlminb() should
 proceed with NAs. The question is: What would be a successful way to
 deal with an evaluation point of the objective function where the
 gradient and the hessian are not well defined?

 If the gradient and the hessian both return NA values (assuming R 
 r60789, e.g. R 2.15.1), and also if both return +Inf values, nlminb
 steps to an NA parameter vector.
 Here is a really artificial one-dimensional example for demonstration:

 f - function (x) {
cat(evaluating f(, x, )\n)
if(is.na(x)) {Inf   # to prevent an infinite loop for R  r60789
} else abs(x)
 }
 gr - function (x) if (abs(x)  1e-5) Inf else sign(x)
 hess - function (x) matrix(if (abs(x)  1e-5) Inf else 0, 1L, 1L)
 trace(gr)
 trace(hess)
 nlminb(5, f, gr, hess, control=list(eval.max=30, trace=1))

 Thus, if nlminb reaches a point where the derivatives are not defined,
 optimization is effectively lost. Is there a way to deal with such
 points in nlminb? Otherwise, the objective function is doomed to
 emergency stop() if it receives NA parameters because nlminb won't pick
 up courage - regardless of the following return value of the objective
 function.
 As far as I would assess the situation, nlminb is currently not capable
 of optimizing objective functions with non-differentiable points.
 
   Are you familiar with the CRAN Task View on Optimization and
 Mathematical Programming?  I ask, because as far as I know, nlminb is
 one of the oldest nonlinear optimizer in R.  If I understand the
 history, it was ported from S-Plus after at least one individual in the
 R Core team decided it was better for a certain task than optim, and
 it seemed politically too difficult to enhance optim.  Other nonlinear
 optimizers have been developed more recently and are available in
 specialized packages.
 
 
   In my opinion, functions like nlminb should never stop because
 it gets NA for a derivative at some point -- unless that honestly
 happened to be a local optimum.  If a function like nlminb computes an
 NA for a derivative not at a local optimum, it should then call a
 derivative-free optimizer, then try to compute the derivative at a local
 optimum.
 
 
   Also, any general optimizer that uses analytic derivatives should
 check to make sure that the analytic derivatives computed are reasonably
 close to numeric derivatives.  This can easily be done using the
 compareDerivatives function in the maxLik package.
 
 
   Hope this helps.
   Spencer
 
 Best regards,
Sebastian Meyer
 


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

[Rd] non-differentiable evaluation points in nlminb(), follow-up of PR#15052

[Sebastian Meyer]

This is a follow-up question for PR#15052
http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15052

There is another thing I would like to discuss wrt how nlminb() should
proceed with NAs. The question is: What would be a successful way to
deal with an evaluation point of the objective function where the
gradient and the hessian are not well defined?

If the gradient and the hessian both return NA values (assuming R 
r60789, e.g. R 2.15.1), and also if both return +Inf values, nlminb
steps to an NA parameter vector.
Here is a really artificial one-dimensional example for demonstration:

f - function (x) {
  cat(evaluating f(, x, )\n)
  if(is.na(x)) {Inf   # to prevent an infinite loop for R  r60789
  } else abs(x)
}
gr - function (x) if (abs(x)  1e-5) Inf else sign(x)
hess - function (x) matrix(if (abs(x)  1e-5) Inf else 0, 1L, 1L)
trace(gr)
trace(hess)
nlminb(5, f, gr, hess, control=list(eval.max=30, trace=1))

Thus, if nlminb reaches a point where the derivatives are not defined,
optimization is effectively lost. Is there a way to deal with such
points in nlminb? Otherwise, the objective function is doomed to
emergency stop() if it receives NA parameters because nlminb won't pick
up courage - regardless of the following return value of the objective
function.
As far as I would assess the situation, nlminb is currently not capable
of optimizing objective functions with non-differentiable points.

Best regards,
  Sebastian Meyer

-- 
Sebastian Meyer
Division of Biostatistics
Institute of Social and Preventive Medicine
University of Zurich

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

[Rd] using setOldClass() causes warning on unloadNamespace() if the package imports methods

[sebastian . meyer]

For the CRAN-package surveillance, unloadNamespace(surveillance) gives the 
following warning message:

In FUN(X[[2L]], ...) :
  Created a package name, ‘2012-08-28 22:42:37’, when none found

Similar warnings appear for the CRAN-package solaR and probably some other 
packages.

I created a dummy package (tarball is attached) to find out where this warning 
comes from.
Apparently, the warning is related to the package defining a virtual S4 class 
using setOldClass(fooS3class). However, the crucial thing is that the warning 
only appears, when the methods package is imported in the NAMESPACE. There is 
also no warning if setClass(fooS3class) is used instead. So my question is: 
What would be the right way of handling S3 classes in the S4 world?

My minor second question is: Should the NAMESPACE state exportMethods(coerce) 
if the package defines new coerce-methods? It seems that coercion-methods 
defined by the package using setAs() are also visible after loading the package 
without explicitly exporting these. However, if one includes 
exportMethods(coerce) then one must also document them (as stated by R CMD 
check).

Thanks for any hints!

   Sebastian


PS: using
R Under development (unstable) (2012-08-28 r60472)
Platform: x86_64-unknown-linux-gnu (64-bit)

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

[Rd] R CMD check . segfault on re-building vignettes

[Sebastian Meyer]

(Warning: There is some potential that this message is redundant.)

I think that i have spotted an issue with R CMD check that does not
trace back to a rare case, so it must have been reported already or i am
doing something stupid. However, to be sure and because I did not find
any comments on this while searching the R mailing lists, here is what i
did:
  R CMD check .
from within a package source directory which has some vignettes in
inst/doc. When the check finally comes to
checking re-building of vignette PDFs ...
i get the following error

 *** caught segfault ***
address 0x7fff6073c998, cause 'memory not mapped'

Traceback:
 1: file.copy(pkgdir, vd2, recursive = TRUE)
 2: run_vignettes(desc)
 3: check_pkg(pkgdir, pkgname, pkgoutdir, startdir, libdir, desc,
is_base_pkg, is_rec_pkg, thispkg_subdirs, extra_arch)
 4: tools:::.check_packages()
aborting ...
Segmentation fault (core dumped)

as one can see, the error stems from the call
file.copy(pkgdir, vd2, recursive = TRUE)
in the run_vignettes function defined in the tools:::.check_packages
function. this call will copy the contents of pkgdir (the source
directory) to the ..Rcheck/vign_test/ directory _recursively_, the
problem of which being that the ..Rcheck directory is part of
pkgdir. Thus we get into a loop of copying pkgdir into
pkgdir/..Rcheck/vign_test, which is interrupted at some point by a
segfault (at least on my x86_64 GNU/Linux machine running Ubuntu 12.04
and R 2.15.0; the OS might be crucial for this issue).

I can reproduce the error by e.g.:

  pkgdir - tempdir()
  file.create(file.path(pkgdir,DESCRIPTION))# not necessary
  vd2 - file.path(pkgdir,..Rcheck/vign_test)
  dir.create(vd2, recursive=TRUE)
  ### Better Do NOT run - buffer overflow
  # file.copy(pkgdir, vd2, recursive=TRUE)
  ###

Can anybody confirm this problem? Of course, a workaround is to run R
CMD check from outside the source directory (which is probably the
preferred way).

Thanks in advance,
Sebastian


-- 
Sebastian Meyer
Division of Biostatistics
Institute of Social and Preventive Medicine
University of Zurich

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

Re: [Rd] (PR#14066) model.frame error with formula=~1 and na.action=na.fail

[Sebastian Meyer]

Thank you for your rapid bug fix and for your instructive comments on my
bug report.

 this is not 'model.frame error', nor even reported by R as such.

Of course you are right, but I thought that a bug report on model.frame
would probably reach more attention further providing a more motivating
frame for the bug than just writing that
complete.cases(as.data.frame(matrix(,150,0)))
would not work, and I was absolutely sure that you would be able to
track down the source of the problem.

 data(iris)

 That line is unnecessary: 'iris' is a visible object in package
 'datasets'.

Ok. I was not sure about this and just wanted to be on the save side to
offer a reproducible example working in a maximum variety of R sessions.

Best regards and thank you very much for your intense development of R,
   Sebastian Meyer

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