Re: [R-pkg-devel] gcc14 checks on fedora

[Gábor Csárdi]

Fedora 40 comes with gcc 14.1.x. But I would first try to use the
`-Wformat-truncation=` flag with the compiler you have, it is possible
that you don't need gcc 14.1. If you do, then the `fedora:40`
container should be good.

Gabor

On Fri, May 24, 2024 at 9:02 PM Brad Eck  wrote:
>
> Dear List -
>
> I received a note that my package -- epanet2toolkit -- was showing a
> warning in the fedora-gcc results on CRAN.
> https://www.stats.ox.ac.uk/pub/bdr/gcc12/epanet2toolkit.out
>
> I'd like to reproduce the warning and fix it.  Usually I'd do that with
> Docker.  Is anyone aware of a docker image or dockerfile with this setup?
>
> Thanks,
>
> Brad
>
> [[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] State of the art for UBSAN testing

[Gábor Csárdi]

R-hub v2 has UBSAN testing, the clang-asan image also has UBSAN. [1]

With the glitch that UBSAN errors do not fail the build because of a bug [2],
so you'll need to look at the results even if the build has passed.

Gabor

[1] https://r-hub.github.io/containers/
[2] https://github.com/r-hub/actions/issues/16

On Thu, May 16, 2024 at 10:27 PM Ralf Stubner  wrote:
>
> Dear all,
>
> I have been asked to fix a UBSAN error in my dqrng package. The error
> itself and the necessary fix are quite straight forward. However, I
> want to make 100% sure that I am really fixing the error. In the past
> I had used rhub for tasks like that. But it seems like the new rhub v2
> offers only ASAN testing. I have also tried various docker images
> (wch1/r-debug, old rhub images, rocker), but with none of them I was
> able to reproduce the error seen on CRAN. What would you consider as
> "state of the art" for reproducing UBSAN errors?
>
> Thanks
> Ralf
>
> __
> 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] Interpretation of rhub check failures

[Gábor Csárdi]

The lines
```
* checking examples with --run-donttest ...
Error: The operation was canceled.
```
and the 6 hours running time means that your build gets stuck while
running the examples, and then cancelled after 6 hours, that's the
time limit for a build.

This might or might not be specific for GitHub Acitions. If you want
to fix it, you'll need to figure out why the examples get stuck. Try
downloading the build artifacts, and see the output of the examples.
You might need to add more output to see what's going on.

Gabor

On Thu, May 16, 2024 at 1:18 AM Leonardo Cefalo
 wrote:
>
> Dear all,
>
> I should submit a new version of the package SchoolDataIT
>  and
> before doing so I need to check it on multiple flavors.
>
> So I have started trying some checks with rhub.
> I have loaded the new version of the package on github
> .
> It basically fails all checks, even if changes with respect to the
> previous version (the one on CRAN) are minor and should have no impact
> on the *most likely* causes of error, nor do devtools::check() or
> devtools::check_win_devel() return any error (but I cannot rely solely
> on these two checks since I have already experienced how unpredictably
> they behave on different flavors).
>
> What I am wondering about, however, is how to interpret error outputs
> like this
> (https://github.com/lcef97/SchoolDataIT/actions/runs/9092369467/job/24988944819,
> ubuntu-clang) or
> this(https://github.com/lcef97/SchoolDataIT/actions/runs/9092427648/job/24989126404
> atlas). I guess something wrong happens in the functions with
> --run-donttest.
>
> Could somebody please point me a way to interpret  these failures, or
> way to run checks with operating systems different than mine that does
> not involve the passage on github?
>
> Thank you very much in advance
> Best regards
> Leonardo
> 
> Sostieni la formazione e la ricerca universitaria con il tuo 5 per mille
> all'Università di Bari.
> Firma la casella "Finanziamento della ricerca scientifica e della
> Università"
> indicando il codice fiscale 80002170720.
>
> Il tuo contributo può fare la differenza: oggi più che mai!
>
> __
> 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] clang-UBSAN

[Gábor Csárdi]

The rhub package should be able to reproduce that, see
https://github.com/r-hub/rhub#readme

Or you can use the clang-asan container directly:
https://r-hub.github.io/containers/

Gabor

