Re: [R-pkg-devel] CRAN packages dependency on bioconductor packages

[Sebastian Meyer]

Am 16.05.24 um 11:34 schrieb Duncan Murdoch:

On 2024-05-16 4:15 a.m., Sebastian Meyer wrote:

Am 15.05.24 um 00:09 schrieb Lluís Revilla:

Hi Junhui,

There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle 
installed.
I don't know if it is possible to use a vignette output conditionally 
with

knitr: In any case it seems that it would be a requirement (Imports, or
Depends).


Yes, I'd consider the package providing the vignette output format for
the rmarkdown engine, here BiocStyle, as a strong dependency of that
vignette.


It is documented in WRE as a soft dependency of the package: "As Sweave 
is the only engine supplied with the R distribution, the package 
providing any other engine must be specified in the ‘VignetteBuilder’ 
field of the package DESCRIPTION file, and also specified in the 
‘Suggests’, ‘Imports’ or ‘Depends’ field (since its namespace must be 
available to build or check your package)."


I forget now, but presumably the thinking at the time was that Suggested 
packages would always be available for building and checking vignettes.


With most soft dependencies, it's up to the package writer to handle the 
possibility that it is missing, but here, I think it has to be the check 
code that does it, skipping the vignette test if the builder is missing.


Yes, re-building vignettes is skipped when a VignetteBuilder package is 
unavailable.


In the present case, the VignetteBuilder package that provides the 
engine is knitr and BiocStyle is used for an alternative rmarkdown 
output format. Not sure if the latter should be declared as an 
additional VignetteBuilder even if it does not provide the vignette 
engine, but you are right that it comes very close.




Alternatively, it could be required to be a hard dependency, but that 
seems too strong:  most package users don't need to rebuild vignettes.


Agreed. Declaring it as part of the vignette's \VignetteDepends is what 
I'd do to solve the check issue.


    Sebastian Meyer



Duncan Murdoch


  The error from the additional "noSuggests" check

(<https://www.stats.ox.ac.uk/pub/bdr/noSuggests/README.txt>) shows it
cannot be rebuild if BiocStyle is unavailable.

The 'StepReg' vignette could use a metadata line to declare strong
vignette dependencies, for example:

  %\VignetteDepends{StepReg, BiocStyle, kableExtra}

(I haven't checked if this list is complete.)

This avoids spurious check errors in incomplete setups, such as when
mass-checking packages (e.g., reverse dependencies) without some of the
suggested packages being installed.

Best,

Sebastian Meyer



However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from 
rmarkdown

if I recall correctly).
You will remove a dependency and avoid this problem entirely.

Best,

Lluís


On Tue, 14 May 2024 at 22:48, Li, Junhui  
wrote:



Hi everyone,

I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:

output:
    BiocStyle::html_document:
  toc_float: true
    BiocStyle::pdf_document: default

In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:

VignetteBuilder: knitr
biocViews:
Suggests:
  knitr,
  testthat,
  BiocStyle,
  kableExtra

You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev

There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error 
message

occurred when I attempted to upload it to CRAN:

* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'

SUMMARY: processing the following file failed:
 'StepReg.Rmd'

Error: Vignette re-building failed.
Execution halted

For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.

Thanks,
Junhui

  [[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/mailma

Re: [R-pkg-devel] CRAN packages dependency on bioconductor packages

[Sebastian Meyer]

Am 15.05.24 um 00:09 schrieb Lluís Revilla:

Hi Junhui,

There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle installed.
I don't know if it is possible to use a vignette output conditionally with
knitr: In any case it seems that it would be a requirement (Imports, or
Depends).


Yes, I'd consider the package providing the vignette output format for 
the rmarkdown engine, here BiocStyle, as a strong dependency of that 
vignette. The error from the additional "noSuggests" check 
(<https://www.stats.ox.ac.uk/pub/bdr/noSuggests/README.txt>) shows it 
cannot be rebuild if BiocStyle is unavailable.


The 'StepReg' vignette could use a metadata line to declare strong 
vignette dependencies, for example:


%\VignetteDepends{StepReg, BiocStyle, kableExtra}

(I haven't checked if this list is complete.)

This avoids spurious check errors in incomplete setups, such as when 
mass-checking packages (e.g., reverse dependencies) without some of the 
suggested packages being installed.


Best,

    Sebastian Meyer



However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from rmarkdown
if I recall correctly).
You will remove a dependency and avoid this problem entirely.

Best,

Lluís


On Tue, 14 May 2024 at 22:48, Li, Junhui  wrote:


Hi everyone,

I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:

output:
   BiocStyle::html_document:
 toc_float: true
   BiocStyle::pdf_document: default

In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:

VignetteBuilder: knitr
biocViews:
Suggests:
 knitr,
 testthat,
 BiocStyle,
 kableExtra

You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev

There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error message
occurred when I attempted to upload it to CRAN:

* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'

SUMMARY: processing the following file failed:
'StepReg.Rmd'

Error: Vignette re-building failed.
Execution halted

For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.

Thanks,
Junhui

 [[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] 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: [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: [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: [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: [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: [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: [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: [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: [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: [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