On Mon, May 13, 2024 at 12:31 AM Kaifeng Lu  wrote:
>
> Dear friends,
>
> I am developing an R package built with Rcpp. The package passed the test
> with devtools::check() before submission to CRAN, but failed with the
> following clang-UBSAN issue after submission to CRAN:
>
> /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25:
> runtime error: nan is outside the range of representable values of type
> 'int'
>
> Is there any way to reproduce the error before submitting the package to
> CRAN?
>
> Thank you very much for helping!
>
> Regards,
> Kaifeng
>
> [[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] Question about Clang 17 Error

[Gábor Csárdi]

You might be able to reproduce it with the clang17 container here:
https://r-hub.github.io/containers/
You can either run it directly or with the rhub2 package:
https://github.com/r-hub/rhub2#readme

Gabor

On Wed, Sep 27, 2023 at 8:29 PM Reed A. Cartwright
 wrote:
>
> My package, RBedrock, is now throwing an error when compiled against
> Clang17. The error log is here:
>
> https://www.stats.ox.ac.uk/pub/bdr/clang17/rbedrock.log
>
> The important part is
> """
> Error: package or namespace load failed for ‘rbedrock’ in dyn.load(file,
> DLLpath = DLLpath, ...):
>  unable to load shared object
> '/data/gannet/ripley/R/packages/tests-clang-trunk/rbedrock.Rcheck/00LOCK-rbedrock/00new/rbedrock/libs/rbedrock.so':
>
> /data/gannet/ripley/R/packages/tests-clang-trunk/rbedrock.Rcheck/00LOCK-rbedrock/00new/rbedrock/libs/rbedrock.so:
> undefined symbol: _ZNSt3__122__libcpp_verbose_abortEPKcz
> Error: loading failed
> """
>
> From what I can gather through googling, this error can be caused by using
> the C linker when one of the dependent libraries is a C++ library.
>
> I cannot tell if this is an issue with my package (likely) or CRAN's
> clang17 setup (less likely).
>
> Background about the package: rbedrock is written in C but links against a
> C++ library (Mojang's leveldb fork)  via the library's C-API functions. I
> use a dummy .cpp file in the source directory to trigger R into using the
> C++ linker. That does still seem to be happening according to the log.
>
> Has anyone seen this before and know where I should start looking to fix it?
>
> Thanks.
>
> --
> Reed A. Cartwright, PhD
> Associate Professor of Genomics, Evolution, and Bioinformatics
> School of Life Sciences and The Biodesign Institute
> Arizona State University
> ==
> Address: The Biodesign Institute, PO Box 876401, Tempe, AZ 85287-6401 USA
> Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
> 85287-6401 USA
> Office: Biodesign B-220C, 1-480-965-9949
> Website: http://cartwrig.ht/
>
> [[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] help with revdep_check

[Gábor Csárdi]

Seems like you are on macOS. You need to install XCode or the Command
Line Tools to be able to compile packages with C/C++/Fortran code.

Gabor

On Mon, Sep 25, 2023 at 7:02 PM William Revelle  wrote:
>
> Dear friends,
> I am trying to release a new update to psych and psychTools and am having 
> problems with revdep_check
>
> The error message from revdep_check is less than helpful:’
>
> fn is
>
> fn  <-  "/Users/WR/Library/CloudStorage/Dropbox/psychTools/"
>
> revdep_check(fn,num_workers=8)
> ── CHECK 
> ──
>  15 packages ──
> [0/15] 00:00:15 | ETA:  ?s | (8) afex [I], bootnet [I], modnets [I], psych 
> [I], alphaci [D], C...Error: Could not find tools necessary to compile a 
> package
> Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
> > check_build_tools(debug=TRUE)
> Trying to compile a simple C file
> Error: Could not find tools necessary to compile a package
> Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
> rror: Could not find tools necessary to compile a package
>
> Any suggestions would be appreciated.
>
> William Revellepersonality-project.org/revelle.html
> Professor  personality-project.org
> Department of Psychology www.wcas.northwestern.edu/psych/
> Northwestern Universitywww.northwestern.edu/
> Use R for psychology personality-project.org/r
> It is 90 seconds to midnight   www.thebulletin.org
>
>
> [[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] length() conflict with C++17

[Gábor Csárdi]

Yeah, I think both `R_NO_REMAP` and rearranging the includes are good
solutions, personally I would do both.

There is a container at https://r-hub.github.io/containers/ if you
want to make sure that you fixed everything:
docker run -ti ghcr.io/r-hub/containers/clang17 bash

Or, you can try the new rhub2 package, which uses the same container on GHA:
https://github.com/r-hub/rhub2#readme

Best,
Gabor


On Fri, Jun 30, 2023 at 11:39 AM Duncan Murdoch
 wrote:
>
> rgl has a lot of C++ code which is now getting errors in the clang17
> tests on CRAN:
>
>https://www.stats.ox.ac.uk/pub/bdr/clang17/rgl.log
>
> I haven't looked at the whole list yet, but many of the errors arise
> because R's include/Rinternals.h defines a length() macro, and that
> conflicts with a definition in clang's library.  For example,
>
>   /lib64/glib-2.0/include -I/usr/include/sysprof-4 -pthread  -Iext
> -Iext/glad/include  -isystem /usr/local/clang-trunk/include
> -I/usr/local/clang/include-fpic  -O3 -Wall -pedantic -frtti
> -Wp,-D_FORTIFY_SOURCE=3  -c PlaneSet.cpp -o PlaneSet.o
>   In file included from NULLgui.cpp:9:
>   In file included from ./NULLgui.h:4:
>   In file included from ./gui.h:9:
>   In file included from ./glgui.h:8:
>   In file included from
> /usr/local/clang-trunk/bin/../include/c++/v1/vector:322:
>   In file included from
> /usr/local/clang-trunk/bin/../include/c++/v1/__format/formatter_bool.h:21:
>   In file included from
> /usr/local/clang-trunk/bin/../include/c++/v1/__format/formatter_integral.h:32:
>   In file included from
> /usr/local/clang-trunk/bin/../include/c++/v1/locale:203:
>   /usr/local/clang-trunk/bin/../include/c++/v1/__locale:961:34: error:
> too many arguments provided to function-like macro invocation
>961 | int length(state_type& __st, const extern_type* __frm,
> const extern_type* __end, size_t __mx) const
>|  ^
>   /data/gannet/ripley/R/R-flang/include/Rinternals.h:968:9: note: macro
> 'length' defined here
>968 | #define length(x)   Rf_length(x)
>
> For those R users who know C++ better than me, is there a standard way
> to avoid this?  I can think of a couple that should work (e.g. defining
> R_NO_REMAP globally, or rearranging the order of includes).  I'd like to
> use the standard one if there is such a thing.
>
> Duncan Murdoch
>
> __
> 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] Problems with devtools::build() in R

[Gábor Csárdi]

Seems like you are on R 4.2.x, so you could try this one:
https://github.com/R-macos/gcc-darwin-arm64/releases

Gabor

On Tue, May 16, 2023 at 7:16 PM Jarrett Phillips
 wrote:
>
> Installing from the URL you provide, as well as doing R CMD build HACSim as
> suggested by @JeffNewmiller fails.
>
> When trying the latter solution, I get the same error as the one provided
> in my original post.
>
> Any thoughts?
>
>
>
>
>
> On Tue, May 16, 2023 at 12:52 PM Jarrett Phillips <
> phillipsjarre...@gmail.com> wrote:
>
> > Hi Duncan,
> >
> > I actually installed gfortran from
> >
> > https://github.com/fxcoudert/gfortran-for-macOS/releases
> >
> > but I can instead install from the URL you provide.
> >
> > Hopefully this fixes the problem.
> >
> > I will respond here if there are still issues.
> >
> > Thanks.
> >
> > Cheers,
> >
> > Jarrett
> >
> >
> > On Tue, May 16, 2023 at 12:39 PM Duncan Murdoch 
> > wrote:
> >
> >> On 16/05/2023 12:07 p.m., Jarrett Phillips wrote:
> >> > Hi All,
> >> >
> >> > I'm trying to generate a `tar.gz` file on a Mac for R package
> >> submission to
> >> > CRAN but am having issues.
> >> >
> >> > I'm using `devtools`, specifically `build()` and `install()`.
> >> >
> >> > My package relies on compiled code via `Rcpp/RcppArmadillo`.
> >> >
> >> >  build("HACSim_OO")
> >> >  ── R CMD build
> >> > ─
> >> >  ✔  checking for file ‘/Users/jarrettphillips/Desktop/HAC
> >> > simulation/HACSim_OO/DESCRIPTION’ ...
> >> >  ─  preparing ‘HACSim’:
> >> >  ✔  checking DESCRIPTION meta-information ...
> >> >  ─  cleaning src
> >> >  ─  installing the package to process help pages
> >> >   ---
> >> >  ─  installing *source* package ‘HACSim’ ...
> >> > ** using staged installation
> >> > ** libs
> >> > clang++ -arch arm64 -std=gnu++11 -
> >> > I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> >> >
> >>  
> >> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
> >> >
> >> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
> >> > -I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2
> >> -Wall
> >> > -pedantic -fdiagnostics-color=always -c RcppExports.cpp -o RcppExports.o
> >> > clang++ -arch arm64 -std=gnu++11
> >> > -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> >> >
> >>  
> >> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
> >> >
> >> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
> >> > -I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2
> >> -Wall
> >> > -pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
> >> > clang++ -arch arm64 -std=gnu++11 -dynamiclib
> >> > -Wl,-headerpad_max_install_names -undefined dynamic_lookup
> >> -single_module
> >> > -multiply_defined suppress
> >> -L/Library/Frameworks/R.framework/Resources/lib
> >> > -L/opt/R/arm64/lib -o HACSim.so RcppExports.o accumulate.o
> >> > -L/Library/Frameworks/R.framework/Resources/lib -lRlapack
> >> > -L/Library/Frameworks/R.framework/Resources/lib -lRblas
> >> > -L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
> >> > -L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath
> >> > -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
> >> > -Wl,CoreFoundation
> >> > ld: warning: directory not found for option
> >> > '-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
> >> > ld: warning: directory not found for option
> >> > '-L/opt/R/arm64/gfortran/lib'
> >> > ld: library not found for -lgfortran
> >> > clang: error: linker command failed with exit code 1 (use -v to
> >> see
> >> > invocation)
> >> > make: *** [HACSim.so] Error 1
> >> > ERROR: compilation failed for package ‘HACSim’
> >> >  ─  removing
> >> >
> >> ‘/private/var/folders/r4/xm5blbcd2tn06tjv00lm1c78gn/T/RtmpN4uaYR/Rinstdf4219594de/HACSim’
> >> >   ---
> >> >  ERROR: package installation failed
> >> >  Error in `(function (command = NULL, args = character(),
> >> > error_on_status = TRUE, …`:
> >> >  ! System command 'R' failed
> >> >   ---
> >> >   Exit status: 1
> >> >   stdout & stderr: 
> >> >   ---
> >> >  Type .Last.error to see the more details.
> >> >
> >> > `clang` is installed (since I am able to run the code within my package)
> >> > and I've verified by typing `gcc` in the Mac Terminal. I've also
> >> installed
> >> > `Homebrew` and `gfortran`, verifying via typing in the Terminal.
> >> >
> >> > Any idea on what's going on how to fix the issue(s)?
> >>
> >> You don't say how you installed gfortran, but it sounds as though you
> >> installed Homebrew's build of it.  You should 

Re: [R-pkg-devel] CRAN submission error when running tests in testthat

[Gábor Csárdi]

On Thu, Nov 25, 2021 at 11:49 AM Ivan Krylov  wrote:
>
> On Wed, 24 Nov 2021 16:37:44 + (UTC)
> Nathan Green via R-package-devel  wrote:
>
> > An irrecoverable exception occurred. R is aborting now ...
>
> It seems that some of your dependencies which use compiled code
> manage to crash the R process on CRAN Mac machines. Since testthat
> normally hides most output from you and it doesn't get a chance to
> produce useful output on R process crash, it's hard to determine where
> the crash occurs, especially with testthat's backtrace being so long.

Are you sure about this? I don't think testthat hides any output. R
CMD check on the other hand AFAICT only shows the last 13 lines by
default. See the _R_CHECK_TESTS_NLINES_ environment variable in
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html

> Try submitting the package to
> : that should give
> you the full backtrace, at least.

This is an arm64 mac, and the package does not fail on that:
https://cran.rstudio.com/web/checks/check_results_BCEA.html

It is still worth a shot, the crash might be non-deterministic. If it
does not fail, then you can try rhub::check() and select an x86_64
macOS builder.
You can supply environment variables to set in rhub::check, so you can
set _R_CHECK_TESTS_NLINES_ to zero, or you'll also have access to the
testthat.Rout* files at the end of the check.

Considering that your package does not have any compiled code, the
crash is probably in some other package, which will make this quite
hard to fix, especially if you cannot reproduce the crash on R-hub.
FWIW I just ran it on my x86_64 mac and it did not crash.

> If the *.Rout files from the Mac builder don't pinpoint the culprit, try
> passing different reporter= arguments to test_check() and see if any of
> them result in verbose logs that show every test being run.
> Alternatively, switch some of your tests to the classic R tests, which
> produce a verbose .Rout file for every tests/*.R file [*].

I don't think that a different reporter will help if you only have the
truncated R CMD check output.

Gabor


> --
> Best regards,
> Ivan
>
> [*]
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories
>
> __
> 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] What influences the size of the rdb file in a package

[Gábor Csárdi]

You probably (accidentally?) put some large object into your package,
e.g. a non-function object. But it is hard to say more without seeing
the actual code

Gabor

On Fri, Oct 29, 2021 at 10:07 PM Mosqueira Sanchez, Iago
 wrote:
>
>
> I am getting warnings in some packages about the size of the R folder
>
> * checking installed package size ... NOTE
>   installed size is 20.5Mb
>   sub-directories of 1Mb or more:
> data   2.4Mb
> R 17.8Mb
>
> This package contains around 3300 lines of code, if the results of
>
> grep -v '^\s*#' *.R | wc
>
> are correct.
>
> Is this size to be expected? Is there anything I might be missinmg to
> make it smaller?
>
> Thanks,
>
>
> Iago
> --
> dr. Iago Mosqueira
>
> Wageningen Marine Research
>
> Haringkade 1
> Postbus 68
> 1976CP, IJmuiden
>
> Tel.: +31 (0)317 488 995
> iago.mosque...@wur.nl
> __
> 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] multithreading in packages

[Gábor Csárdi]

On Sat, Oct 9, 2021 at 8:52 AM Ivan Krylov  wrote:
[...]
> >* pthread or openmp ? I am particularly concerned about
> > interaction with other packages. I have seen that using pthread and
> > openmp libraries simultaneously can result in incorrectly pinned
> > threads.
>
> pthreads-based code could be harder to run on Windows (which is a
> first-class platform for R, expected to be supported by most packages).

R uses mingw on windows, and mingw supports pthreads, you don't need
to do anything special on Windows. You don't even need a
`Makevars`/`Makevars.win` or configure* file just for using pthreads.

Some CRAN packages do this, you can search here:
https://github.com/search?l=C=5=org%3Acran+pthread_create=Code
(Some of these are from Unix-specific code, but not all.)

Gabor

[...]

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

Re: [R-pkg-devel] Solaris segfaults

[Gábor Csárdi]

Hi Ben,

According to https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
CRAN's Solaris is also 32 bit.
But maybe I am missing something?

You can download a Solaris VM (for Virtualbox or VMware) from
https://files.r-hub.io/solaris/
It has both 32 bit and 64 bit R (with gcc) and ODS R as well. You can
update R on it like this:
https://github.com/r-hub/solarischeck/tree/master/packer#updating-r

Best,
Gabor

On Wed, Sep 15, 2021 at 1:51 AM Ben Bolker  wrote:
>
>I may have asked something like this before, but ...
>
> The glmmTMB package is currently segfaulting (on the very first example)
> on its CRAN Solaris checks
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html
>
> 
>  > ## Comparing variance-covariance matrix with manual computation
>  > data("sleepstudy",package="lme4")
>  > fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)
>
>   *** caught segfault ***
> address 4539ec45, cause 'memory not mapped'
> ---
>
>
>
>   We have to submit a new version to CRAN soon; we will most likely beg
> the CRAN maintainers' indulgence for having it fail on Solaris, but it
> would be nice to fix it if we can.
>
> The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because
> the package uses Rcpp.
>
>The package builds/checks fine on the r-hub `solaris-x86-patched`
> platform, which is identical as far as I can tell **except** 32-bit
> rather than 64-bit.
>
>Short of installing 64-bit Solaris in a VM (which I have not done yet
> because of random compatibility/command-line bullshittery that put me
> off), does anyone have any wisdom to share for diagnosing and/or
> guessing what the problem is?
>
>Here are some links to similar errors, none of them seem terribly
> useful/relevant.
>
> https://github.com/gagolews/stringi/issues/94
> https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html
>
>glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen,
> CppAD, TMB) - the problem could be somewhere in there (the TMB package
> runs no tests and very few examples on CRAN, so there could be problems
> there that only get flagged when we try glmmTMB examples).
>
> More discussion at
>   https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings)
> if anyone is interested.
>
>cheers
> Ben Bolker
>
> __
> 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] submitting package update failed, since old version out of date (?)

[Gábor Csárdi]

I think they are this:

* checking CRAN incoming feasibility ... NOTE
...

and this:

* checking examples ... [76s/77s] NOTE
Examples with CPU (user + system) or elapsed time > 5s
  user system elapsed
ordPens-package 54.112  0.044  54.158
ordPCA  18.377  0.004  18.382

G.

On Tue, Aug 17, 2021 at 3:38 PM Aisouda Hoshiyar
 wrote:
>
> The CRAN (pretest) email states:
>
> package ordPens_1.0.0.tar.gz does not pass the incoming checks automatically, 
> please see the following pre-tests:
> Debian: 
>   
> >
> Status: 2 NOTEs
>
> Last released version's CRAN status: NOTE: 13
> See:  >
>
> Please fix all problems and resubmit a fixed version via the webform.
> If you are fairly certain the rejection is a false positive, please reply-all 
> to this message and explain.
>
> I really don’t understand how else to fix (and what to fix). These are out of 
> date problems of version 0.3-1, which are not relevant any more in version 
> 1.0.0
> Version 1.0.0 exactly was a fix to those.
>
> Do you think I can reply-all & explain that this must be a false-positive?
>
> Best
> Aisouda
>
>
>
> > Am 17.08.2021 um 15:22 schrieb Georgi Boshnakov 
> > :
> >
> > When the previous version has problems, you get an email listing them, 
> > followed with something like 'Did you fix them? Please Reply-All...'
> >
> > Maybe you missed the last phrase?
> >
> > Georgi Boshnakov
> >
> >
> >
> > Get Outlook for Android 
> > From: R-package-devel  on behalf of 
> > Aisouda Hoshiyar 
> > Sent: Tuesday, August 17, 2021 12:59:13 PM
> > To: r-package-devel@r-project.org 
> > Subject: [R-pkg-devel] submitting package update failed, since old version 
> > out of date (?)
> >
> > Hi,
> >
> > submitting an update of our package ordPens failed (update version is 
> > 1.0.0), reporting the following:
> > Version: 1.0.0
> > ok
> > Version: 0.3-1
> > Check: R code for possible problems, Result: NOTE
> >   genRidge: no visible global function definition for 'plogis'
> >   ordGene: no visible global function definition for 'anova'
> >   ordGene: no visible global function definition for 'lm'
> >   ordSelect: no visible binding for global variable 'sd'
> >   ordSmooth: no visible binding for global variable 'sd'
> >   plot.ordPen: no visible global function definition for 'grey'
> >   plot.ordPen: no visible global function definition for 'devAskNewPage'
> >   plot.ordPen: no visible global function definition for 'lines'
> >   predict.ordPen: no visible global function definition for 'plogis'
> >   Undefined global functions or variables:
> > anova devAskNewPage grey lines lm plogis sd
> >   Consider adding
> > importFrom("grDevices", "devAskNewPage", "grey")
> > importFrom("graphics", "lines")
> > importFrom("stats", "anova", "lm", "plogis", "sd")
> >   to your NAMESPACE file.
> > Version: 0.3-1
> > Check: package dependencies, Result: NOTE
> >   Package suggested but not available for checking: ‘IsoGene’
> > https://cran.r-project.org/web/checks/check_results_ordPens.html 
> >  
> >  > >
> >
> > https://win-builder.r-project.org/incoming_pretest/ordPens_1.0.0_20210817_114846/Debian/
> >  
> > 
> >  
> >  >  
> > >
> >
> > But these are exactly the new changes that we already took care of in the 
> > updated version 1.0.0
> > The previous version 0.3-1 is from 2015 and due to R updates, the old 
> > package won’t work any more.
> > That is exactly the reason for update version 1.0.0, were everything is 
> > fixed now.
> >
> > Also,
> > - there is a NOTE about change in maintainer, which is already stated in 
> > the cran-comments.md, and the previous maintainer sent an e-main to CRAN as 
> > well
> > - there is a NOTE saying 'Examples with CPU (user + system) or elapsed time 
> > > 10s‘
> > which is also stated in the cran-comments.md explaining that 
> > cross-validation examples are important for illustrating the package usage.
> >
> >
> > So is this a false positive?
> >
> > Best
> > Aisouda
> >
> >
> >
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > 

Re: [R-pkg-devel] windows and configure scripts

[Gábor Csárdi]

On Sat, Aug 7, 2021 at 1:32 AM Timothy Keitt  wrote:
>
> Snarky answers aside, it's still a valid question whether it's not just
> cleaner in simple cases to run commands from the Makevars file as described
> in the extensions doc. Of course there's no particularly useful examples
> there and searching 'Makevars' on github (yes tried that) is not very
> illuminating as it's too generic.

You can restrict your search to CRAN packages by using the 'cran' organization:
https://github.com/search?q=org%3Acran+filename%3AMakevars.win=Code

You can also have a `configure.win` file, that runs only on Windows, with sh.
Or you can have a single `configure` that works on all platforms, and
call that from `configure.win`. E.g.
https://github.com/cran/ps/blob/master/configure.win

G.

[...]

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

Re: [R-pkg-devel] Scrapping R CRAN website from package

[Gábor Csárdi]

On Sat, Jul 17, 2021 at 2:21 AM  wrote:
>
> Maciej:
>
> There are other packages that query the CRAN site (cranlogs, etc.).  So it
> seems the queries/fetches are generally allowed.  I can only find a couple
> relevant mentions in the CRAN policies:
[...]

For the record, the cranlogs package does not scrape or even just
download anything from CRAN or any CRAN mirror.

Gabor

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

Re: [R-pkg-devel] package test returns error when R version 4.1.0

[Gábor Csárdi]

I think the Bioconductor error on R-hub is a red herring. The error
message is printed, but the actual error is ignored. So this is really
only an issue if you do need a Bioconductor package for the check.

I think the issue might be that for R-devel CRAN binaries are x64
only, but R CMD INSTALL and R CMD check still try to install the
package for i386 as well. Dependencies (e.g. chron in this case) will
not be available on i386.

At least this is the issue for R-hub, because it uses CRAN binaries by
default: 
https://artifacts.r-hub.io/movecost_1.2.tar.gz-cbda0dbe4d7a414498921e9ab2a54aaf/movecost.Rcheck/00install.out

AFAICT Win-builder has its own package library, which might have i386
support, I don't know. So maybe the issue is different there.

Gabor

On Mon, Jul 5, 2021 at 11:27 AM Gianmarco Alberti
 wrote:
>
> Hello,
> Thanks for your reply.
>
> I got mixed results using:
> devtools::check_win_oldrelease() - STATUS OK (R version 4.0.5) - 
> https://win-builder.r-project.org/7qy6PL8C7ye7
>
> devtools::check_win_release() - 1 ERROR (R version 4.1.0) - 
> https://win-builder.r-project.org/hlA15dFq5BdR
>
> devtools::check_win_devel()  - 1 ERROR (R Under development (unstable) - 
> https://win-builder.r-project.org/uQ0LGZ7v0E5h
>
> The reported error is to be:
> ERROR: lazy loading failed for package ‘movecost’
>
> Since I couldn’t understand the actual underlying issue, I ran 
> devtools::check_rhub() (as described in my earlier email) which brought to 
> the fore the Bioconductor issue.
>
> I have tested the package on Win (R version 4.1) and everything was fine.
>
> I hope I have addressed your question.
> Please let me know if you need any other relevant info from my end.
>
> Best
> Gm
>
> 
> Dr Gianmarco Alberti (PhD Udine)
> Lecturer in Spatial Forensics
> Coordinator of the BA dissertations
> Department of Criminology
> Faculty for Social Wellbeing
> Room 332, Humanities B (FEMA)
> University of Malta, Msida, Malta (Europe) - MSD 2080
> tel +356 2340 3718
>
> Academic profiles
> https://www.researchgate.net/profile/Gianmarco_Alberti4
> https://malta.academia.edu/GianmarcoAlberti
>
> Google Scholar profile
> https://scholar.google.com/citations?user=tFrJKQ0J=en
>
> Correspondence Analysis website
> http://cainarchaeology.weebly.com/
>
> R packages on CRAN:
> CAinterprTools
> https://cran.r-project.org/web/packages/CAinterprTools/index.html
>
> GmAMisc
> https://cran.r-project.org/package=GmAMisc
>
> movecost
> https://cran.r-project.org/web/packages/movecost/index.html
> 
> On 5 Jul 2021, 11:20 +0200, Uwe Ligges , 
> wrote:
> > What happens when you test it on winbuilder?
> > It is configured like the CRAN incoming checks and there should be all
> > relevant packages available.
> >
> > Best,
> > Uwe Ligges
> >
> >
> > On 05.07.2021 11:16, Gianmarco Alberti wrote:
> > > Hello,
> > > Further to my earlier email, I think I have located a likely issue, and I 
> > > would appreciate feedback.
> > >
> > > I ran devtools::check_rhub(), and somewhere in the flood of the output I 
> > > got there is the following message:
> > >
> > > Bioconductor does not yet build and check packages for R version 4.2
> > >
> > > The complete report that I got from devtools::check_rhub() is here:
> > > https://builder.r-hub.io/status/movecost_1.2.tar.gz-cbda0dbe4d7a414498921e9ab2a54aaf
> > >
> > >
> > > Any idea about how to proceed in order for me to get my package on CRAN?
> > > I am noticing that I am not the only one experiencing that isse 
> > > (https://github.com/r-hub/rhub/issues/471).
> > >
> > > Best
> > > GmA
> > >
> > > 
> > > Dr Gianmarco Alberti (PhD Udine)
> > > Lecturer in Spatial Forensics
> > > Coordinator of the BA dissertations
> > > Department of Criminology
> > > Faculty for Social Wellbeing
> > > Room 332, Humanities B (FEMA)
> > > University of Malta, Msida, Malta (Europe) - MSD 2080
> > > tel +356 2340 3718
> > >
> > > Academic profiles
> > > https://www.researchgate.net/profile/Gianmarco_Alberti4
> > > https://malta.academia.edu/GianmarcoAlberti
> > >
> > > Google Scholar profile
> > > https://scholar.google.com/citations?user=tFrJKQ0J=en
> > >
> > > Correspondence Analysis website
> > > http://cainarchaeology.weebly.com/
> > >
> > > R packages on CRAN:
> > > CAinterprTools
> > > https://cran.r-project.org/web/packages/CAinterprTools/index.html
> > >
> > > GmAMisc
> > > https://cran.r-project.org/package=GmAMisc
> > >
> > > movecost
> > > https://cran.r-project.org/web/packages/movecost/index.html
> > > 
> > > On 5 Jul 2021, 09:49 +0200, Gianmarco Alberti 
> > > , wrote:
> > > > Good morning,
> > > >
> > > > I got stuck on what follows.
> > > > I have tested a new version of my package locally (on a MAC), and 
> > > > everything is fine.
> > > >
> > > > I got mixed results using:
> > > > 

Re: [R-pkg-devel] speeding up package code/build/test cycle

[Gábor Csárdi]

Actually, I see somewhat different things in RStudio, for me there is
no pre-clean (with the default options AFAIR).

I can reproduce the rebuilding for rgl, but not for other packages I
tried. I vaguely remember a similar issue for another package, which
also used autoconf. So this indeed might be a bug in devtools/pkgload
or some unfortunate interplay between load_all() and autoconf's
configure.

In general, it seems that both RStudio and devtools just use the
package directory, and the object files are in src/. For all the
packages I tried, I did not see an unneeded full rebuild.

G.

On Thu, Jun 24, 2021 at 11:32 PM Duncan Murdoch
 wrote:
>
> On 24/06/2021 5:22 p.m., Gábor Csárdi wrote:
> > On Thu, Jun 24, 2021 at 10:31 PM Duncan Murdoch
> >  wrote:
> > [...]
> >> I'm working in RStudio on a Mac, in case that makes any difference.
> >
> > Yes, RStudio probably does its own thing in "Install and restart". The
> > pre-clean of course removes the object files from the package src/
> > directory, so the next load_all() will need to recompile everything.
>
> But why did step 5 recompile everything?  Here's what you left out of
> the quote:
>
> > 4.  Click "Install and Restart" button again
> >
> > This is the fast build I was talking about:  no recompiling.
> >
> > 5.  devtools::load_all(".")
> >
> > This does the full compile again, so it's slow.
>
> Duncan Murdoch

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

Re: [R-pkg-devel] speeding up package code/build/test cycle

[Gábor Csárdi]

On Thu, Jun 24, 2021 at 10:31 PM Duncan Murdoch
 wrote:
[...]
> I'm working in RStudio on a Mac, in case that makes any difference.

Yes, RStudio probably does its own thing in "Install and restart". The
pre-clean of course removes the object files from the package src/
directory, so the next load_all() will need to recompile everything.

> Your last paragraph is incorrect if "you" is taken to be me rather than
> a generic developer:  I *often* want to install the package while
> working on it.  I like the help system to work; I like to work on the
> source code and help pages together.

I meant 'you' to be generic, and yes, YMMV.

After devtools::load_all(), `?` will show the help pages of the
`load_all()`-d package, not the installed one. So just to get the help
pages of the dev package, you don't need to install it. E.g. after I
`load_all()` rgl, I get

> ?rgl::rgl.bbox
ℹ Rendering development documentation for 'rgl.bbox'

But there are certainly other good reasons to install the package, and
I am sure that with ccache it is not that bad.

[...]

G.

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

Re: [R-pkg-devel] speeding up package code/build/test cycle

[Gábor Csárdi]

On Thu, Jun 24, 2021 at 8:55 PM Duncan Murdoch  wrote:
[...]
> A disadvantage of the devtools method is that a regular build after
> load_all() seems to do a full 75 sec build:  load_all caches things for
> itself, but doesn't put them in the same place as a regular build, so
> make doesn't see the object files, and rebuilds all of them.  Or at
> least it did that last time I tried it, a few months ago.

That is definitely not how load_all() should work, so this might be a
bug. AFAIK it does not use a special cache or anything, just compiles
the files inside the package tree, like a regular package install from
a package tree. This is a regular install after load_all():

❯ system.time(devtools::load_all())
ℹ Loading rgl
This build of rgl does not include OpenGL functions.  Use
 rglwidget() to display results, e.g. via options(rgl.printRglwidget = TRUE).
   user  system elapsed
  0.411   0.024   0.446

❯ q()

❯ time R CMD INSTALL .
* installing to library ‘/Users/gaborcsardi/Library/R/4.0/library’
[...]
* DONE (rgl)
R CMD INSTALL .  9.95s user 1.28s system 97% cpu 11.503 total

So a load_all() that does not need to recompile anything, just reload
the R code, takes less than half a second. After that a regular
install from the command line takes about 12s, most of which is the
byte compilation. If I turn byte compilation off, then it is less than
6s.

But it is rare that you actually need to install the package while
working on it, and you typically just use load_all() to iterate, or
devtools::test() if you use testthat.

Gabor

[...]

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

Re: [R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Gábor Csárdi]

On Wed, Jun 2, 2021 at 1:08 PM Duncan Murdoch  wrote:
[...]
> search.  It would be nice to know if there's an automatic way to answer
> the question
>
> "Why does package xxx appear to require yyy?"

One quick way with the dev version of pak:

install.packages("pak", repos = "https://r-lib.github.io/p/pak/dev/;)
pak::pkg_deps_explain("mvSLOUCH", "gtools")
#> mvSLOUCH -> TreeSim -> geiger -> phytools -> gtools

Gabor

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

Re: [R-pkg-devel] R vignettes

[Gábor Csárdi]

That's not the _full_ output, unfortunately. And if you can't share a
file that reproduces this (not necessarily your original file!), then
Duncan's advice is all we can tell you: don't install packages in
vignettes.

Gabor

On Thu, Apr 29, 2021 at 7:34 PM Danielle Maeser  wrote:
>
> Hi Gabor,
>
> My full output is below:
>Error: object 'col_ed' is not exported by 'namespace:cli'
>Execution halted
>ERROR: lazy loading failed for package 'packagename'
>  ---
>ERROR: package installation failed
>
> Error: 'col_ed' is not an exported object from 'namespace:cli'
> Execution halted
>
> Exited with status 1.
>
> Unfortunately, I can't share a full reproducible example since this package 
> is also included in a manuscript for publication.
>
> I don't export any objects named 'col_ed' so I am quite perplexed by this 
> error message.
>
> I'd appreciate any advice!
>
> Danielle
>
> On Thu, Apr 29, 2021 at 11:42 AM Gábor Csárdi  wrote:
>>
>> If you could share a reproducible example with us, and/or you could
>> show the full output, then we could probably help you better.
>>
>> Gabor
>>
>> On Thu, Apr 29, 2021 at 6:29 PM Danielle Maeser  wrote:
>> >
>> > Hi Duncan,
>> >
>> > I really appreciate your response. Unfortunately, I am still receiving the
>> > error below.
>> >
>> > If anyone has ideas, I'd appreciate it!
>> >
>> > This is the only online forum I can find that discusses the error, but I
>> > have not found it helpful: https://github.com/r-lib/cli/issues/94
>> >
>> >
>> >
>> >
>> > *   ERROR: package installation failedError: 'col_ed' is not an exported
>> > object from 'namespace:cli'Execution halted*
>> >
>> > On Wed, Apr 28, 2021 at 7:32 PM Duncan Murdoch 
>> > wrote:
>> >
>> > > On 28/04/2021 4:41 p.m., Danielle Maeser wrote:
>> > > > Hi Duncan,
>> > > >
>> > > > Thank you for your feedback!
>> > > >
>> > > > Unfortunately, when I made the changes recommended I have a new error:
>> > > >
>> > > > *trying to use CRAN without setting a mirror
>> > >
>> > > That would be a result of your code.  Do you call install.packages() in
>> > > one of your functions?  Normally you shouldn't do that.
>> > >
>> > > > *
>> > > >
>> > > > And:
>> > > > *Error: 'col_ed' is not an exported object from 'namespace:cli'*
>> > >
>> > > Similarly, something in your code or NAMESPACE file.  Do you refer to
>> > > cli::col_ed, or try to import col_ed from cli?
>> > >
>> > > > *
>> > > > *
>> > > > My description file includes:
>> > > > *VignetteBuilder: knitr
>> > > > Depends: R (>= 4.0), knitr
>> > > > License: GPL-2
>> > > > Encoding: UTF-8
>> > > > Roxygen: list(rmarkdown = TRUE)
>> > > > RoxygenNote: 7.1.1
>> > > > LazyData: true
>> > >
>> > > Do you really have a data subdir in your package? You shouldn't have the
>> > > LazyData line without one.
>> > >
>> > > > Suggests: knitr, rmarkdown*
>> > >
>> > > You shouldn't list knitr in both Depends and Suggests.
>> > >
>> > > Duncan Murdoch
>> > >
>> > > > *
>> > > > *
>> > > > And my vignette includes:
>> > > > *title: "title"
>> > > > author: "name"
>> > > > output: rmarkdown::html_vignette
>> > > > vignette: >
>> > > >%\VignetteIndexEntry{title}
>> > > >%\VignetteEngine{knitr::rmarkdown}
>> > > >%\VignetteEncoding{UTF-8}*
>> > > > *
>> > > > *
>> > > > I'd appreciate any advice!
>> > > >
>> > > > Danielle
>> > > >
>> > > > On Wed, Apr 28, 2021 at 2:27 PM Duncan Murdoch 
>> > > > > > > > <mailto:murdoch.dun...@gmail.com>> wrote:
>> > > >
>> > > > On 28/04/2021 2:44 p.m., Danielle Maeser wrote:
>> > > >  > Hello,
>> > > >  >
>> > > >  > I am doing a R CMD check on an R package I have developed.
>> > > > However, I keep
&

Re: [R-pkg-devel] R vignettes

[Gábor Csárdi]

If you could share a reproducible example with us, and/or you could
show the full output, then we could probably help you better.

Gabor

On Thu, Apr 29, 2021 at 6:29 PM Danielle Maeser  wrote:
>
> Hi Duncan,
>
> I really appreciate your response. Unfortunately, I am still receiving the
> error below.
>
> If anyone has ideas, I'd appreciate it!
>
> This is the only online forum I can find that discusses the error, but I
> have not found it helpful: https://github.com/r-lib/cli/issues/94
>
>
>
>
> *   ERROR: package installation failedError: 'col_ed' is not an exported
> object from 'namespace:cli'Execution halted*
>
> On Wed, Apr 28, 2021 at 7:32 PM Duncan Murdoch 
> wrote:
>
> > On 28/04/2021 4:41 p.m., Danielle Maeser wrote:
> > > Hi Duncan,
> > >
> > > Thank you for your feedback!
> > >
> > > Unfortunately, when I made the changes recommended I have a new error:
> > >
> > > *trying to use CRAN without setting a mirror
> >
> > That would be a result of your code.  Do you call install.packages() in
> > one of your functions?  Normally you shouldn't do that.
> >
> > > *
> > >
> > > And:
> > > *Error: 'col_ed' is not an exported object from 'namespace:cli'*
> >
> > Similarly, something in your code or NAMESPACE file.  Do you refer to
> > cli::col_ed, or try to import col_ed from cli?
> >
> > > *
> > > *
> > > My description file includes:
> > > *VignetteBuilder: knitr
> > > Depends: R (>= 4.0), knitr
> > > License: GPL-2
> > > Encoding: UTF-8
> > > Roxygen: list(rmarkdown = TRUE)
> > > RoxygenNote: 7.1.1
> > > LazyData: true
> >
> > Do you really have a data subdir in your package? You shouldn't have the
> > LazyData line without one.
> >
> > > Suggests: knitr, rmarkdown*
> >
> > You shouldn't list knitr in both Depends and Suggests.
> >
> > Duncan Murdoch
> >
> > > *
> > > *
> > > And my vignette includes:
> > > *title: "title"
> > > author: "name"
> > > output: rmarkdown::html_vignette
> > > vignette: >
> > >%\VignetteIndexEntry{title}
> > >%\VignetteEngine{knitr::rmarkdown}
> > >%\VignetteEncoding{UTF-8}*
> > > *
> > > *
> > > I'd appreciate any advice!
> > >
> > > Danielle
> > >
> > > On Wed, Apr 28, 2021 at 2:27 PM Duncan Murdoch  > > > wrote:
> > >
> > > On 28/04/2021 2:44 p.m., Danielle Maeser wrote:
> > >  > Hello,
> > >  >
> > >  > I am doing a R CMD check on an R package I have developed.
> > > However, I keep
> > >  > receiving the warning below:
> > >  >
> > >  > *Files in the 'vignettes' directory but no files in 'inst/doc':*
> > >  >
> > >  > And
> > >  >
> > >  > *Files named as vignettes but with no recognized vignette engine:*
> > >  >
> > >  > I am pretty sure I have the correct YAML header for my vignettes,
> > > and also
> > >  > inst/docs is an older convention for vignettes that's no longer
> > >  > recommended.
> > >  >
> > >  > Do you have an idea of what's going wrong? I have attached my
> > > YAML header
> > >  > below as reference.
> > >
> > > You may be missing the line
> > >
> > > VignetteBuilder: knitr
> > >
> > > in your DESCRIPTION file.  Without that, R won't know how to
> > interpret
> > > your vignette.
> > >
> > > It's also a little unusual to use
> > >
> > > %\VignetteEngine{knitr::markdown}
> > >
> > > nowadays; the more common engine is knitr::rmarkdown (but I believe
> > > both
> > > are still supported).  If you make this change you should also have
> > >
> > > rmarkdown::html_vignette
> > >
> > > as the output format.
> > >
> > > Finally, since a recent update of knitr, you need to make sure that
> > > package holding the output format (i.e. markdown currently,
> > > rmarkdown if
> > > you make the change above) is declared as a Suggested package in your
> > > DESCRIPTION file.
> > >
> > > Duncan Murdoch
> > >
> > >  >
> > >  > Sincerely,
> > >  > Danielle
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > *title: "title of this vignette"author: "name"output:
> > >  > markdown::html_vignettevignette: >  %\VignetteIndexEntry{vignette
> > > title}
> > >  > %\VignetteEngine{knitr::markdown}  %\VignetteEncoding{UTF-8}*
> > >  >
> > >
> > >
> > >
> > > --
> > > Ph.D. Student
> > > Bioinformatics and Computational Biology
> > > University of Minnesota
> > >
> >
> >
>
> --
> Ph.D. Student
> Bioinformatics and Computational Biology
> University of Minnesota
>
> [[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] Using ggplot2 within another package

[Gábor Csárdi]

On Thu, Apr 22, 2021 at 11:19 PM Kevin R. Coombes
 wrote:
[...]
> Instead, the vignette says you should
> importFrom("rlang", ".data")
> in your NAMESPACE, and write
> ggplot(myData, aes(x = .data$myX, y = .data$myY))
>
> And now my dinosaur question: That looks like using one non-standard
> hack to cover up the problems with another non-standard hack. Why the
> heck  is that any better for the developer than writing
> ggplot(myData, aes(x = myData$myX, y = myData$myY))

Well, for one, because it does not always work, see e.g. the examples
and links here:
https://github.com/tidyverse/ggplot2/issues/2693

> or using Dirk Eddelbuettel's suggestion of calling utils::globalVariables ??

Because if you refer to a hundred different columns in your plots, then
you'll need to add all of them to globalVariables(), and this is error prone
and cumbersome to update. If you only refer a handful of columns, then sure,
this will work as well.

Gabor

[...]

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

Re: [R-pkg-devel] Another newbie question: vignettes not appearing in GitHub hosted package

[Gábor Csárdi]

remotes::install_github() is a function aimed at developers that need
the unreleased version of a package for testing or other dev purposes.
In these cases you don't usually need the vignettes. hence the
default.

Gabor

On Wed, Apr 14, 2021 at 8:17 PM Chris Evans  wrote:
>
> Oh no, how embarrassing!
>
> But in my defence, am I the only one who thinks having build_vignettes = 
> FALSE as default is a bit anti-vignettes?!
>
> Many thanks both,
>
> Chris
>
> - Original Message -
> > From: "Zhian N. Kamvar" 
> > To: "r-package-devel" 
> > Sent: Wednesday, 14 April, 2021 17:57:11
> > Subject: Re: [R-pkg-devel] Another newbie question: vignettes not appearing 
> > in GitHub hosted package
>
> > Hi Chris,
> >
> > You need to add the `build_vignettes = TRUE` argument to `install_github()`.
> >
> > On 4/14/21 9:53 AM, Chris Evans wrote:
> >> As ever, my package is https://github.com/cpsyctc/CECPfuns and I am 
> >> building
> >> withing Rstudio 1.4.1103
> >>
> >> I am aiming for the package to have fairly comprehensive vignettes and 
> >> there are
> >> four now, but two are very incomplete.
> >>
> >> The problem I have may relate to
> >> https://github.com/Kenkleinman/clusterPower/issues/113 and to
> >> https://github.com/rstudio/rstudio/issues/1766 or it may not. I have a 
> >> nasty
> >> feeling that I am just looking
> >> straight through something obvious.
> >>
> >> When I run
> >> browseVignettes(package = "CECPfuns")
> >> within Rstudio working on the package I see the vignettes and I have now 
> >> got
> >> pkgdown working to compile the
> >> lovely web site around the package (at https://cecpfuns.psyctc.org/) and I 
> >> see
> >> the vignettes there and they
> >> update.
> >>
> >> The bizarre thing that is beating me is that when I pull the package down 
> >> to any
> >> machine with
> >> remotes::install_github("cpsyctc/CECPfuns")
> >> gets the function but no vignettes! Here's an example from my little Pi 
> >> machine:
> >>
> >>> remotes::install_github("cpsyctc/CECPfuns")
> >> Downloading GitHub repo cpsyctc/CECPfuns@HEAD
> >> ✔ checking for file
> >> ‘/tmp/RtmpPhD1Rg/remotes294e1d1ff9d6/cpsyctc-CECPfuns-ab23518/DESCRIPTION’
> >> (722ms)
> >> ─ preparing ‘CECPfuns’:
> >> ✔ checking DESCRIPTION meta-information ...
> >> ─ installing the package to process help pages
> >> ─ checking for LF line-endings in source and make files and shell scripts
> >> (13.7s)
> >> ─ checking for empty or unneeded directories
> >> ─ looking to see if a ‘data/datalist’ file should be added
> >> ─ building ‘CECPfuns_0.0.0.9041.tar.gz’
> >>
> >> * installing *source* package ‘CECPfuns’ ...
> >> ** using staged installation
> >> ** R
> >> ** inst
> >> ** byte-compile and prepare package for lazy loading
> >> ** help
> >> *** installing help indices
> >> ** building package indices
> >> ** installing vignettes
> >> ** testing if installed package can be loaded from temporary location
> >> ** testing if installed package can be loaded from final location
> >> ** testing if installed package keeps a record of temporary installation 
> >> path
> >> * DONE (CECPfuns)
> >>> browseVignettes(package = "CECPfuns")
> >> No vignettes found by browseVignettes(package = "CECPfuns")
> >>
> >> I hope someone can see what I'm doing wrong! As ever, TIA,
> >>
> >> Chris
> >>
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Chris Evans (he/him)  Visiting Professor, University of 
> Sheffield 
> I do some consultation work for the University of Roehampton 
>  and other places
> but  remains my main Email address.  I have a work web site 
> at:
>https://www.psyctc.org/psyctc/
> and a site I manage for CORE and CORE system trust at:
>http://www.coresystemtrust.org.uk/
> I have "semigrated" to France, see:
>https://www.psyctc.org/pelerinage2016/semigrating-to-france/
>
> https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/
>
> If you want an Emeeting, I am trying to keep them to Thursdays and my diary 
> is at:
>https://www.psyctc.org/pelerinage2016/ceworkdiary/
> Beware: French time, generally an hour ahead of UK.
>
> __
> 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] Another newbie question: vignettes not appearing in GitHub hosted package

[Gábor Csárdi]

remotes::install_github() does not build the vignettes by default, you
can use the build_opts argument to change this.

Gabor

On Wed, Apr 14, 2021 at 6:53 PM Chris Evans  wrote:
>
> As ever, my package is https://github.com/cpsyctc/CECPfuns and I am building 
> withing Rstudio 1.4.1103
>
> I am aiming for the package to have fairly comprehensive vignettes and there 
> are four now, but two are very incomplete.
>
> The problem I have may relate to 
> https://github.com/Kenkleinman/clusterPower/issues/113 and to
> https://github.com/rstudio/rstudio/issues/1766 or it may not. I have a nasty 
> feeling that I am just looking
> straight through something obvious.
>
> When I run
> browseVignettes(package = "CECPfuns")
> within Rstudio working on the package I see the vignettes and I have now got 
> pkgdown working to compile the
> lovely web site around the package (at https://cecpfuns.psyctc.org/) and I 
> see the vignettes there and they
> update.
>
> The bizarre thing that is beating me is that when I pull the package down to 
> any machine with
> remotes::install_github("cpsyctc/CECPfuns")
> gets the function but no vignettes! Here's an example from my little Pi 
> machine:
>
> > remotes::install_github("cpsyctc/CECPfuns")
> Downloading GitHub repo cpsyctc/CECPfuns@HEAD
> ✔ checking for file 
> ‘/tmp/RtmpPhD1Rg/remotes294e1d1ff9d6/cpsyctc-CECPfuns-ab23518/DESCRIPTION’ 
> (722ms)
> ─ preparing ‘CECPfuns’:
> ✔ checking DESCRIPTION meta-information ...
> ─ installing the package to process help pages
> ─ checking for LF line-endings in source and make files and shell scripts 
> (13.7s)
> ─ checking for empty or unneeded directories
> ─ looking to see if a ‘data/datalist’ file should be added
> ─ building ‘CECPfuns_0.0.0.9041.tar.gz’
>
> * installing *source* package ‘CECPfuns’ ...
> ** using staged installation
> ** R
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded from temporary location
> ** testing if installed package can be loaded from final location
> ** testing if installed package keeps a record of temporary installation path
> * DONE (CECPfuns)
> > browseVignettes(package = "CECPfuns")
> No vignettes found by browseVignettes(package = "CECPfuns")
>
> I hope someone can see what I'm doing wrong! As ever, TIA,
>
> Chris
>
> --
> Chris Evans (he/him)  Visiting Professor, University of 
> Sheffield 
> I do some consultation work for the University of Roehampton 
>  and other places
> but  remains my main Email address. I have a work web site 
> at:
> https://www.psyctc.org/psyctc/
> and a site I manage for CORE and CORE system trust at:
> http://www.coresystemtrust.org.uk/
> I have "semigrated" to France, see:
> https://www.psyctc.org/pelerinage2016/semigrating-to-france/
> https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/
>
> If you want an Emeeting, I am trying to keep them to Thursdays and my diary 
> is at:
> https://www.psyctc.org/pelerinage2016/ceworkdiary/
> Beware: French time, generally an hour ahead of UK.
>
> __
> 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 on Debian on RHub

[Gábor Csárdi]

I mean, here:
https://github.com/r-hub/sysreqsdb/commit/e4dd4d6c240407317abb67e156d99ef738a7e73c
https://github.com/r-hub/sysreqsdb/commit/88718aad52df59b7e76c2db563991558a168b05e

G.

On Thu, Apr 8, 2021 at 6:12 PM Gábor Csárdi  wrote:
>
> Should be fixed in e4dd4d6c240407317abb67e156d99ef738a7e73c and
> 88718aad52df59b7e76c2db563991558a168b05e
>
> I haven't yet tested it, though
>
> G.
>
> On Thu, Apr 8, 2021 at 5:58 PM Roy Mendelssohn - NOAA Federal
>  wrote:
> >
> > My apologies, it is the Fedora instance.  Short version summary:
> >
> > Warning messages:
> > 5558#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero exit 
> > status
> > 5559#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit 
> > status
> > 5560#> 3: In i.p(...) :
> > 5561#> installation of package ‘plotdap’ had non-zero exit status
> >
> > 'plotdap' depends on sf which is why it fails.  Long version is at 
> > https://builder.r-hub.io/status/rerddapXtracto_1.1.0.tar.gz-f3facfb7e282436c98dce8b5014de474
> >
> > Thanks,
> >
> > -Roy
> >
> > > On Apr 8, 2021, at 7:35 AM, Roy Mendelssohn - NOAA Federal 
> > >  wrote:
> > >
> > > Thanks Gabor.  I will post more information later today when I get a 
> > > chance.  I actually put something on issue tracker a year or two ago,  
> > > after posting here and having suggested that I raise an issue.
> > >
> > > I really appreciate the work going into RHub - the reason I am having 
> > > this problem is I use RHub to check my submissions.  I just keep failing 
> > > in my CRAN submissions on Debian while passing on Windows and Mac, sort 
> > > of frustrating.
> > >
> > > -Roy
> > >
> > >> On Apr 8, 2021, at 12:22 AM, Gábor Csárdi  wrote:
> > >>
> > >> Hi,
> > >>
> > >> Which one is your package? Which spatial package fails? Can you link
> > >> to an issue in the issue tracker, if there is one?
> > >>
> > >> As for an alternative, you can run a Docker container. This works on
> > >> Linux, Windows and macOS, on any recent enough machine. You can run
> > >> one of the R-hub containers, e.g.
> > >> https://hub.docker.com/repository/docker/rhub/debian-gcc-devel and
> > >> then try to fix the installation issue. Or you can try a bigger
> > >> container that tries to mirror CRAN exactly:
> > >> https://hub.docker.com/r/cran/debian
> > >>
> > >> Gabor
> > >>
> > >> On Thu, Apr 8, 2021 at 6:49 AM Roy Mendelssohn - NOAA Federal via
> > >> R-package-devel  wrote:
> > >>>
> > >>> Hi All:
> > >>>
> > >>> I still have problems with checking one of my packages on RHub running 
> > >>> Debian,  as the Preprocessing fails in building in some of the needed 
> > >>> spatial packages.  This problem was reported quite awhile ago,  and 
> > >>> never appears to have been completely fixed.  Is there an alternate 
> > >>> place I can test a package under Debian that is consistent with CRAN.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> -Roy
> > >>>
> > >>> **
> > >>> "The contents of this message do not reflect any position of the U.S. 
> > >>> Government or NOAA."
> > >>> **
> > >>> Roy Mendelssohn
> > >>> Supervisory Operations Research Analyst
> > >>> NOAA/NMFS
> > >>> Environmental Research Division
> > >>> Southwest Fisheries Science Center
> > >>> ***Note new street address***
> > >>> 110 McAllister Way
> > >>> Santa Cruz, CA 95060
> > >>> Phone: (831)-420-3666
> > >>> Fax: (831) 420-3980
> > >>> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
> > >>>
> > >>> "Old age and treachery will overcome youth and skill."
> > >>> "From those who have been given much, much will be expected"
> > >>> "the arc of the moral universe is long, but it bends toward justice" 
> > >>> -MLK Jr.
> > >>>
> > >>> __
> > >>> R-package-devel@r-project.org mailing list
> > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >

Re: [R-pkg-devel] Checking on Debian on RHub

[Gábor Csárdi]

Should be fixed in e4dd4d6c240407317abb67e156d99ef738a7e73c and
88718aad52df59b7e76c2db563991558a168b05e

I haven't yet tested it, though

G.

On Thu, Apr 8, 2021 at 5:58 PM Roy Mendelssohn - NOAA Federal
 wrote:
>
> My apologies, it is the Fedora instance.  Short version summary:
>
> Warning messages:
> 5558#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero exit 
> status
> 5559#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit status
> 5560#> 3: In i.p(...) :
> 5561#> installation of package ‘plotdap’ had non-zero exit status
>
> 'plotdap' depends on sf which is why it fails.  Long version is at 
> https://builder.r-hub.io/status/rerddapXtracto_1.1.0.tar.gz-f3facfb7e282436c98dce8b5014de474
>
> Thanks,
>
> -Roy
>
> > On Apr 8, 2021, at 7:35 AM, Roy Mendelssohn - NOAA Federal 
> >  wrote:
> >
> > Thanks Gabor.  I will post more information later today when I get a 
> > chance.  I actually put something on issue tracker a year or two ago,  
> > after posting here and having suggested that I raise an issue.
> >
> > I really appreciate the work going into RHub - the reason I am having this 
> > problem is I use RHub to check my submissions.  I just keep failing in my 
> > CRAN submissions on Debian while passing on Windows and Mac, sort of 
> > frustrating.
> >
> > -Roy
> >
> >> On Apr 8, 2021, at 12:22 AM, Gábor Csárdi  wrote:
> >>
> >> Hi,
> >>
> >> Which one is your package? Which spatial package fails? Can you link
> >> to an issue in the issue tracker, if there is one?
> >>
> >> As for an alternative, you can run a Docker container. This works on
> >> Linux, Windows and macOS, on any recent enough machine. You can run
> >> one of the R-hub containers, e.g.
> >> https://hub.docker.com/repository/docker/rhub/debian-gcc-devel and
> >> then try to fix the installation issue. Or you can try a bigger
> >> container that tries to mirror CRAN exactly:
> >> https://hub.docker.com/r/cran/debian
> >>
> >> Gabor
> >>
> >> On Thu, Apr 8, 2021 at 6:49 AM Roy Mendelssohn - NOAA Federal via
> >> R-package-devel  wrote:
> >>>
> >>> Hi All:
> >>>
> >>> I still have problems with checking one of my packages on RHub running 
> >>> Debian,  as the Preprocessing fails in building in some of the needed 
> >>> spatial packages.  This problem was reported quite awhile ago,  and never 
> >>> appears to have been completely fixed.  Is there an alternate place I can 
> >>> test a package under Debian that is consistent with CRAN.
> >>>
> >>> Thanks,
> >>>
> >>> -Roy
> >>>
> >>> **
> >>> "The contents of this message do not reflect any position of the U.S. 
> >>> Government or NOAA."
> >>> **
> >>> Roy Mendelssohn
> >>> Supervisory Operations Research Analyst
> >>> NOAA/NMFS
> >>> Environmental Research Division
> >>> Southwest Fisheries Science Center
> >>> ***Note new street address***
> >>> 110 McAllister Way
> >>> Santa Cruz, CA 95060
> >>> Phone: (831)-420-3666
> >>> Fax: (831) 420-3980
> >>> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
> >>>
> >>> "Old age and treachery will overcome youth and skill."
> >>> "From those who have been given much, much will be expected"
> >>> "the arc of the moral universe is long, but it bends toward justice" -MLK 
> >>> Jr.
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > **
> > "The contents of this message do not reflect any position of the U.S. 
> > Government or NOAA."
> > **
> > Roy Mendelssohn
> > Supervisory Operations Research Analyst
> > NOAA/NMFS
> > Environmental Research Division
> > Southwest Fisheries Science Center
> > ***Note new street address***
> > 110 McAllister Way
> > Santa Cruz, CA 95060
> > Phone: (831)-420-3666
> > Fax: (831) 420-3980
> > e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
> >
> > "Old age and treachery will overcome youth and skill."
> > "From those wh

Re: [R-pkg-devel] Checking on Debian on RHub

[Gábor Csárdi]

Hi,

Which one is your package? Which spatial package fails? Can you link
to an issue in the issue tracker, if there is one?

As for an alternative, you can run a Docker container. This works on
Linux, Windows and macOS, on any recent enough machine. You can run
one of the R-hub containers, e.g.
https://hub.docker.com/repository/docker/rhub/debian-gcc-devel and
then try to fix the installation issue. Or you can try a bigger
container that tries to mirror CRAN exactly:
https://hub.docker.com/r/cran/debian

Gabor

On Thu, Apr 8, 2021 at 6:49 AM Roy Mendelssohn - NOAA Federal via
R-package-devel  wrote:
>
> Hi All:
>
> I still have problems with checking one of my packages on RHub running 
> Debian,  as the Preprocessing fails in building in some of the needed spatial 
> packages.  This problem was reported quite awhile ago,  and never appears to 
> have been completely fixed.  Is there an alternate place I can test a package 
> under Debian that is consistent with CRAN.
>
> Thanks,
>
> -Roy
>
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>
> __
> 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] rcmdcheck reports wrong version of lattice

[Gábor Csárdi]

On Mon, Mar 8, 2021 at 5:45 PM Thierry Onkelinx 
wrote:

> Yes, This was the problem. The recent version of lattice was in my home
> folder ~/R/x86_64-pc-linux-gnu-library/4.0 (first element of .libPaths()).
> An older version of lattice was in /usr/lib/R/library (last element of
> .libPaths()).
>
> install.packages("lattice", lib = "/usr/lib/R/library") solved the problem.
>
> So it looks like rcmdcheck ignored the first element of .libPaths(). I'm
> not sure if that is a bug of rcmdcheck. Shall I report an issue?
>

If you suspect that this behavior is different from running `R CMD check`
directly, then yes, please do.

Thanks,
Gabor

[...]

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] rcmdcheck reports wrong version of lattice

[Gábor Csárdi]

Hi,

If you think this is a bug in rcmdcheck, then please report an issue
here: https://github.com/r-lib/rcmdcheck/issues

My guess is that you have another version of lattice in another
library, and that version is used with `--as-cran`.

Gabor

On Mon, Mar 8, 2021 at 5:18 PM Thierry Onkelinx
 wrote:
>
> Dear all,
>
> rcmdcheck::rcmdcheck() runs fine on my package.  rcmdcheck::rcmdcheck(args
> = c("--as-cran")) reports an error: package ‘lattice’ was installed before
> R 4.0.0: please re-install it
> The error persists, even when I reinstall lattice.
>
> What am I missing?
>
> Best regards,
>
> Thierry
>
> sessioninfo::session_info("lattice")
> ─ Session info
> 
>  setting  value
>  version  R version 4.0.4 (2021-02-15)
>  os   Ubuntu 18.04.5 LTS
>  system   x86_64, linux-gnu
>  ui   RStudio
>  language nl_BE:nl
>  collate  nl_BE.UTF-8
>  ctypenl_BE.UTF-8
>  tz   Europe/Brussels
>  date 2021-03-08
>
> ─ Packages
> 
>  package * version date   lib source
>  lattice   0.20-41 2020-04-02 [1] CRAN (R 4.0.4)
>
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> ///
>
> 
>
> [[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] Support for several versions of another package

[Gábor Csárdi]

On Sun, Feb 21, 2021 at 3:47 PM Iñaki Ucar  wrote:
>
> Hi,
>
> Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
> removes function1 and exports function2 for the same functionality. So
> pkgA does something along these lines:
>
> if (utils::packageVersion("pkgB") < 2) {
>   pkgB::function1()
> } else {
>   pkgB::function2()
> }
>
> I'd say that there's nothing wrong with this code, and yet checks will
> complain about "missing o unexported object" in pkgB, for either
> function1 or function2 depending on the version of pkgB that is
> available.
>
> Isn't this a false positive? Or is there a better way of doing this?

I would just do this:

if (utils::packageVersion("pkgB") < 2) {
  getExportedValue("pkgB", "function1")()
} else {
  getExportedValue("pkgB", "function2")()
}

I would think that the check is fine with this, although I haven't tried.

Gabor

> Regards,
> --
> Iñaki Úcar
>
> __
> 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] Support for several versions of another package

[Gábor Csárdi]

On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch  wrote:
>
> On 21/02/2021 9:47 a.m., Iñaki Ucar wrote:
> > Hi,
> >
> > Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
> > removes function1 and exports function2 for the same functionality. So
> > pkgA does something along these lines:
> >
> > if (utils::packageVersion("pkgB") < 2) {
> >pkgB::function1()
> > } else {
> >pkgB::function2()
> > }
> >
> > I'd say that there's nothing wrong with this code, and yet checks will
> > complain about "missing o unexported object" in pkgB, for either
> > function1 or function2 depending on the version of pkgB that is
> > available.
> >
> > Isn't this a false positive? Or is there a better way of doing this?
>
> I'd agree it's a false positive, but I wouldn't expect the check code to
> be able to interpret the logic.
>
> A better way could be to handle it in your NAMESPACE file.  For example,
> this is legal (if nonsense):
>
> if (utils::packageVersion("rgl") < "0.99.0") {
> importFrom(rgl, bar = somethingNonexistent)
> } else
> importFrom(rgl, bar = persp3d)

Isn't this evaluated at install time? I think it is, and then you
would need to potentially reinstall the package when you update rgl,
which is not quite ideal, because it is easy to miss it, and then
you'll get runtime errors.

Gabor

> Now in the package you can refer to bar, and it'll be persp3d for a new
> version of rgl, somethingNonexistent for an old one.  You won't get a
> warning that somethingNonexistent doesn't exist as long as you're not on
> the old version of rgl.
>
> Duncan Murdoch
>
> __
> 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] Cannot reproduce CRAN error (Solaris i386)

[Gábor Csárdi]

Actually, I can reproduce it if I use the Oracle Studio compilers. You
can also reproduce it on R-hub like this:

rhub::check("metapack_0.1.0.tar.gz", platform = "solaris-x86-patched-ods")

I suggest you fix the valgrind issues first, because they might be
causing this crash as well.

You can also get a Solaris VM, to make it easier to debug the issue on
Solaris: https://github.com/r-hub/solarischeck/tree/master/packer Let
me know if you don't want to build the VM yourself, and I can give you
access to one.

Gabor

On Thu, Feb 18, 2021 at 10:54 AM Gábor Csárdi  wrote:
>
> FWIW this code does not give me any warnings or errors on Solaris and
> R 4.0.4 and the current CRAN version of metapack.
>
> Gabor
>
> On Thu, Feb 18, 2021 at 1:54 AM Daeyoung Lim  wrote:
> >
> > Hello,
> >
> > I have a package on CRAN called 'metapack' and received a message from
> > Professor Ripley that the error must be resolved for the package to be
> > safely retained in CRAN. I've encountered this error on R-CMD-check on
> > GitHub but cannot replicate it on any of my local machines to save my life.
> > The reproducible code snippet is as follows (I use Rcpp/RcppArmadillo):
> >
> > library(metapack)
> > data("cholesterol")
> > Outcome <- model.matrix(~ pldlc + phdlc + ptg, data = cholesterol)
> > SD <- model.matrix(~ sdldl + sdhdl + sdtg, data = cholesterol)
> > Trial <- cholesterol$Trial
> > Treat <- cholesterol$trt
> > Npt <- cholesterol$Npt
> > XCovariate <- model.matrix(~ 0 + bldlc + bhdlc + btg + age + durat +
> > white + male + dm, data = cholesterol)
> > WCovariate <- model.matrix(~ trt, data = cholesterol)
> >
> > fmodel <- 1
> > set.seed(2797542)
> > fit <- bayes.parobs(Outcome, SD, XCovariate, WCovariate, Treat, Trial,
> >   Npt, fmodel, mcmc = list(ndiscard = 1, nskip = 1, nkeep = 1),
> >   scale_x = TRUE, group = cholesterol$onstat, verbose = FALSE)
> >
> > which gives me the following error:
> >
> > warning: chol(): given matrix is not symmetric  error: chol():
> > decomposition failed
> >
> > This can't be true because (1) it runs without problem on other machines,
> > (2) every matrix that is Cholesky-decomposed is ensured to be symmetric
> > through Sig = 0.5 * (Sig + Sig.t());. Even with Sig = arma::symmatu(Sig)
> > doesn't seem to guarantee symmetry.
> >
> > Has anyone encountered something similar to this?
> > Thank you for your time.
> >
> > *Daeyoung Lim, MS*
> >
> > Ph.D. Student
> >
> > Department of Statistics
> >
> > University of Connecticut
> >
> > Philip E. Austin, <https://goo.gl/maps/HsS7bzAMgCw>215 Glenbrook Road
> > <https://goo.gl/maps/HsS7bzAMgCw>
> >
> > Storrs Mansfield, CT 06269-4120 <https://goo.gl/maps/HsS7bzAMgCw>
> >
> > [[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] Cannot reproduce CRAN error (Solaris i386)

[Gábor Csárdi]

FWIW this code does not give me any warnings or errors on Solaris and
R 4.0.4 and the current CRAN version of metapack.

Gabor

On Thu, Feb 18, 2021 at 1:54 AM Daeyoung Lim  wrote:
>
> Hello,
>
> I have a package on CRAN called 'metapack' and received a message from
> Professor Ripley that the error must be resolved for the package to be
> safely retained in CRAN. I've encountered this error on R-CMD-check on
> GitHub but cannot replicate it on any of my local machines to save my life.
> The reproducible code snippet is as follows (I use Rcpp/RcppArmadillo):
>
> library(metapack)
> data("cholesterol")
> Outcome <- model.matrix(~ pldlc + phdlc + ptg, data = cholesterol)
> SD <- model.matrix(~ sdldl + sdhdl + sdtg, data = cholesterol)
> Trial <- cholesterol$Trial
> Treat <- cholesterol$trt
> Npt <- cholesterol$Npt
> XCovariate <- model.matrix(~ 0 + bldlc + bhdlc + btg + age + durat +
> white + male + dm, data = cholesterol)
> WCovariate <- model.matrix(~ trt, data = cholesterol)
>
> fmodel <- 1
> set.seed(2797542)
> fit <- bayes.parobs(Outcome, SD, XCovariate, WCovariate, Treat, Trial,
>   Npt, fmodel, mcmc = list(ndiscard = 1, nskip = 1, nkeep = 1),
>   scale_x = TRUE, group = cholesterol$onstat, verbose = FALSE)
>
> which gives me the following error:
>
> warning: chol(): given matrix is not symmetric  error: chol():
> decomposition failed
>
> This can't be true because (1) it runs without problem on other machines,
> (2) every matrix that is Cholesky-decomposed is ensured to be symmetric
> through Sig = 0.5 * (Sig + Sig.t());. Even with Sig = arma::symmatu(Sig)
> doesn't seem to guarantee symmetry.
>
> Has anyone encountered something similar to this?
> Thank you for your time.
>
> *Daeyoung Lim, MS*
>
> Ph.D. Student
>
> Department of Statistics
>
> University of Connecticut
>
> Philip E. Austin, 215 Glenbrook Road
> 
>
> Storrs Mansfield, CT 06269-4120 
>
> [[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 R CMD build / check using LTO

[Gábor Csárdi]

You can use this Docker container:
https://hub.docker.com/repository/docker/rhub/debian-gcc-devel-lto

It is somewhat old, but chances are that it will reproduce the LTO
issues. I'll update it in a minute, anyway.

Gabor

On Wed, Feb 17, 2021 at 9:33 PM Ivan Krylov  wrote:
>
> On Wed, 17 Feb 2021 20:04:34 +0100
> Paul Schmidt-Walter  wrote:
>
> > I simply don't know how to "build with configure --enable-lto"
>
> "R Installation and Administration"
> 
> contains a detailed set of instructions on how to compile R, including
> section 2.7.4 about the use of LTO. Start with Appendix A, which lists
> the packages you would need to install on your Ubuntu (basically,
> build-essential, gfortran and the libraries mentioned there). Good luck!
>
> --
> Best regards,
> Ivan
>
> __
> 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] URL in RMarkdown file (libcurl error code 35)

[Gábor Csárdi]

I suspect that this is an issue with the CRAN Windows machine, not
with your package.

If you want to work around it in the incoming checks, you can remove
the URL. Maybe it is enough to remove the `https://` from the
beginning, but I am not sure.

Gabor

On Wed, Feb 17, 2021 at 4:33 PM Vincent van Hees
 wrote:
>
> Hello,
> My R package submission got rejected today because of the URL libcurl error
> code 35 issue below (see heading Attempt 1). It seems I have a subscription
> to these errors, because I have been getting them a lot through the years.
> Next, I edited the URL and submitted the package to R-devel on
> win-builder.r-project.org, but there it got flagged again. I am struggling
> to resolve this. Please find below an overview of all my attempts so far..
> Could anyone tell me what I am doing wrong?
> Thanks, Vincent
>
> Attempt 1: Warning after CRAN submission
>
> Flavor: r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility,
> Result: NOTE Maintainer: 'Vincent T van Hees '
> Found the following (possibly) invalid URLs: URL:
> https://journals.humankinetics.com/view/journals/jmpb/2/3/article-p188.xml
> From: inst/doc/GGIR.html Status: Error Message: libcurl error code 35:
> schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
> (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
> received (e.g. handshake failed).
>
> Attemp 2: This is what I submitted to win-builder R-devel. In comparison to
> the CRAN submission this has the doi URL instead of the full journal URL.:
>
> Found the following (possibly) invalid URLs: URL:
> https://doi.org/10.1123/jmpb.2018-0063 From: inst/doc/GGIR.html Status:
> Error Message: libcurl error code 35: schannel: next
> InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This
> error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake
> failed).
>
> Attempt 3:
> Putting a URLencode() statement around the URL was suggested somewhere, e.g.
> [link](URLencode("https://doi.org/10.1123/jmpb.2018-0063;)),  but this
> breaks the URL on my local machine.
>
> Attempt 4: Curl test (in Ubuntu with curl version 7.68) for the journal url
> to see whether this provides any insight:
>
> vincent@vincent:~$ curl -Is
> https://journals.humankinetics.com/view/journals/jmpb/2/3/article-p188.xml
> HTTP/1.1 200 OK
> server: Apache-Coyote/1.1
> set-cookie: JSESSIONID=AF4859DD2D01CF4E1C16EE530712A13F; Path=/; Secure;
> HttpOnly
> content-type: text/html;charset=UTF-8
> transfer-encoding: chunked
> date: Wed, 17 Feb 2021 15:14:04 GMT
> content-security-policy: frame-ancestors 'self'
> set-cookie: ServerID=hk-web-live-bot24; path=/
>
> [[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] Testing on old R versions

[Gábor Csárdi]

On Sun, Jan 31, 2021 at 6:52 PM Duncan Murdoch  wrote:
>
> On 31/01/2021 12:35 p.m., Duncan Murdoch wrote:
> > On 31/01/2021 10:57 a.m., Gábor Csárdi wrote:
> >> Do you actually experience any problems, if you don't treat this case 
> >> specially?
> >
> > Yes, what was happening was that remotes::install_deps skipped
> > installing rgl from CRAN because the local copy had a later version
> > number.  Sorry, I deleted most of the runs that had failures in them, so
> > I can't quote the exact message about this.
>
> I just re-ran a version of the old one.  I'm caching package builds, so
> now I get alphashape3d anyway, but in case you're interested, the
> message was:
>
>   Skipping 1 packages ahead of CRAN: rgl

Right. This is probably because in some iteration you installed the
local (dev) rgl into the library that is cached.
It should still be harmless, because `R CMD check` uses the (new)
local package for the check. The old cached version is only used for
installing alphashape3d and other suggested packages that import or
depend on rgl.

In any case, `remotes::install_local()` seems to be the safest way to
go about this currently.

Gabor


> Duncan Murdoch
>
> >
> >>
> >> AFAIR, in most cases this is not a problem in practice. remotes might
> >> install the CRAN version of rgl as the dependency of alphashape3d, but
> >> `R CMD check` will install and use the local copy of the rgl package
> >> for the check, anyway, so that does not matter much.
> >>
> >> More precisely, it would only matter if alphashape3d had some install
> >> time dependency on rgl, because at install time, it will use the CRAN
> >> rgl version. But this is pretty rare I think.
> >>
> >> If you still want to fix this, you can replace
> >> `remotes::install_deps()` with `remotes::install_local()` and then
> >> remotes will install the local package as well, not only its
> >> dependencies.
> >
> > I'll try that.
> >
> > Duncan
> >
> >>
> >> Gabor
> >>
> >> On Sun, Jan 31, 2021 at 11:32 AM Duncan Murdoch
> >>  wrote:
> >>>
> >>> I am trying out a modified version of the tidyverse actions, and it does
> >>> seem to be going well.  Just one question:
> >>>
> >>> rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
> >>> dependency on rgl.  This means that I need to install in the order
> >>>
> >>>  rgl hard dependencies
> >>>  rgl
> >>>  rgl soft dependencies
> >>>
> >>> Currently I'm using this code to do that:
> >>>
> >>>  # First install rgl with minimal deps then the rest
> >>>  devtools::install()
> >>>  remotes::install_deps(dependencies = TRUE)
> >>>
> >>> but devtools seems unnecessarily heavy for this.  Does remotes have a
> >>> way to specify the install in the right order?
> >>>
> >>> Duncan Murdoch
> >>>
> >>>
> >>> On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
> >>>> On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson
> >>>>  wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> you're probably already aware of it, but 'rgl' depends on 'magrittr'
> >>>>> which depends on 'rlang', and the latter requires R (>= 3.3.0).
> >>>>
> >>>> For the reference, we support R-release, R-devel, and the last four
> >>>> versions of R:
> >>>> https://www.tidyverse.org/blog/2019/04/r-version-support/.
> >>>>
> >>>> We automatically run checks on all these R versions using GitHub
> >>>> actions. You can use the same config as us by running
> >>>> usethis::use_tidy_github_actions(). If you're already using GitHub,
> >>>> I'm pretty confident that this is the fastest/easiest way to check
> >>>> with older versions of R.
> >>>>
> >>>> Hadley
> >>>>
> >>>
> >>> __
> >>> 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] Testing on old R versions

[Gábor Csárdi]

Do you actually experience any problems, if you don't treat this case specially?

AFAIR, in most cases this is not a problem in practice. remotes might
install the CRAN version of rgl as the dependency of alphashape3d, but
`R CMD check` will install and use the local copy of the rgl package
for the check, anyway, so that does not matter much.

More precisely, it would only matter if alphashape3d had some install
time dependency on rgl, because at install time, it will use the CRAN
rgl version. But this is pretty rare I think.

If you still want to fix this, you can replace
`remotes::install_deps()` with `remotes::install_local()` and then
remotes will install the local package as well, not only its
dependencies.

Gabor

On Sun, Jan 31, 2021 at 11:32 AM Duncan Murdoch
 wrote:
>
> I am trying out a modified version of the tidyverse actions, and it does
> seem to be going well.  Just one question:
>
> rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
> dependency on rgl.  This means that I need to install in the order
>
>rgl hard dependencies
>rgl
>rgl soft dependencies
>
> Currently I'm using this code to do that:
>
># First install rgl with minimal deps then the rest
>devtools::install()
>remotes::install_deps(dependencies = TRUE)
>
> but devtools seems unnecessarily heavy for this.  Does remotes have a
> way to specify the install in the right order?
>
> Duncan Murdoch
>
>
> On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
> > On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson
> >  wrote:
> >>
> >> Hi,
> >>
> >> you're probably already aware of it, but 'rgl' depends on 'magrittr'
> >> which depends on 'rlang', and the latter requires R (>= 3.3.0).
> >
> > For the reference, we support R-release, R-devel, and the last four
> > versions of R:
> > https://www.tidyverse.org/blog/2019/04/r-version-support/.
> >
> > We automatically run checks on all these R versions using GitHub
> > actions. You can use the same config as us by running
> > usethis::use_tidy_github_actions(). If you're already using GitHub,
> > I'm pretty confident that this is the fastest/easiest way to check
> > with older versions of R.
> >
> > Hadley
> >
>
> __
> 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] Solaris CRAN check error for package {targets}

[Gábor Csárdi]

Will,

I can help you get a Solaris VM, for VirtualBox or VMware, let me know
in private if you need one.

OTOH that crash is coming from a requireNamespace("clustermq", quietly
= TRUE) call, so it does not seem like it is your fault.

You could also try to reproduce this with `rhub::check()` and one of
the Solaris builders.

Gabor


On Wed, Jan 27, 2021 at 12:18 PM Rasmus Liland  wrote:
>
> On 2021-01-26 21:36 -0500, Will L wrote:
> > All,
> >
> > The {targets} package shows an error
> > on CRAN when checked with Solaris:
> > https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/targets-00check.html.
>
> Hi!  Maybe try out things in a virtual
> machine in qemu or something?
>
> OT: Who uses Solaris anyway, I thought
> it was a long dead project after Oracle
> went in and bought Sun some ten odd
> years ago, contiued in the form of
> Illumos, SmartOS, perhaps now Oxide
> Computing?  Also: i386?? I think no one
> uses this ... this is really old and
> crusty stuff from 2007 [1] ...
>
> Rasmus
>
> [1] https://gcc.gnu.org/legacy-ml/gcc-help/2007-03/msg00042.html
>
> __
> 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] GitHub actions incantation for package living in a subdirectory?

[Gábor Csárdi]

You can try to add some `setwd()` calls at the beginning of each step
that calls some R command.

This is not great of course, much of the GitHub-R tooling just assumes
that a repo contains a single package, at the root of the repo.
Converting your repos to this structure is painful, but can be still
better in the long run.

Gabor

On Thu, Dec 24, 2020 at 12:46 AM Ben Bolker  wrote:
>
>Hi folks,
>
>Attempting to transition a package (glmmTMB/glmmTMB on GitHub) from
> Travis-CI to GIthub Actions.
>
>Setting this up with usethis::use_github_actions() seems fairly
> straightforward, ... but ... this project has the R package living, not
> in the root directory of the repository, but in the 'glmmTMB'
> subdirectory.  In principle, "all" I have to do is add
> "working-directory: ./glmmTMB" in the right place in the
> .github/workflows/R-CMD-check.yaml file, but I don't seem to have
> succeeded so far. The results have either been very rapid failure due to
> syntax errors (https://github.com/glmmTMB/glmmTMB/actions), *or*
> apparently nothing (browsing around, it seems as though one doesn't
> generally see GH actions results until the run is completed?)
>
> Does anyone have suggestions (or, ideally, an example of a package
> with this repository configuration with a working GH actions setup)?
>
> Recent attempts: https://github.com/glmmTMB/glmmTMB/commits/github_actions
>
> Most recent attempt:
> https://github.com/glmmTMB/glmmTMB/commit/d1a08058636df0a4835f897d1e43909510f9c652
>
>  happy holidays to all ...
>
>   Ben Bolker
>
> __
> 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.

[Gábor Csárdi]

On Wed, Dec 16, 2020 at 8:39 PM Henrik Bengtsson
 wrote:
>
> BTW, 'backports' provides a backport for tools::R_user_dir() also for
> R (< 4.0.0), so an alternative solution in this case is:
>
> Imports: backports
>
> and
>
> importFrom(backports, R_user_dir)
>
> The 'backports' package takes the same approach as I did in my previous 
> message.

FWIW, the backports README actually suggests a different approach:
https://github.com/r-lib/backports#in-packages

G.

[...]

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

Re: [R-pkg-devel] ggplot2 axis title with various size fonts

[Gábor Csárdi]

The best place for ggplot2 related questions is https://community.rstudio.com/

Make sure you use the ggplot2 tag for your question.

Gabor

On Tue, Dec 8, 2020 at 9:25 AM neonira Arinoem  wrote:
>
> Is it possible to compose a string to be used as axis title in ggplot2,
> with the main part being drawn using one given font and font size, and the
> last part being drawn with another font and font size. See below for an
> example
>
> *my axis title **(units)*
>
> Currently struggling to achieve this.
> Thanks in advance for suggestions.
>
> [[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] Rglpk on Linux

[Gábor Csárdi]

Hi,

on R-hub's Linux builders it is automatically installed if needed,
except that it wasn't on Fedora, because of a bug. Please try again,
and if it does not work report an issue on R-hub.

On Travis, you'll need to install the required packages yourself in
the `.travis.yml` file.

On CRAN's machines it should be installed, so nothing to worry about there.

If you don't have a Linux machine, but you have a fairly recent macOS
or Windows computer, then you can run Linux in Docker. If you ever
need to debug issues on Linux.

Gabor

On Fri, Nov 27, 2020 at 1:33 PM Benjamin Becker
 wrote:
>
> Dear R developer list,
>
> I want to add 'Rglpk' as a dependency to a package. On windows and MacOS
> everything works fine, but there seem to be installation issues with the
> underlying optimization software 'GLPK' on Linux systems. The problem
> occurs when testing on Rhub and on Travis (I don't have a local Linux
> machine available):
>
> https://builder.r-hub.io/status/eatATA_0.9.0.tar.gz-bbf79f5120bc435d89eb4ea3f5b62918
>
> https://travis-ci.org/github/beckerbenj/eatATA/jobs/743971533
>
> with the error message:
>
> * installing *source* package ‘Rglpk’ ...
>
> ** package ‘Rglpk’ successfully unpacked and MD5 sums checked
>
> ** using staged installation
>
> ** libs
>
> /bin/bash: line 0: cd: GLPK: No such file or directory
>
> Makevars:10: recipe for target 'GLPK.ts' failed
>
> make: *** [GLPK.ts] Error 1
>
> ERROR: compilation failed for package ‘Rglpk’
> I am aware that there are other/similar reports of Rglpk installation
> problems on Linux (e.g.
> https://stackoverflow.com/questions/25114771/glpk-no-such-file-or-directory-error-when-trying-to-install-r-package)
> But other reverse dependencies of Rglpk on CRAN do not appear to have
> these issues (e.g. mknapsack, MSCMT, npbr ...)? Thanks, Benjamin
>
>
> [[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] devtools::release() does not release

[Gábor Csárdi]

Why not submit a bug report at the devtools repository?

❯ packageDescription("devtools")$BugReports
[1] "https://github.com/r-lib/devtools/issues;

Gabor

On Thu, Nov 26, 2020 at 7:50 PM Spencer Graves
 wrote:
>
> Hi folks,
>
>
>   devtools::release() gave the following errors:
>
>
> ...
> Ready to submit fda (5.1.7) to CRAN?
> 1: Not yet
> 2: Absolutely
> 3: U... Maybe?
>
> Selection: 2
> Uploading package & comments
> Confirming submission
> Error in if (new_url$query$submit == "1") { : argument is of length zero
> In addition: Warning messages:
> 1: In charToRaw(enc2utf8(val)) :
>   argument should be a character vector of length 1
> all but the first element will be ignored
> 2: In charToRaw(enc2utf8(val)) :
>   argument should be a character vector of length 1
> all but the first element will be ignored
>
>
>   Jim Ramsay got this after setwd to what seemed to be the appropriate
> working directory and then running devtools::release(), as noted above.
> As near as both of us can determine, we've followed essentially the same
> protocol here as with other package submissions.
>
>
>   In case you want the entire devtools::release() transcript, it
> appears below running under Big Sur on a Mac.
>
>
>   Suggestions?
>   Thanks,
>   Spencer Graves & Jim Ramsay
>
>
> > ——
> >
> > devtools::release()
> >
> > Have you checked for spelling errors (with `spell_check()`)?
> > 1: Not yet
> > 2: Nope
> > 3: Absolutely
> >
> > Selection: 3
> > Have you run `R CMD check` locally?
> > 1: Yes
> > 2: I forget
> > 3: No
> >
> > Selection: 1
> > ── Running additional devtools checks for fda 
> > Checking version number has three components... OK
> > Checking dependencies don't rely on dev versions... OK
> > Checking DESCRIPTION doesn't have Remotes field... OK
> > ──
> > Were devtool's checks successful?
> > 1: I forget
> > 2: No
> > 3: Absolutely
> >
> > Selection: 3
> > Have you fixed all existing problems at
> > https://cran.rstudio.com//web/checks/check_results_fda.html ?
> > 1: Yes
> > 2: Not yet
> > 3: No
> >
> > Selection: 1
> > Have you checked on R-hub (with `check_rhub()`)?
> > 1: Not yet
> > 2: I forget
> > 3: Definitely
> >
> > Selection: 3
> > Have you checked on win-builder (with `check_win_devel()`)?
> > 1: No
> > 2: Nope
> > 3: Absolutely
> >
> > Selection: 3
> > Have you checked the 67 reverse dependencies (with the revdepcheck
> package)?
> > 1: Definitely
> > 2: No
> > 3: U... Maybe?
> >
> > Selection: 1
> > Have you updated `NEWS.md` file?
> > 1: U... Maybe?
> > 2: No
> > 3: Yeah
> >
> > Selection: 3
> > Have you updated `DESCRIPTION`?
> > 1: Yup
> > 2: Nope
> > 3: I forget
> >
> > Selection: 1
> > Have you updated `cran-comments.md?`
> > 1: Nope
> > 2: Not yet
> > 3: Yeah
> >
> > Selection: 3
> > ── Running Git checks for fda 
> > Current branch: master
> > Checking uncommitted files...
> > WARNING: All files should be tracked and committed before release.
> Please add and commit.
> > Checking synchronisation with remote branch...
> > ERROR: Error in 'git2r_remote_fetch': unsupported URL protocol
> >
> > ──
> > Were Git checks successful?
> > 1: Not yet
> > 2: Nope
> > 3: Yup
> >
> > Selection: 3
> > Is your email address ram...@psych.mcgill.ca?
> > 1: Yup
> > 2: I forget
> > 3: U... Maybe?
> >
> > Selection: 1
> > Building
> > ✓  checking for file
> ‘/Users/jamesramsay/Documents/R/fda_work/fda/DESCRIPTION’ (437ms)
> > ─  preparing ‘fda’: (5.8s)
> > ✓  checking DESCRIPTION meta-information ...
> > ─  checking for LF line-endings in source and make files and shell
> scripts (1.6s)
> > ─  checking for empty or unneeded directories
> > ─  building ‘fda_5.1.7.tar.gz’
> >
> > Submitting file:
> /var/folders/sc/6zzfzqbs5w7dl8q5g18tlqfcgn/T//RtmpbcSyMD/fda_5.1.7.tar.gz
> > File size: 102.9 Mb
> > Ready to submit fda (5.1.7) to CRAN?
> > 1: Not yet
> > 2: Absolutely
> > 3: U... Maybe?
> >
> > Selection: 2
> > Uploading package & comments
> > Confirming submission
> > Error in if (new_url$query$submit == "1") { : argument is of length zero
> > In addition: Warning messages:
> > 1: In charToRaw(enc2utf8(val)) :
> >  argument should be a character vector of length 1
> > all but the first element will be ignored
> > 2: In charToRaw(enc2utf8(val)) :
> >  argument should be a character vector of length 1
> > all but the first element will be ignored
> >
> >
>
> __
> 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] Conditional Makevars MacOS

[Gábor Csárdi]

I am not sure if you can solve this without a configure file, which
can be a simple shell script. Here is an example, that detects a bunch
of OSes and then creates an OS-dependent Makevars file:
https://github.com/r-lib/ps/blob/master/configure

You'll probably also need configure.win if you have configure, but it
can just call configure in this case:
https://github.com/r-lib/ps/blob/master/configure.win

Gabor

On Wed, Nov 25, 2020 at 9:01 PM Guido Kraemer  wrote:
>
> I have solved it for now using:
>
> UNAME_S := $(shell uname -s)
> ifeq ($(UNAME_S),Linux)
>  PKG_CPPFLAGS=...
>  PKG_LIBS=...
> else
>  PKG_CPPFLAGS=...
>  PKG_LIBS=...
> endif
>
> But R CMD check now complains about GNU extensions.
>
> Best,
>
> Guido
>
>
> On 11/25/20 2:50 PM, Guido Kraemer wrote:
> > I need to set up different compile flags for MacOS, Linux, and
> > Windows. For Windows I can just use `Makevars.win` but I cannot figure
> > out how to do the same for MacOS.
> >
> > Cheers,
> >
> > Guido
> >
> > __
> > 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] Having shiny as an optional dependency

[Gábor Csárdi]

You probably import functions from shiny. Don't do that, refer to them
with the `::` operator instead.

Gabor

On Sat, Nov 14, 2020 at 6:12 PM Kamil Stachowski
 wrote:
>
> I wrote a package that contains a graphical interface written with packages
> "shiny" and "shinyjqui". My package can also be used from the CLI, so I
> listed both "shiny" and "shinyjqui" as optional dependencies. I ran R CMD
> check --as-cran on my computer in R 3.6.3 and devel, and both passed
> without any errors or warnings. However, when I tried uploading the package
> to CRAN, I got this error:
>
> Error in loadNamespace(x) : there is no package called ‘shiny’
> Error: unable to load R code in package ‘soundcorrs’
> Execution halted
> ERROR: lazy loading failed for package ‘soundcorrs’
>
> How can I fix this?
>
> [[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] Error in loadNamespace(x) : there is no package called 'formatR'

[Gábor Csárdi]

On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch  wrote:
[...]
> Things may have changed since Henrik and I wrote the code, but his
> description matches my understanding as well (and I think he's
> contributed more recently than I have).
>
> The way non-Sweave vignettes work is that some packages register
> themselves to recognize vignette files in the vignettes directory.  The
> default one recognizes .Rnw files as vignettes (and a few other
> extensions too); the knitr::rmarkdown one recognizes .Rmd files and some
> others.  The only way for a package's registration code to be called is
> for it to be listed as a VignetteBuilder.  See ?tools::vignetteEngine
> for details of the engine.

Can one of you please fix WRE then? The part that says

"...then knitr provides the engine but both knitr and rmarkdown are
needed for using it, so both these packages need to be in the
‘VignetteBuilder’ field..."

Thanks a lot!

Gabor

[...]

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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Gábor Csárdi]

On Fri, Nov 13, 2020 at 6:10 PM Henrik Bengtsson
 wrote:
>
> I'm quite sure you want to use the following:
>
> Suggests: knitr, rmarkdown, formatR
> VignetteBuilder: knitr

So this means that WRE is wrong? It says:

"Note that if, for example, a vignette has engine ‘knitr::rmarkdown’,
then knitr provides the engine but both knitr and rmarkdown are needed
for using it, so both these packages need to be in the
‘VignetteBuilder’ field and at least suggested (as rmarkdown is only
suggested by knitr, and hence not available automatically along with
it). Many packages using knitr also need the package formatR which it
suggests and so the user package needs to do so too and include this
in ‘VignetteBuilder’."

My understanding is that R CMD build (and possibly other
commands/functions as well) checks for the packages in
'VignetteBulider`, this is why you need to include rmarkdown and
formatR as well. See the source code in build.R and e.g.
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15775 etc.

G.

[...]

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

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

[Gábor Csárdi]

I think you need to Suggest the formatR package, because your
vignettes use it. From 'Writing R extensions':

"Many packages using knitr also need the package formatR which it
suggests and so the user package needs to do so too and include this
in ‘VignetteBuilder’."

Gabor

On Fri, Nov 13, 2020 at 1:49 PM Joseph Park  wrote:
>
> Dear r-package-devel,
>
> The rEDM package is failing the automated check, as noted here:
>
> https://win-builder.r-project.org/incoming_pretest/rEDM_1.7.0_20201113_131811/Windows/00check.log
>
> When running rhub::check_for_cran(), disk file errors were reported.
>
> The automated check seems to be failing with:
>
> Error in loadNamespace(x) : there is no package called 'formatR'
>
> This package does not explicitly use formatR:
>
> Imports: methods, Rcpp (>= 1.0.1)
> LinkingTo: Rcpp, RcppThread
> Suggests: knitr, rmarkdown
> VignetteBuilder: knitr
>
> Could it be these errors (disk full, no formatR) are related?  If not,
> does formatR need to be listed as a dependency?
>
> If the former (R server config/resource build errors), do I need to
> resubmit the package?
>
> Thank you.
>
> J Park
>
>
> [[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] Usage of internet resources in examples

[Gábor Csárdi]

On Tue, Oct 20, 2020 at 10:07 PM Ben Bolker  wrote:
>
>
>
> On 10/20/20 4:51 PM, Gábor Csárdi wrote:
> > On Tue, Oct 20, 2020 at 9:45 PM Ben Bolker  wrote:
> > [...]
> >> if (testthat::skip_on_cran())
> >>
> >> all seem like reasonable solutions.
> >
> > I don't think you can use `testthat::skip_on_cran()` for this, it does
> > not return a logical flag:
> >
> > ❯ isTRUE(testthat::skip_on_cran())
> > Error: Reason: On CRAN
> >
> > It only works in testthat tests.
> >
> > Gabor
> >
> > [...]
> >
>
>oh OK, sorry.  The guts of the function are (in testthat:::on_cran(),
> which can't be used because it's not exported)
>
> !identical(Sys.getenv("NOT_CRAN"), "true")

It is not really worth exporting this, because it just checks for an
environment variable, that's all it does. So all users would need to
set this environment variable to be able to run the examples. Which
does not seem like a great solution.

G.

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

Re: [R-pkg-devel] Usage of internet resources in examples

[Gábor Csárdi]

On Tue, Oct 20, 2020 at 9:45 PM Ben Bolker  wrote:
[...]
>if (testthat::skip_on_cran())
>
> all seem like reasonable solutions.

I don't think you can use `testthat::skip_on_cran()` for this, it does
not return a logical flag:

❯ isTRUE(testthat::skip_on_cran())
Error: Reason: On CRAN

It only works in testthat tests.

Gabor

[...]

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

Re: [R-pkg-devel] rJava (broken installation?)

[Gábor Csárdi]

Make sure you quit from all R sessions before you reinstall rJava, and
also that it is not loaded in the current session.

You can also run tools::checkMD5sums("rJava") to check the MD5 sums.

Gabor

On Tue, Oct 13, 2020 at 4:55 PM Helmut Schütz  wrote:
>
> Dear all,
>
> in one of my packages I import from package xlsx, which itself imports
> rJava.
> I have the current Java (jre1.8.0_261) installed:
> JAVA_VERSION="1.8.0_261"
> OS_NAME="Windows"
> OS_VERSION="5.2"
> OS_ARCH="amd64"
>
> However:
> devtools::session_info("rJava")
> - Session info
> ---
>  setting  value
>  version  R version 4.0.3 (2020-10-10)
>  os   Windows 7 x64 SP 1
>  system   x86_64, mingw32
>  ui   Rgui
>  language EN
>  collate  German_Germany.1252
>  ctypeGerman_Germany.1252
>  tz   Europe/Vienna
>  date 2020-10-13
>
> - Packages
> ---
>  ! package * version date   lib source
>  D rJava 0.9-13  2020-07-06 [1] CRAN (R 4.0.2)
>
> [1] D:/Program Files/R/R-4.0.3/library
>
>  D -- DLL MD5 mismatch, broken installation.
>
> I found only this:
> https://community.rstudio.com/t/error-dll-md5-mismatch-broken-installation/64141
> with no answer.
>
> Deleted rJava from my library and made a new install, no avail.
>
> The functions I need from xlsx work as intended but I'm worried a bit.
>
> Helmut
>
> --
> Ing. Helmut Schütz
> BEBAC – Consultancy Services for
> Bioequivalence and Bioavailability Studies
> Neubaugasse 36/11
> 1070 Vienna, Austria
> E helmut.schu...@bebac.at
> W https://bebac.at/
> F https://forum.bebac.at/
>
> __
> 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] dependency fails checking a package on ASAN/UBSAN (on r-hub)

[Gábor Csárdi]

It seems that Debian testing has a new version of libxml2, or maybe
the ICU is newer, and the xml package does not compile with this.

I am afraid that xml2 needs some fixes to solve this. It might be
enough to require C++11 support. If you don't want to wait for the
xml2 maintainer, then you can fork the repo, add C++11 support to your
fork, and then (temporarily) add a `Remotes` field to `DESCRIPTION`
that points to your fork.

Gabor

On Thu, Oct 1, 2020 at 1:08 PM Georgi Boshnakov
 wrote:
>
> Hi,
>
> A package submitted on CRAN shows problems only on ASAN/UBSAN.
> I  used 'r-hub' (rhub::check()) to check if my update has fixed that on that 
> platform but
> This is unsuccessful since a dependency fails to install.
>
> The dependency in question is 'xml2'  so it surely can be installed one way 
> or another but do I need to give additional parameters? The report from r-hub 
> is at
> HTML
>
>
> Georgi Boshnakov
>
> [[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] force revdepcheck to use local version of a dependency

[Gábor Csárdi]

You can define the special dependency of the revdep-checked package in
the `Remotes` field. More info:
https://cran.rstudio.com/web/packages/remotes/vignettes/dependencies.html

E.g. if you are revdep-checking package PKG, then you can add
something like this in the DESCRIPTION file of PKG:
Remotes: local::/path/to/your/package
or if the package is on GitHub:
Remotes: user/repo

Then revdepcheck will automatically install the special version of the
dependency, for the dev version of the revdep-checked package. (But
not for the CRAN version of the package.)

Best,
Gabor

On Mon, Sep 28, 2020 at 6:17 PM Georgi Boshnakov
 wrote:
>
> Hi,
>
> I am using package 'revdepcheck' to check reverse dependencies of a package 
> and it works great. But now I have a scenario such that I wish it to use a 
> local version of one of the dependencies of the checked package and am not 
> able to find out how.
>
> Some context: Package A imports package B. Package A has many reverse 
> dependencies. I wish to check if an update to package B will break some of 
> the reverse dependencies of A and/or repair broken reverse dependencies of A. 
> It is obvious to update B on CRAN but this may lead unnecessarily to a number 
> of CRAN updates.
>
>
> Georgi Boshnakov
>
>
> [[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] visible binding for '<<-' assignment

[Gábor Csárdi]

You can include Unicode strings in a package, either as data, or just
as character vectors. Or character vectors returned by functions. Many
packages do that. E.g. cli:::symbol_utf8$tick is Unicode (not
exported, but it could be).

The only restriction is that the source file must be ASCII, i.e. you
need to create these vectors with `\u` escapes. For example the tick
in cli is created like this:
https://github.com/r-lib/cli/blob/e3ca34656f5bb82df63bfc1c741e75acc79b13d9/R/symbol.R#L27

When you print it (e.g. with something like
`cat(cli:::symbol_utf8$tick)`) the proper Unicode character is
printed, as long as the platform supports it. E.g. on macOS:

❯ cli:::symbol_utf8$tick
[1] "✔"

Gabor

On Thu, Sep 3, 2020 at 11:26 PM Dan Zigmond  wrote:
>
> I get that, but these variables are created by the package. It's a data
> package so the whole point is to provide access to the data. I'm just
> trying to provide an option to make the data more readable since I can't
> include Unicode strings directly in the package. In other words, these
> variables (eg, pali_alphabet) will already exist when the user attaches the
> package – but is there a way I can tweak them after the package has been
> loaded?
>
>  Dan
>
> .
> --
> Dan Zigmond
> d...@shmonk.com
>
>
>
> On Thu, Sep 3, 2020 at 2:56 PM William Dunlap  wrote:
>
> > > Is there a reason that this slightly more explicit
> > > version [assign(envir=.GlobalEnv)] wouldn't work?
> >
> > https://cran.r-project.org/web/packages/policies.html
> > - Packages should not modify the global environment (user’s workspace).
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> > On Thu, Sep 3, 2020 at 2:36 PM Ben Bolker  wrote:
> > >
> > >   Is there a reason that this slightly more explicit version wouldn't
> > work?
> > >
> > > pali_string_fix <- function() {
> > >  assign("pali_alphabet",
> > stringi::stri_unescape_unicode(pali_alphabet),
> > > .GlobalEnv)
> > > }
> > >
> > >
> > > On 9/3/20 5:25 PM, Dan Zigmond wrote:
> > > > Thanks, Gabor. I want these to be easily available to package users
> > though
> > > > – that's why they are in the package. So I would rather not "hide"
> > them in
> > > > a local environment. This is fundamentally a data package, so access to
> > > > this data is the primary point of installing it.
> > > >
> > > > Is there any other solution?
> > > >
> > > >   Dan
> > > >
> > > > .
> > > > --
> > > > Dan Zigmond
> > > > d...@shmonk.com
> > > >
> > > >
> > > >
> > > > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi 
> > wrote:
> > > >
> > > >> Store the cached data in an environment within the package:
> > > >>
> > > >> pali_data <- new.env(parent = emptyenv())
> > > >>
> > > >> pali_string_fix <- function() {
> > > >>pali_data$alphabet <-
> > > >>   stringi::stri_unescape_unicode(pali_alphabet)
> > > >> ...
> > > >> }
> > > >>
> > > >> Gabor
> > > >>
> > > >> On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond  wrote:
> > > >>>
> > > >>> Hi, all. I am developing a package that includes some global
> > variables.
> > > >>> Because these are non-ASCII, I have escaped them. But then because
> > these
> > > >>> are difficult to read, I want to provide an easy way for users to
> > > >> unescape
> > > >>> all of them up front. Thus I have code like to create and save the
> > data
> > > >> in
> > > >>> global variables in one file:
> > > >>>
> > > >>> pali_vowels <-
> > > >>>c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o")
> > > >>> pali_consonants <-
> > > >>>c("k", "kh", "g", "gh", "\u1e45",
> > > >>>  "c", "ch", "j", "jh", "\u00f1",
> > > >>>  "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47",
> > > >>>  &q

Re: [R-pkg-devel] visible binding for '<<-' assignment

[Gábor Csárdi]

On Thu, Sep 3, 2020 at 10:25 PM Dan Zigmond  wrote:
>
> Thanks, Gabor. I want these to be easily available to package users though – 
> that's why they are in the package. So I would rather not "hide" them in a 
> local environment. This is fundamentally a data package, so access to this 
> data is the primary point of installing it.

Well, if you want to put a cache in a package, then the way I showed
you works well.

Possibly more importantly, maybe I misunderstood something, but
stringi::stri_unescape_unicode() is not doing anything or your
character vectors, because they do not contain escaped characters:

fixed <- stringi::stri_unescape_unicode(pali_alphabet)
identical(pali_alphabet, fixed)
#> TRUE

Gabor

> Is there any other solution?
>
>  Dan
>
> .
> --
> Dan Zigmond
> d...@shmonk.com
>
>
>
> On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi  wrote:
>>
>> Store the cached data in an environment within the package:
>>
>> pali_data <- new.env(parent = emptyenv())
>>
>> pali_string_fix <- function() {
>>   pali_data$alphabet <-
>>  stringi::stri_unescape_unicode(pali_alphabet)
>> ...
>> }
>>
>> Gabor
>>
>> On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond  wrote:
>> >
>> > Hi, all. I am developing a package that includes some global variables.
>> > Because these are non-ASCII, I have escaped them. But then because these
>> > are difficult to read, I want to provide an easy way for users to unescape
>> > all of them up front. Thus I have code like to create and save the data in
>> > global variables in one file:
>> >
>> > pali_vowels <-
>> >   c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o")
>> > pali_consonants <-
>> >   c("k", "kh", "g", "gh", "\u1e45",
>> > "c", "ch", "j", "jh", "\u00f1",
>> > "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47",
>> > "t", "th", "d", "dh", "n",
>> > "p", "ph", "b", "bh", "m",
>> > "y", "r", "l", "v", "s", "h", "\u1e37", "\u1e43")
>> > pali_alphabet <-c(pali_vowels, pali_consonants)
>> > use_data(pali_alphabet, overwrite = TRUE)
>> >
>> > and then I try to export a function like this in another file:
>> >
>> > pali_string_fix <- function() {
>> >   pali_alphabet <<-
>> >  stringi::stri_unescape_unicode(pali_alphabet)
>> >   # Several more of these...
>> >   }
>> >
>> > The idea is that users can run pali_string_fix() once when they load the
>> > package and then they won't need to deal with all the Unicode escape
>> > sequences after that.
>> >
>> > However, this is getting rejected by the CRAN checks with the message:
>> >
>> > * checking R code for possible problems ... [4s] NOTE
>> > pali_string_fix: no visible binding for '<<-' assignment to
>> >   'pali_alphabet'
>> >
>> > I'm guessing this is because the data and the function are defined in
>> > different files, so even though those globals are defined by my package,
>> > that isn't obvious when the check is run on this code.
>> >
>> > Does anyone have advice for how to fix this?
>> >
>> >  Dan
>> >
>> > .
>> > -
>> > Dan Zigmond
>> > d...@shmonk.com
>> >
>> > [[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] visible binding for '<<-' assignment

[Gábor Csárdi]

Store the cached data in an environment within the package:

pali_data <- new.env(parent = emptyenv())

pali_string_fix <- function() {
  pali_data$alphabet <-
 stringi::stri_unescape_unicode(pali_alphabet)
...
}

Gabor

On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond  wrote:
>
> Hi, all. I am developing a package that includes some global variables.
> Because these are non-ASCII, I have escaped them. But then because these
> are difficult to read, I want to provide an easy way for users to unescape
> all of them up front. Thus I have code like to create and save the data in
> global variables in one file:
>
> pali_vowels <-
>   c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o")
> pali_consonants <-
>   c("k", "kh", "g", "gh", "\u1e45",
> "c", "ch", "j", "jh", "\u00f1",
> "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47",
> "t", "th", "d", "dh", "n",
> "p", "ph", "b", "bh", "m",
> "y", "r", "l", "v", "s", "h", "\u1e37", "\u1e43")
> pali_alphabet <-c(pali_vowels, pali_consonants)
> use_data(pali_alphabet, overwrite = TRUE)
>
> and then I try to export a function like this in another file:
>
> pali_string_fix <- function() {
>   pali_alphabet <<-
>  stringi::stri_unescape_unicode(pali_alphabet)
>   # Several more of these...
>   }
>
> The idea is that users can run pali_string_fix() once when they load the
> package and then they won't need to deal with all the Unicode escape
> sequences after that.
>
> However, this is getting rejected by the CRAN checks with the message:
>
> * checking R code for possible problems ... [4s] NOTE
> pali_string_fix: no visible binding for '<<-' assignment to
>   'pali_alphabet'
>
> I'm guessing this is because the data and the function are defined in
> different files, so even though those globals are defined by my package,
> that isn't obvious when the check is run on this code.
>
> Does anyone have advice for how to fix this?
>
>  Dan
>
> .
> -
> Dan Zigmond
> d...@shmonk.com
>
> [[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] Help with a note

[Gábor Csárdi]

`return()` is a function in R, so `return` does nothing. You probably
want `return()`.

Here:
https://github.com/Anirban166/testComplexity/blob/c991c31e5250bcaf804c3ad781fbc126c6a17e57/R/asymptoticMemoryUsage.R#L22
https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R#L22

Gabor

On Thu, Sep 3, 2020 at 6:42 PM Anirban  wrote:
>
> Hi, I've one note in my package which I can't seem to resolve while
> submitting to CRAN:
>
>   New submission
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: R code for possible problems, Result: NOTE
>   Possibly missing '()' after 'return' in the following functions:
> 'asymptoticMemoryUsage' 'asymptoticTimings'
>
>
> There are opening and closing brackets with the return statement to the
> functions already. The source code can be found here:
> asymptoticTimings:
> https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticTimings.R
> asymptoticMemoryUsage:
> https://github.com/Anirban166/testComplexity/blob/master/R/asymptoticMemoryUsage.R
>
>
> The note seems trivial but I can't seem to get rid of it. Any help would be
> appreciated.
>
> Thanks,
> Anirban
>
> [[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] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

[Gábor Csárdi]

On Wed, Sep 2, 2020 at 11:11 PM Dirk Eddelbuettel  wrote:
>
>
> On 2 September 2020 at 23:59, Emmanuel Blondel (GMAIL) wrote:
[...]
> | Your advice in order to solve that would be much appreciated,
>
> Life, as they say, "is too short" so you could just comment-out the test.

Indeed, it is probably best not to run this test on CRAN's machines.

It probably fails because CRAN's keyring package is built without the
OS's keyring library, at least on Fedora.

But really, ideally you would not access the OS keyring in test cases,
except when running on a CI, or on the developers' machines.

Gabor

[...]

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

Re: [R-pkg-devel] help in identifying a segfault (rhub)

[Gábor Csárdi]

Is this reproducible on R-hub? Do you see it with the other R-devel
containers as well?

Some things to try:

Try running address sanitizer on your package to see if it can find
any memory errors. You can do this on R-hub as well, if you cannot do
it on your machine.

Try downloading the https://hub.docker.com/r/rhub/fedora-clang-devel
Docker container and reproduce this locally.

Gabor

On Mon, Aug 24, 2020 at 10:09 PM Jendoubi Bedhiafi, Takoua
 wrote:
>
> Hi all,
>
> I am reaching out to seeking help in debugging my package.
> The package has been already on CRAN for some time, updated twice. Also, I 
> have been checking the package regularly on rhub, since my last submission to 
> CRAN, with no errors.
>
> However, recently last checks on rhub end with a segmentation fault for the 
> following platform:
> Platform:   Fedora Linux, R-devel, clang, gfortran
>
> From the error log below it seems that the error happens after running the 
> examples:
>
>
> * checking examples with --run-donttest ...sh: line 1: 10229 Segmentation 
> fault  (core dumped) LANGUAGE=en _R_CHECK_INTERNALS2_=1 
> R_LIBS=/tmp/RtmpBr5Iyu/RLIBS_264b50c09c34 R_ENVIRON_USER='' R_LIBS_USER='' 
> R_LIBS_SITE='no_such_dir' '/opt/R-devel/lib64/R/bin/R' --vanilla 
> --encoding=UTF-8 > 'iCARH-Ex.Rout' 2>&1 < 'iCARH-Ex.R'
>  ERROR
> Running examples in ‘iCARH-Ex.R’ failed
> The error most likely occurred in:
>
> > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> > ### Name: iCARH.getPathwaysMat
> > ### Title: Builds pathways adjacency matrices
> > ### Aliases: iCARH.getPathwaysMat
> >
> > ### ** Examples
> >
> > keggid = list("C08363")
> > iCARH.getPathwaysMat(keggid, "rno")
> [1] "no result"
> NULL
> > ## No test:
> > keggid = list("Unk1", "C00350","Unk2",c("C08363", "C00712"))
> > iCARH.getPathwaysMat(keggid, "rno")
> named list()
> > ## End(No test)
> >
> >
> >
> >
> > base::assign(".dptime", (proc.time() - get(".ptime", pos = "CheckExEnv")), 
> > pos = "CheckExEnv")
> > base::cat("iCARH.getPathwaysMat", base::get(".format_ptime", pos = 
> > 'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n", 
> > file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
> > cleanEx()
>
>  *** caught segfault ***
> address 0xff96, cause 'memory not mapped'
> An irrecoverable exception occurred. R is aborting now ...
>
>
>  The full log link is below:
> https://builder.r-hub.io/status/original/iCARH_2.0.2.1.tar.gz-5af530549db347e2827b37d9e8b00231
>
> Any ideas on how this can be solved are welcome.
>
> Thanks in advance,
> Bw,
>
> Dr. Takoua Jendoubi
> Statistics section | Department of Mathematics |
> Imperial College London | Room 533 |
> South Kensington Campus | London |
> SW7 2AZ |
>
>
> [[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] install_git +submodules

[Gábor Csárdi]

Hi, If you mean remotes::install_git(), and you think this is a bug in
remotes, then please open an issue in the remotes issue tracker:
https://github.com/r-lib/remotes/issues

Thanks,
Gabor


On Sat, Aug 22, 2020 at 9:08 PM Sameh M. Abdulah
 wrote:
>
>
> I am using install_git to download my package from Github. The problem that I 
> am using submodule on my repo and install_git always uses the master branch 
> of this submodule.
> I defined mu submodules to uses a specific commit, not the master.
>
> I tried to used args="--recursive" but the same problem is still occurring.
>
>
> --Sameh
>
> [[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

[R-pkg-devel] cran macos metadata error for ps package

[Gábor Csárdi]

❯ install.packages("ps", repos = "https://cran.r-project.org;)
Installing package into ‘/Users/gaborcsardi/Library/R/4.0/library’
(as ‘lib’ is unspecified)
trying URL 'https://cran.r-project.org/bin/macosx/contrib/4.0/ps_1.3.4.tgz'
Error in download.file(url, destfile, method, mode = "wb", ...) :
  cannot open URL
'https://cran.r-project.org/bin/macosx/contrib/4.0/ps_1.3.4.tgz'
In addition: Warning message:
In download.file(url, destfile, method, mode = "wb", ...) :
  cannot open URL
'https://cran.r-project.org/bin/macosx/contrib/4.0/ps_1.3.4.tgz': HTTP
status was '404 Not Found'
Warning in download.packages(pkgs, destdir = tmpd, available = available,  :
  download of package ‘ps’ failed

FYI,
Gabor

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

Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang

[Gábor Csárdi]

On Fri, Aug 7, 2020 at 3:51 PM Helmut Schütz  wrote:
>
> Hi Gábor,
>
> Gábor Csárdi wrote on 2020-08-07 16:46:
> > If you want to link to a package in the documentation, you'll have to
> > add it to Suggests.
>
> THX, will do. Is this documented somewhere?

The check is documented in
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html
You can turn it on with the _R_CHECK_XREFS_PKGS_ARE_DECLARED_
environment variable.

> Any why don't the *other*
> installations of CRAN complain as well?

I don't know if they run a different set of checks on purpose or by accident.

G.

> Helmut
>
> --
> Ing. Helmut Schütz
> BEBAC – Consultancy Services for
> Bioequivalence and Bioavailability Studies
> Neubaugasse 36/11
> 1070 Vienna, Austria
> T +43 1 2311746
> M +43 699 10792458
> E helmut.schu...@bebac.at
> W https://bebac.at/
> C https://bebac.at/Contact.htm
> F https://forum.bebac.at/
> GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209
> GDPR https://bebac.at/Data-Protection.htm
>
>

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

Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang

[Gábor Csárdi]

If you want to link to a package in the documentation, you'll have to
add it to Suggests.

Gabor

On Fri, Aug 7, 2020 at 3:45 PM Helmut Schütz  wrote:
>
> Dear all,
>
> I'm struggling to understand this NOTE in
> r-devel-linux-x86_64-fedora-clang (only)
> https://cran.r-project.org/web/checks/check_results_PowerTOST.html
> emmeans is a great package (THX Russell!) but we don't use it anywhere
> in ours.
>
> Only in two man pages we have
> ... obtained via \code{\link[emmeans]{emmeans}} of package \code{emmeans}.
>
> Previously we had plain text and were asked by users for details.
> AFAIK, this is the correct syntax acc. to the REM linking to the man
> page of another package. In the library links work as intended.
>
> Our package is used in a regulated environment where even a NOTE raises
> eyebrows.
> In all other R-versions and operating systems there is no problem. What
> surprises me is that on Fedora the results depends on the C-compiler.
> Strange.
>
> Of course, we could use in NAMESPACE
>importFrom(emmeans, emmeans)
> but that would force users to install a package they might not need at all.
>
>
> Helmut
>
> --
> Ing. Helmut Schütz
> BEBAC – Consultancy Services for
> Bioequivalence and Bioavailability Studies
> Neubaugasse 36/11
> 1070 Vienna, Austria
> E helmut.schu...@bebac.at
> W https://bebac.at/
> F https://forum.bebac.at/
>
> __
> 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 Error Due to Unicode in Documentation

[Gábor Csárdi]

On Thu, Jul 23, 2020 at 10:25 PM Gábor Csárdi  wrote:
>
> On Thu, Jul 23, 2020 at 9:58 PM Duncan Murdoch  
> wrote:
> >
> > On 23/07/2020 4:14 p.m., b...@denney.ws wrote:
[...]
> Bill, please report a roxygen2 issue at
> https://github.com/r-lib/roxygen2/issues and we can probably fix this.
[...]

Btw. you can possibly work around this by manually providing the
@usage for this one function.

Gabor

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

Re: [R-pkg-devel] Check Error Due to Unicode in Documentation

[Gábor Csárdi]

On Thu, Jul 23, 2020 at 9:58 PM Duncan Murdoch  wrote:
>
> On 23/07/2020 4:14 p.m., b...@denney.ws wrote:
[...]
>
> If you change the source to include the explicit characters (i.e. use
> pattern = c("μ", "µ") instead of pattern=c("\u03bc", "\u00b5")), does
> that help?
>
> It may cause other issues:  WRE recommends against including UTF-8 chars
> in source code.
>
> If that doesn't solve the problem, then it looks like an issue with
> Roxygen2.  I don't know if there's a way to tell it not to convert \u
> escapes into the corresponding character.  If there isn't, it seems like
> that's something they should add.  As a workaround, is there a way to
> say that this one particular .Rd file should be edited by hand, instead
> of auto-generated?

I don't think roxygen2 intentionally converts \u sequences, I think
this is just a consequence of the parse() + deparse() roundtrip:

x <- '"\\u03bc"'
charToRaw(x)
#>  [1] 22 5c 75 30 33 62 63 22
y <- deparse(eval(parse(text = x)))
charToRaw(y)
#> [1] 22 b5 22

Bill, please report a roxygen2 issue at
https://github.com/r-lib/roxygen2/issues and we can probably fix this.
Thanks!

Gabor

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

Re: [R-pkg-devel] Failing rhub::check_for_cran() because of data.table

[Gábor Csárdi]

Hi, this is because data.table is not available as a binary package
for R-devel, on CRAN. You can tell R to build it from source like
this:

rhub::check(
  platform="windows-x86_64-devel",
  env_vars=c(R_COMPILE_AND_INSTALL_PACKAGES = "always")
)

Btw. please report R-ghub errors in the issue tracker, e.g.
https://github.com/r-hub/rhub/issues/367#issuecomment-621757715

Thanks,
Gabor

On Mon, Jul 13, 2020 at 8:22 PM Chuck Powell  wrote:
>
> Hi,
>
> My first posting.  Apologies in advance if I misspeak or am asking a dumb
> question.
>
> I maintain a small package on CRAN
> https://cran.r-project.org/web/packages/CGPfunctions/index.html
>
> Source is on Github here https://github.com/ibecav/CGPfunctions/
>
> Recently received note I needed to fix my package because of changes to
> broom.  Corrections made and everything passes locally.
>
> When I submit to rhub::check_for_cran() however it creates an error in the
> development branch
> *Build ID:* CGPfunctions_0.6.2.tar.gz-3e48a7f97fa04b64924552dc50b43fd2
>
>
> with:
>
> #> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
> versionCheck = vI[[j]]) :
>
> 1181
> #>
> Calls: ... loadNamespace -> withRestarts -> withOneRestart ->
> doWithOneRestart
>
> 1182
> #>
> Execution halted
>
> 1183
> #>
> there is no package called 'data.table'
>
> 1184
> #>
> ERROR: lazy loading failed for package 'CGPfunctions'
>
> 1185
> #>
> * removing 'C:/Users/USERDFJOuzrklm/R/CGPfunctions'
>
>
>
> Looking at data.table on CRAN I see there is no windows binary
> Windows binaries: r-devel: not available
> ,
>
>
> I don't use any data.table functions, I don't import it, or suggest it or
> enhance it it's being pulled in through some dependency in car and/or broom.
>
> Am I okay to submit to CRAN?  Is there a setting I can change?
> Obviously data.table exists despite what Rhub is reporting.
>
> Thank you hopefully that is a clear enough description.
>
> Chuck
>
> [[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 refer to COPYRIGHTS and AUTHORS extra files in DESCRIPTION

[Gábor Csárdi]

HI,

here is an example from a package that was accepted relatively recently:
https://github.com/r-lib/presser/blob/master/DESCRIPTION#L8-L11

Gabor

On Tue, Jul 7, 2020 at 6:30 PM git demont  wrote:
>
> Hi all,
>
> Sorry for asking again, but I got absolutely no advice on how to
> correctly refer to extra copyrights and authors files in package
> DESCRIPTION.
> I know this can be considered as impolite and I don't want to do so.
> So, I waited one week until sending the present message and I promise I
> will not send another to ask for the same thing after this one.
>
> Best,
> Yohann
>
>
>
>
> On Mon, Jun 29, 2020 at 4:04 PM git demont  wrote:
>
> > Hi all,
> >
> > I am developing a package called 'IFC'.
> > https://github.com/gitdemont/IFC/
> > 
> >
> > Last submission (v0.0.7) was almost the final one to get it CRAN
> > https://github.com/gitdemont/IFC/tree/v0.0.7
> > It was manually checked and it should be accepted if I removed a dontrun
> > (that I unfortunately forgot).
> >
> > For the next submission ( I hope it will be the good one ), in addition to
> > fixing the dontrun, I would like to include a small modification that was
> > not asked. I would like to avoid another round of submission/review by
> > introducing an issue that was not here. In DESCRIPTION of 'IFC', I am
> > inviting users to refer to files for copyrights and authorship. "See file
> > inst/COPYRIGHTS and file inst/AUTHORS for a list of copyright holders and
> > authors"
> >
> > However, I am not sure whether I should say 'inst/COPYRIGHTS' and
> > 'inst/AUTHORS' because these files are in the 'inst/' directory of the
> > built tar.gz, or if I should only refer to 'COPYRIGHTS' and 'AUTHORS'
> > (without inst/) because once installed these files will be at the root of
> > IFC library directory.
> > The same question olds for "Copyright: file inst/COPYRIGHTS".
> >
> > In CRAN policies, one can read:
> > "Where copyrights are held by an entity other than the package authors,
> > this should preferably be indicated via ‘cph’ roles in the ‘Authors@R’
> > field, or using a ‘Copyright’ field (if necessary referring to an
> > inst/COPYRIGHTS file)."
> > In 'RcppMsgPack' for instance we have:
> > - in the description: "See the files 'COPYRIGHTS' and 'AUTHORS' for a full
> > list of copyright holders and contributors to 'msgpack-c'."
> > - in the copyrights: "inst/COPYRIGHTS".
> >
> > Best,
> > Yohann
> >
>
> [[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 from checking for detritus in the temp directory

[Gábor Csárdi]

URLs are fine, the problem is with opening external programs like a
web browser or a PDF viewer. I think you do that here:

https://github.com/AppliedStat/R/blob/8e4173da8917caf0f4f68d4056902075fb9013c2/rQCC/man/factors.cc.Rd#L118
https://github.com/AppliedStat/R/blob/8e4173da8917caf0f4f68d4056902075fb9013c2/rQCC/man/rcc.Rd#L297

Maybe at other places as well.

If you want to open the vignette from the example, maybe you can try
something like

if (interactive()) vignette("factors.cc", package="rQCC")

so it does not run in R CMD check.

Gabor

On Sun, Jul 5, 2020 at 12:51 AM Applied Statistics Laboratory
 wrote:
>
> Thanks Gábor,
>
> I removed all the URLs in the *.Rd files and resubmitted to CRAN.
>
> I got the same NOTE again as below:
>
> After removing the URLs in the *.Rd :
> https://win-builder.r-project.org/incoming_pretest/rQCC_1.20.7_20200704_161730/Debian/00check.log
>
> Just in case, the below is the NOTE before removing the ULRs in the Rd:
> https://win-builder.r-project.org/incoming_pretest/rQCC_1.20.7_20200702_112950/Debian/00check.log
>
> I have this trouble after adding vignettes.
> So my guess is that this NOTE may be from vignette.
> I checked the package using  rhub::check_for_cran  with all the platforms. 
> They do not have this kind of issue.
> Only CRAN produces this NOTE. My vignette is written in *.Rnw (essentially 
> the same as LaTeX format).
> When the vignette file is compiled, some aux files are generated. So, I think 
> that CRAN may not delete aux files properly.
>
> Thanks,
> CP
>
>
>
> On Sat, Jul 4, 2020 at 9:48 PM Gábor Csárdi  wrote:
>>
>> Most likely this is because you start a web browser in your examples
>> or tests. Try to find where that happens, and don't run it that
>> example or test case on CRAN.
>>
>> Gabor
>>
>> On Sat, Jul 4, 2020 at 1:46 PM Applied Statistics Laboratory
>>  wrote:
>> >
>> > Dear All,
>> >
>> > I got a NOTE from CRAN:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ** checking for detritus in the temp directory ... NOTEFound the following
>> > files/directories:  ‘calibre_4.99.6_tmp_lezpx205’
>> > ‘calibre_4.99.6_tmp_mzjswhrh’  ‘calibre_4.99.6_tmp_zc8txrmi’
>> > ‘calibre_4.99.6_tmp_zw0pp8wj’* DONEStatus: 1 NOTE*
>> > Here is the log file for the CRAN check. (At the bottom, you can find the
>> > above NOTE.)
>> >
>> > https://win-builder.r-project.org/incoming_pretest/rQCC_1.20.7_20200702_112950/Debian/00check.log
>> >
>> >
>> >
>> > When I checked my package, there was no detritus in the temp dir. I tested
>> > my package using the command below:
>> >
>> >  > rhub::platforms()
>> >  > rhub::check_for_cran(platforms = "debian-clang-devel")
>> >  > rhub::check_for_cran(platforms = "debian-gcc-devel" )
>> >  > rhub::check_for_cran(platforms = "debian-gcc-devel-nold" )
>> >  > rhub::check_for_cran(platforms = "debian-gcc-patched" )
>> >  > rhub::check_for_cran(platforms = "debian-gcc-release" )
>> >
>> > As shown below, it says "OK"
>> >
>> > https://artifacts.r-hub.io/rQCC_1.20.7.tar.gz-66c588542824483db19cdc9130c715c4/
>> >
>> > Please help me if you know how to fix the detritus issue in the temp dir.
>> >
>> > Thanks,
>> > CP
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Applied Statistics Laboratory
>
> https://sites.google.com/view/appliedstatlab

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

Re: [R-pkg-devel] NOTE from checking for detritus in the temp directory

[Gábor Csárdi]

Most likely this is because you start a web browser in your examples
or tests. Try to find where that happens, and don't run it that
example or test case on CRAN.

Gabor

On Sat, Jul 4, 2020 at 1:46 PM Applied Statistics Laboratory
 wrote:
>
> Dear All,
>
> I got a NOTE from CRAN:
>
>
>
>
>
>
>
> ** checking for detritus in the temp directory ... NOTEFound the following
> files/directories:  ‘calibre_4.99.6_tmp_lezpx205’
> ‘calibre_4.99.6_tmp_mzjswhrh’  ‘calibre_4.99.6_tmp_zc8txrmi’
> ‘calibre_4.99.6_tmp_zw0pp8wj’* DONEStatus: 1 NOTE*
> Here is the log file for the CRAN check. (At the bottom, you can find the
> above NOTE.)
>
> https://win-builder.r-project.org/incoming_pretest/rQCC_1.20.7_20200702_112950/Debian/00check.log
>
>
>
> When I checked my package, there was no detritus in the temp dir. I tested
> my package using the command below:
>
>  > rhub::platforms()
>  > rhub::check_for_cran(platforms = "debian-clang-devel")
>  > rhub::check_for_cran(platforms = "debian-gcc-devel" )
>  > rhub::check_for_cran(platforms = "debian-gcc-devel-nold" )
>  > rhub::check_for_cran(platforms = "debian-gcc-patched" )
>  > rhub::check_for_cran(platforms = "debian-gcc-release" )
>
> As shown below, it says "OK"
>
> https://artifacts.r-hub.io/rQCC_1.20.7.tar.gz-66c588542824483db19cdc9130c715c4/
>
> Please help me if you know how to fix the detritus issue in the temp dir.
>
> Thanks,
> CP
>
> [[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)

[Gábor Csárdi]

Yes, this is one consequence of the newly enforced check. Now you can
choose which version of the ff package you want to be compatible with.
In the GH version a manual file was renamed and this is now a breaking
change, so you cannot be compatible with both.

Gabor

On Thu, Jul 2, 2020 at 11:47 AM Dr. Jens Oehlschlägel
 wrote:
>
> Thanks Gabor and Duncan,
>
> > It's actually in ff/man/clone.rd, not clone.ff.rd.  There is no
> > ff/man/clone.ff.rd file.
>
> but there *is* clone.ff.rd in the >= 4.0.0 versions of the packages 
> bit/bit64/ff.
>
> Hence the check warning is a false alarm resulting from checking bit 4.0.2 
> (GitHub.com/truecluster) against ff 2.2-14.2 (CRAN) instead of checking it 
> against the also submitted ff 4.0.2 (GitHub.com/truecluster).
>
> So all I can and will do is waiting that CRAN maintainers install and check 
> again.
>
> Best
>
> Jens
>
>
>
> >
> > Duncan Murdoch
> >
> > >
> > > Best regards
> > >
> > > Jens
> > >
> > >
> > >
> > >
> > > On 16.06.20 22:31, Gábor Csárdi wrote:
> > >> 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: 
> > >>> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
> > >>> 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: 
> > >>> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
> > >>> 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: 
> > >>> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
> > >>> 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

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

[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: 
>> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
>> > 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: 
>> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
>> > 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: 
>> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
>> > 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: [R-pkg-devel] check cross-references error: Non-file 
>> package-anchored link(s)
>> >
>> > I think that the current behaviour is documented in WRE:
>> >
>> > "...There are two other forms of optional argument specified as 
>> \link[pkg]{foo} and
>> > \link[pkg:bar]{foo} to link to the package pkg, to files foo.html 
>> and bar.html respectively.
>> >

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

[Gábor Csárdi]

Linking to the manual _file_ is now enforced on CRAN. Here is how to
get the file name:

> help("clone.ff", package = "ff")[[1]]
[1] "/Users/gaborcsardi/Library/R/4.0/library/ff/help/clone"

So in this case you need to link to 'clone'.

Btw. since you already use roxygen2, you could also turn on markdown
support, and then [ff::clone.ff()] automatically creates the right
links in the latest version of roxygen2.

Gabor

On Wed, Jul 1, 2020 at 6:46 PM Dr. Jens Oehlschlägel
 wrote:
>
> Good evening,
>
> My package bit 4.0.2 (https://github.com/truecluster/bit) is being
> rejected by CRAN checks with warning:
>
>
>  >Check: Rd cross-references, Result: WARNING
>  >  Non-file package-anchored link(s) in documentation object 'clone.Rd':
>  >'[ff]{clone.ff}'
>  >
>  >  See section 'Cross-references' in the 'Writing R Extensions' manual.
>
> although clone.ff is in clone.ff.rd as confirmed by
>
>  > help("clone.ff","ff")[[1]]
> [1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"
>
> I asked the maintainers to explain what is wrong and what to do and got
> no answer. Does someone here can help?
>
> Best regards
>
> Jens
>
>
>
>
> On 16.06.20 22:31, Gábor Csárdi wrote:
> > 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: 
> >> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
> >> 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: 
> >> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
> >> 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: 
> >> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
> >> 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: [R-pkg-devel] check cross-references error: Non-file 
> >> package-anchored link(s)
> >>
> >>  I think that the current behaviour is documented in WRE:
> >>
> >>  "...There are two other forms of optional argument specified as 
> >> \link[pkg]{foo} and
> >>  \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and 
> >> bar.html respectively.
> 

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

[Gábor Csárdi]

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: 
> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
> 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: 
> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
> 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: 
> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
> 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: [R-pkg-devel] check cross-references error: Non-file 
> package-anchored link(s)
>
> I think that the current behaviour is documented in WRE:
>
> "...There are two other forms of optional argument specified as 
> \link[pkg]{foo} and
> \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and 
> bar.html respectively.
> These are rarely needed, perhaps to refer to not-yet-installed packages 
> (but there the HTML
> help system will resolve the link at run time) or in the normally 
> undesirable event that more
> than one package offers help on a topic7 (in which case the present 
> package has precedence so
> this is only needed to refer to other packages). They are currently only 
> used in HTML help
> (and ignored for hyperlinks in LATEX conversions of help pages), and link 
> to the file rather
> than the topic (since there is no way to know which topics are in which 
> files in an uninstalled
> package) ...   Because they have been frequently misused, the HTML help 
> system looks for topic foo in package pkg
> if it does not find file foo.html."
>
> Unless I am missing something, it seems that it would be relatively 
> painless to reverse the logic of the current behaviour of the help system,
> i.e. to start looking first for the topic and then for a file.
>
> Georgi Boshnakov
>
> -Original Message-
> From: R-package-devel  On Behalf 
> Of Gábor Csárdi
> Sent: 16 June 2020 13:44
> To: Duncan Murdoch 
> Cc: List r-package-devel 
> Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
> package-anchored link(s)
>
> On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch  
> wrote:
> >
> > On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> > >
> > >  > I agree with almost everything you wrote, except one thing:  
> this isn't
> > >  > newly enforced, it has been enforced since the help system 
> began.  What
> > >  > I think is new is that there are now tests for it.  Previously 
> those
> > >  > links just wouldn't work.
> > >
> > >  > Duncan Murdoch
> > >
> > > Yes, to all..

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

[Gábor Csárdi]

On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch  wrote:
>
> On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> >> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> >
> >  > I agree with almost everything you wrote, except one thing:  this 
> > isn't
> >  > newly enforced, it has been enforced since the help system began.  
> > What
> >  > I think is new is that there are now tests for it.  Previously those
> >  > links just wouldn't work.
> >
> >  > Duncan Murdoch
> >
> > Yes, to all... including Duncan's agreement with Gábor.
> >
> > Also, Duncan M earlier did mention that he had wanted to
> > *change* the link-to-file behavior for these cases (when he
> > wrote most of the Rd2html source code) but somehow did not get it.
>
> Actually, I don't think I pushed for this change at the time (or at
> least I didn't push much).  I just wish now that I had, because I think
> it will be harder to do it now than it would have been then.
>
> Duncan

I am not entirely sure, but maybe just documenting the current
behaviour and undoing 78674 could work. With some tweaks? E.g.

* updating R-exts to say that \link[pkg:topic]{text} will link to
`topic.html` in `pkg` first (for historical reasons), and falls back
to searching for `topic` in `pkg` at render time.
* updating Rd2HTML to look for the topic and use it in the link,
instead of throwing a warning, in it cannot find `topic.html`
* removing the `R CMD check` warning for non-file links, that was
added in 78674 :)

Is there anything else?

Gabor

[...]

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

[Gábor Csárdi]

On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
 wrote:
[...]
>
> I think the argument was that static builds of the help pages would have
> trouble resolving the links.  With the current system, you can build a
> help page that links to a page in package foo even if package foo is not
> installed yet, and have the link work later after you install foo.

That is true, but it is also not a big problem, I think. The CRAN
Windows R installer does indeed build static help pages by default.
But the built-in web server that serves these works around broken
links by treating them as help topics instead of files. As you know.
:) So this would only be a problem if you wanted to serve the static
help pages with another web server. (Which is not a bad use case, but
then maybe Rd2HTML() can just resolve them as topics and avoid the
broken links.)

Btw. the problem of linking to the wrong page is even worse with
static builds of help pages, because if a link w/o a package (e.g.
\link{filter}) picks up the wrong package at install time, then the
wrong link is hard-coded in the html. If you are building binary
packages, then they will link to the wrong help pages.

WRE says that specifying the package in the link is rarely needed.
This was probably the case some time ago, especially when packages did
not have (compulsory) namespaces. But I am not sure if it still holds.
I would argue that it is better to specify the package you are linking
to. But the newly enforced requirement that we need to link to files
instead of topics makes this more error prone.

Gabor

[...]

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

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

[Gábor Csárdi]

On Mon, Jun 8, 2020 at 3:58 PM Uwe Ligges
 wrote:
[...]
> Nor do I how they can find out, as our idea is that CRAN cannot be
> special cased.
> If you want to run additional tests, you can execute them if some env
> var is set that you define on machines where you want to run the
> additional tests.
[...]

That is exactly how testthat::skip_on_cran() works. If you set
`NOT_CRAN="true"` then the test runs. And to make it more helpful,
Travis, GitHub Actions, etc. automatically set it.

Gabor

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

Re: [R-pkg-devel] using devtools::install_github() when curl is a dependency

[Gábor Csárdi]

Hi, you can use the remotes package (that devtools itself uses under
the hood), and set the R_REMOTES_STANDALONE="true" environment
variable. Then remotes will not use any packages to perform the
downloads and the installations. See more here:
https://github.com/r-lib/remotes#standalone-mode

Gabor

On Sat, Jun 6, 2020 at 9:24 PM Blätte, Andreas
 wrote:
>
> Dear colleagues,
>
> using devtools::install_github() is suggested frequently to install the 
> development version of a package from GitHub.
>
> But there is a nasty scenario on Windows when the package to be installed 
> from GitHub has curl as a dependency and if a new version of curl or 
> backports is available. The user will be prompted whether the outdated 
> packages shall be updated. Users will usually confirm to update all CRAN 
> packages. But after downloading the binaries, the installation will fail with 
> a message that curl cannot be removed.
>
> My understanding of the issue is as follows: devtools has curl as a 
> dependency. When calling devtools::install_github() or 
> remotes::install_github(), the curl package is attached. This implies loading 
> the curl DLL. The dll file is then non-writable, if my analysis is correct. 
> If (a) the package to be installed from GitHub has curl as a dependency and 
> if (b) the curl version present on the users’ system needs to be updated and 
> if (c) the user agrees to perform the update, the binary is downloaded 
> successfully, but installing the newer version of curl will fail, because 
> loading the curl DLL has been triggered when attaching devtools and the DLL 
> file is write-protected.
>
> This is the line that has caused my headaches:
> devtools::install_github(“PolMine/cwbtools”, ref = “dev”)
> The cwbtools package has curl as a dependency, and it was curl v4.2 that was 
> installed, the newest version is v4.3.
>
> First, I am interested whether you think my analysis is correct. Second, I 
> would appreciate your advice on good practice to deal with this scenario!
>
> My idea so far is to amend the README file, telling users (a) to reject 
> updating dependencies if  curl is to be updated or alternatively (b) to 
> recommend the snippet ` devtools::install_github(“PolMine/cwbtools”, ref = 
> “dev”, upgrade = “never”)` for GithHub-installations and a manual update of 
> dependencies.
>
> I tend to think this is not an uncommon issue for Windows users. Something 
> like this may occur whenever a package is to be installed from GitHub that 
> has common dependency with devtools that needs to be updated. The error 
> message is very hard to understand for “human” users and it is hard to find 
> the solution for “human” users. Recommendations welcome!
>
> Kind regards
> Andreas
>
> --
> Prof. Dr. Andreas Blätte
> Professor of Public Policy and Regional Politics
> University of Duisburg-Essen
>
> [[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] win-builder failing without informative message

[Gábor Csárdi]

Seems like your tests did not finish:
https://win-builder.r-project.org/SFSFeP44df58/examples_and_tests/tests_x64/testthat.Rout

Either they take too long, or they froze. You can use a different
testthat reporter, to see which one is stuck, e.g. like this:
https://github.com/cran/desc/blob/3e52b4923c7852bc00fbc94887c42657ffc67283/tests/testthat.R#L4

Gabor

On Tue, Jun 2, 2020 at 3:09 PM Daniel Sjoberg  wrote:
>
> Hello List!
>
> I am prepping gtsummary for a new release, but I am running into a problem
> with the CRAN win-builder.
>
> The package is passing checks on my local Windows machine, another local
> Windows machine, on a GitHub Actions Windows machine (
> https://github.com/ddsjoberg/gtsummary/runs/729569705?check_suite_focus=true).
> However I am getting this error on win-builder in `00check.log`:
>
> Check process probably crashed or hung up for 20 minutes ... killed
> Most likely this happened in the example checks (?),
> if not, ignore the following last lines of example output:
>
>  End of example output (where/before crash/hang up occured ?) 
>
> link to win-builder results https://win-builder.r-project.org/SFSFeP44df58/
>
> Any ideas on how to troubleshoot this error?  The build is also passing on
> macOS and Ubuntu GitHub Actions checks.
>
> Thank you!
> Daniel
>
> [[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] S4 methods

[Gábor Csárdi]

You export these S4 classes from your package:
https://github.com/cran/sizeMat/blob/c4d257a9108cde3ddb6e8eb2072cd567ae85b5c8/NAMESPACE#L13-L15

But these are not actually S4 classes, AFAICT. Remove the
`@exportClass` tags here:
https://github.com/cran/sizeMat/blob/c4d257a9108cde3ddb6e8eb2072cd567ae85b5c8/R/gonadMat-main.R#L47
https://github.com/cran/sizeMat/blob/c4d257a9108cde3ddb6e8eb2072cd567ae85b5c8/R/morphMat-main.R#L101
https://github.com/cran/sizeMat/blob/c4d257a9108cde3ddb6e8eb2072cd567ae85b5c8/R/morphMat-main.R#L305

Gabor

On Tue, Jun 2, 2020 at 10:57 AM Edgar Josymar Torrejón-Magallanes
 wrote:
>
> 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.
>
> --
> Edgar Josymar Torrejón Magallanes
>
> [[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] Package submission failed with two warnings

[Gábor Csárdi]

The reason is that CRAN does not have an R-devel binary for
data.table, and because of this install.packages() decides not to
install it. Here is a workaround:
https://github.com/r-hub/rhub/issues/367#issuecomment-621757715

Gabor

On Fri, May 15, 2020 at 10:50 PM Max Turgeon  wrote:
>
> Hi Farshad,
>
>
> The error you get when compiling your vignette gives us a hint:
>
> Error: processing vignette 'Rpvt.Rmd' failed with diagnostics:
> package or namespace load failed for 'ggpubr' in loadNamespace(j <- i[[1L]], 
> c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
>  there is no package called 'data.table'
>
> There is a long chain of dependencies here: if I write A -> B to say that 
> package A lists package B as an Import (and therefore package B is loaded 
> when package A is attached), we have
>
>
> ggpubr -> rstatix -> car -> rio -> data.table.
>
>
> I think the issue is that, since you list ggpubr in "Suggests", there's never 
> a check that all its dependencies (and their dependencies etc) are installed, 
> and therefore data.table was not installed before checking your package. (But 
> I'm not sure exactly why ggpubr is installed but not all the dependencies.)
>
>
> A solution would be to make your whole vignette fail "gracefully" when ggpubr 
> isn't attached properly. Which is good practice anyway.
>
>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
> 
> From: R-package-devel  on behalf of 
> FARSHAD TABASINEJAD 
> Sent: May 15, 2020 4:11:36 PM
> To: Duncan Murdoch; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Package submission failed with two warnings
>
> 
> Caution: This message was sent from outside the University of Manitoba.
> 
>
> Hi Duncan,
>
> I changed the version, recreated the package, and then tested it with the 
> rhub::check_for_cran(). The function failed to create a summary for all the 
> platform results together, however individual results are available in the 
> following links.
>
>
> https://builder.r-hub.io/status/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3
> https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-5e89b16f7bfb420ebe310a57eb8357b3/
> https://artifacts.r-hub.io/Rpvt_0.1.1.tar.gz-2ee682316e0f4bc7b09faf7a9e46b670/
> https://builder.r-hub.io/status/original/Rpvt_0.1.1.tar.gz-08fc2dbd591f4d80b2e0049a7c8db8b8
>
> you can also find the source code in the following link:
> https://github.com/susaenergy/Rpvt
>
> Thank you for the help!
>
> Farshad
>
>
> From: Duncan Murdoch
> Sent: Friday, May 15, 2020 9:28 AM
> To: FARSHAD TABASINEJAD; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Package submission failed with two warnings
>
> For your first warning, see the CRAN policy:  "Updates to
> previously-published packages must have an increased version. Increasing
> the version number at each submission reduces confusion so is preferred
> even when a previous submission was not accepted."
>
> For the second, it's hard to say what's happening.  Is your package
> online somewhere so we could try it on different machines?
>
> Duncan Murdoch
>
> On 15/05/2020 12:46 a.m., FARSHAD TABASINEJAD wrote:
> > Dear R-package-devel experts,
> >
> > This is the first time I’m writing to this platform about a package I 
> > recently submitted to CRAN (my first package).
> > While the package is already available on CRAN, I still must fix a few 
> > warnings and one error as reported on the CRAN package check results page:
> > https://cran.r-project.org/web/checks/check_results_Rpvt.html
> >
> > I recently resubmitted a modified version of the package to CRAN, however, 
> > it didn’t pass the automatic incoming checks.
> >
> > Windows:  
> > https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Windows/00check.log
> > Status: 1 WARNING
> >
> > Debian:  
> > https://win-builder.r-project.org/incoming_pretest/Rpvt_0.1.0_20200512_051950/Debian/00check.log
> > Status: 2 WARNINGs
> >
> >
> > 1) The first warning that appears on both Windows and Debian results is 
> > “Insufficient package version (submitted: 0.1.0, existing: 0.1.0)”.
> >
> > Since the package is conditionally available on CRAN, do I need to modify 
> > the package version to 0.1.1 to get rid of this warning?
> > Is there any way to fix this problem with the current version of the 
> > package(0.1.0)?
> >
> > 2) The second problem appears on the Debian test results:
> >
> >  * checking re-building of vignette outputs ... [8s/8s] WARNING
> >
> >  Error(s) in re-building vignettes:
> >  ...
> >  --- re-building ‘Rpvt.Rmd’ using rmarkdown
> >
> >  pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
> > [1,20] but attempted to decode with [1,17,5,4].
> >
> >  CallStack (from HasCallStack):
> 

Re: [R-pkg-devel] Help Debugging Debian Error

[Gábor Csárdi]

You don't need to move the files around, though, just use a more
verbose testthat reporter, e.g. in testthat.R use

test_check("PAutilities", reporter = "summary")

and then at least you'll know where it crashes. But to fix this,
you'll probably need to debug it locally. You can do that in Docker if
you don't have a local Linux machine.

Gabor

On Fri, May 15, 2020 at 10:00 AM Ivan Krylov  wrote:
>
> On Fri, 15 May 2020 03:50:12 -0400
> Paul Hibbing  wrote:
>
> > Complete output:
> >   > library(testthat)
> >   > library(PAutilities)
> >   >
> >   > test_check("PAutilities")
>
> It seems to me that the R process crashes while running your tests, but
> since testthat::test_check captures everything to summarise it later,
> you don't get to know where the crash occurs.
>
> Perhaps if you (temporarily) move your tests out of testthat/
> subdirectory and remove the context() and testthat::test_that("...",
> { ... }) calls, you would be able to see the exact location of the
> crash in the *.Rout files?
>
> That said, it's probably one of your dependencies that's responsible
> for the crash, not your package, since there is no compiled code.
>
> --
> Best regards,
> Ivan
>
> __
> 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] Help Debugging Debian Error

[Gábor Csárdi]

Apparently, this is not a warning, but the package itself is printing
it as a startup message:
https://github.com/cran/PAutilities/blob/ada73d8d44177c12867cc385cdca0054885ddae3/R/zzz.R#L5

Gabor

On Fri, May 15, 2020 at 2:30 AM Gábor Csárdi  wrote:
>
> It is unlikely that this is an R-hub issue because the first link is
> CRAN's machine, and the same error happens there.
>
> I can reproduce it on macOS:
>
> git clone https://github.com/paulhibbing/PAutilities
> R CMD INSTALL PAutilities
>
> R -q -e 'packageDescription("PAutilities")$Built'
> #> > packageDescription("PAutilities")$Built
> #> [1] "R 3.6.2; x86_64-apple-darwin15.6.0; 2020-05-15 01:24:03 UTC; unix"
>
> R -q -e "library(PAutilities)"
> #> > library(PAutilities)
> #> package 'PAutilities' was built under R version 3.5.0
>
> I have no clue how this can happen, I clearly just built it on R 3.6.3
>
> Gabor
>
> On Fri, May 15, 2020 at 2:08 AM Dirk Eddelbuettel  wrote:
> >
> > On 14 May 2020 at 11:41, Paul Hibbing wrote:
> > | * Here is the CRAN check (devel version 2020-05-13):
> > |
> > | 
> > https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/PAutilities-00check.html
> > |
> > | * Here is the successful R-hub check (devel version 2020-05-10):
> > |
> > | 
> > https://artifacts.r-hub.io/PAutilities_1.0.0.tar.gz-43f919fd5595416799d74bfb312fdd34/PAutilities.Rcheck/00check.log
> > |
> > | * Here is the unsuccessful R-hub check (R 3.6.3)
> > |
> > | 
> > https://artifacts.r-hub.io/PAutilities_1.0.0.tar.gz-c1592e94abe04155933d5dfe5898c1b8/PAutilities.Rcheck/00check.log
> >
> > Hm, doesn't that simply mean that this r-hub box is out of sync?
> >
> > So maybe file an issue at the rhub github repo, and test with another of the
> > (many!)  available platforms at rhub -- run rhub::platforms() to see.
> >
> > Dirk
> >
> > | On Thu, May 14, 2020 at 11:36 AM Paul Hibbing  
> > wrote:
> > | >
> > | > Hi all,
> > | >
> > | > At some point (I believe within the last week or so), my package
> > | > `PAutilities` has developed the following error for
> > | > r-devel-linux-x86_64-debian-gcc:
> > | >
> > | > * checking tests ... [3s/3s] ERROR
> > | >   Running ‘testthat.R’ [3s/3s]
> > | > Running the tests in ‘tests/testthat.R’ failed.
> > | > Complete output:
> > | >   > library(testthat)
> > | >   > library(PAutilities)
> > | >   package 'PAutilities' was built under R version 3.5.0
> > | >   >
> > | >   > test_check("PAutilities")
> > | >
> > | > I get the same error using `rhub::check_on_debian`, but not
> > | > `rhub::check(platform = "debian-gcc-devel")`.
> > | >
> > | > So far, my best guesses have been that issues were caused by either a
> > | > dependency problem (particularly the `matchingMarkets` package, which
> > | > has given me trouble in the past), or with the major increment in R
> > | > itself. But so far neither of those ideas have yielded much fruit. Any
> > | > other ideas, considerations, or things I should be aware of? I'm
> > | > working on installing a virtual machine to see about some manual
> > | > debugging, but I would love some guidance in the meantime.
> > | >
> > | > Best,
> > | > Paul Hibbing
> > |
> > | __
> > | R-package-devel@r-project.org mailing list
> > | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >
> > __
> > 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] Help Debugging Debian Error

[Gábor Csárdi]

It is unlikely that this is an R-hub issue because the first link is
CRAN's machine, and the same error happens there.

I can reproduce it on macOS:

git clone https://github.com/paulhibbing/PAutilities
R CMD INSTALL PAutilities

R -q -e 'packageDescription("PAutilities")$Built'
#> > packageDescription("PAutilities")$Built
#> [1] "R 3.6.2; x86_64-apple-darwin15.6.0; 2020-05-15 01:24:03 UTC; unix"

R -q -e "library(PAutilities)"
#> > library(PAutilities)
#> package 'PAutilities' was built under R version 3.5.0

I have no clue how this can happen, I clearly just built it on R 3.6.3

Gabor

On Fri, May 15, 2020 at 2:08 AM Dirk Eddelbuettel  wrote:
>
> On 14 May 2020 at 11:41, Paul Hibbing wrote:
> | * Here is the CRAN check (devel version 2020-05-13):
> |
> | 
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/PAutilities-00check.html
> |
> | * Here is the successful R-hub check (devel version 2020-05-10):
> |
> | 
> https://artifacts.r-hub.io/PAutilities_1.0.0.tar.gz-43f919fd5595416799d74bfb312fdd34/PAutilities.Rcheck/00check.log
> |
> | * Here is the unsuccessful R-hub check (R 3.6.3)
> |
> | 
> https://artifacts.r-hub.io/PAutilities_1.0.0.tar.gz-c1592e94abe04155933d5dfe5898c1b8/PAutilities.Rcheck/00check.log
>
> Hm, doesn't that simply mean that this r-hub box is out of sync?
>
> So maybe file an issue at the rhub github repo, and test with another of the
> (many!)  available platforms at rhub -- run rhub::platforms() to see.
>
> Dirk
>
> | On Thu, May 14, 2020 at 11:36 AM Paul Hibbing  wrote:
> | >
> | > Hi all,
> | >
> | > At some point (I believe within the last week or so), my package
> | > `PAutilities` has developed the following error for
> | > r-devel-linux-x86_64-debian-gcc:
> | >
> | > * checking tests ... [3s/3s] ERROR
> | >   Running ‘testthat.R’ [3s/3s]
> | > Running the tests in ‘tests/testthat.R’ failed.
> | > Complete output:
> | >   > library(testthat)
> | >   > library(PAutilities)
> | >   package 'PAutilities' was built under R version 3.5.0
> | >   >
> | >   > test_check("PAutilities")
> | >
> | > I get the same error using `rhub::check_on_debian`, but not
> | > `rhub::check(platform = "debian-gcc-devel")`.
> | >
> | > So far, my best guesses have been that issues were caused by either a
> | > dependency problem (particularly the `matchingMarkets` package, which
> | > has given me trouble in the past), or with the major increment in R
> | > itself. But so far neither of those ideas have yielded much fruit. Any
> | > other ideas, considerations, or things I should be aware of? I'm
> | > working on installing a virtual machine to see about some manual
> | > debugging, but I would love some guidance in the meantime.
> | >
> | > Best,
> | > Paul Hibbing
> |
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> 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] MathJax for Rd files

[Gábor Csárdi]

On Thu, May 14, 2020 at 10:27 AM Duncan Murdoch
 wrote:
>
> On 14/05/2020 3:30 a.m., Georgi Boshnakov wrote:
> > The issue is not with Rstudio per se but that in devtools' development mode 
> >  help() is modified to show the Rd files in the source directory, as one 
> > would expect, but doesn't load the RdMacros. So, the issue appears when one 
> > is development mode.
>
> Yes, the error appears to be in the pkgload::load_rd_macros() function
> here:
> https://github.com/r-lib/pkgload/blob/1b1adc39628671f2ea4256f0bebcdb76e1f89f45/R/dev-help.r#L47.
>
> It doesn't look at the DESCRIPTION file to see if there's an RdMacros entry.

Isn't that what tools::loadPkgRdMacros() does there? I believe so.

Gabor

[...]

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

Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN

[Gábor Csárdi]

Hi Jan,

this is the only example that I could find:
https://github.com/cran/regRSM/blob/master/DESCRIPTION#L13

I.e. you can have an 'Archs' field in DESCRIPTION, and apparently you
can set that to 'i386' or 'x64' or both.

 I don't know what OSes support this field, and this package hasn't
been updated for a while, so I am not 100% sure, but this definitely
seems like the proper way to declare a 64-bit only package.

Gabor


On Mon, May 11, 2020 at 1:50 PM Jan Wijffels  wrote:
>
> Duncan,
>
> Thanks for the reply. Let me make this more clear.
> The R package reticulate works on 32bit and 64bit. My golgotha package 
> depends on reticulate and an extra Python package called torch which is not 
> available for 32bit platforms. This is specified in the DESCRIPTION file at 
> https://github.com/bnosac/golgotha/blob/master/DESCRIPTION#L17
>
> For that reason R CMD check will fail on CRAN for 32bit. Hence my question. 
> How do I specify this in the package such that I can distribute it on CRAN.
>
> best,
> Jan
>
>
> Jan Wijffels
> Statistician
> www.bnosac.be  | +32 486 611708
>
> ‐‐‐ Original Message ‐‐‐
> On Monday 11 May 2020 14:39, Duncan Murdoch  wrote:
>
> > On 11/05/2020 7:54 a.m., Jan Wijffels wrote:
> >
> > > Hello everyone,
> > > I have a package which I would like to host on CRAN. The package is at 
> > > https://github.com/bnosac/golgotha
> > > The package only builds on 64bit however because the package uses R 
> > > package reticulate which requires a python library called torch which 
> > > does not build on 32 bit platforms.
> > > So installation only works using INSTALL_opts = "--no-multiarch"
> > > How do you specify this to the CRAN maintainers that this is the way it 
> > > should be set up on CRAN such that it only is built for 64bit systems.
> >
> > I don't see how your package has any 32 bit dependence, since it has no
> > src directory. It's probably sufficient to declare the dependency on
> > reticulate, which indirectly implies the 32 bit dependence. But if
> > reticulate works on 32 bit systems as long as users don't need "torch",
> > then just state that.
> >
> > One thing I'd recommend: you should try to change the dependency from
> > Depends to Imports. If there are a few reticulate functions that you
> > want your users to have access to, you can import them and re-export
> > them so they're available from your package as well.
> >
> > Duncan
>
> __
> 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] Problems importing packages with SystemRequirements

[Gábor Csárdi]

Yeah, this is a bug in whoami I think. It has a tryCatch() but it does
not suppress the error message from system().

Gabor

On Tue, Apr 28, 2020 at 2:35 PM  wrote:
>
> Dear Uwe,
> thanks for your reply.
> But wouldn't checking for the SystemRequirements be the dependencies' jobs?
> Looking at `whoami`'s code (which is basically a single very well structured
> and clearly written file of 350 lines including roxygen comments by Gabor 
> Csardi),
> I see exactly a single call to system("whoami"), which of course gets caught 
> if it throws an exception and it should be called on windows only. Under 
> solaris I would expect whoami::whoami() to call `id`.
> I don't understand why I'm getting this error with  r-patched-solaris-x86.
> Gabor, can you help?!
>
> Best, Dominik Cullmann
>
> On Tue, Apr 28, 2020 14:08:03, Uwe Ligges wrote:
> >
> >
> > On 28.04.2020 09:28, fvaf...@mailbox.org wrote:
> > > Dear Jeff,
> > > thanks for your reply,
> > > I exactly know, where gitr and whoami are called, since I constitently 
> > > use the
> > > `::` operator to import from any dependency.
> > > I am pretty sure that I use those packages for intended purposes only.
> > >
> > > Furthermore, CRAN reports issues for system calls (made by `git2r` and 
> > > `whoami`, I guess)
> > > for my package on r-patched-solaris-x86 only, so I am not sure how to 
> > > reproduce
> > > them.
> >
> > Yes, but as SystemRequirements are not alsways fullfilled, you should test
> > whether these are available before use.
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> > > Best,
> > > Dominik Cullmann
> > >
> > > On Mon, Apr 27, 2020 23:34:40, Jeff Newmiller wrote:
> > > > Maybe your use of those packages represent use cases that are not 
> > > > tested by those packages. If you pare down your code that triggers 
> > > > these problems to small reproducible examples then you can contribute 
> > > > them to those packages?
> > > >
> > > > On April 27, 2020 11:05:49 PM PDT, fvaf...@mailbox.org wrote:
> > > > > Dear All,
> > > > > I maintain a package that has issues
> > > > > `sh: whoami: not found` and `sh: git: not found`
> > > > > (see
> > > > > https://cran.r-project.org/web/checks/check_results_packager.html),
> > > > > albeit not having any (declared or undeclared) external
> > > > > dependencies -- no calls to system() or system2().
> > > > >
> > > > > It does import functions from CRAN packages `whoami` and `git2r`,
> > > > > though.
> > > > > Mysteriously to me, neither
> > > > > https://cran.r-project.org/web/checks/check_results_git2r.html
> > > > > nor
> > > > > https://cran.r-project.org/web/checks/check_results_whoami.html
> > > > > show any issues.
> > > > >
> > > > > Has anybody any clue why this is so?
> > > > >
> > > > > Thanks anyway,
> > > > > Dominik Cullmann
> > > > >
> > > > > __
> > > > > R-package-devel@r-project.org mailing list
> > > > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > > >
> > > > --
> > > > Sent from my phone. Please excuse my brevity.
> > >
> > >
>
>
> --
> https://www.globalplanetauthority.com/

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

Re: [R-pkg-devel] Non-standard things in the check directory

[Gábor Csárdi]

Just realized that nobody replied to this. So this seems to be a bug
in `R CMD check --as-cran`, it does not ignore the arch specific
examples and tests directories and files. It happens as well if you
run your check on a local windows, not just on R-hub.

Should I open a bug for this?

There is an env var for it called _R_CHECK_THINGS_IN_CHECK_DIR_, but
--as-cran overrides that, so there is not much we can do about it on
R-hub.

Right now this NOTE does not show up in new package submissions, new
package submission probably do not use `--as-cran`, but they set up
their own configuration, which might look like this:
https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Uwe/make/incoming_env.bat

Summary: you'll have to ignore this NOTE for now on R-hub and on your machines.

Gabor


On Tue, Mar 31, 2020 at 3:37 PM Goldfeld, Keith
 wrote:
>
> Good morning -
> I am running checks (using devtools::check_rhub) for my package `simstudy`, 
> and I get one note from one server, Windows Server 2008 R2 SP1, R-devel, 
> 32/64 bit:
> NOTES:
>
> * checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>   'examples_i386' 'examples_x64' 'simstudy-Ex_i386.Rout'
>   'simstudy-Ex_x64.Rout' 'tests_i386' 'tests_x64'
>
> In my previous submission, I got this note as well. I see that it is likely a 
> server issue, and not my issue, but is there any way for me to modify my 
> package to make this go away?
>
>
> - Keith
>
> [[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 R-hub Windows Server 2008 : qpdf needed

[Gábor Csárdi]

Hi,

which R version was this? Can you point to a build log?

qpdf is definitely installed on R-hub's Windows machines, and it is
even on the PATH. Maybe the new toolchain did not find it, I have
copied it to a better place now, please try again.

Best,
Gabor

On Wed, Apr 22, 2020 at 5:44 PM Paul SAVARY  wrote:
>
> Hello,
>
> I'm having trouble checking a package (graph4lg).
>
> With devtools::check_rhub(), I obtain a warning message on Windows Server 2008
>
> *checking data fro ASCII and uncompressed saves ... OK
> WARNING
> 'qpdf' is needed for checks on size reduction of PDFs
>
> I checked that qpdf is intalled. It is, because I have Rtools.
> Rtools is in my environment path
>
> That's the first time I obtain this message, although I checked my package 
> several times on Rhub.
> I do not obtain similar messages with other checking platforms.
>
> I thank you in advance
> Regards
> Paul Savary
>
>
> [[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_for_cran not responsive

[Gábor Csárdi]

Hi, please reports R-hub issues at https://github.com/r-hub/rhub/issues

It takes a bit longer to get started when there R-hub is busy. You can
always interrupt the display with CTRL+C / ESC, and then query the
results later:

❯ rhub::get_check("factorial2x2_0.2.0.tar.gz-6c92f626dae242f7b915c43bbf111e48")

── factorial2x2 0.2.0: OK

  Build ID:   factorial2x2_0.2.0.tar.gz-6c92f626dae242f7b915c43bbf111e48
  Platform:   Windows Server 2008 R2 SP1, R-devel, 32/64 bit
  Submitted:  20h 48m 11.3s ago
  Build time: 2m 33.8s

You'll always get a summary email as well.

Gabor
0 errors ✔ | 0 warnings ✔ | 0 notes ✔

On Mon, Apr 20, 2020 at 10:34 PM Eric Leifer  wrote:
>
> Hello,
> I apologize if I'm asking this question in the wrong place, but I'm trying
> to check my R package for upload to CRAN using  the check_for_cran command,
> and it's stuck after the following messages:
>
> -  Building package
> -  Uploading package
> -  Preparing build, see status at
>
> https://builder.r-hub.io/status/factorial2x2_0.2.0.tar.gz-6c92f626dae242f7b915c43bbf111e48
>
> https://builder.r-hub.io/status/factorial2x2_0.2.0.tar.gz-de397558bc2a453cbcd389ffe3a45c77
>
> https://builder.r-hub.io/status/factorial2x2_0.2.0.tar.gz-f500a010bc0e4e07b8dbd0821efaa242
>
> Does anybody know what might be going on?
> Thank you.
>
> [[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] slightly polemic question re R CMD check

[Gábor Csárdi]

You can add the ... argument to chop.default(), and then check that
length(list(...)) is zero.

Also, you might be interested in the ellipsis package.

Gabor

On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
 wrote:
>
> Hi all,
>
> My package defines the following method and generic:
>
> chop <- function (x, ...) UseMethod("chop")
>
> chop.default <- function (x, breaks, labels, extend = NULL, drop = TRUE) {
> ... }
>
> R CMD check then gives a warning:
>
> W  checking S3 generic/method consistency (695ms)
>chop:
>  function(x, ...)
>chop.default:
>  function(x, breaks, labels, extend, drop)
>
>See section ‘Generic functions and methods’ in the ‘Writing R
>Extensions’ manual.
>
> I can fix this by adding a ... argument to chop.default:
>
> chop.default <- function (x, breaks, labels, extend = NULL, drop =
> TRUE, ...)
>
> But that makes the code less robust because e.g.
>
> chop(x, Breaks = 1:3)
>
> will no longer throw an error from the misspelled argument.
>
> Or I can write:
>
> chop(x, breaks, labels, extend, drop) UseMethod("chop")
>
> but this means I cannot use a different interface for a different method.
>
> This seems like a mistake. (That's the polemic.) Or am I missing a better
> way? (That's the question.)
>
> David
>
> [[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] Building Windoze packages using rhub.

[Gábor Csárdi]

Thanks for the great walk-through!

For reference, if you want to know more about R-hub, this is the
documentation: https://docs.r-hub.io/

Best,
Gabor

On Fri, Mar 6, 2020 at 4:22 AM Rolf Turner  wrote:
>
>
> Recently I complained about the fact that it was taking forever for
> packages to come back to me from the winbuilder facility that Uwe Ligges
> so kindly provides.
>
> Ben Bolker suggested that I use "rhub" instead.  I responded that I'd
> *heard* of rhub but had no real idea what it was nor how to use it.  Roy
> Mendelssohn chimed in with "Download the 'rhub' package.  Then
> submission to 'rhub' is one easy command."
>
> Well, "Hah!" I say to that!!! :-) Easy perhaps if you are not a Bear of
> Very Little Brain, as I am.  However it seems to be do-able, even for a
> Bear of Very Little Brain, and I managed (I think!!!) to get it to work.
>
> Since I found the procedure a bit opaque, I thought I would set out step
> by step instructions, that perhaps others might find useful.
>
> (1) Install rhub. E.g. in R issue the command
>
>install.packages("rhub",lib=)
>
> (2) Load rhub:  library(rhub)
>
> (3) Validate your email address: validate_email()
>
> You get prompted for an email address, and then asked for a verification
> code.  That code gets emailed to you; copy and paste it in and you're
> good to go.
>
> (4) Then (and this is one of the things that foxed me) you invoke the
> *check()* function from the rhub package.  (For the love of Pete, I
> don't want to check the  package, I want to *build*
> it!!!  But never mind.)  The simplest thing to do is to make sure your
> working directory is that in which the source package lives.  Then issue
> the command
>
> xxx <- check("blah_1.1-1.tar.gz",platform="windows-x86_64-release")
>
> where of course "blah_1.1-1.tar.gz" is the name of the tarball holding
> your source package.
>
> Wait a while --- the function keeps you pretty well informed of what
> it's doing.
>
> Finally it completes, and you see that xxx is an object of class
> "rhub_check" "R6" that prints as:
>
> > ── blah 1.1-1: OK
> >
> >   Build ID:   blah_1.1-1.tar.gz-3b30749f06644fd4833d02da6ec895fb
> >   Platform:   Windows Server 2008 R2 SP1, R-release, 32/64 bit
> >   Submitted:  3h 56m 39.3s ago
> >   Build time: 11m 54.2s
> >
> > 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
>
> (5) Now what?  Here's where I really got foxed.  I want a Windoze
> binary.  Where the  is it?
>
> Then I noticed that I'd got an email.  It was headed "blah 1.1-1 OK" and
> contained essentially the same material as did xxx.  But it also had:
>
> > See the full build log: HTML, text, artifacts.
>
> This did not look at all promising; I did not want the  deleted> build log, nor any "artefacts", but I clicked on "artefacts"
> out of curiosity.  And *this*, mirabile dictu, took me to a page from
> which I could download blah_1.1-1.zip, and this was indeed the required
> Windoze binary.
>
> Ta-da!!!  Victory.  I hope that those who are as mentally handicapped as
> I am find the foregoing useful.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> __
> 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 hanging for some but not all packages

[Gábor Csárdi]

It is actually rather complicated, because .Rbuildignore can have
regular expressions, that refer to files or directories, and for the
latter you need to ignore the whole directory. You can look up in the
R source code how R does it, maybe you can reuse that code.

Here is a quick and dirty function that does it, mostly based on code
from the remotes package. It is very slow for me currently, mainly
because my .git directory has thousands of files. Still faster than
copying a huge directory I guess.

Speeding it up is left as an exercise. :) I think doing a manual
filtering for /.git initially would probably make it fast enough. Oh,
it is also not super tested. :)

without_ignored <- function(path = ".",
extra = c("^\\.git$", "^\\.gitignore$")) {
  paths <- dir(path, recursive = TRUE, all.files = TRUE)
  ignore_file <- file.path(path, ".Rbuildignore")
  ignore <- c(extra, tools:::get_exclude_patterns())

  if (file.exists(ignore_file)) {
ignore <- c(ignore, readLines(ignore_file, warn = FALSE))
  }

  vlapply <- function(X, FUN, ..., USE.NAMES = TRUE) {
vapply(X, FUN, logical(1L), ..., USE.NAMES = USE.NAMES)
  }

  matches_ignores <- function(x) {
any(vlapply(ignore, grepl, x, perl = TRUE, ignore.case = TRUE))
  }

  directories <- function(paths) {
dirs <- unique(dirname(paths))
out <- dirs[dirs != "."]
while(length(dirs) > 0 && any(dirs != ".")) {
  out <- unique(c(out, dirs[dirs != "."]))
  dirs <- unique(dirname(dirs))
}
sort(out)
  }

  # We need to search for the paths as well as directories in the path, so
  # `^foo$` matches `foo/bar`
  should_ignore <- function(path) {
any(vlapply(c(path, directories(path)), matches_ignores))
  }

  paths[! vlapply(paths, should_ignore)]
}

Gabor

On Tue, Feb 11, 2020 at 2:23 PM Ben Bolker  wrote:
>
>
>Something like file.copy( setdiff(list.files(recursive=TRUE)),
> scan(".Rbuildignore", what=character())),  to = destdir) ?
>
> On 2020-02-11 8:50 a.m., Rainer Krug wrote:
> > Thinking about it - what would be the easiest way, to copy the package, 
> > excluding files in .Rbuidignore, into the temp directory?
> >
> > I would like to use directly the .Rbuildignore file, to exclude the files 
> > from copying.
> >
> > Any suggestions?
> >
> >
> >> On 11 Feb 2020, at 10:20, Rainer M Krug  wrote:
> >>
> >>
> >>
> >>> On 11 Feb 2020, at 09:54, Gábor Csárdi  wrote:
> >>>
> >>> On Tue, Feb 11, 2020 at 8:52 AM Rainer M Krug  wrote:
> >>>> On 11 Feb 2020, at 09:42, Gábor Csárdi  wrote:
> >>>> On Tue, Feb 11, 2020 at 8:38 AM Rainer M Krug  wrote:
> >>>> On 10 Feb 2020, at 17:58, Gábor Csárdi  wrote:
> >>>>
> >>>> Maybe you have large, ignored files in the package directory? R first
> >>>> creates a copy of the whole directory and only applies `.Rbuildignore`
> >>>> after that.
> >>>>
> >>>> THANKS - you solved my question without me having to answer it. As I am 
> >>>> using a makefile to build the package, I can easily rename the ignored 
> >>>> directories before calling build.
> >>>>
> >>>> But the question is why are these ignored directories scanned before 
> >>>> building the package? They should be ignored anyway?
> >>>>
> >>>> Rainer
> >>>>
> >>>>
> >>>> A makefile is a good idea, but I would rather move the files that are
> >>>> needed to a temporary directory, instead of temporarily renaming
> >>>> unneeded files, because if the makefile fails, then you won't restore
> >>>> them and your project will be in a broken state.
> >>>>
> >>>>
> >>>> You are right. Having two targets (prepare build, finalise build) which 
> >>>> move the files and put them back afterwards would be the best option 
> >>>> (and make the build call both).
> >>>>
> >>>> Is there a way to have an .onExit() type function in a makefile?
> >>>
> >>> The on-exit mechanism can fail as well. It is just better not to move
> >>> around the files of the project I think.
> >>
> >> True.
> >>
> >> Thanks,
> >>
> >> Rainer
> >>
> >>>
> >>> Gabor
> >>>
> >>> [...]
> >>
> >> --
> >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation 
> >> B

Re: [R-pkg-devel] R CMD build hanging for some but not all packages

[Gábor Csárdi]

On Tue, Feb 11, 2020 at 8:52 AM Rainer M Krug  wrote:
> On 11 Feb 2020, at 09:42, Gábor Csárdi  wrote:
> On Tue, Feb 11, 2020 at 8:38 AM Rainer M Krug  wrote:
> On 10 Feb 2020, at 17:58, Gábor Csárdi  wrote:
>
> Maybe you have large, ignored files in the package directory? R first
> creates a copy of the whole directory and only applies `.Rbuildignore`
> after that.
>
> THANKS - you solved my question without me having to answer it. As I am using 
> a makefile to build the package, I can easily rename the ignored directories 
> before calling build.
>
> But the question is why are these ignored directories scanned before building 
> the package? They should be ignored anyway?
>
> Rainer
>
>
> A makefile is a good idea, but I would rather move the files that are
> needed to a temporary directory, instead of temporarily renaming
> unneeded files, because if the makefile fails, then you won't restore
> them and your project will be in a broken state.
>
>
> You are right. Having two targets (prepare build, finalise build) which move 
> the files and put them back afterwards would be the best option (and make the 
> build call both).
>
> Is there a way to have an .onExit() type function in a makefile?

The on-exit mechanism can fail as well. It is just better not to move
around the files of the project I think.

Gabor

[...]

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

Re: [R-pkg-devel] R CMD build hanging for some but not all packages

[Gábor Csárdi]

On Tue, Feb 11, 2020 at 8:38 AM Rainer M Krug  wrote:
>
>
>
> On 10 Feb 2020, at 17:58, Gábor Csárdi  wrote:
>
> Maybe you have large, ignored files in the package directory? R first
> creates a copy of the whole directory and only applies `.Rbuildignore`
> after that.
>
> THANKS - you solved my question without me having to answer it. As I am using 
> a makefile to build the package, I can easily rename the ignored directories 
> before calling build.
>
> But the question is why are these ignored directories scanned before building 
> the package? They should be ignored anyway?
>
> Rainer

A makefile is a good idea, but I would rather move the files that are
needed to a temporary directory, instead of temporarily renaming
unneeded files, because if the makefile fails, then you won't restore
them and your project will be in a broken state.

Gabor

[...]

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

Re: [R-pkg-devel] R CMD build hanging for some but not all packages

[Gábor Csárdi]

Maybe you have large, ignored files in the package directory? R first
creates a copy of the whole directory and only applies `.Rbuildignore`
after that.

Gabor

On Mon, Feb 10, 2020 at 4:54 PM Hong Ooi via R-package-devel
 wrote:
>
> Actually, cancel that: it finished successfully, but took 3 minutes to 
> prepare the package:
>
> r$> devtools::build()
> v  checking for file 'C:\Users\hongo\Documents\GitHub\AzureStor/DESCRIPTION'
> -  preparing 'AzureStor': (3m 4s)
> v  checking DESCRIPTION meta-information ...
> -  installing the package to build vignettes
> v  creating vignettes (6.5s)
> -  checking for LF line-endings in source and make files and shell scripts 
> (13.8s)
> -  checking for empty or unneeded directories
> -  building 'AzureStor_3.1.0.9000.tar.gz'
>
> This is really weird, I'm used to the package prep step taking 10 seconds at 
> most.
>
>
> -Original Message-
> From: R-package-devel  On Behalf Of 
> Hong Ooi via R-package-devel
> Sent: Tuesday, 11 February 2020 3:50 AM
> To: r-package-devel@r-project.org
> Subject: [EXTERNAL] [R-pkg-devel] R CMD build hanging for some but not all 
> packages
>
> This is with R 3.6.2 on Windows 10 Pro 1909.
>
> In the last couple of weeks, devtools::build() and devtools::check() have 
> started hanging on some, but not all, of my packages. After some poking 
> around, I discovered that it's actually R CMD build that is having problems, 
> right after the "checking for file 'DESCRIPTION'" step.
>
> A reproducible example can be found by cloning my AzureStor package: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2FAzureStordata=02%7C01%7Chongooi%40microsoft.com%7Cae76a58d39b64b491a1008d7ae4955a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169502304943506sdata=RW3TQM2D%2F3X43oGhiywDyKd%2F4oo5hFkOoVwZTUe9cOw%3Dreserved=0
>  If you run "R CMD build ." in the package directory, it should hang. This is 
> a relatively simple package that doesn't require compilation, although it 
> does import some commonly-used packages like httr, curl, jsonlite and xml2.
>
> As far as I can tell, R on Ubuntu works fine. What's going on?
>
> __
> R-package-devel@r-project.org mailing list
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=02%7C01%7Chongooi%40microsoft.com%7Cae76a58d39b64b491a1008d7ae4955a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169502304943506sdata=DPyD6zGGcxq41irkaMfMLyjnmqSB96PiIxIh9N2p%2Ft4%3Dreserved=0
>
> __
> 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] revdepcheck::revdep_check interpretation problem

[Gábor Csárdi]

On Mon, Feb 10, 2020 at 8:24 AM Spencer Graves
 wrote:
[...]
>  1.  What does the "E: 1" for "gamclass" mean?  It sounds
> like an error to me, but that contradicts the final message,
> "OK: 16, BROKEN: 0".

✓ gamclass 0.58  ── E: 1 | W: 0 | N: 0

means that gamclass triggered the same error for both the CRAN version
and the dev version of your package. Which is fine for you, hence the
tick mark.

>  2.  How can I even find gamclass?  It's not available on
> CRAN.
[...]

It was probably still on CRAN when you started the checks, but then it
was archived in the meanwhile. If you run `revdep_report()` then AFAIR
there is a link there to the package.

Gabor

[...]

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

Re: [R-pkg-devel] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures

[Gábor Csárdi]

Can you please show some numbers?

Thanks,
Gabor

On Wed, Feb 5, 2020 at 2:40 PM Brian G. Peterson  wrote:
>
> We've noticed over the past week that Winbuilder/R-Hub's 'experimental'
> Rtools4 toolchain images for Windows are approximately 4-5x slower than
> all other containers to build and check several packages we maintain.
>
> This affects everything, including example timings, where this
> architecture is the only architecture that shows any example run-times
> over 5 seconds. (including Windows under the older toolchain).
>
> Does CRAN expect us to optimize our code for the clearly non-performant
> 'experimental' Windows toolchain?
>
> I'd like to send a new version of our package PerformanceAnalytics to
> CRAN, but the Windows experimental toolchain is preventing a 100% clean
> set of checks.
>
>
> Regards,
>
> Brian
>
> --
> Brian G. Peterson
> ph: +1.773.459.4973
> im: bgpbraverock
>
> __
> 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-hub status

[Gábor Csárdi]

This is the R-hub issue tracker:
https://github.com/r-hub/rhub/issues

Gabor

On Tue, Feb 4, 2020 at 4:47 PM brian knaus  wrote:
>
> Does anyone know the current status of r-hub? My package (
> https://github.com/knausb/vcfR) is throwing warnings on R-devel (
> https://cran.r-project.org/web/checks/check_results_vcfR.html) and CRAN has
> asked me to fix it. Tried r-hub but it failed.
>
> https://builder.r-hub.io/status/vcfR_1.9.0.9000.tar.gz-ad6bc014056941a58d94765de3134c4e
>
> https://builder.r-hub.io/status/vcfR_1.9.0.9000.tar.gz-f673df2011864365ae5f7f66b4d16bf3
>
> My interpretation is that this is not due to my package. Is anyone else
> having issues with r-hub?
>
> Thanks!
> Brian
>
> [[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] Error after package update

[Gábor Csárdi]

Hi, I don't see this with dplyr 0.8.3 and tidyselect 1.0.0.

Please make sure that you restart your R session after installing
packages, otherwise the previous versions might be still loaded.
One easy way to start a new R process is to use the reprex package to
create a reproducible example.

If you still see this problem after restarting R, please open an issue
in the tidyselect issue tracker:
https://github.com/r-lib/tidyselect/issues

Gabor

On Wed, Jan 29, 2020 at 4:53 AM Tiago Olivoto  wrote:
>
> Hi everyone,
>
> After updating my R package list I just begin to get the following error
> with dplyr::select()
>
> A minimal reproducible example with iris dataset:
>
> ---
>
> library(dplyr)
>
> select(iris, Species)
>
>
>
> Erro: `...` is not empty.
>
>
>
> We detected these problematic arguments:
>
> * `logical`
>
>
>
> These dots only exist to allow future extensions and should be empty.
>
> Did you misspecify an argument?
>
> ---
>
>
>
> It seems that this error occurs when tidyselect changed from v0.2.5 (binary)
> to v1.0.0 (source)
>
> https://cran.r-project.org/web/packages/tidyselect/index.html
>
>
>
> If I put back 'tidyselect' to v0.2.5 the error doesn't occur.
>
> Any idea about why I am getting this error?
>
> Best regards,
>
>
>
> --
>
> M.Sc. Tiago Olivoto
>
> Ph.D student in Agronomy
>
> Department of Plant Science
>
> Federal University of Santa Maria
>
> 1000 Roraima Ave.
>
> Santa Maria, RS 97105-340
>
> E-mail:   tiagooliv...@gmail.com
>
>   Research Gate
>
>  
> Currículo Lattes
>
>
>
>
> [[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