Re: [R-pkg-devel] help with CRAN failures (broom.mixed, rstan-related)

[Ivan Krylov via R-package-devel]

В Wed, 25 Sep 2024 16:57:55 -0400
Ben Bolker  пишет:

> Next question, is this (in your opinion) worth escalating to 
> r-devel ?

I think so, yes. Hopefully there will be a way to temporarily re-enable
the S4 dispatch for primitive operators in methods:::.requirePackage
(that lives in R/RClassUtils.R as ..requirePackage) around the call to
require(). This has existed since r50609 (2009) and seems to be causing
problems only now!

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] help with CRAN failures (broom.mixed, rstan-related)

[Ivan Krylov via R-package-devel]

В Wed, 25 Sep 2024 12:28:25 -0400
Ben Bolker  пишет:

>What is your current estimate of the probability that this is 
> something that I've done wrong vs. exposing something wonky elsewhere 
> (i.e. at the level of testthat, brms, rstan, Rcpp, R-devel, ...) ?

I didn't have a good answer (the most recently updated package should
be the one to suspect, right?), but stopping the investigation now
would be akin to closing a murder mystery in the middle of the last
chapter. Here's what I've been able to find out:

When running library(testthat); debugonce(Rcpp::loadModule);
source('tests/testthat/test-alltibbles.R'), by the time we reach
Rcpp:::loadModule, the reference classes don't come out right. A simple
new('C++OverloadedMethods') returns an object that doesn't have a $show
or $info method. A similar problem happens for 'envRefClass', from
which 'C++OverloadedMethods' inherits: printing it will fail due to a
missing $show() method.

The problem is not in the class definition or object contents. I don't
see differences between serialised class definitions. Reloading a
serialized object from a "broken" R session into a fresh R session makes
it work normally.

The first difference I was able to notice was in how the $ operator
works for the reference semantics objects. In both cases,
.Primitive('$') -> do_subset3 eventually calls DispatchOrEval(). In a
healthy R session, the test [*] for IS_S4_OBJECT(x) &&
R_has_methods(op) succeeds. In a "broken" R session it fails because
R_has_methods(op) is FALSE.

That's because allowPrimitiveMethods had been set to FALSE.

Judging by the traceback, brms::variables(object) ->
variables.brmsfit(object) -> dimnames(x$fit) needs to resolve the S4
'dimnames' method for class 'stanfit'. At this point
methods:::.findInheritedMethods temporarily disables S4 methods for
primitives. The comment says it's done "to avoid infinite recursion,
and somewhat for speed". Unfortunately, later the 'rstan' namespace
needs to be loaded, and 'rstan' calls Rcpp functions that use reference
classes, which break without S4 dispatch for `$`.

As far as endings go, this one is rather like Murder on the Orient
Express. Even understanding what happened doesn't point towards the
"right" fix. Josiah's suggestion should have helped by loading the
namespace at a safer time.

-- 
Best regards,
Ivan

[*]
https://github.com/r-devel/r-svn/blob/776045d4601ed3ac7b8041e94c665bbfe9709191/src/main/eval.c#L4152

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

Re: [R-pkg-devel] help with CRAN failures (broom.mixed, rstan-related)

[Ivan Krylov via R-package-devel]

Hmm, so it's *not* a machine-specific problem after all [1,2] and can
now be reproduced on a regular R-devel build on Debian Sid. I'm sorry
for jumping to conclusions.

Why would Rcpp::loadModule() (called from rstan's .onLoad) end up trying
to apply a non-function, but only when being called from
broom.mixed/tests/testthat/test-alltibbles.R, and only on the first
attempt? (A repeated source() will run to completion without signalling
any errors.)

>> Error: package or namespace load failed for 'rstan' in
>> .doLoadActions(where, attach):
>> error in load action .__A__.1 for package rstan:
>> Rcpp::loadModule(module = "class_model_base", what = TRUE, env = ns,:
>> Unable to load module "class_model_base": attempt to apply
>> non-function
>> Error in .requirePackage(package) : unable to load required package
>> 'rstan'

The underlying error is in Rcpp::Module('class_model_base', mustStart =
TRUE, where = ):

>> simpleError in METHOD$info(""): attempt to apply non-function

This call originates in Rcpp:::method_wrapper:

Browse[3]> METHOD$info
NULL
Browse[3]> str(METHOD)
Prototypical reference class 'C++OverloadedMethods' [package "Rcpp"]
Browse[3]> unclass(METHOD) # print(METHOD) fails due do $info

attr(,".xData")

Browse[3]> ls(METHOD@.xData, all = TRUE)
 [1] ".->class_pointer" ".->const" ".->docstrings"".->nargs"
 [5] ".->pointer"   ".->signatures"".->size"  ".->void"
 [9] ".refClassDef" ".self""class_pointer""const"
[13] "docstrings"   "nargs""pointer""signatures"
[17] "size" "void"

Why would an object of reference class 'C++OverloadedMethods' suddenly
lose its $info method? This doesn't look like anything printed when I
trace(Rcpp:::method_wrapper, quote(print(METHOD))) and then load
'rstan' in a fresh R session.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/web/checks/check_results_broom.mixed.html

[2]
https://www.stats.ox.ac.uk/pub/bdr/donttest/broom.mixed.out

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

Re: [R-pkg-devel] help with CRAN failures (broom.mixed, rstan-related)

[Ivan Krylov via R-package-devel]

В Tue, 24 Sep 2024 10:27:34 -0400
Ben Bolker  пишет:

>Weirdly, I can't get this to fail on my local system even if I
> remove rstan -- maybe rstan needs to be present for brms at install
> time but not at runtime ... ???

I'm noticing that despite broom.mixed having Suggests: rstan and it
being seemingly unable to load, you don't get a NOTE for the missing
dependency:

>> checking package dependencies ... NOTE
>> Packages suggested but not available for checking: 'dotwhisker',
>> 'glmmADMB'

At that stage, R CMD check verifies that at least one of the libraries
contains file.path(PACKAGE_NAME, 'DESCRIPTION'). Later, something else
needs a valid rstan/Meta/package.rds. (There are also tests for links
between help pages, but they don't stop the check.) While running the
tests, methods:::.requirePackage actually tries to load the namespace
using require() -> ... -> loadNamespace(), which fails.

> Weirdly, I can't get this to fail on my local system even if I
> remove rstan -- maybe rstan needs to be present for brms at install
> time but not at runtime ... ???

Having only the following files left from a valid 'rstan' installation,
I can make R CMD check broom.mixed_0.2.9.5.tar.gz reach the same error
as you're getting:

rstan
rstan/Meta
rstan/Meta/package.rds
rstan/DESCRIPTION

Something must have happened on the Fedora machine.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Rolling Back an Archived Package

[Ivan Krylov via R-package-devel]

В Mon, 23 Sep 2024 16:15:28 +
Eric Giunta  пишет:

> Recently I submitted a large update to the package I maintain and was
> unable to resolve the testing errors prior to it being archived. I've
> been unable to reproduce the errors, so I expect to have to setup my
> own fedora_clang virtual machine to debug my package. 

> Is it against CRAN policy to resubmit an earlier version of an
> archived package, assuming I fully explain what led to the archival
> and re-submission in the submission comment?

If this is Colossus [1], as suggested by Lluís, I would recommend
making sure that you can reproduce the problem with the latest version
of the package and then verifying that the previous version of the
package doesn't exhibit that problem.

Unfortunately, starting with `podman run fedora:36` and following [2]
to compile clang-18 and R was not enough to reproduce the problem for
me: the tests in Colossus_1.1.4.1.tar.gz don't fail. I even tried with
19.1.0 by accident.

-- 
Best regards,
Ivan

[1]
https://cran-archive.r-project.org/web/checks/2024/2024-09-23_check_results_Colossus.html

[2]
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x86_64-fedora-clang

It's important to install llvm-18.1.8, not 19.1.0 from the example URL.

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

Re: [R-pkg-devel] flang-new-18 complains: incompatiple object shapes

[Ivan Krylov via R-package-devel]

В Fri, 20 Sep 2024 13:44:44 +0200
Göran Broström  пишет:

> It is of course easy (but tedious) to cut the Gordian knot by
> explicitly writing out the loops that defines 'daxpy', but is it
> necessary?

Definitely not. I think that flang will be satisfied if you provide an
explicit interface for DAXPY. Do you need help testing your code with
this compiler?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Justification and status of the 100-bytes path length limit.

[Ivan Krylov via R-package-devel]

В Fri, 13 Sep 2024 15:00:06 +0200
Iago Bonnici  пишет:

>      - Is the 100-bytes paths limitation only supposed to ensure 
> compatilbility with pre-POSIX.1-1998 `tar` files?

There are also the Windows systems. While support for paths longer than
260 characters appeared in Windows 10 build 1607 and exists in modern
versions of R [*], it's not enabled by default on many current systems:

d <- tempfile(); dir.create(d); setwd(d); d
"C:\\Users\\[SNIP]\\AppData\\Local\\Temp\\3\\RtmpodtJLb\\file3fec5fce5feb"

(path <- paste(
 sample(
  c('/', letters, LETTERS),
  256, TRUE,
  c(.05, rep((1-.05)/52, 52))
 ),
 collapse = ''
))

"nJpmTZvEleQsFrgjFzvaNRVHGzSIIgERElnFRRmVKpoZkBkfGJlUpnnPaWYhpELTCQ/djTwBiKCvuG/gEjjnRjisLG/sjfayxYXQCycnU/Uu/xcPhMUCwtFOlttgP/OfWKDZJSjmXgAvIyCVCQmIeUXjvGmntEiSqlUqzZOGQRASSMjUHUN/mdTFWuOlIxy/flbyKhKQnjFEIZrowuswFBWLmMmJNHOfRZLeLtDbOlpR/IdycTiIblkYQS/MYawp"


(dir.create(path, recursive = TRUE))

# [1] FALSE
# Warning message:
# In dir.create(path, recursive = TRUE) :
#   cannot create dir
'nJpmTZvEleQsFrgjFzvaNRVHGzSIIgERElnFRRmVKpoZkBkfGJlUpnnPaWYhpELTCQ\djTwBiKCvuG\gEjjnRjisLG\sjfayxYXQCycnU\Uu\xcPhMUCwtFOlttgP\OfWKDZJSjmXgAvIyCVCQmIeUXjvGmntEiSqlUqzZOGQRASSMjUHUN\mdTFWuOlIxy',
reason 'No such file or directory'

sessionInfo()
# R version 4.3.2 (2023-10-31 ucrt)
# Platform: x86_64-w64-mingw32/x64 (64-bit)
# Running under: Windows Server 2022 x64 (build 20348)

As a test, I have prepared a source package with an exactly 256-byte
maximal path length:

untar('foo_1.0.tar.gz', list = TRUE) |> nchar() |> max()
# [1] 256

I was not able to install it with the internal untar() ("ERROR:
extracted multiple files from ‘foo_1.0.tar.gz’" -- it seems to have
extracted both the long path from the GNU extension and the "dummy"
path stored in the 100-octet 'name' field), but it did work with the
R_INSTALL_TAR='tar' environment variable on Linux. On Windows, it
failed to extract the tarball in a manner similar to the first
experiment when the total path length exceeded 260.

-- 
Best regards,
Ivan

[*]
https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html

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

Re: [R-pkg-devel] Error in creating virtual environment on Debian machines

[Ivan Krylov via R-package-devel]

Hello Taeyong and welcome to R-package-devel!

В Thu, 5 Sep 2024 23:40:00 +0300
Taeyong Park  пишет:

>   # Define paths
>   venv_path <- file.path(Sys.getenv("HOME"), ".virtualenvs",
> "pytrends-in-r-new")
>   python_path <- file.path(venv_path, "bin", "python")

Please don't require placing the virtual environments under
~/.virtualenvs. 'reticulate' will use this path as a default if you only
provide the name of the virtual environment, but will also let the user
configure virtualenv_root() using environment variables.

>   TrendReq <<- reticulate::import("pytrends.request", delay_load =
> TRUE)$TrendReq
>   ResponseError <<- reticulate::import("pytrends.exceptions",
> delay_load = TRUE)$ResponseError

I'm afraid this defeats the purpose of 'delay_load' by immediately
accessing the module object and forcing 'reticulate' to load it.

I understand the desire to get everything working automatically right
when the package is loaded, but Python dependency management is a
complex topic and not all of it is safe to perform from .onLoad. In
particular, if .onLoad fails, you don't get to let the user call
PytrendsLongitudinalR::install_pytrends() because the namespace will
not be available. Try following the guidance in the 'reticulate'
vignettes [1]:

1. In .onLoad, only express a soft preference for a named virtual
environment and create but do not access lazy-load Python module
objects:

.onLoad <- function(libname, pkgname) {
 use_virtualenv("pytrends-in-r-new", required = FALSE)
 pytrends.request <<- reticulate::import("pytrends.request", delay_load
= TRUE)
 pd <<- reticulate::import("pandas", delay_load = TRUE)
 # and so on
}

2. Move all the installation work into a separate function:

install_pytrends <- function(envname = "pytrends-in-r-new", ...)
 # the vignette suggests wiping the "pytrends-in-r-new" venv here,
 # just in case
 py_install(
  c("pandas", "requests", "pytrends", "rich"),
  envname = envname, ...
 )

3. In tests and examples, wrap all uses of Python in checks for
py_module_available(...). In regular code, you can suggest running
install_pytrends(), but don't run it for the user. _Automatically_
installing additional software, whether Python modules or Python
itself, is prohibited by the CRAN policy [2]:

>> Packages should not write in the user’s home filespace <...> nor
>> anywhere else on the file system apart from the R session’s
>> temporary directory (or during installation in the location pointed
>> to by TMPDIR: and such usage should be cleaned up). <...>
>> Limited exceptions may be allowed in interactive sessions if the
>> package obtains confirmation from the user.

Admittedly, this complicates the tests and the examples for your
package with boilerplate. I see that 'tensorflow', for example, wraps
all its examples in \dontrun{}, but it's an exceptional package. A few
other packages that depend on 'reticulate' that I've just taken a look
at do wrap their examples in checks for the Python packages being
available.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/package=reticulate/vignettes/package.html
https://cran.r-project.org/package=reticulate/vignettes/python_dependencies.html

[2]
https://cran.r-project.org/web/packages/policies.html

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

Re: [R-pkg-devel] Build process generated non-portable files

[Ivan Krylov via R-package-devel]

В Fri, 16 Aug 2024 18:53:55 +
anj5x...@nilly.addy.io пишет:

> In the past other packages have failed to build and not only on the
> intel container see
> "https://github.com/SpeakEasy-2/speakeasyR/actions/runs/10202337528/job/28226219457";
> where several containers failed at the setup-deps step. There is
> overlap in which package fails (i.e. protGenerics and sparseArray
> fail in multiple containers but succeed in others while in one
> container ExperimentHub fails). It seems the only packages failing
> are from Bioconductor. Assume this is a bioconductor or pak issue.

Could also be an rhub issue, although unlike the igraph problem below,
I have no idea where to start diagnosing it.

> > > igraph::sample_pref(10)  
> > Error in dyn.load(file, DLLpath = DLLpath, ...) :
> >  unable to load shared object
> > '/root/R/x86_64-pc-linux-gnu-library/4.5/igraph/libs/igraph.so':
> > libopenblasp.so.0: cannot open shared object file: No such file or
> > directory  
> 
> I.e. the same error with building targets. I can raise an issue on
> rigraph as well.

This is a problem with the binary package used by rhub. If you
reinstall the source package from CRAN instead of
https://github.com/r-hub/repos and
https://github.com/cran/igraph/releases/, it will work, but take much
more time compiling the package:

options(repos = getOption('repos')['CRAN'])
install.packages('igraph')

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] R CMD check options

[Ivan Krylov via R-package-devel]

В Sat, 17 Aug 2024 09:17:40 -0400
Ben Bolker  пишет:

> does there exist/has someone compiled a list of
> the environment variables that determine R CMD check's behaviour?

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

But the _R_CHECK_CRAN_INCOMING_USE_ASPELL_ variable that Kevin would
need to set to "TRUE" in order to enable the spell checks is not
documented there.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Build process generated non-portable files

[Ivan Krylov via R-package-devel]

В Thu, 15 Aug 2024 18:58:41 +
anj5x...@nilly.addy.io пишет:

> This seems like it should work. Unfortunately my rhub github actions
> is failing to get past the setup deps step which has been occuring
> inconsistently in the past but right now it's consistently failing to
> build deps so I can't confirm it work.

This may be worth reporting to the rhub developers. The error is really
strange. It looks like the package at
https://github.com/cran/igraph/releases/download/2.0.3/igraph_2.0.3_b1_R4.5_x86_64-pc-linux-gnu-fedora-38.tar.gz
(referenced from https://github.com/r-hub/repos) has a binary
dependency on OpenBLAS:

$ readelf -d igraph/libs/igraph.so | grep openblas
0x0001 (NEEDED) Shared library: [libopenblasp.so.0]

...but that's either not noted or not installed correctly.

> I was also unable to successfully build R using intel compilers, even
> when using Rhubs container as template.

If you'd like to dig deeper, feel free to ask here with details.
 
> In case anyone else comes across this, the genmod files end up in
> `src` even if the original source files are under a subdirectory so
> the recipe ends up being:
> 
> > -rm -f *genmod.f90  

Thank you for letting us know!
 
> I installed intel compilers and checked the `ifx` man page. Could not
> find an option for turning off generation of the genmod files.

I experimented with the "ghcr.io/r-hub/containers/intel:latest"
container and was able to find out that the option -[no]gen-interfaces
controls the generation of *__genmod* files:

/opt/intel/oneapi/compiler/latest/bin/ifx -O3 -fp-model precise \
 -warn all,noexternals -c -o arpack/dgetv0.o arpack/dgetv0.f; \
 ls *genmod*
#  ...
# dgetv0__genmod.f90  dgetv0__genmod.mod
rm -vf *genmod*
# removed 'dgetv0__genmod.f90'
# removed 'dgetv0__genmod.mod'
/opt/intel/oneapi/compiler/latest/bin/ifx -nogen-interfaces -O3 \
 -fp-model precise -warn all,noexternals -c -o arpack/dgetv0.o \
 arpack/dgetv0.f; \
 ls *genmod*
#  ...
# ls: cannot access '*genmod*': No such file or directory

This option is already used as part of the "Intel" additional checks
performed by Prof. Brian D. Ripley, so the *__genmod.* files should not
be a problem on CRAN:
https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/BDR/gannet/Intel/config.site

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Build process generated non-portable files

[Ivan Krylov via R-package-devel]

В Mon, 12 Aug 2024 18:24:30 +
David via R-package-devel  пишет:

> in the intel environment (provided by rhub), the intel fortran
> compiler generates intermediary files from *.f -> *__genmod.f90. The
> R check then complains that the genmod files are not portable. I
> include removal of the files in my cleanup file so the files do not
> exist in the original package source or in the final source tarball
> but it seems the portable files check is done after compilation but
> before cleanup.
> 
> - Is there a way to get around this complaint?

Include the first 'all' target in your Makevars, make it depend on the
package shared library, and make it remove genmod files in the recipe:

all: $(SHLIB)
-rm -f arpack/*genmod.f90

A similar trick is mentioned in
.

> - Should this complaint be here in the first place?

Perhaps not. If you manage to find an option for the ifx compiler that
disables creation of these files (a brief Web search says they are for
only the user to read, but most results are from early 2010's), post it
here. This may be a good argument to make this option recommended for R.

> Shouldn't the portable files check only be performed on the shipped
> source code?

False negatives are possible too, in case the installation stage
(configure and/or make) performs a lot of preprocessing, or unpacks
extra sources. You could be right; I don't have statistics to back
either option as less wasteful of effort.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] rhub (version 2) baulking at building a vignette.

[Ivan Krylov via R-package-devel]

В Fri,  2 Aug 2024 11:10:59 +
Rolf Turner  пишет:

> The advice was to the effect that if the vignette was actually just a
> *.tex file, one could (after putting in some preparatory code, in the
> form of comments, before the documentclass command) pre-process the
> file (with pdflatex) and the build would use the *.pdf file that was
> created, without any processing being required.

I think that you are looking for the "asis" vignette engine from the
R.rsp package:
https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf

> Now I want to build a Windoze binary of the package.

If the vignette uses LaTeX packages unavailable on the computer (rhub2
virtual machine) running R CMD build or R CMD check, that would indeed
not work. Not sure about CRAN.

Since your package doesn't seem to contain any native code, wouldn't
the Windows users be satisfied with a source package? Unless running R
CMD build --no-build-vignettes, it will include the PDF file.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] LaTeX errors under MacOS on CRAN

[Ivan Krylov via R-package-devel]

В Thu, 1 Aug 2024 10:53:56 -0400
Ben Bolker  пишет:

>! Undefined control sequence.
>l.176 \hlkwd{library}\hldef
>   {(}\hlsng{"glmmTMB"}\hldef{)}

Very strange.

This may be related to https://github.com/yihui/knitr/issues/2345
(no diagnosis) and possibly https://github.com/yihui/knitr/pull/2341
(where some of the highlight commands have been renamed).

It would be interesting to see the resulting *.tex file: somehow,
\hlkwd is defined, but \hldef isn't.

Looking at the code, knitr should be generating all these definitions
in styler_assistant_latex, called from theme_to_header_latex. This one
is either called from theme_to_header (thus from knit_theme$get(name)),
or at installation time, converting inst/themes/default.css (which
should have both hlkwd and hldef set).

Since you aren't setting any knitr highlighting themes or
opts_knit$set('header'), you should be getting both \hlkwd and \hldef
defined from themes/default.css via knitr::render_latex. Is there a way
to inadvertently set the 'header' knitr option?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Ivan Krylov via R-package-devel]

On Sun, 28 Jul 2024 15:27:33 -0500
Dirk Eddelbuettel  wrote:

> If we cannot (or do not want to) modify the given main.R, I would
> suggest something along the lines of
> 
>   Rscript -e 'pdf(myfilenamevar); source("main.R"); dev.off()' | tee
> 2024-07-28.log

Perhaps even options(device = \(file = myfilenamevar, ...) pdf(file =
file, ...)) so that every plot would get the same treatment, though
that requires re-implementing the dev.new() logic to guess an available
file name. You can even misuse R_PROFILE_USER to inject the code into
the R CMD BATCH session:

# myplots.R:
local({
cmdline <- commandArgs(FALSE)
srcfile <- cmdline[[which(cmdline == '-f')[[1]] + 1]]
plotfile <- sub('(\\.R)?$', '', srcfile)
options(device = \(file, ...) {
i <- 1
if (missing(file)) repeat {
file <- sprintf('%s_%03d.pdf', plotfile, i)
if (!file.exists(file)) break
i <- i+1
}
pdf(file = file, ...)
})
})

# example.R:
plot(1:100 / 10, sin(1:100 / 10))
dev.off()
plot(1:100 / 10, cos(1:100 / 10))

R_PROFILE_USER=myplots.R R CMD BATCH example.R
# produces example.Rout, example_001.pdf, example_002.pdf

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package

[Ivan Krylov via R-package-devel]

Dear Marc Schwartz,

В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz  пишет:

> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv

This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with perl
-d, I can confirm this:

main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:135):
135:my @FileNames = "";
  DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:136):
136:open (DFHANDLE, $Encode, "$CSVPath/FileNames.txt") || die
"ERROR: cannot open $CSVPath/FileNames.txt. $!\n";
  DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:137):
137:@FileNames = ;
  DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:138):
138:close DFHANDLE;
  DB<3> x \@FileNames
0  ARRAY(0xa005e3c08)
   0  "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM\cJ"
  DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:141):
141:chomp(@FileNames);
  DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:302):
302:foreach my $FileName (@FileNames) {
  DB<4> x \@FileNames
0  ARRAY(0xa005e3c08)
   0  "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM"

Since the R code always uses a text-mode connection with WriteLines,
it always results in CR-LF line endings on Windows. The difference must
be in the default PerlIO layers applied by Strawberry Perl by default.
MSYS is based on Cygwin, which does its best to pretend to be an
Unix-like environment, so it's reasonable for an MSYS build of Perl to
default to LF line endings. But that means special-casing the MSYS
build of Perl:

  DB<5> x $Encode
0  '<:encoding(utf8)'
  DB<6> x $^O
0  'msys'

...and adding $Encode .= ":crlf" if $^O eq 'msys'; somewhere.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Fwd: CRAN Submission rkriging 1.0.1

[Ivan Krylov via R-package-devel]

Hi Chaofan and welcome to R-package-devel!

В Wed, 17 Jul 2024 11:52:53 -0700
Bill Huang <10billhuan...@gmail.com> пишет:

> The package can be installed successfully locally and passed CRAN
> auto-check. However, it cannot pass the gcc-UBSAN test with the
> following error message: a problem with the LLT function in Eigen. I
> am not sure how to fix this.

The problem is detected by special, normally disabled instrumentation
called UBSanitizer [1]. If you don't want to compile R with sanitizers
enabled yourself, ready-made Docker/Podman containers
rocker-org/r-devel-san and rocker-org/r-devel-san-clang [2] (and
others, there are sanitizer containers published by the R-hub
project as well) should help you reproduce the problem.

In this case, I suspect that you stumbled upon a problem in Eigen
itself: the Eigen::LLT constructor does not initialise an enumeration
field, ComputationInfo m_info, which results in the field being
populated by something out of range of the enumeration, which invokes
undefined behaviour.

You can reproduce the problem without building an R package at all:

#include 
#include 

struct foo : Eigen::LLT {
foo() : Eigen::LLT(42) {
// m_info is protected, hence use of inheritance
std::cout << m_info << std::endl;
}
};

int main() {
foo L;
}

g++ -fsanitize=undefined -g -Og -I $LIBRARY/RcppEigen/include/Eigen \
 -o ex ex.cpp
./ex
# ex.cpp:7:16: runtime error: load of value 32608, which is not a valid
# value for type 'ComputationInfo'
# 32608

A workaround for the problem is to move the initialization of the
Eigen::LLT Kriging::L_ field from the constructor body
into the member initializer list:

--- rkriging.orig/src/kriging.cpp   2024-07-04 06:45:57.0 +0300
+++ rkriging/src/kriging.cpp2024-07-18 14:10:54.0 +0300
@@ -20,10 +20,9 @@
 return kriging->get_nllh(log_lengthscale, nugget);
 }

-Kriging::Kriging(const Eigen::MatrixXd& X, const Eigen::VectorXd& y, Kernel& 
Ker, const bool& interpolation): n_(X.rows()), p_(X.cols()), X_(X), y_(y), 
Ker_(Ker), interpolation_(interpolation) {
+Kriging::Kriging(const Eigen::MatrixXd& X, const Eigen::VectorXd& y, Kernel& 
Ker, const bool& interpolation): n_(X.rows()), p_(X.cols()), X_(X), y_(y), 
Ker_(Ker), interpolation_(interpolation), L_(n_) {
 a_.resize(n_);
 b_.resize(n_);
-L_ = Eigen::LLT(n_);
 y_tss_ = y_.squaredNorm() - std::pow(y_.sum(),2)/n_;
 nugget_ = interpolation_ ? 1e-6 : 1e-3;
 nllh_ = std::numeric_limits::infinity();

This seems to avoid poking the bear of undefined behaviour with
potential copying of invalid enum value in L_ until something
initialises it properly.

I'm not sure whether this is worth reporting to Eigen as something to
fix. I hope that people here with more experience in C++ and Eigen will
be able to answer that question.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Using-Undefined-Behaviour-Sanitizer

[2]
https://rocker-project.org/images/base/r-devel.html

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

Re: [R-pkg-devel] Disable parallelism on installation time

[Ivan Krylov via R-package-devel]

В Tue, 16 Jul 2024 21:18:17 -0300
Alberson Miranda  пишет:

> besides examples, tests, vignettes and readme, what parts of code
> runs during installation of a R package

Neither. This is about `cargo build` compiling in parallel, not your
package code computing in parallel. Giving the -j 2 flag to cargo
should solve the problem:
https://github.com/R-ArcGIS/arcgisgeocode/blob/8fbd93c3607363a9fef2d445711de647e5127566/src/Makevars#L5

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Properly referencing copied code

[Ivan Krylov via R-package-devel]

В Fri, 12 Jul 2024 20:17:22 +
DRC via R-package-devel  пишет:

> > Has copyright holders of included software in a [ctb] role only  
> 
> I think I'm being asked to add the cph role to essentially every
> author in addition to [ctb]

That's how I'm reading it too.

> but that doesn't seem to be what the CRAN policy wants

I agree that there does seem to be a conflict, with the policy only
asking to use 'cph' for non-'aut' or 'ctb' copyright holders.

> and I still don't know how to decide who gets both.

Technically, the conflict can be resolved by noting that the CRAN
policy doesn't _prohibit_ using 'cph' for 'aut' or 'ctb' co-authors.
Since both your reviewer and help(person) ask for 'cph' for all
copyright holders, it sounds like all co-authors who wrote any code
should get an additional 'cph'.

It would help if CRAN Policy also said that 'cph' should be used for
all copyright holders.

> Right now there are several people who have explicit copyright over
> certain code so I would think just add cph to all those authors? Or
> just give everyone cph who isn't a minor contributor?

It shouldn't be too wrong to say that if someone wrote a nontrivial line
of code you're including in your package, they are a copyright holder.

This is an important cornerstone of "bazaar-style" development of free
software: if many entities own copyright to parts of a computer
program, no single entity has the right to re-license the whole under a
non-free license. Contrast this with "cathedral-style" development
where every contribution is either accompanied by a copyright transfer
document or rewritten from scratch (e.g. SQLite): this lets the single
owner re-license the code under whatever terms they prefer.

Having said that, if you would like to follow the recommendations of
Simon and Tomas and package some of the third-party code for MXE and
macOS recipes, don't hesitate to ask.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Properly referencing copied code

[Ivan Krylov via R-package-devel]

В Thu, 11 Jul 2024 20:58:53 +
DRC via R-package-devel  пишет:

> 1. How does linking to external libs differ from providing the source
> of a library and linking against that?

I think that the author information in the DESCRIPTION is about what
your package provides by itself, not everything that may end up in the
address space once the package is loaded. Since CRAN prefers
self-contained packages, we end up including them in our packages
(unless the third-party library is already very common and present in
RTools & macOS recipes & common GNU/Linux distros), which requires us
to specify their authors.

> Do I need to provide references to lapack and blas if they aren't
> shipped with the package? What about math (lm)?

No.

> 2. What roles to supply to authors of external software?

> Do I need to differentiate between authors with explicit copyrights
> `c('ctb', 'cph')` vs those who are authors but are not listed as
> copyright holders `c('ctb')` in the third party source? Or just give
> everyone both?

I would expect most authors and contributors to be copyright holders
too, but it must be possible to contribute without providing patches
and becoming one. E.g. a project might recognise a tester and bug
reporter as a full author, but there is no code that they own any
copyright on.

> 3. One of my dependencies has a lot of copyright holders throughout
> the source. Most of these are for individual functions and cmake
> files that are not directly used by my package. What is the best way
> to handle this? Add as much of the unused parts of the third party
> package to the .Rbuildignore file as possible to filter out the
> unused parts?

If it's feasible to implement, omitting unused files from the tarball
is a good idea.

> 4. Is there a better place to put all these authors? The author list
> has already gotten large and I still have many more to add.

CRAN recognises inst/AUTHORS. Here's a recently released package with
no obvious problems that makes use of it:
https://CRAN.R-project.org/package=xlcharts

We should probably document it somewhere.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Help for understanding CRAN rejection

[Ivan Krylov via R-package-devel]

(I am adding the mailing list back in Cc: because package licensing is
a complicated topic.)

В Tue, 9 Jul 2024 09:25:14 +
Matei Teleman  пишет:

> I’ve added “ … SuperCell uses
> [velocyto.R](https://github.com/velocyto-team/velocyto.R) for RNA
> velocity. ” in the Description field. Is that enough or I need also
> to directly give the command line to install the package from GitHub ?

It looks like a link should be fine. Here are a few examples of CRAN
packages that have a non-CRAN/Bioconductor package in Suggests: without
setting up Additional_repositories:

https://CRAN.R-project.org/package=babelmixr2
https://CRAN.R-project.org/package=bandsfdp
https://cran.r-project.org/package=GCD

I'm sorry that I didn't note any of the following in my initial reply,
but what worries me about CC BY-NC-ND specifically is that out of 117
CRAN packages with a Creative Commons license and 18 of those that use
the non-FOSS "NonCommercial" clause, none use the "NoDerivatives"
clause. Your users would probably appreciate being able to install
binary builds of your package from CRAN. Does `R CMD INSTALL --build`
count as creating a derivative work, or is it "merely changing the
format"? Then again, CC BY-NC-ND _is_ mentioned in the list of CRAN
licenses, so it could work.

I found a rejected copy of your package in the archive subdirectory on
the CRAN FTP server and a GitHub repository [*] that seems to be
slightly outdated compared to the archived package. (It's best to link
to up-to-date package sources when seeking help with code.) I'm getting
an additional NOTE:

>> Imports includes 21 non-default packages.
>> Importing from so many packages makes the package vulnerable to any
>> of them becoming unavailable.  Move as many as possible to Suggests
>> and use conditionally.

Is there a way to make some of the currently required dependencies into
conditional dependencies? R CMD check --as-cran sets the limit to 20,
so moving just one package from Imports to Suggests will silence this
particular NOTE.

I see that most of your package size comes from the data subdirectory.
CRAN policy says: "Packages should be of the minimum necessary size.
<...> Neither data nor documentation should exceed 5MB. <...> Where a
large amount of data is required (even after compression),
consideration should be given to a separate data-only package which can
be updated only rarely (since older versions of packages are archived
in perpetuity)."
Is there a way to reduce the size of the data? It's ideal if there's
only enough data to demonstrate how an algorithm works in the
\examples{} section of your documentation and to exercise as much of
your code as feasible in your tests.

Finally, were there any recommendations in the rejection e-mail from
CRAN? Sometimes NOTEs are unavoidable, but we should strive to minimise
them anyway.

-- 
Best regards,
Ivan

[*] https://github.com/GfellerLab/SuperCell

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

Re: [R-pkg-devel] NOTE about lack of prebuilt manual

[Ivan Krylov via R-package-devel]

В Tue, 9 Jul 2024 08:54:22 +
"Viechtbauer, Wolfgang (NP)"
 пишет:

> This appears to be related to this change
> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):
> 
> - tools::checkRd() (used by R CMD check) detects more problems with
> ⁠\Sexpr⁠-based dynamic content, including bad nesting of ⁠\Sexpr⁠s
> and invalid arguments.

The exact change was:

r85348 | hornik | 2023-10-18 08:13:46 + (Wed, 18 Oct 2023) | 1 line
Build PDF refman only when explicitly asked for.

--- src/library/tools/R/build.R (revision 85347)
+++ src/library/tools/R/build.R (revision 85348)
@@ -633,7 +633,7 @@
 }

needRefman <- manual &&
-parse_description_field(desc, "BuildManual", TRUE) &&
+parse_description_field(desc, "BuildManual", FALSE) &&
 any(btinfo[, "later"])
if (needRefman) {
messageLog(Log, "building the PDF package manual")

So now R CMD build only builds the manual when both BuildManual is set
to yes _and_ there are \Sexpr{}s with [stage=install or render].
(Previously BuildManual: yes was assumed by default.)

Was the motivation for this change to make R CMD build faster for
everyone, with the expectation that the relatively rare package
maintainers with non-[stage=build] \Sexpr{}s will set BuildManual: yes
to adapt?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Help for understanding CRAN rejection

[Ivan Krylov via R-package-devel]

В Mon, 8 Jul 2024 15:12:24 +
Matei Teleman  пишет:

> Non-FOSS package license (file LICENSE)

> The license we’re using is the standard CC BY-NC-ND 4.0 and is listed
> among the accepted licenses for CRAN

Instead of putting the license text in a file inside the package (that
would have to match byte by byte in order to be recognised
automatically, or may be subtly different from the original with
potentially drastic legal consequences), use the name of the license
listed at [1]:

License: CC BY-NC-ND 4.0

If you want to keep the full text of the license in your source code
repository, put it in a file that you exclude from the source package
using .Rbuildignore.

I'm assuming you've already seen the CC FAQ [2] that recommends against
using CC licenses for software and chose it because it offers
restrictions for commercial use and distribution of derivatives. Too
bad none of the other licenses at [1] offer the same kind of
restrictions.

>Suggests or Enhances not in mainstream repositories:
>  velocyto.R

Just making sure: have you provided the instructions for obtaining
velocyto.R in the 'Description' field of the DESCRIPTION file?

-- 
Best regards,
Ivan

[1]
https://svn.r-project.org/R/trunk/share/licenses/license.db

[2]
https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

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

Re: [R-pkg-devel] Incomprehensible warning while checking

[Ivan Krylov via R-package-devel]

В Fri, 28 Jun 2024 17:57:13 -0400
Iris Simmons  пишет:

> * checking whether the namespace can be unloaded cleanly ... WARNING
>  unloading

Here's what the check does (in a separate process):

invisible(suppressMessages(loadNamespace("this.path")));
cat('\n unloading\n');
unloadNamespace("this.path")

Since the output stops at " unloading", the package may be crashing
somewhere in SEXP do_onUnload(...). I couldn't reproduce the crash with
this.path_2.4.0.20 (commit 301f3691e93dce95adf937387b1a7bbbed5ae15d)
you currently have available in the Git repository, but I did find
this.path_2.5.0.tar.gz in the archive subdirectory on the CRAN FTP
server, which crashes R-devel but not R-4.4.1 on Windows:

* checking whether the namespace can be unloaded cleanly ...Rterm.exe caused an 
Access Violation at location 7FFCC43B2640 DEP violation at location 
7FFCC43B2640.

AddrPC   Params
7FFCC43B2640 7FFCB98E85D8 01DCA1D23E60 01DCA1D20500
7FFCBFB758B4 01DCA1D24AB0    
this.path.dll!getInFrame+0x54  
[C:/Users/user/THISPA~1.RCH/00_PKG~1/THIS~1.PAT/src/thispathdefn.c @ 120]
   118: Rf_error(_("object '%s' not found"), 
EncodeChar(PRINTNAME(sym)));
   119: if (TYPEOF(value) == PROMSXP) {
>  120: if (ptr_PRVALUE(value) == R_UnboundValue) {
   121: Rf_protect(value);
   122: value = Rf_eval(value, R_EmptyEnv);
7FFCBFB579B1 01DCA1D04110 006D595FCA78 01DC9D42BFC8  
this.path.dll!do_onUnload+0x2c1  
[C:/Users/user/THISPA~1.RCH/00_PKG~1/THIS~1.PAT/src/ns-hooks.c @ 1011]
  1009: R_ProtectWithIndex(expr = Rf_cons(libpath, R_NilValue), &indx);
  1010: R_Reprotect(expr = Rf_cons(Rf_mkString("this.path"), expr), 
indx);
> 1011: R_Reprotect(expr = 
> Rf_lcons(getFromBase(Rf_install("library.dynam.unload")), expr), indx);
  1012: R_Reprotect(expr = Rf_cons(expr, R_NilValue), indx);
  1013: R_Reprotect(expr = Rf_lcons(getFromBase(on_exitSymbol), expr), 
indx);
7FFCB7525CCF 01DCA02A6C70 01DC9D452A78 01DC9D42BF58  
R.dll!do_External+0x28f  [C:/R/R-svn/src/main/dotcode.c @ 573]

I don't understand why a call to
on.exit(library.dynam.unload("this.path", libpath)) has to be
constructed this way and not directly in R/ns-hooks.R (something to do
with R-2.15.0 compatibility? that's very impressive, by the way, as are
the rest of the package internals), but I hope that this helps you
diagnose the problem further.

One other thing I also found was a small memory leak: the memory
allocated in path_join -> unix_path_join -> src/pathjoin.c:461 is not
released. (Looks like it's the same in windows_path_join.) I'd use
R_alloc if I could.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Vignette error: "there is no package called 'markdown'"

[Ivan Krylov via R-package-devel]

В Fri, 28 Jun 2024 22:55:23 -0500
Spencer Graves  пишет:

> I'm getting, "Error: processing vignette 'sos.Rmd' failed
> with diagnostics: there is no package called 'markdown'":
> 
> 
> https://github.com/sbgraves237/sos/actions/runs/9721300082/job/26833793243
> 
> 
> This is in:
> 
> 
> https://github.com/sbgraves237/sos/blob/master/vignettes/sos.Rmd

This is an rmarkdown vignette, but you're setting
\VignetteBuilder{knitr::knitr}. Does the error go away if you set
\VignetteBuilder{knitr::rmarkdown}?

Also, it's best to put both knitr and rmarkdown in the VignetteBuilder
field of the DESCRIPTION, because both packages are required to process
the vignette successfully.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] CRAN check servers terminating on stanExports_*.o files

[Ivan Krylov via R-package-devel]

Correction: Kurt Hornik says that the installation most likely times out due to 
the hardware running the checks being more than a decade old. The problems 
should disappear once the new hardware, already received, is up and running. 
(Something prevents him from replying directly to the list.)

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

Re: [R-pkg-devel] CRAN check servers terminating on stanExports_*.o files

[Ivan Krylov via R-package-devel]

В Sat, 15 Jun 2024 15:11:36 +
"Slager, Dave"  пишет:

> The r-patched-linux-x86_64 and/or r-release-linux-x86_64 CRAN check
> servers seem to be erroring out on multiple packages, including
> these, for similar reasons:
> 
> bakR
> baldur
> bayes4psy
> BayesGmed
> ctsem
> eggCounts
> FlexReg
> networkscaleup
> ssMousetrack
> thurstonianIRT
> trialr

I've experimented with BayesGmed a bit (because it has less
dependencies than other packages in the list). Most of its object files
require the C++ compiler to allocate more than three gigabytes of
memory. Additionally, ctsem has a slightly different error:

>> g++-13: fatal error: Killed signal terminated program cc1plus
>> compilation terminated.
>> make[1]: ***
>> [/home/hornik/tmp/R.check/r-release-gcc/Work/build/etc/Makeconf:200:
>> stanExports_ctsm.o] Error 1

This is evidence of the computer running out of memory and killing the
processes that the kernel deems responsible.

How much memory should it normally take to install a package that makes
use of rstan?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Vignette with error=TRUE chunks fails CRAN checks on r-oldrel-macos

[Ivan Krylov via R-package-devel]

В Fri, 14 Jun 2024 07:58:09 +0200
Roland Fuß  пишет:

> We have many code chunks with knitr option `error=TRUE`.

A recent change required knitr to actually tangle the code for
vignettes when requested by R CMD check, with the intent to make sure
that the resulting *.R file runs without errors. Unfortunately, chunks
with error = TRUE get included in the tangled output, but it's not so
simple to fix for historical reasons, partially because a simple tangle
would not work for vignettes that expect to interact with the
vignette engine from inside their code chunks or rely on the side
effects from inline expressions.

Tim Taylor has very helpfully provided [*] the link to the knitr issue
with more context: https://github.com/yihui/knitr/issues/2338

purl=FALSE should indeed work; see
https://github.com/yihui/knitr/pull/2036 and
https://stat.ethz.ch/pipermail/r-devel/2014-May/069113.html for more
context.

-- 
Best regards,
Ivan

[*]
https://stat.ethz.ch/pipermail/r-package-devel/2024q2/010868.html

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

Re: [R-pkg-devel] Seeking help with a phantom "re-building vignettes" error in 00check.log from CRAN

[Ivan Krylov via R-package-devel]

В Fri, 7 Jun 2024 12:03:23 -0700
Jeff Lewis  пишет:

> I am running into a perplexing issue that creates an error in the
> Windows build when I submit the package to CRAN.  The error does not
> occur on: win-builder-devel,
> Debian on CRAN, my mac, or in Docker using r-base on my mac.  Here is
> the reported error and the lines above and below in the 00check.log
> from CRAN (under windows):
> 
> 
> ...
> 
> * checking package vignettes ... OK
> * checking re-building of vignette outputs ... [13s] ERROR
> Error(s) in re-building vignettes:
> --- re-building 'wnominate.Rnw' using Sweave
> 
> 
> * checking PDF version of manual ... [21s] OK

It looks the the process terminates without producing an R-level error.
(E.g. putting q('no', status = 254) in a code block gave me a similar
result.)

> I maintain this package for a friend who has retired and I thought the
> tedious part of keeping it on CRAN was going to be bringing 4k+ lines
> of legacy Fortran (sort of) into the 21th century

I think you have been right about the Fortran code. Running R CMD check
compiled with -fsanitize=address,undefined gives me memory access
errors in both the examples and the vignette:

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500385b0c0
WRITE of size 4 at 0x62500385b0c0 thread T0
#0 0x7f080a61b213 in wnom_
.../wnominate.Rcheck/00_pkg_src/wnominate/src/wnominate.f90:757

0x62500385b0c0 is located 72 bytes to the right of 8056-byte region
[0x625003859100,0x62500385b078) allocated by thread T0 here:
#0 0x7f0818eb89cf in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x56024a3746a7 in Rf_allocVector3 ../../../src/main/memory.c:2886
#2 0x56024a378c7b in Rf_allocVector
../../../src/include/Rinlinedfuns.h:597
#3 0x56024a378c7b in R_alloc ../../../src/main/memory.c:2332
#4 0x560249fcfde4 in do_dotCode ../../../src/main/dotcode.c:1817

Subroutine WNOM overflows a REAL(4) buffer POOLE(NUMMEMBERS,NUMVOTES)
allocated for it inside R's .Fortran(). A breakpoint set at line 757
reveals that I is 21 and J is 101 at this point. This is to be
expected, given the two nested DO-loops for J=1,NRCALL (=NUMVOTES, 100)
and I=1,NP (=NUMMEMBERS, 20) in the preceding lines.

I think that the original code in version 1.4 was meant to extend both
loops until the line 109 CONTINUE, not to immediately end them with
1091 CONTINUE and 1092 CONTINUE after performing (NP*NRCALL)
assignments to the variable ICH, as done in version 1.5 (just
downloaded from the CRAN FTP server, subdirectory incoming/archive).

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] debugging R CMD build

[Ivan Krylov via R-package-devel]

В Fri, 7 Jun 2024 08:40:48 -0400
Vincent Carey  пишет:

> I wanted to know if anyone has a way of stepping through in a CMD
> build task.

On Linux, R CMD build launches file.path(R.home('bin'), 'build'), which
is a short script. It should be possible to step into R CMD build by
doing the same thing in an interactive R session:

R_DEFAULT_PACKAGES= LC_COLLATE=C R --no-restore
# set hooks as needed
debug(system)
debug(system2)
# run CMD build
tools:::.build_packages(args = 'package/source/directory')

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Check errors for RMarkdown vignettes with error chunks

[Ivan Krylov via R-package-devel]

В Fri, 7 Jun 2024 09:10:03 +0200
"C.H."  пишет:

> RMarkdown vignettes are sometimes used to demonstrate errors and one
> can write vignettes with `error` chunks.
> 
> ```{r, error = TRUE}
> stop()
> ```

> But now CRAN also reports the same ERRORS for mac and linux `oldrel`
> (4.3.3).
> 
> https://cran.r-project.org/web/checks/check_results_rio.html

It sounds like R Markdown, when tangling a vignette into an *.R file,
should provide additional wrapping for chunks with the error = TRUE
option set. Would a try({ chunk content }) suffice?

R CMD check relies on the tangled script not to crash, and there is
currently no such wrapping in the generated output:
https://github.com/cran/rio/blob/master/inst/doc/remap.R

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Help with detritus on temporary directory note

[Ivan Krylov via R-package-devel]

В Thu, 30 May 2024 11:12:05 +0200
Héctor Meleiro Suárez  пишет:

> So why is this a problem? Is it that there are too many files aftes
> examples and tests are run? or would this NOTE be an issue to CRAN
> even if only one file was detected at the end?

This problem has two sides.

The side that R CMD check is giving you NOTEs about is that _examples
and tests_ are requried to keep the global state of the system intact.
This includes all files on the computer: writing anywhere except the
tempdir() is prohibited, and even that must be done with care not to
overwrite anything and cleaned up afterwards.

(See https://cran.r-project.org/web/packages/policies.html and search
for "temporary directory".)

The side that's more subjective is that outside tests and examples,
code shouldn't be touching the filesystem without the user's
permission. Many functions (e.g. write.table()) have a legitimate need
to alter the filesystem. If the user would legitimately benefit from not
having to download the files again (including between R sessions), feel
free to follow the advice of Thierry Onkelinx and use
tools::R_user_dir(...), except in tests and examples.

Testing functions that access external resources over the Internet is
fraught with additional peril. Your examples and tests must not fail if
a download attempt fails, but your users will probably prefer your
functions to stop() with an exception on download failure. One way to
solve this problem is to make sure that the functions that fetch
anything from the Internet raise errors with a specific class set and
then to wrap all examples and tests in tryCatch(...,
yourpackage_Internet_error = function(e) message('Caught an error while
accessing an Internet resource: ', conditionMessage(e))). This way any
other unchecked errors (that your tests attempt to uncover) will still
surface.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Debian and Fedora clang segmentation faults

[Ivan Krylov via R-package-devel]

В Mon, 27 May 2024 13:29:56 -0500
Stephen Meyers  пишет:

> I'm updating the 'astrochron' R package, and I'm trying to resolve a
> new segmentation fault that arises only with the Debian and Fedora
> clang compilers. An example is the function 'asm', which has been a
> component of astrochron since its debut July 2014:
> 
> https://cran.r-project.org/web/checks/check_results_astrochron.html

This one is reproducible using containers or a virtual machine. Indeed,
the code crashes at the very beginning of the asm18_R subroutine:

> asm(freq=freq,target=target,fper=fper,rayleigh=rayleigh,nyquist=nyquist,sedmin=0.5,sedmax=3,
+ numsed=100,linLog=1,iter=10,output=FALSE)

- PERFORMING AVERAGE SPECTRAL MISFIT ANALYSIS -

Program received signal SIGSEGV, Segmentation fault.
0x7ff407f36774 in asm18_r_ ()
(gdb) disas
Dump of assembler code for function asm18_r_:
   0x7ff407f36760 <+0>: push   %rbp
   0x7ff407f36761 <+1>: mov%rsp,%rbp
   0x7ff407f36764 <+4>: push   %r15
   0x7ff407f36766 <+6>: push   %r14
   0x7ff407f36768 <+8>: push   %r13
   0x7ff407f3676a <+10>:push   %r12
   0x7ff407f3676c <+12>:push   %rbx
   0x7ff407f3676d <+13>:sub$0x17e42a78,%rsp
=> 0x7ff407f36774 <+20>:mov%r9,-0x17e42838(%rbp)
   0x7ff407f3677b <+27>:mov%r8,-0x17e42830(%rbp)
   0x7ff407f36782 <+34>:mov%rcx,-0x17e42828(%rbp)
   0x7ff407f36789 <+41>:mov%rdx,-0x17e42820(%rbp)
   0x7ff407f36790 <+48>:mov%rsi,-0x17e42818(%rbp)
   0x7ff407f36797 <+55>:mov%rdi,-0x17e42810(%rbp)

flang-new-18 decided to subtract 400 megabytes from the stack pointer
right from the start, and never mind the fact that operating systems
treat the stack space like hundred-year-old brandy and the total stack
size limit is only 8 megabytes or so.

I think that the 400.8 megabytes come from the saveAsm(mxsr,mxdata)
array, which is mxsr=500 * mxdata=10 * 8 bytes per real(8) in size,
and store(mxdata), which takes additional 800 kilobytes. When compiling
with warnings enabled, GFortran even produces a message about it:

>> Warning: Array ‘saveasm’ at (1) is larger than limit set by
>> ‘-fmax-stack-var-size=’, moved from stack to static storage. This
>> makes the procedure unsafe when called recursively, or concurrently
>> from multiple threads. Consider increasing the
>> ‘-fmax-stack-var-size=’ limit (or use ‘-frecursive’, which implies
>> unlimited ‘-fmax-stack-var-size’) - or change the code to use an
>> ALLOCATABLE array. If the variable is never accessed concurrently,
>> this warning can be ignored, and the variable could also be declared
>> with the SAVE attribute. [-Wsurprising]

The Fortran standard is silent about the stack vs heap vs static
storage issue, so flang-new is technically allowed to try to fit 400
megabytes of temporary storage on the stack [*].

Since asm18_R doesn't seem to be supposed to be reentrant, the fix is
to give the SAVE attribute to the two large variables, making the
Fortran processors prefer a different memory location for them:

implicit real(8) (a-h,o-z)
save saveAsm, store

(Untested because I accidentally deleted the container while preparing
the message.)

-- 
Best regards,
Ivan

[*] https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010237.html

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

Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP

[Ivan Krylov via R-package-devel]

On Sun, 26 May 2024 17:57:17 -0500
Dirk Eddelbuettel  wrote:

> and we'd need something like this (untested)
> 
>.plugins[["openmp"]] <- function() {
>list(env =
> list(PKG_CXXFLAGS=Sys.getenv("SHLIB_OPENMP_CXXFLAGS, ""),
> PKG_LIBS=Sys.getenv("SHLIB_OPENMP_CXXFLAGS, ""))) }

>From the documentation, it sounds like a good use for

# variables will be pre-loaded from Makeconf
Rcpp.plugin.maker(Makevars = '
 PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS)
 PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS)
')

...but I can't figure out where out$Makevars is used in Rcpp.

This could also be a use for R CMD config, but SHLIB_OPENMP_CXXFLAGS is
not currently on the list of variables to query:

# Makes use of implementation details, ignores user settings
make \
 R_HOME=/usr/lib/R R_SHARE_DIR=/usr/share/R/share \
 -f /usr/lib/R/etc/Makeconf -f /usr/share/R/share/make/config.mk \
 print VAR=SHLIB_OPENMP_CXXFLAGS
# => -fopenmp

R CMD config SHLIB_OPENMP_CXXFLAGS
# => ERROR: no information for variable 'SHLIB_OPENMP_CXXFLAGS'

Looking at RcppArmadillo:::inlineCxxPlugin itself, it seems that
there's no escaping, so Make expressions can be used directly inside
the environment variables:

registerPlugin('openmp', function() list(env = list(
 PKG_LIBS = '$(SHLIB_OPENMP_CXXFLAGS)',
 PKG_CPPFLAGS = '$(SHLIB_OPENMP_CXXFLAGS)'
)))

This is mandated by POSIX ("All other environment variables, including
those with null values, shall be used as macros") and seems to work in
OpenBSD make too.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP

[Ivan Krylov via R-package-devel]

On Wed, 22 May 2024 09:18:13 -0500
Dirk Eddelbuettel  wrote:

> Testing via 'nm' as you show is possible but not exactly 'portable'.
> So any suggestions as to what to condition on here?

(My apologies if you already got an answer from Kurt. I think we're not
seeing his mails to the list.)

Perhaps take the configure test a bit further and try to dyn.load() the
resulting shared object? To be extra sure, call the function that uses
the OpenMP features? (Some weird systems may have lazy binding enabled,
making dyn.load() succeed but crashing the process on invocation of a
missing function.)

On GNU/Linux, the linker will happily leave undefined symbols in when
creating a shared library (unlike on, say, Windows, where extern void
foo(void); foo(); is a link-time error unless an object file or an
import library providing foo() is also present). When loading such a
library, the operation fails unless the missing symbols are already
present in the address space of the process (e.g. from a different
shared library).

A fresh process of R built without OpenMP support will neither link in
the OpenMP runtime while running SHLIB nor have the OpenMP runtime
loaded and so should successfully fail the test.

I also wouldn't call the entry point "main" just in case some future
compiler considers this a violation of the rules™ [*] and breaks the
code. extern "C" void configtest(int*) would be compatible with .C()
without having to talk to R's memory manager:

# The configure script:
cat > test-omp.cpp <
extern "C" void configtest(int * arg) {
  *arg = omp_get_num_threads();
}
EOF
# Without the following you're relying on the GNU/Linux-like behaviour
# w.r.t. undefined symbols (see WRE 1.2.1.1):
cat > Makevars 

Re: [R-pkg-devel] [External] Re: Assistance Needed to Resolve CRAN Submission Note

[Ivan Krylov via R-package-devel]

On Sun, 19 May 2024 09:52:08 +
Daniel Kelley  wrote:

> In answer to the question about tidy version on macOS, I have the
> latest version of that OS (Sonoma 14.5 release 23F79 -- a beta
> release, unless the official has caught up in recent days) and I get
> as follows.

> $  ~ /usr/bin/tidy --version
> HTML Tidy for Mac OS X released on 31 October 2006 - Apple Inc. build
> 9576

Thank you for providing the output! R CMD check only knows about "Apple
Inc. build 2649" (not 9576) being old, which must be why the spurious
NOTEs appeared on Zeinab's computer.

Submitted the updated patch at
.

> The second one is from the homebrew project, and that's
> what gets used by default on my machine.  I don't know which of these
> R would be using, but I could check that if required (and if provided
> a hint on how to invoke R to tell me).

I would expect Sys.which(Sys.getenv("R_TIDYCMD", "tidy")) to point to
the new version in /usr/local/bin/.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [External] Re: Assistance Needed to Resolve CRAN Submission Note

[Ivan Krylov via R-package-devel]

On Sat, 18 May 2024 21:10:18 +
"Richard M. Heiberger"  wrote:

> when checking a package and discovering these messages about html5,
> can you generate an informational message about tidy with a link to
> updating tidy?

That's a useful suggestion.

Would you mind testing the patch from
?

If you or someone else here has a computer running macOS, what exactly
does it print when running `tidy --version` (1) with an old version of
Tidy (that comes with macOS) and (2) with a new (>= 5) version of Tidy?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Altrep header, MSVC, and STRUCT_SUBTYPES macro

[Ivan Krylov via R-package-devel]

В Thu, 16 May 2024 21:32:24 +0200
David Cortes  пишет:

> Unfortunately, after some further testing, it seems this was just a
> matter of getting lucky - using the alternative non-STRUCT_SUBTYPES 
> def. of Altrep still leads to memory corruptions and crashes, just at
> different points than when using the STRUCT_SUBTYPES definition.

So much for the hope for an easy solution.
 
> May I ask: how would you go around getting R code into Godbolt?

Definitely not much of it. I was assuming that the problem was due to
passing structs by value (something that had been a problem for MSVC
compatibility more than a decade ago on x86 Windows), so I only
provided typedef struct SEXPREC *SEXP, one of the two definitions of
R_altrep_class_t and related macros, declared a number of functions
that would accept or return R_altrep_class_t by value, and tried to
call them.

I don't know a good way to use Godbolt for larger amounts of code.

> As far as I can tell, the altrep methods are calling the functions
> which they were assigned so at least the 'set' and 'dataptr' methods
> are working, but memory corruptions that crash the program happen
> after calling such altrep methods, particularly when there is a
> combination of 'R_UnwindProtect', C++ 'catch' that involves
> destructing variables before 'R_ContinueUnwind', and then 'Rf_error'.

What do the crashes look like? Is it heap corruption? Stack corruption?
Are they at least deterministic?

Can you reproduce the error by compiling one of the example ALTREP
classes [1] with MSVC, without C++ exception handling? What about using
R_ContinueUnwind() and/or C++ exceptions in some non-ALTREP code
compiled using MSVC?

Maybe if you run the code under Dr. Memory [2] or Application Verifier
[3], it'll detect the corruption slightly earlier and let you pinpoint
the problem? I'm assuming that there is no good way to link a sanitizer
into the process.

Can you eliminate C runtime incompatibility? Is there a chance that a
heap object allocated by the UCRT linked to R is freed by the CRT
linked to the MSVC-side library (or vice versa)?

-- 
Best regards,
Ivan

[1]
https://github.com/altrep-examples

[2]
https://drmemory.org/

[3]
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/application-verifier

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

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Ivan Krylov via R-package-devel]

В Thu, 16 May 2024 16:01:45 +
Zeinab Mashreghi  пишет:

> checking HTML version of manual ... NOTE
> Found the following HTML validation problems:
> All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type"
> attribute
> All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] Altrep header, MSVC, and STRUCT_SUBTYPES macro

[Ivan Krylov via R-package-devel]

В Wed, 15 May 2024 18:54:37 +0200
David Cortes  пишет:

> The code compiles without errors under MSVC, but executing code that
> involves returning Altrep objects leads to segfaults and memory
> corruptions, even though it works fine under other compilers.
> 
> I see the R Altrep header has this section:
> #define STRUCT_SUBTYPES
> #ifdef STRUCT_SUBTYPES
> # define R_SEXP(x) (x).ptr
> # define R_SUBTYPE_INIT(x) { x }
>   typedef struct { SEXP ptr; } R_altrep_class_t;
> #else
> # define R_SEXP(x) ((SEXP) (x))
> # define R_SUBTYPE_INIT(x) (void *) (x)
>   typedef struct R_altcls *R_altrep_class_t;
> #endif

Interesting ABI incompatibility you've found. Can you show a minimal
example? I've tried playing with https://godbolt.org/ and passing
around values of type R_altrep_class_t between functions, but couldn't
convince "x64 msvc v19.latest" to generate different assembly no matter
whether R_altrep_class_t was a pointer or a struct containing a SEXP.

> If I manually edit the R header to remove the definition of
> 'STRUCT_SUBTYPES', leading to the second definition of
> 'R_altrep_class_t' being used, then things work as expected when the
> package is compiled with MSVC (no segfaults and no memory
> corruptions).

While it's hard to argue with results (I don't think it'll ever be
broken on x86_64 Windows), this workaround relies on undefined
behaviour and will only work as long as the ABI as understood by GCC
passes a structure with a pointer inside exactly the same way as the
ABI as understood by MSVC passes a bare pointer.

Isolating the MSVC-specific code as suggested by Vladimir should be
safer, but it's also important to find out where exactly the
incompatibility arises from. The GCC and MSVC parts still have to use a
common ABI to talk to each other.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Ivan Krylov via R-package-devel]

Dear Zeinab,

Welcome to R-package-devel!

В Thu, 16 May 2024 03:22:56 +
Zeinab Mashreghi  пишет:

> I recently submitted my R package to CRAN, and I received this note
> from the CRAN teams: "checking CRAN incoming feasibility ... NOTE."

Without a link to the full error log and, ideally, to the source code
of the package, it's impossible to help with such a NOTE, because the
check for "CRAN incoming feasibility" encompasses many tests. I was
lucky to fish your package from the archived queue and correlate it
with the publicly available logs, but it's not always this simple:

https://win-builder.r-project.org/incoming_pretest/bootsurv_0.0.0.9000_20240515_212834/

>> New submission

This is expected and will always result in a NOTE to flag the package
to a CRAN reviewer.

>> Version contains large components (0.0.0.9000)

The convention is to use version components like 9000 for pre-release,
untested versions of packages. Could you please use a version like
0.0.1 for the version of the package to be released on CRAN?

> Unknown, possibly misspelled, fields in DESCRIPTION:
>  ‘ImportFrom’ ‘Data’

'importFrom' is a NAMESPACE file directive [1]. The DESCRIPTION must
list 'Imports:' instead [2]. What did you intend to mean with the Data:
field of your DESCRIPTION?

>> The Title field should be in title case. Current version is:
>> ‘Bootstrap Methods for complete (absence of missing values) survey
>> data’
>> In title case that is:
>> ‘Bootstrap Methods for Complete (Absence of Missing Values) Survey
>> Data’

This is yet another CRAN convention. You'll need to change the 'Title:'
field of the DESCRIPTION file.

>> * checking Rd line widths ... NOTE
>> Rd file 'boot.twostage.Rd':
>>  \examples lines wider than 100 characters:

Could you please wrap the lines of your \examples{} sections to 100
characters or less?

>> * checking examples ... [21m/21m] NOTE
>> Examples with CPU (user + system) or elapsed time > 5s
>>user system  elapsed
>> boot.weights.stsrs 1242.735  0.492 1243.285
>> boot.twostage 9.799  0.0489.847

The \examples{...} in your documentation are not only to be read by the
user. R CMD check runs them periodically on the CRAN servers. The user
should also be able to run example(boot.weights.stsrs) and see your
code directly in action. CRAN requires examples to run in 5 seconds or
less, both elapsed and CPU time. An example(...) that runs for 20
minutes is way too long. You'll need to find a way to reduce the time
spent in the example.

Wasn't something like this said in the e-mail you received from CRAN?

> When I run R CMD check on my device, I do not encounter any issues,

Even with R CMD check --as-cran?

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports

[2]
https://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file

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

Re: [R-pkg-devel] An issue regarding the authors field in DESCRIPTION

[Ivan Krylov via R-package-devel]

В Mon, 13 May 2024 08:33:04 -0500
Ruwani Herath  пишет:

> This is what I entered in DESCRIPTION field.
> 
> Authors@R: c(person(given = "Ruwani", family = "Herath", role =
> c("aut","cre"), email = "ruwanirasanja...@gmail.com"),
>person(given = "Leila", family = "Amiri",  role = "ctb"),
>  person(given = "Mahmoud", family = "Torabi", role =
> "ctb"))
> 
> Authors: Ruwani Herath [aut, cre],
>   Leila Amiri [ctb],
>   Mahmoud Torabi [ctb]
> Maintainer: Ruwani Herath 

R CMD build generates the fields "Authors" and "Maintainers" from the
field "Authors@R", so the easiest way forward is to delete Authors: and
Maintainer: from your DESCRIPTION. Next time you run R CMD build, the
DESCRIPTION file inside the resulting *.tar.gz file will contain the
correct fields "Authors" and "Maintainers".

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] clang-UBSAN

[Ivan Krylov via R-package-devel]

В Sun, 12 May 2024 14:43:18 -0400
Kaifeng Lu  пишет:

> /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'

On line 4618 of src/misc.cpp of the lrstat package, you have a
suspicious default parameter value:

>> const int n = NA_REAL

NA_REAL is a special kind of NaN, and C++ signed integers cannot
represent NaNs. You probably meant NA_INTEGER.

I think that Rcpp::traits::input_parameter takes care of
asking R to cast NA_REAL to NA_INTEGER, so this shouldn't directly
cause problems, but without a link to the code and the full error
report we have to resort to forbidden OSINT techniques [1], which don't
always work reliably and may attract the wrong kind of attention on the
darknet [2].

> Is there any way to reproduce the error before submitting the package
> to CRAN?

Yes.

If you use containers, try the rocker/r-devel-ubsan-clang [3] image
that should already contain a "sanitized" build of R produced with the
clang compiler.

If that doesn't help, start with a Fedoda 36 installation and follow
the description [4] to install clang and compile R from source with
sanitizers enabled. This procedure is described in more detail in WRE
4.3.4 [5].

If you start having problems using the Docker/podman image or compiling
R from source, don't hesitate to ask further questions.

-- 
Best regards,
Ivan

[1]
Such as searching your name on CRAN and GitHub.

[2]
Such as Google suggesting AI-powered results.

[3]
https://rocker-project.org/images/

[4]
https://www.stats.ox.ac.uk/pub/bdr/memtests/README.txt

[5]
https://cran.r-project.org/doc/manuals/R-exts.html#Using-Undefined-Behaviour-Sanitizer

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

Re: [R-pkg-devel] Fast Matrix Serialization in R?

[Ivan Krylov via R-package-devel]

On Fri, 10 May 2024 15:12:17 +1200
Simon Urbanek  wrote:

> I wonder if it may be worth doing something a bit smarter and tag
> officially a "reverse XDR" format instead - that way it would be
> well-defined and could be made the default.

Do you mean changing R so that when reading a "B\n" serialized stream,
a format code read as 0x0200 or 0x0300 would mean regular
formats 2 or 3 but byte-swapped? That would be backwards-compatible,
and we probably weren't going to have >= 65536 format versions anyway...

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement

[Ivan Krylov via R-package-devel]

В Wed, 8 May 2024 16:01:23 -0400
Josiah Parry  пишет:

>- I'll see if I can get the configure.ac to make the appropriate
> Rscript call for configure.win.
>   - I think the idea of having a single `confgure.ac` file to
> generate both configure and configure.win is nice. Guidance with
> GitHub actions and ChatGPT is essentially a must for me since my bash
> is remedial at best.

Then you might like Kevin Ushey's configure
, which is like autoconf
redone in R. The only few lines of bash are the system-specific bits in
{configure,cleanup}{.win,} to run the R scripts under tools/, and they
are already written for you.

Generating two system-specific configures from one configure.ac might
be possible - GNU m4 is very versatile - but to implement that, you
would have to program m4, which is even more niche than bash.

> The requirement to avoid GitHub feels surprisingly anachronistic
> given how central it is to the vast majority of software development.

I think that Ben Bolker's answer explains it very well. Part of the
goal of the CRAN archive is to be able to take a package, a
period-appropriate version of R and install the former on the latter.
The URL carrying the code must be able to survive as long. Unlike
Zenodo, GitHub's goal is not directly to provide storage forever, and
its current owners have a reputation [*] that could have played a part
in the requirement to avoid them.

I wonder if it would be ethical to use Archive.org for this.

In an ideal world, CRAN would be able to directly archive larger
software packages (just like PyPI is currently hosting more than a
terabyte of Tensorflow builds and a few terabytes more of other
GPU-related code [**]) without requiring the maintainers to swim
between the Scylla of vendoring the dependencies and the Charybdis of
making the build depend on an external URL, but that's a luxury someone
would have to pay for.

-- 
Best regards,
Ivan

[*]
https://stat.ethz.ch/pipermail/r-package-devel/2024q2/010708.html

[**]
https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributions-that-support-them/7125/16

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

Re: [R-pkg-devel] flang doesn't support derived types

[Ivan Krylov via R-package-devel]

В Thu, 09 May 2024 15:31:25 +
Othman El Hammouchi  пишет:

> Do I understand it correctly that there is no way to specify a
> Fortran standard in the SystemRequirements?

It's possible (and even recommended) to describe the Fortran version
requirement in SystemRequirements [1], but this field is for now mostly
informational. I think I remember efforts to standardise it, but they
are far from complete.

> I had resubmitted my package in the mean time with a configure script
> that aborts the install if the compiler does not support
> polymorphism, but I understand that this is a fruitless avenue for
> CRAN?

Signs point to yes, at least judging by a previous time we had
flang-related problems [2]. On the other hand, there were relatively
easy workarounds that time, and here I'm not seeing anything as simple.

> I should point out my local flang install is version 16, but I cannot
> install 18 on my system since it's in unstable (this again
> underscores the problem of developing under these constraints).

Would you consider containers for this purpose? I was able to reproduce
the problem relatively quickly by starting podman run --rm -it
debian:sid and installing flang-18 in there. (Unlike Docker a few years
ago, podman can be installed straight from the repository, at least on
Debian, and doesn't require adding users to special groups in order to
work. Maybe Docker has also improved.) I don't like containers as a
basis for software distribution, but I can't deny that they are being
great at letting me quickly reproduce problems without installing 10
different GNU/Linux distros.

> What would you advise? And don't you think these Fortran constraints
> should be better documenten.

I'm afraid I don't have any more specific advice besides testing your
workarounds with Debian Sid in a container or a virtual machine or a
chroot. I can try to take a look at more concrete problems. I hope you
will be able to find a relatively painless workaround.

I do wish that flang-new would be a better compiler or at least a
better documented one, but instead of a list of features on their
website, I can only see "Getting Involved [3] for tips on how to get in
touch <...> and to learn more about the current status". There is only
so many projects one can get involved in.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Using-modern-Fortran-code

[2]
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010065.html

[3]
https://flang.llvm.org/docs/GettingInvolved.html

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

Re: [R-pkg-devel] flang doesn't support derived types

[Ivan Krylov via R-package-devel]

Dear Othman El Hammouchi,

Welcome to R-package-devel!

В Wed, 08 May 2024 16:52:51 +
Othman El Hammouchi  пишет:

> However, upon submission I received an automatic reply shortly
> afterwards saying the build had failed on CRAN's servers for Debian.
> The log gives the following error:
> 
> flang/lib/Lower/CallInterface.cpp:949: not yet implemented: support
> for polymorphic types

Your use of contained procedures in class(t_mack_triangle) and
class(t_cl_res) signifies the derived types as being extensible and
thus potentially polymorphic. You'll have to replace class(...) with
type(...) and move the contained procedures out of the type definitions
(and maybe additionally make the types 'sequence' or 'bind(C)' to
signify them being non-extensible) to make the code work with flang-18.
I'm afraid this will also prevent you from defining destructors for
these types.

flang-new can be a very disappointing compiler at times [*], but it's
what people do use in the real world, especially for 64-bit ARM
processors, so in order to keep our packages portable, we have to cater
to its whims.

-- 
Best regards,
Ivan

[*] https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009987.html

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

Re: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement

[Ivan Krylov via R-package-devel]

В Wed, 8 May 2024 14:08:36 -0400
Josiah Parry  пишет:

> With ChatGPT's ability to write autoconf, I *think *I have something
> that can work.

You don't have to write autoconf if your configure.ac is mostly a plain
shell script. You can write the configure script itself. Set the PATH
and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the
regular, non-multiarch configure for Unix-like systems) or exec
"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in
configure.win, which you'll also need). You've already wrote the rest
of the code in a language you know well: R.

Autoconf would be useful if you had system-specific dependencies with
the need to perform lots of compile tests. Those would have been a pain
to set up in R. Here you mostly need sys.which() instead of
AC_CHECK_PROGS and command -v.

> The configure file runs tools/get-deps.R which will download the
> dependencies from the repo if available and verify the checksums.

One of the pain points is the need for a strong, cryptographically
secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake
build, you would be able to use cmake's built in strong hashes (such as
SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only
requires a "checksum". If you figure out a way to use a strong hash
from tools/configure.R for the downloaded tarball, please let us know.

> If the checksums don't match, an error is thrown, otherwise it can
> continue. I believe this meets the requirements of CRAN?

The other important CRAN requirement is to store the vendor tarball
somewhere as permanent as CRAN itself (see the caveats at the bottom of
https://cran.r-project.org/web/packages/using_rust.html), that is, not
GitHub. I think that Zenodo counts as a sufficiently reliable store.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] package removed from CRAN

[Ivan Krylov via R-package-devel]

В Wed, 8 May 2024 17:30:46 +0200
"Jose V. Die Ramon"  пишет:

> Could anyone please help me understand the reasons behind this, or
> suggest any steps I should take to resolve it?

Here's what I could find in
https://cran.r-project.org/src/contrib/PACKAGES.in:

>> X-CRAN-Comment: Archived on 2024-04-30 for policy violation.
>>  .
>>  On Internet access.  Also other errors.

So Avi is right, this is about the tests and/or examples failing
(possibly due to problems on the remote server).

If possible, try to emit errors with a special class set for
Internet-related errors. This will make it possible for your examples
and tests to catch them, as in:

tests/*.R:

tryCatch(
 ,
 refseqR_internet_error = function(e)
  message("Caught Internet-related error")
)

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Cannot repro failing CRAN autochecks

[Ivan Krylov via R-package-devel]

В Tue, 7 May 2024 21:40:31 +0300
Ivan Krylov via R-package-devel  пишет:

> It's too late for Makevars to exclude files from the source package
> tarball. Use .Rbuildignore instead:

Sorry, that was mostly misguided. .Rbuildignore won't help with the
contents of the Rust vendor tarball.

1. Can you omit the .cff file from src/rust/vendor.tar.xz when building
it?

2. I think that there is --exclude in both GNU tar and BSD tar. How
about tar --exclude="*.cff" -x -f rust/vendor.tar.xz ?

3. From
<https://win-builder.r-project.org/incoming_pretest/arcgisutils_0.3.0_20240507_194020/Debian/00install.out>,
it can be seen that the "clean" target does not get called. Can you
remove the *.cff file in the same Make target?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Cannot repro failing CRAN autochecks

[Ivan Krylov via R-package-devel]

В Tue, 7 May 2024 14:03:42 -0400
Josiah Parry  пишет:

> This NOTE does not appear in Ubuntu, Mac, or Windows checks
> https://github.com/R-ArcGIS/arcgisutils/actions/runs/8989812276/job/24693685840

That's a bit strange. It fires for me in a local R CMD check for a test
package even without --as-cran. The code performing the check has been
in R since ~2010.

> I've made an edit to the Makevars to specifically remove this
> directory, but it seems to continue to persist.

It's too late for Makevars to exclude files from the source package
tarball. Use .Rbuildignore instead:
https://cran.r-project.org/doc/manuals/R-exts.html#Building-binary-packages

I think that the line src/vendor/chrono/CITATION\\.cff will prevent the
file from appearing in the package tarball.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Trouble with dependencies on phyloseq and microViz

[Ivan Krylov via R-package-devel]

On Tue, 7 May 2024 10:07:59 +1200
Simon Urbanek  wrote:

> That doesn't work - additional repositories are not allowed on CRAN
> other than in very exceptional cases, because it means the package
> cannot be installed by users making it somewhat pointless.

I suppose that with(tools::CRAN_package_db(),
sum(!is.na(Additional_repositories)) / length(Additional_repositories))
= 0.7% does make it very rare. But not even for a weak dependency? Is
it for data packages only, as seems to be the focus of
[10.32614/RJ-2017-026]? The current wording of the CRAN policy makes it
sound like Additional_repositories is preferred to explaining the
non-mainstream weak dependencies in Description.

So what should be done about the non-Bioconductor weak dependency
microViz?

> As for the OP, can you post the name of the package and/or the link
> to the errors so I can have a look?

Sharon has since got rid of the WARNING and now only has NOTEs due to
microViz and a URL to its repo in the Description:
https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.2_20240504_185748/Debian/00check.log

If Additional_repositories: is the correct way to specify a
non-mainstream weak dependency for a CRAN package, the URL must be
specified as https://david-barnett.r-universe.dev/src/contrib, not just
https://david-barnett.r-universe.dev/. I am sorry for not getting it
right the first time.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Trouble with dependencies on phyloseq and microViz

[Ivan Krylov via R-package-devel]

В Sat, 4 May 2024 15:53:25 +
Sharon Bewick  пишет:

> I have a dependency on phyloseq, which is available through GitHub
> but not on the CRAN site. I have a similar problem with microViz,
> however I’ve managed to make it suggested, rather than required.
> There is no way to get around the phyloseq requirement. How do I fix
> this problem so that I can upload my package to the CRAN website?

Did a human reviewer tell you to get rid of the dependencies? There is
at least 444 packages on CRAN with strong dependencies on Bioconductor
packages, so your phyloseq dependency should work. In fact, 14 of them
depend on phyloseq.

What you need is an Additional_repositories field in your DESCRIPTION
specifying the source package repository where microViz could be
installed from. I think that

Additional_repositories: https://david-barnett.r-universe.dev

...should work.

Besides that, you'll need to increment the version and list the *.Rproj
file in .Rbuildignore:
https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.1_20240504_173331/Debian/00check.log

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Ivan Krylov via R-package-devel]

On Sat, 4 May 2024 08:09:28 +0200
Maciej Nasinski  wrote:

> What do you think about promoting containers?

Containers have an attack surface too, have user experience problems
(how's Docker on Windows?) and may bring in more third-party code than
what you're trying to protect against (whole operating system images!).
Even Firejail and Bubblewrap, containers specifically designed to
sandbox untrusted code, have bugs in their setup or implementation
every now and then.

Still, you are welcome to run third-party code in a virtual machine or
a container. It may be not everyone's favourite trade-off, but is a net
increase in security over running untrusted code directly. Feel free to
search for a point on the Pareto optimal line between security and
convenience that you'll be comfortable with: https://xkcd.com/2044/

> Nowadays, containers are more accessible, with GitHub codespaces
> being more affordable (mostly free for students and the educational
> sector).

The GitHub-isation of the development process is kind of a
vulnerability too, or at the very least has a cost. I'm a few
handshakes away from several people who have been disappeared from
GitHub and couldn't get their accounts back. Microsoft is too big to
have real tech support [*], so once you fall foul of their AI
moderation systems, you'll have to be a Hacker News celebrity to
attract attention of a human on the inside.

I've got an ageing ThinkPad that I cannot afford to replace. It can
process all the data I've been gathering during my PhD and then some,
least squares, inverse problems, you name it, all while playing music
and having Quake I open. But the moment I try to launch Codespaces, it
downloads more bytes of JavaScript than the whole Quake I installation
takes in size, and then the browser overheats the laptop.

Maybe programming other people's computers in the browser is the
future, but then you need a fancy laptop and maybe a friend in
Microsoft just to be admitted into that future. A solution for some,
but not for all.

-- 
Best regards,
Ivan

[*] https://danluu.com/diseconomies-scale/

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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Ivan Krylov via R-package-devel]

On Fri, 3 May 2024 18:17:52 +0200
Maciej Nasinski  wrote:

> I found the https://github.com/hrbrmstr/rdaradar solution and ran it
> on the 100 most downloaded R packages.
> Happily, all data/inst rda files are safe/non-exposed to RDS exploit
> (using the linked solution).

This is a bit useful - knowing that there are no obvious exploits in
the 100 most downloaded CRAN packages is better that not knowing that - 
but it is important to keep the big picture in mind. Bob himself said
that the script is "super basic". Currently, it only checks whether an
*.rda file, when loaded in the global environment, would shadow certain
important functions. This is not an attack a package author would
perform; this is something one would send directly to the victim.

In order to defeat an attacker, you must think like an attacker.

Here's someone jokingly describing how they would trojan the world's
online shop checkout systems if they wanted to commit financial crimes:
https://archive.ph/FCdBu
(With kindness and pull requests.)

Here's someone spending two years to plant a fake maintainer with a
backdoor in a key free software project:
https://lwn.net/Articles/967192/
(The backdoor was assembled from obfuscated "test files for the
decompressor".)

Here's the 2015 Underhanded C Contest, where people competed in writing
the most harmless-looking code that would instead do something
nefarious: http://www.underhanded-c.org/

On the one hand, hiding the bad functions in a data file (which is
compressed and binary) instead of the R files (which are plain text and
indexed everywhere) would be the obvious first step, so it may be
useful to flag data files with functions in them for human review.

On the other hand, an evil package author has so many tools at their
disposal that they may not need this one in particular. There are CRAN
packages with tens of megabytes of compiled code inside. Sneaking a
little extra something in a file starting with "// This is generated
grammar parser. Do not edit!" followed by an impenetrable wall of C
could be easier and stay undetected for longer. How many packages use
Java? You don't even have to ship the Java source together with an R
package, so one of your *.jars could have a poisoned dependency with
nobody being the wiser.

Attackers are very cunning, and we don't even know what exactly we are
looking for. We can automate some of it, but the kind of code review
that will spot an evil function tucked 50 layers inside a giant
auxiliary data object is a lot of effort, hours to days per package.

> It will be great to run it on all CRAN packages, but I imagine we
> should be sure that the check is decent enough to not overload the
> servers without a need.

This probably counts as creating an unofficial CRAN mirror:
https://cran.r-project.org/mirror-howto.html

(I remember someone sending too many requests to download packages one
my one and losing access from a university address to CRAN as a result.)

You'll need 12.7 Gb for the current versions of the packages or >400 Gb
for the whole archive.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Ivan Krylov via R-package-devel]

Dear Maciej Nasinski,

On Fri, 3 May 2024 11:37:57 +0200
Maciej Nasinski  wrote:

> I believe we must conduct a comprehensive review of all existing CRAN
> packages.

Why now? R packages are already code. You don't need poisoned RDS files
to wreak havoc using an R package.

On the other hand, R data files contain R objects, which contain code.
You don't need exploits to smuggle code inside an R object.

> Additionally, I will expect an introduction of an additional
> step in the R CMD check process.

What exactly would you like this step to be?

> It is stated that R Team is aware of
> that, and the exploit is fixed in R 4.4.0, but I can not find any
> clear bullet point in the NEWS file for 4.4.0
> (https://cran.r-project.org/doc/manuals/r-release/NEWS.html).

This has recently been discussed in the R-help thread:
https://stat.ethz.ch/pipermail/r-help/2024-May/479287.html

> I look forward to your thoughts and collaborating closely on this
> urgent review.

It may be worth teaching people that in general, R data files should be
as trusted as R code.

It may also be worth setting aside a strict subset of the R data format
to carry data only, without any executable code [*], but it may turn
out to be much less useful than it sounds. For example, you won't be
able to save many kinds of model objects using this plain data format,
which makes it unrealistic to require plain data only inside data files
in CRAN packages.

An independent review of the whole >2 packages on CRAN for
malicious behaviour is a noble endeavour, but it will require people
and funding. Perhaps you could try to apply for an R Consortium
infrastructure grant to do that.

-- 
Best regards,
Ivan

[*] https://aitap.github.io/2024/05/02/unserialize.html#subset

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

Re: [R-pkg-devel] Extending proj with proj.line3d methods and overloading the methods

[Ivan Krylov via R-package-devel]

В Sun, 28 Apr 2024 15:15:06 +
Leo Mada  пишет:

> This is why I intended to define a new method "proj.line3d" and
> overload this method. But it seems that R interprets "line3d.numeric"
> as a class - which originates probably from the "data,frame" class.

It may help to call the original 'proj' function and your new
'proj.line3d' function "generics", because that's what most S3
literature calls these functions that you overload. This separates them
from the "methods" 'proj.line3d.numeric' and 'proj.line3d.matrix' that
can be said to "implement" or "overload" the generic.

A concise but very readable guide to S3 and other built-in OOP systems
in R can be found in Advanced R by Hadley Wickham:
http://adv-r.had.co.nz/OO-essentials.html#s3

> How can I define a real method "proj.line3d"?

In order to export an S3 generic and register methods for it from a
package, you need the following directives in your NAMESPACE:

export(proj.line3d)
S3method(proj.line3d, numeric) # will use function proj.line3d.numeric
S3method(proj.line3d, matrix) # similar



> There might be some limitations from Roxygen as well (as I use it for
> the package); but it might be easier to proceed, once I understand
> how to do it in R.

The roxygen2 documentation says that if there are multiple dots in the
name of a function, you need to use the two-argument form of the
@method keyword: @method proj.line3d numeric (untested).


> I thought that this solves the problem:
> proj.line3d <- function(p, x, y, z, ...)
>   UseMethod("proj.line3d")

Right. This is the definition of an S3 generic generic in R. As long as
all the methods will also accept arguments (p, x, y, z, , ), all will be fine.

> The other solution, as you pointed out, is more cumbersome; and it
> needs 2 separate classes, so I would need to define "proj" as an S4
> class (as S3 does not handle 2 classes at once).

Moreover, you still need an exported generic proj.line3d and registered
methods for it to work. Inheritance does work in S3 (see NextMethod()),
but it alone won't help you call proj.line3d.numeric() from proj() and
'numeric' x.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Extending proj with proj.line3d methods and overloading the methods

[Ivan Krylov via R-package-devel]

27 апреля 2024 г. 00:49:47 GMT+03:00, Leo Mada via R-package-devel 
 пишет:
>Dear List-Members,
>
>I try to implement a proj.line3d method and to overload this method as follows:
>
>proj.line3d <- function(p, x, y, z, ...)
>  UseMethod("proj.line3d")
>
>proj.line3d.numeric = function(p, x, y, z, ...) {
>  # ...
>}
>
>proj.line3d.matrix = function(p, x, y, z, ...) {
>  # ...
>}

>p = c(1,2,3)
>line = matrix(c(0,5,2,3,1,4), 2)
>proj.line3d(p, line)
>#  Error in UseMethod("proj.line3d") :
>#   no applicable method for 'proj.line3d' applied to an object of class 
>"c('double', 'numeric')"

>methods(proj)
># [1] proj.aov*   proj.aovlist*   proj.default*   proj.line3d
># [5] proj.line3d.matrix  proj.line3d.numeric proj.lm

In your NAMESPACE, you've registered methods for the generic function 'proj', 
classes 'line3d.matrix' and 'line3d.numeric', but above you are calling a 
different generic, 'proj.line3d', for which no methods are registered.

For proj.line3d(, ) to work, you'll have to register the 
methods for the proj.line3d generic. If you need a visible connection to the 
proj() generic, you can try registering a method on the 'proj' generic, class 
'line3d' *and* creating a class 'line3d' that would wrap your vectors and 
matrices:

proj(line3d(p), line) -> call lands in proj.line3d -> maybe additional dispatch 
on the remaining classes of 'p'?

This seems to work, but I haven't tested it extensively:

> proj.line3d <- \(x, ...) UseMethod('proj.line3d')
> proj.line3d.numeric <- \(x, ...) { message('proj.line3d.numeric'); x }
> line3d <- \(x) structure(x, class = c('line3d', class(x)))
> proj(line3d(pi))
proj.line3d.numeric
[1] 3.141593
attr(,"class")
[1] "line3d"  "numeric"

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Some, but not all vignettes compressed

[Ivan Krylov via R-package-devel]

В Thu, 25 Apr 2024 11:54:49 -0700
Bryan Hanson  пишет:

> So my version of gs blows things up!

The relatively good news is that GhostScript is not solely to blame. A
fresh build of "GPL Ghostscript 10.03.0 (2024-03-06)" was able to
reduce the files to 16..70% of their original size on my computer. But
I just typed ./configure && make and relied on the dependencies already
present on my system.

We can try to compare the build settings (which will involve compiling
things by hand) or ask the Homebrew people [*] (and they will probably
ask for a PDF file and a specific command line that works on some
builds of gs-10.03.0 but not with Homebrew).

What would you rather do?

qpdf, on the other hand, results in no size reduction (99.7% or worse),
just like on your system.

-- 
Best regards,
Ivan

[*]
https://docs.brew.sh/Troubleshooting
https://github.com/Homebrew/homebrew-core/issues?q=ghostscript

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

Re: [R-pkg-devel] Some, but not all vignettes compressed

[Ivan Krylov via R-package-devel]

В Thu, 25 Apr 2024 08:54:41 -0700
Bryan Hanson  пишет:

>   'gs+qpdf' made some significant size reductions:
>  compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb
>  compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb
>  compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb
>  compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb
>  compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb

I'm getting similar (but not same) results on Debian Stable, gs 10.00.0
& qpdf 11.3.0:

# R CMD build --no-resave-data --compact-vignettes=both
compacted ‘Vig_01_Start_Here.pdf’ from 244Kb to 45Kb   
compacted ‘Vig_02_Conceptual_Intro_PCA.pdf’ from 432Kb to 143Kb
compacted ‘Vig_03_Step_By_Step_PCA.pdf’ from 411Kb to 100Kb
compacted ‘Vig_04_Scores_Loadings.pdf’ from 335Kb to 78Kb  
compacted ‘Vig_05_Visualizing_PCA_3D.pdf’ from 679Kb to 478Kb  
compacted ‘Vig_06_Math_Behind_PCA.pdf’ from 556Kb to 145Kb 
compacted ‘Vig_07_Functions_PCA.pdf’ from 378Kb to 89Kb
compacted ‘Vig_08_Notes.pdf’ from 239Kb to 39Kb

 
> - doc/Vig_01_Start_Here.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=49942)/(old=45101) = 1.10734 .. not worth using  
> - doc/Vig_02_Conceptual_Intro_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using  
> - doc/Vig_03_Step_By_Step_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using  
> - doc/Vig_04_Scores_Loadings.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using  
> - doc/Vig_05_Visualizing_PCA_3D.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using  
> - doc/Vig_06_Math_Behind_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=816690)/(old=571493) = 1.42905 .. not worth using  
> - doc/Vig_07_Functions_PCA.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using  
> - doc/Vig_08_Notes.pdf:gs: res=0;  + qpdf: res=0; 
> ==> (new=40919)/(old=38953) = 1.05047 .. not worth using  

Thank you for providing this data! Somehow, instead of compacting the
PDFs, one of the tools manages to blow them up in size, as much as ~23
times.

Can you try tools::compactPDF() separately with gs_quality = 'none'
(isolating qpdf) and with qpdf = '' (isolating GhostScript)?

If the culprit turns out to be GhostScript, it may be due to their
rewritten PDF rendering engine (now in C instead of PostScript with
special extensions) not being up to par when the PDF file needs to be
compressed. If it turns out to be qpdf, we might have to extract the
exact command lines and compare results further.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [External] Re: Package submission to CRAN not passing incoming checks

[Ivan Krylov via R-package-devel]

В Wed, 24 Apr 2024 00:17:28 +
"Petersen, Isaac T"  пишет:

> I included the packages (including the raw package folders and their
> .tar.gz files) in the /inst/extdata folder.

Would you prefer your test to install them from the source directories
(as you currently do, in which case the *.tar.gz files can be omitted)
or the *.tar.gz files (in which case you can set the `repos` argument
to a file:/// URI and omit the package directories and the setwd()
calls)?

I think (but haven't tested) that the two problems that are currently
breaking your test are with .libPaths() and setwd().

.libPaths(temp_lib) overwrites the library paths with `temp_lib` and
the system libraries, the ones in %PROGRAMFILES%\R\R-*\library. In
particular, this removes %LOCALAPPDATA%\R\win-library\* from the list
of library paths, so the packages installed by the user (including
'waldo', which is needed by 'testthat') stop being available.

In order to add temp_lib to the list of the paths, use
.libPaths(c(temp_lib, .libPaths())).

Since setwd() returns the previous directory, one that was current
before setwd() was called, the code newpath <- setwd(filepath);
setwd(newpath) will keep the current directory, not set it to
`filepath`. Use oldpath <- setwd(filepath) instead.

Since you're already using 'testthat' and it already depends on
'withr', you may find it easier to use withr::local_dir(...) and
withr::local_temp_libpaths(...).

In order to test for a package being attached by load_or_install() (and
not just installed and loadable), check for 'package:testpackage1'
being present in the return value of search(). (This check is good
enough and much easier to write than comparing environments on the
search path with the package exports or comparing searchpaths() with
the paths under the temporary library.)

Finally, I think that there is no need for the test_load_or_install()
call because I don't see the function being defined anywhere. Doesn't
test_that(...) run the tests by itself?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Package submission to CRAN not passing incoming checks

[Ivan Krylov via R-package-devel]

Dear Isaac,

В Mon, 22 Apr 2024 17:00:27 +
"Petersen, Isaac T"  пишет:

> This my first post--I read the posting guidelines, but my apologies
> in advance if I make a mistake.

Welcome to R-package-devel! You're doing just fine.

> 1) The first note <...> includes the contents of the LICENSE file

It's multiple NOTEs in a trench coat. Kasper has addressed the "large
version components" and the DOIs interpreted as file URIs, but there's
one more.

The ' + file LICENSE' syntax has two uses: (1)
for when the terms of the license is a template, requiring the author
of the software to substitute some information (e.g. the year and the
copyright holder for MIT) and (2) for when a package puts additional
restrictions on the base license.

(Hmm. Only case (2) is currently described at
; case
(1) is only described inside the license files.)

The CRAN team has expressed a preference for the package authors not to
put 2 twisty little copies of standard licenses, all slightly
different, inside their packages. Since you're not restricting CC BY
4.0, it's enough to say 'License: CC BY 4.0'. If you'd like a full copy
of the license text in your source code repository, that's fine, but
you'll need to list the file in .Rbuildignore:
https://cran.r-project.org/doc/manuals/R-exts.html#Building-package-tarballs

Speaking of the Creative Commons license: the choice of a license for
your code is obviously yours, but Creative Commons themselves recommend
against using their licenses for software:
.
I can't recommend you a license - that would be politically motivated
meddling in foreign affairs - but the lists linked by the CC FAQ and
Writing R Extensions section 1.1.2 should provide a good starting point.

> Here are the results from win-builder:
> https://win-builder.r-project.org/incoming_pretest/petersenlab_0.1.2-9033_20240415_212322/

There is one more NOTE:

>> * checking examples ... [437s/438s] NOTE
>> Examples with CPU (user + system) or elapsed time > 5s
>>user system elapsed
>> load_or_install 349.410 37.410 387.233
>> vwReg35.199  0.379  35.606
 
The examples are not only for the user to read in the help page; they
are also for the user to run example(vwReg) and see your code in action
(and for R CMD check to see whether they crash, including regularly on
CRAN).

For vwReg, try reducing the number of regressions you are running
(since your dataset is mtcars, which is already very compact).

For load_or_install, we have the additional issue that running
example(load_or_install) modifies the contents of the R library and the
search path, which belong to the user. The CRAN policy forbids such
modifications: 

Examples in general should change as little of the global state of the
R session and the underlying computer as possible. I suggest wrapping
the example in \dontrun{} (since everything about load_or_install() is
about altering global state) and creating a test for the function in
tests/*.R.

The test should set up a new library under tempdir(), run
load_or_install(), check the outcomes (that the desired package is
attached, etc.) and clean up after itself. There's also the matter of
the package not failing without a connection to the Internet, which is
another CRAN policy requirement. You might have to bring a very small
test package in inst/extdata just for load_or_install() to install and
load it, so that R CMD check won't fail when running offline.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Old references in the Description file.

[Ivan Krylov via R-package-devel]

В Thu, 11 Apr 2024 11:57:00 +
Gabriel Constantino Blain  пишет:

> The problem is that it is a paper from the 70's (Priestley and
> Taylor, 1972) and its DOI has very uncommon symbols, such as <>. The
> DOI is: 10.1175/1520-0493(1972)100<0081:OTAOSH>2.3.CO;2.

Since the R CMD check function responsible for locating and checking
the DOIs from the package metadata expects to see them URL-encoded, it
should be possible to put your DOI through paste0('') in order to generate the correct link.

Another workaround is to generate a shortDOI that would redirect to the
same place as the original DOI:
https://shortdoi.org/10.1175/1520-0493(1972)100%3C0081:OTAOSH%3E2.3.CO;2
Now  should work like the original DOI.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Question about CRAN submission resulting in 1 note

[Ivan Krylov via R-package-devel]

В Wed, 10 Apr 2024 14:11:53 +
Chris Knoll  пишет:

> For "Package has VignetteBuilder field but no prebuilt vignette
> index", how would this be resolved?

The package at https://github.com/OHDSI/CirceR/ doesn't seem to have any
vignettes. Without vignettes, there's no need for VignetteBuilder:
knitr.

> For "Package ahs FOSS license, installs .class/.jar but has no 'java
> directory'':  This is custom code that I've written in Java plus has
> a few maven dependencies and I'm not sure if they are asking me to
> bundle the source code of all Java dependencies (that have classes in
> the jar file).   That could be hard to do, and was hoping if anyone
> had experience in this, is it enough to put into the Readme where
> such source code could be found?

Here's what the policy has to say:

>> For Java .class and .jar files, the sources should be in a top-level
>> java directory in the source package (or that directory should
>> explain how they can be obtained).



At the very least, XLconnect seems to be fine supplying just the
README. If it's not too much trouble, shipping your custom source code
(definitely not all of the maven dependencies) would be the kind thing
to do, I think. (Feel free to disregard this part if a more experienced
Java package developer says otherwise.)

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Linking Tutorial Site to CRAN Package site.

[Ivan Krylov via R-package-devel]

В Sat, 6 Apr 2024 18:27:24 +
"Ruff, Sergej"  пишет:

> The CRAN site
> (https://cran.r-project.org/web/packages/RepeatedHighDim/index.html)
> has a "documentation" part with the refrence pdf.
> 
> Can I link to our tutorial site (https://software.klausjung-lab.de/.)
> under documentation?

Since your tutorial is relatively short and contains R code intermixed
with the results of running it, it could make a great vignette.
Vignettes are linked on the CRAN page for a package right under the
PDF reference manual. For example, the BiocManager package has one
vignette: https://cran.r-project.org/package=BiocManager

Vignettes are a part of the package and their code is automatically
checked together with your examples. For the users of your package,
this will help keep the tutorial available (even if the website moves
in the future) and compatible with the current version of the package
(even if the package evolves and the tutorial website evolves together
with it).

R has built-in support for PDF vignettes via LaTeX using Sweave [*].
HTML vignettes can be much more accessible than PDF files, but there is
no built-in HTML vignette engine in R [**]. The 'markdown' package is
reasonably lightweight and has an HTML vignette engine. Markdown tries
to be a superset of HTML, so it should be possible to keep most of your
original HTML, including the styling, while rewriting the tutorial as
an executable vignette.

-- 
Best regards,
Ivan

[*]
https://cran.r-project.org/doc/manuals/R-exts.html#Writing-package-vignettes

[**]
It's possible to write a crude HTML vignette engine in ~100 lines of R
code, but we cannot expect every package author to do that.

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

Re: [R-pkg-devel] How to store large data to be used in an R package?

[Ivan Krylov via R-package-devel]

В Mon, 25 Mar 2024 11:12:57 +0100
Jairo Hidalgo Migueles  пишет:

> Specifically, this data consists of regression and random forest
> models crucial for making predictions within our R package.

Apologies for asking a silly question, but is there a chance that these
models are large by accident (e.g. because an object references a large
environment containing multiple copies of the training dataset)? Or it
is there really more than a million weights required to make
predictions?

> Initially, I attempted to save these models as internal data within
> the package. While this approach maintains functionality, it has led
> to a package size exceeding 20 MB. I'm concerned that this would
> complicate submitting the package to CRAN in the future.

The policy mentions the possibility of having a separate large
data-only package. Since CRAN strives to archive all package versions,
this data-only package will have to be updated as rarely as possible.
You will need to ask CRAN for approval.

If there is a significant amount of core functionality inside your
package that does *not* require the large data (so that it can still
be installed and used without the data), you can publish the data-only
package yourself (e.g. using the 'drat' package), put it in Suggests
and link to it in the Additional_repositories field of your DESCRIPTION.
Alternatively, you can publish the data on Zenodo and offer to download
it on first use. Make sure to (1) use tools::R_user_dir to determine
where to put the files, (2) only download the files after the user
explicitly agrees to it and (3) test as much of your package
functionality as possible without requiring the data to be downloaded.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Request for assistance: error in installing on Debian (undefined symbol: omp_get_num_procs) and note in checking the HTML versions (no command 'tidy' found, package 'V8' unavailable

[Ivan Krylov via R-package-devel]

В Thu, 21 Mar 2024 18:32:59 +
Annaig De-Walsche  пишет:

> If ever I condition the use of OpenMD directives, users will indeed
> be capable of installing the package, but they wont access to a
> performant version of the code, as it necessitates the use of OpenMD.
> Is there a method to explicitly express that the use of OpenMD is
> highly encouraged?

I think the most practical method would be to produce a
packageStartupMessage() from the .onAttach function of your package if
you detect that the package has been compiled without OpenMP support:
https://cran.r-project.org/doc/manuals/R-exts.html#Load-hooks

> In practical, how to know from R code if OpenMP is present or not?

Your C code will have to detect it and provide this information to the
R code. WRE 1.6.4 says:

>> [C]heck carefully that you have followed the advice in the
>> subsection on OpenMP support [WRE 1.2.1.1]. In particular, any use
>> of OpenMP in C/C++ code will need to use
>> 
>>  #ifdef _OPENMP
>>  # include 
>>  #endif



Similarly, any time you use #pragma omp ... or call
omp_set_num_threads(), it needs to be wrapped in #ifdef _OPENMP ...
#endif.

Additionally, it is important to make sure that during tests and
examples, your OpenMP code doesn't use more than two threads:
https://cran.r-project.org/web/packages/policies.html
This is in place because CRAN checks are run in parallel, and a package
that tries to helpfully use all of the processor cores would interfere
with other packages being checked at the same time.

>   [[alternative HTML version deleted]]

This mailing list removes HTML e-mails. If you compose your messages in
HTML, we only get the plain text version automatically prepared by your
mailer:
https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010595.html

In order to preserve the content and the presentation of your messages,
it's best to compose them in plain text.

-- 
Très cordialement,
Ivan

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

Re: [R-pkg-devel] help diagnosing win-builder failures

[Ivan Krylov via R-package-devel]

Hi,

This may need the help of Uwe Ligges to diagnose. I suspect this may be
related to the Windows machine having too much memory committed (as Uwe
has been able to pinpoint recently [*] about a package that failed to
compile some heavily templated C++), but there is not enough information
to give a conclusive diagnosis.

On Sun, 17 Mar 2024 14:01:33 -0400
Ben Bolker  wrote:

> 2. an ERROR running tests, where the output ends with a cryptic
> 
>Anova: ..
> 
> (please try to refrain from snarky comments about not using testthat
> ...)

Pardon my ignorance, but is it an option to upload a version of the
package that uses test_check(pkg, reporter=LocationReporter()) instead
of the summary reporter?

-- 
Best regards,
Ivan

[*] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010304.html

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

Re: [R-pkg-devel] Removing import(methods) stops exporting S4 "meta name"

[Ivan Krylov via R-package-devel]

On Thu, 14 Mar 2024 16:06:50 -0400
Duncan Murdoch  wrote:

> Error in xj[i] : invalid subscript type 'list'
> Calls: join_inner -> data.frame -> [ -> [.data.table -> [.data.frame
> Execution halted

And here's how it happens:

join_inner calls xi[yi,on=by,nomatch=0] on data.tables xi and yi.

`[.data.table` calls cedta() to determine whether the calling
environment is data.table-aware. If the import of `.__T__[:base` is
removed, cedta() returns FALSE.

`[.data.table` then forwards the call to `[.data.frame`, which cannot
handle data.table-style subsetting.

This is warned about in
;
the 'do' package should have set the .datatable.aware = TRUE marker in
its environment. In fact, example(join_inner) doesn't raise an error
with the following changes when running with data.table commit f92aee69
(i.e. pre-#6001):

diff -rU2 do/NAMESPACE do_2.0.0.0.2/NAMESPACE
--- do/NAMESPACE2021-08-03 12:37:00.0 +0300
+++ do_2.0.0.0.2/NAMESPACE  2024-03-15 14:01:10.588561222 +0300
@@ -130,5 +130,4 @@
 export(upper.dir)
 export(write_xlsx)
-importFrom(data.table,`.__T__[:base`)
 importFrom(methods,as)
 importFrom(reshape2,melt)
diff -rU2 do/R/join.R do_2.0.0.0.2/R/join.R
--- do/R/join.R 2020-06-30 06:47:22.0 +0300
+++ do_2.0.0.0.2/R/join.R   2024-03-15 13:54:02.289440613 +0300
@@ -1,2 +1,4 @@
+.datatable.aware = TRUE
+
 #' @title Join two dataframes together
 #' @description Join two dataframes by the same id column.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] confusion over spellchecking

[Ivan Krylov via R-package-devel]

В Sun, 10 Mar 2024 13:55:43 -0400
Ben Bolker  пишет:

> I am working on a package and can't seem to get rid of a NOTE about
> 
> Possibly misspelled words in DESCRIPTION:
>glmmTMB (10:88)
>lme (10:82)
> 
> on win-builder.

Do you have these words anywhere else in the package (e.g. in the Rd
files)? It turns out that R has a special environment variable that
makes it ignore custom dictionaries specifically for DESCRIPTION:

>>## Allow providing package defaults but make this controllable via
>>##   _R_ASPELL_USE_DEFAULTS_FOR_PACKAGE_DESCRIPTION_
>>## to safeguard against possible mis-use for CRAN incoming checks.

I cannot see it used anywhere under the trunk/CRAN subdirectory in the
developer.r-project.org Subversion repo, but it could be set somewhere
else on Win-Builder.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Submission after archived version

[Ivan Krylov via R-package-devel]

В Mon, 11 Mar 2024 23:45:13 +0100
Nils Mechtel  пишет:

> Despite R CMD check not giving any errors or warnings, the package
> doesn’t pass the pre-tests:

If your question was more about the reasons for the difference between
your R CMD check and the pre-tests, most of it is due to --as-cran:

(Using commit ffe216d from https://github.com/nilsmechtel/MetAlyzer as
the basis for the example, which seems to be different from the
incoming pretest from the link you've shared.)

$ R-devel CMD check MetAlyzer_1.0.0.tar.gz
<...>
Status: OK  
$ R-devel CMD check --as-cran MetAlyzer_1.0.0.tar.gz
<...>
* checking for non-standard things in the check directory ... NOTE
Found the following files/directories: ‘metabolomics_data.csv’
<...>

It's less wasteful to run checks without --as-cran in CI (as you
currently do), but you need to perform additional testing before making
a release. The incoming pre-tests use a custom set of environment
variables that go a but further than just --as-cran:
https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Kurt/lib/R/Scripts/check_CRAN_incoming.R

In particular, _R_CHECK_CRAN_INCOMING_USE_ASPELL_=true enables the
check for words that are possibly misspelled:

(Using an extra environment variable because your package has been
already published and R filters out "misspellings" found in the CRAN
version of the package. Congratulations!)

$ env \
 _R_CHECK_CRAN_INCOMING_ASPELL_RECHECK_MAYBE_=FALSE \
 _R_CHECK_CRAN_INCOMING_USE_ASPELL_=true \
 R-devel CMD check --as-cran MetAlyzer_1.0.0.tar.gz
<...>
Possibly misspelled words in DESCRIPTION:
  metabolomics (15:78)
<...>

Yet another way to avoid false misspellings is to create a custom
dictionary:
http://dirk.eddelbuettel.com/blog/2017/08/10/#008_aspell_cran_incoming

$ mkdir -p .aspell
$ echo '
 Rd_files <- vignettes <- R_files <- description <- list(
  encoding = "UTF-8",
  language = "en",
  dictionaries = c("en_stats", "dictionary")
 )
' > .aspell/defaults.R
$ R -q -s -e '
 saveRDS(c(
  "metabolomics" # , extra words go here
 ), file.path(".aspell", "dictionary.rds"))
'
$ R CMD build .
$ env \
 _R_CHECK_CRAN_INCOMING_ASPELL_RECHECK_MAYBE_=FALSE \
 _R_CHECK_CRAN_INCOMING_USE_ASPELL_=true \
 R-devel CMD check --as-cran MetAlyzer_1.0.0.tar.gz
# No more "Possibly misspelled words in DESCRIPTION"!

Some day, this will be documented in Writing R Extensions, or maybe in
R Internals (where the other _R_CHECK_* variables are documented), or
perhaps in the CRAN policy. See also:
https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010558.html

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Submission after archived version

[Ivan Krylov via R-package-devel]

В Mon, 11 Mar 2024 23:45:13 +0100
Nils Mechtel  пишет:

> Debian:
> 
> Status: 3 NOTEs

>> * checking CRAN incoming feasibility ... [4s/6s] NOTE

>> Possibly misspelled words in DESCRIPTION:
>>  metabolomics (36:78)

This one can be explained in the submission comment. The rest of the
NOTE is to be expected.

>> * checking DESCRIPTION meta-information ... NOTE
>> Author field differs from that derived from Authors@R

Just remove the Author: field from your DESCRIPTION and let R CMD build
automatically generate it from Authors@R.

>> * checking for non-standard things in the check directory ... NOTE
>> Found the following files/directories:
>>  ‘metabolomics_data.csv’

Make sure that when your tests and examples create files, they do so in
the session temp directory and then remove the files afterwards. If a
user had a valuable file named metabolomics_data.csv in the current
directory, ran example(...) and had it overwritten as a result, they
would be very unhappy.

The NOTEs on Windows are similar.

Good luck!

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [EXTERN] Re: [EXTERN] Re: [EXTERN] Re: @doctype is deprecated. need help for r package documentation

[Ivan Krylov via R-package-devel]

В Mon, 11 Mar 2024 14:57:58 +
"Ruff, Sergej"  пишет:

> I uploaded the old version of the package to my repo:
> https://github.com/SergejRuff/boot

After installing this tarball, running RStudio and typing:

library(bootGSEA)
?bootGSEA

...I see the help page in RStudio's help tab, not in the browser. I
think this is the expected behaviour for RStudio.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Ivan Krylov via R-package-devel]

Vladimir,

Thank you for the example and for sharing the ideas regarding
symbol-relative offsets!

On Thu, 7 Mar 2024 09:38:18 -0500 (EST)
Vladimir Dergachev  wrote:

>  unw_get_reg(&cursor, UNW_REG_IP, &pc);

Is it ever possible for unw_get_reg() to fail (return non-zero) for
UNW_REG_IP? The documentation isn't being obvious about this. Then
again, if the process is so damaged it cannot even read the instruction
pointer from its own stack frame, any attempts at self-debugging must
be doomed.

>* this should work as a package, but I am not sure whether the
> offsets between package symbols and R symbols would be static or not.

Since package shared objects are mmap()ed into the address space and
(at least on Linux with ASLR enabled) mmap()s are supposed to be made
unpredictable, this offset ends up not being static. On Linux, R seems
to be normally built as a position-independent executable, so no matter
whether there is a libR.so, both the R base address and the package
shared object base address are randomised:

$ cat ex.c
#include 
#include 
void addr_diff(void) {
 ptrdiff_t diff = (char*)&addr_diff - (char*)&Rprintf;
 Rprintf("self - Rprintf = %td\n", diff);
}
$ R CMD SHLIB ex.c
$ R-dynamic -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = -9900928
$ R-dynamic -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = -15561600
$ R-static -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = 45537907472976
$ R-static -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = 46527711447632

>* R ought to know where packages are loaded, we might want to be
> clever and print out information on which package contains which
> function, or there might be identical R_init_RMVL() printouts.

That's true. Informaion on all registered symbols is available from
getLoadedDLLs().

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [EXTERN] Re: [EXTERN] Re: @doctype is deprecated. need help for r package documentation

[Ivan Krylov via R-package-devel]

В Thu, 7 Mar 2024 20:27:29 +
"Ruff, Sergej"  пишет:

> I am refering to Rstudio. I checked the settings and type is set to
> "htlm", not text. And I was wondering why the package documentation
> opened in a browser when I used @doctype.

Do you still have the source package .tar.gz file for which ?bootGSEA
would start a browser from inside RStudio?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] @doctype is deprecated. need help for r package documentation

[Ivan Krylov via R-package-devel]

В Thu, 7 Mar 2024 10:37:51 +
"Ruff, Sergej"  пишет:

> I noticed that when I try _?bootGSEA_ it goes to the help page in R
> itself but not to the html page

That's up to the user to choose. help(bootGSEA, help_type = 'html')
should get you to the HTML documentation; help(bootGSEA, help_type =
'text') should give you plain text. The default depends on
options(help_type=...). On Windows, you get a choice during
installation of R; this gets recorded in file.path(R.home('etc'),
'Rprofile.site').

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Ivan Krylov via R-package-devel]

On Tue, 5 Mar 2024 18:26:28 -0500 (EST)
Vladimir Dergachev  wrote:

> I use libunwind in my programs, works quite well, and simple to use.
> 
> Happy to share the code if there is interest..

Do you mean that you use libunwind in signal handlers? An example on
how to produce a backtrace without calling any async-signal-unsafe
functions would indeed be greatly useful.

Speaking of shared objects injected using LD_PRELOAD, I've experimented
some more, and I think that none of them would work with R without
additional adjustments. They install their signal handler very soon
after the process starts up, and later, when R initialises, it
installs its own signal handler, overwriting the previous one. For this
scheme to work, either R would have to cooperate, remembering a pointer
to the previous signal handler and calling it at some point (which
sounds unsafe), or the injected shared object would have to override
sigaction() and call R's signal handler from its own (which sounds
extremely unsafe).

Without that, if we want C-level backtraces, we either need to patch R
to produce them (using backtrace() and limiting this to glibc systems
or using libunwind and paying the dependency cost) or to use a debugger.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Ivan Krylov via R-package-devel]

On Wed, 6 Mar 2024 13:46:55 -0500
Duncan Murdoch  wrote:

> is this just a more or less harmless error, thinking that 
> the dot needs escaping

I think it's this one. You are absolutely right that the dot doesn't
need escaping in either TRE (which is what's used inside exportPattern)
or PCRE. In PRCE, this regular expression would have worked as intended:

# We do match backslashes by mistake.
grepl('[\\.]', '\\')
# [1] TRUE

# In PCRE, this wouldn't have been a mistake.
grepl('[\\.]', c('\\', '.'), perl = TRUE)
# [1] FALSE TRUE

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] RcmdrPlugin.HH_1.1-48.tar.gz

[Ivan Krylov via R-package-devel]

В Tue, 5 Mar 2024 22:41:32 +
"Richard M. Heiberger"  пишет:

>  Undocumented code objects:
>'.__global__'
>  All user-level objects in a package should have documentation
> entries. See chapter 'Writing R documentation files' in the 'Writing R
>  Extensions' manual.

This object is not here for the user of the package. If you don't
export it, there will be no WARNING about it being undocumented. This
variable is exported because of exportPattern(".") in the file
NAMESPACE. The lone dot is a regular expression that matches any name
of an R object.

If you don't want to manually list your exports in the NAMESPACE file
(which can get tedious) or generate it (which takes additional
dependencies and build steps), you can use exportPattern('^[^\\.]') to
export everything except objects with a name starting with a period:
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Ivan Krylov via R-package-devel]

On Sun, 3 Mar 2024 19:19:43 -0800
Kevin Ushey  wrote:

> Would libSegFault be useful here?

Glad to know it has been moved to
 and not
just removed altogether after the upstream commit
.

libSegFault is safer than, say, libsegfault [*] because it both
supports SA_ONSTACK (for when a SIGSEGV is caused by stack overflow)
and avoids functions like snprintf() (which depend on the locale code,
which may have been the source of the crash). The only correctness
problem that may still be unaddressed is potential memory allocations
in backtrace() when it loads libgcc on first use. That should be easy
to fix by calling backtrace() once in segfault_init(). Unfortunately,
libSegFault is limited to glibc systems, so a different solution will
be needed on Windows, macOS and Linux systems with the musl libc.

Google-owned "backward" [**] tries to do most of this right, but (1) is
designed to be compiled together with C++ programs, not injected into
unrelated processes and (2) will exit the process if it survives
raise(signum), which will interfere with both rJava (judging by the
number of Java-related SIGSEGVs I saw while running R CMD check) and R's
own stack overflow survival attempts.

-- 
Best regards,
Ivan

[*] https://github.com/stass/libsegfault
(Which doesn't compile out of the box on GNU/Linux due to missing
pthread_np.h, although that should be easy to patch.)

[**] https://github.com/bombela/backward-cpp

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

[R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Ivan Krylov via R-package-devel]

Hello,

This may be of interest to people who run lots of R CMD checks and have
to deal with resulting crashes in compiled code.

Every now and then, the CRAN checks surface a particularly nasty crash.
The R-level traceback stops in the compiled code. It's not obvious
where exactly the crash happens. Naturally, this never happened on the
maintainer's computer before and, in fact, is hard to reproduce.

Containers would help, but they cannot solve the problem completely.
Some problems only surface when there's more than 32 logical
processors, or during certain times of day. It may help to at least see
the location of the crash as it happens on the computer running the
check.

One way to provide that would be to run a special debugger that does
nothing most of the time, attaches to child threads and processes, and
produces backtraces when processes receive a crashing signal. There is
such a debugger for Windows [1], and there is now a proof of concept
for amd64 Linux [2]. 

I've just tried [2] on a 250-package reverse dependency check and saw a
lot of SIGSEGVs with rcx=cafebabe or Java in the backtrace, but
other than that, it seems to work fine. Do you think it's worth
developing further?

The major downside of using a debugger like this is a noticeable change
in the environment: [v]fork(), clone() and exec() become slower,
attaching another tracer becomes impossible, SIGSEGVs may become much
slower (although I do hope that most software I rely upon doesn't care
about SIGSEGVs per second). On the other hand, these wrappers are as
transparent as they get and don't even need R -d to pass the arguments
to the child process.

The other way to provide C-level backtraces is a post-mortem debugger
(registered via the AeDebug registry key on Windows or
kernel.core_pattern sysctl on Linux). This avoids interference with the
process environment during normal execution, but requires more
integration work to collect the crash dumps, process them into usable
backtraces and associate with the R CMD check runs. There are also
injectable DLLs like libbacktrace, but these have to interfere with the
process from the inside, which may be worse than ptrace() in terms of
observable environment changes. On glibc systems (but not musl, macOS,
Windows), R's SIGSEGV handler could be enhanced to call
backtrace_symbols_fd(), which should be safe (no malloc()) as long as
libgcc is preloaded.

Is adding C-level backtraces to R CMD checks worth the effort? Could it
be a good idea to add this on CRAN? If yes, how can I help?

-- 
Best regards,
Ivan

[1] , see "catchsegv"

[2] https://codeberg.org/aitap/tracecrash

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

Re: [R-pkg-devel] Additional issues: Intel segfault

[Ivan Krylov via R-package-devel]

В Sat, 2 Mar 2024 02:07:47 +
Murray Efford  пишет:

> Gabor suggested https://github.com/r-hub/rhub2 and that worked like a
> charm. A check there on the Intel platform found no errors in my
> present version of secrdesign, so I'll resubmit with confidence.

Thank you for letting me know! Having this as a container simplifies a
lot of things.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Additional issues: Intel segfault

[Ivan Krylov via R-package-devel]

В Fri, 1 Mar 2024 07:42:01 +
Murray Efford  пишет:

> R CMD check suggests it is most likely in the Examples for
> 'validate', but all code there is wrapped in \dontrun{}.

The crash happens after q('no'), suggesting a corruption in the heap or
in the R memory manager. At least it's a null pointer being
dereferenced and not a 0xRANDOM_LOOKING_NUMBER: this limits the impact
of the problem.

I don't know if anyone created an easily reproducible container with an
Intel build of R (there's https://hub.docker.com/r/intel/oneapi, but
aren't the compilers themselves supposed to be not redistributable?),
so you will most likely have to follow
https://www.stats.ox.ac.uk/pub/bdr/Intel/README.txt and
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Intel-compilers
manually, compiling R using Intel compilers yourself in order to
reproduce this.

I think it would be great if CRAN checking machines used a just-in-time
debugger to provide C-level backtraces at the place of the crash. For
Windows, such a utility does exist [*], but I recently learned that the
glibc `catchsegv` program (and most other similar programs) used to
perform shared object preloading (before being thrown out of the
codebase altogether), which is more intrusive than it could be. A proof
of concept using GDB on Linux can be shown to work:

R -d gdb \
 --debugger-args='-batch -ex run -ex bt -ex c -ex q' \
 -e '
  Rcpp::sourceCpp(code =
   "//[[Rcpp::export]]\nvoid rip() { *(double*)(42) = 42; }"
  ); rip()
 '

-- 
Best regards,
Ivan

[*] https://github.com/jrfonseca/drmingw

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

Re: [R-pkg-devel] Unexpected multi-core CPU usage in package tests

[Ivan Krylov via R-package-devel]

В Tue, 27 Feb 2024 11:14:19 +
Jon Clayden  пишет:

> My testing route is to install the packages within the
> 'rocker/r-devel' Docker container, which is Debian-based, then use
> 'time' to evaluate CPU usage. Note that, even though 'RNifti' does not
> use OpenMP, setting OMP_NUM_THREADS changes its CPU usage

I think that's because rocker/r-devel uses parallel OpenBLAS:

$ podman run --rm -it docker.io/rocker/r-devel \
 R -q -s -e 'sessionInfo()' | grep -A1 BLAS
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.24.so;  
LAPACK version 3.11.0

The incoming CRAN check machine either sets the BLAS parallellism to 1
or uses a non-parallel BLAS. With rocker/r-devel, you can run R with
the environment variable OPENBLAS_NUM_THREADS set to 1. It's been
effective in the past to run R -d gdb and set a breakpoint on
pthread_create before launching the test. (In theory, it may be
required to set a breakpoint on every system call that may be used to
create threads, including various variations of clone(), subject to
variations between operating systems, but pthread_create has been
enough for me so far.)

With OPENBLAS_NUM_THREADS=1, I'm only seeing OpenMP threads created by
the mmand package during tests for your package tractor.base, and the
latest commit (that temporary disables testing of mmand) doesn't hit
the breakpoint or raise any NOTEs at all.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] CRAN Package Check Note: Warning: trimming empty

[Ivan Krylov via R-package-devel]

В Fri, 23 Feb 2024 17:04:39 +
Sunmee Kim  пишет:

> Version: 1.0.4
> Check: HTML version of manual
> Result: NOTE

This may not be immediately obvious in the e-mail from CRAN, but I
think this is a reminder of a warning from the previous version of the
package. Haven't you just uploaded version 1.0.5? I'm not getting any
warnings for gesca_1.0.5.tar.gz from the /incoming/archive subdirectory
on the CRAN FTP server, except perhaps "This build time stamp is over a
month old", and the latest check looks almost clean in the same manner:
https://win-builder.r-project.org/incoming_pretest/gesca_1.0.5_20240223_172938/

What does the rest of the e-mail say?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Conversion failure in 'mbcsToSbcs'

[Ivan Krylov]

В Wed, 21 Feb 2024 12:29:02 +
Package Maintainer  пишет:

> Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
>  chunk 58 (label = plotCBText)

In order to use the non-standard graphics device, the chunk must
set the option fig=TRUE. Otherwise, when something calls
graphics::strwidth('Lubomír Kubáček', "inches"), R notices that no
graphics device is active and creates a default one, which happens to
be pdf() and has all these problems. With fig=TRUE, Sweave will
initialise the cairo_pdf() device first, and then graphics::strwidth()
will use the existing device, avoiding the error.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Conversion failure in 'mbcsToSbcs'

[Ivan Krylov]

В Mon, 12 Feb 2024 16:01:27 +
Package Maintainer  пишет:

> Unfortunately, I received a reply from the CRAN submission team
> stating that my vignette file is still obtaining the "mbcsToSbcs"
> ERROR as is shown here
> (https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240212_152455/Debian/00check.log).

I am sorry for leading you down the wrong way with my advice. It turns
out that no 8-bit Type-1 encoding known to pdf() can represent both
'Lubomír Kubáček' and 'Anders Ågren':

lapply(
 setNames(nm = c(
  'latin1', 'cp1252', 'latin2', 'latin7',
  'latin-9', 'CP1250', 'CP1257'
 )), function(enc)
  iconv(enc2utf8(c(
   'Lubomír Kubáček', 'Anders Ågren'
  )), 'UTF-8', enc, toRaw = TRUE)
) |> sapply(lengths)
# one of the two strings cannot be represented, returning a NULL:
#  latin1 cp1252 latin2 latin7 latin-9 CP1250 CP1257
# [1,]  0  0 15  0   0 15  0
# [2,] 12 12  0 12  12  0 12

While it may still be possible to give extra parameters to pdf() to use
a font encoding that covers all the relevant characters, it seems
easier to switch to cairo_pdf() for your multi-lingual plots. Place the
following somewhere in the beginning of the vignette:

<>=
my.Swd <- function(name, width, height, ...)
 grDevices::cairo_pdf(
  filename = paste(name, "pdf", sep = "."),
  width = width, height = height
 )
@
\SweaveOpts{grdevice=my.Swd,pdf=FALSE}

This should define a new plot device function for Sweave, one that
handles more Unicode characters correctly.

> PS: Thanks for the advice about plain text mode. Hopefully, I have
> correctly abide by that advice in this current email.

This e-mail arrived in plain text, thank you!

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] failing CRAN checks due to problems with dependencies

[Ivan Krylov via R-package-devel]

В Wed, 7 Feb 2024 08:40:44 -0600
Marcin Jurek  пишет:

> Packages required but not available: 'Rcpp', 'FNN',
> 'RcppArmadillo' Packages suggested but not available for checking:
> 'fields', 'rmarkdown', 'testthat', 'maptools'

One of the machines running the incoming checks was having problems. If
you followed the failing dependency chain by looking at the CRAN check
results of the packages described as "not available", you could
eventually find a package needing compilation (Rcpp or stringi or
something else), look at the installation log and see Make trying to
run commands that are completely wrong.

It looked like the path to the compiler was empty:
https://web.archive.org/web/20240208191430/https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/Rcpp-00install.html

I think that the problems are solved now, so it should be safe to
increment the version and submit it again.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] r-oldrel-linux- not in CRAN checks?

[Ivan Krylov via R-package-devel]

В Tue, 6 Feb 2024 18:27:32 +0100
Vincent van Hees  пишет:

> For details see:
> https://github.com/RfastOfficial/Rfast/issues/99

GitHub processed your plain text description of the problem as if it
was Markdown and among other things ate the text that used to be there
between angle brackets:

> #include
>  ^~~

By digging through the raw source code of the issue at
https://api.github.com/repos/RfastOfficial/Rfast/issues/99 it is
possible to find out which header was missing for Rfast:

> ../inst/include/Rfast/parallel.h:20:10:fatal error: tion: No such
> file or directory
> #include 
>  ^~~
>compilation terminated.

Indeed,  is a C++17 header [1]. While g++ version
7.5.0-3ubuntu1~18.04 seems to accept --std=c++17 without complaint, its
libstdc++-7-dev package is missing this header. Moreover, there's still
no  in libstdc++-8-dev. I think that you need libstdc++-9
for that to work, which is not in Bionic; older versions aren't
C++17-compliant enough to compile Rfast, and C++17 is listed in the
SystemRequirements of the package.

Installing clang-10 and editing Makeconf to use clang++-10 instead of
g++ seems to let the compilation proceed. In order to successfully link
the resulting shared object, I also had to edit Makeconf to specify
-L/usr/lib/gcc/x86_64-linux-gnu/7 when linking -lgfortran.

If you plan to use this in production, be very careful. I don't know
about binary compatibility guarantees between g++-7 and clang++-10, so
you might have to recompile every C++-using R package from source with
clang++-10 in order to avoid hard-to-debug problems when using them
together. (It might also work fine. That's the worst thing about such
problems.)

-- 
Best regards,
Ivan

[1] https://en.cppreference.com/w/cpp/header/execution

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

Re: [R-pkg-devel] new maintainer for CRAN package XML

[Ivan Krylov via R-package-devel]

Dear Uwe Ligges,

On Mon, 22 Jan 2024 15:50:44 +0100
Uwe Ligges  wrote:

> So we are looking for a person volunteering to take over 'XML'.
> Please let us know if you are interested.

Unless someone else has been discussing this with CRAN in private or
had a package depending on XML and was planning to step up but forgot,
I would like to volunteer.

I'm assuming that the Omegahat page is best preserved in its current
form for historical reasons, so instead I have prepared a Git
repository and a page with an option to file issues on the Codeberg
forge: https://codeberg.org/aitap/XML

With the help of the amazing list members, I have also set up a virtual
machine to run the reverse dependency checks, so it should be possible
to avoid immediate breakage if I have to make any changes.

That's the theory, at least.

(Also, thank you for your reply to my question!)

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Ivan Krylov via R-package-devel]

Thank you Georgi Boshnakov, Ben Bolker, and Diego Hernangómez Herrero
for introducing me to `revdepcheck`!

On Tue, 30 Jan 2024 12:38:57 -0500
Ben Bolker  wrote:

> I have had a few issues with it 
>  but overall it's
> been very helpful.

Indeed that looks perplexing. Writable .Library can also cause problems
for people running R-svn built in their home directories without
R_LIBS_USER set when they check their packages without Suggests.
I'm also relying on .Library.site for the dependencies of the reverse
dependencies. So far, my setup seems to be working as intended, but I'll
keep this issue in mind.

On Tue, 30 Jan 2024 18:57:41 +0100
Diego Hernangómez Herrero  wrote:

> Haven’t tried with a package with such an amount of revdeps, but my
> approach is revdepcheck in GH actions and commiting the result to the
> repo (that is somehow similar to the docker approach if you host the
> package in GitHub).

Great to know that reverse dependency checks can run in CI! I think
I'll keep a stateful virtual machine for now, because otherwise I would
need to find space for 4 to 32 gigabytes of cache somewhere (or download
everything from the repository mirrors every time).

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Ivan Krylov via R-package-devel]

On Tue, 30 Jan 2024 16:24:40 +
Martin Morgan  wrote:

> BiocManager (the recommended way to install Bioconductor packages) at
> the end of the day does essentially install.packages(repos =
> BiocManager::repositories()), ensuring that the right versions of
> Bioconductor packages are installed for the version of R in use.

That's great to know, thanks! I think I will use BiocManager::install
for now, both because it uses the correct repositories and because it
doesn't forcibly reinstall the packages I am asking for. With bspm, I
can run BiocManager::install(all_the_dependencies) and have the system
perform the least amount of work required to reach the desired state.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Ivan Krylov via R-package-devel]

Dear Dirk,

Thank you very much for your help here and over on GitHub!

I have finally managed to get the reverse dependency checks working. It
took some additional disk space and a few more system dependencies. If
not for r2u, I would have been stuck for much longer. I really
appreciate the work that went into packaging all these R packages.

On Tue, 30 Jan 2024 10:32:36 -0600
Dirk Eddelbuettel  wrote:

> For what it is worth, my own go-to for many years has been a VM in
> which I install 'all packages needed' for the rev.dep to be checked.

This approach seems to be working for me, too. I had initially hoped to
set something up using CI infrastructure, but there's too many
dependencies to install in a prepare step and it's too much work to
make a container image with all dependencies anew every time I want to
run a reverse dependency check. Easier to just let it run overnight on
a spare computer.

> Well a few of us maintain packages with quite a tail and cope. Rcpp
> has 2700, RcppArmadillo have over 100, BH a few hundred. These aren't
> 'light'.

Maintaining a top-5 CRAN package by in-degree rank
[10.32614/RJ-2023-060] is indeed a very serious responsibility. 

> I wrote myself the `prrd` package (on CRAN) for this, others have
> other tools -- Team data.table managed to release 1.5.0 to CRAN today
> too. So this clearly is possible.

I'll check out `prrd` next, thanks. tools::check_packages_in_dir is
nice, but it could be faster if I could disable mc.preschedule. 

-- 
Best regards,
Ivan

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

[R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Ivan Krylov via R-package-devel]

Hello R-package-devel,

What would you recommend in order to run reverse dependency checks for
a package with 182 direct strong dependencies from CRAN and 66 from
Bioconductor (plus 3 more from annotations and experiments)?

Without extra environment variables, R CMD check requires the Suggested
packages to be available, which means installing...

revdepdep <- package_dependencies(revdep, which = 'most')
revdeprest <- package_dependencies(
 unique(unlist(revdepdep)),
 which = 'strong', recursive = TRUE
)
length(setdiff(
 unlist(c(revdepdep, revdeprest)),
 unlist(standard_package_names())
))

...up to 1316 packages. 7 of these suggested packages aren't on CRAN or
Bioconductor (because they've been archived or have always lived on
GitHub), but even if I filter those out, it's not easy. Some of the
Bioconductor dependencies are large; I now have multiple gigabytes of
genome fragments and mass spectra, but also a 500-megabyte arrow.so in
my library. As long as a data package declares a dependency on your
package, it still has to be installed and checked, right?

Manually installing the SystemRequirements is no fun at all, so I've
tried the rocker/r2u container. It got me most of the way there, but
there were a few remaining packages with newer versions on CRAN. For
these, I had to install the system packages manually in order to build
them from source.

Someone told me to try the rocker/r-base container together with pak.
It was more proactive at telling me about dependency conflicts and
would have got me most of the way there too, except it somehow got me a
'stringi' binary without the corresponding libicu*.so*, which stopped
the installation process. Again, nothing that a bit of manual work
wouldn't fix, but I don't feel comfortable setting this up on a CI
system. (Not on every commit, of course - that would be extremely
wasteful - but it would be nice if it was possible to run these checks
before release on a different computer and spot more problems this way.)

I can't help but notice that neither install.packages() nor pak() is
the recommended way to install Bioconductor packages. Could that
introduce additional problems with checking the reverse dependencies?

Then there's the check_packages_in_dir() function itself. Its behaviour
about the reverse dependencies is not very helpful: they are removed
altogether or at least moved away. Something may be wrong with my CRAN
mirror, because some of the downloaded reverse dependencies come out
with a size of zero and subsequently fail the check very quickly.

I am thinking of keeping a separate persistent library with all the
1316 dependencies required to check the reverse dependencies and a
persistent directory with the reverse dependencies themselves. Instead
of using the reverse=... argument, I'm thinking of using the following
scheme:

1. Use package_dependencies() to determine the list of packages to test.
2. Use download.packages() to download the latest version of everything
if it doesn't already exist. Retry if got zero-sized or otherwise
damaged tarballs. Remove old versions of packages if a newer version
exists.
3. Run check_packages_in_dir() on the whole directory with the
downloaded reverse dependencies.

For this to work, I need a way to run step (3) twice, ensuring that one
of the runs is performed with the CRAN version of the package in the
library and the other one is performed with the to-be-released version
of the package in the library. Has anyone already come up with an
automated way to do that?

No wonder nobody wants to maintain the XML package.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Possible malware(?) in a vignette

[Ivan Krylov via R-package-devel]

There used to be a long analysis in the draft of this e-mail [*], but
let me cut to the chase.

Even something as simple as replacing the four-byte comment [**] at the
beginning of the file ("%\xd0\xd4\xc5\xd8" -> "%") that keeps the
file fully readable (!) results in the same behaviour but zero
detections:

$ sha256sum d_jss_paper*.pdf
0ae3b229fdd763a0571463dc98e02010752bb0213a672db6826afcd72ccaf291  
d_jss_paper1.pdf
9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9  
d_jss_paper.pdf
$ diff -u <(hd d_jss_paper.pdf) <(hd d_jss_paper1.pdf)
--- /dev/fd/63  2024-01-28 13:00:43.454419322 +0300
+++ /dev/fd/62  2024-01-28 13:00:43.454419322 +0300
@@ -1,4 +1,4 @@
-  25 50 44 46 2d 31 2e 35  0a 25 d0 d4 c5 d8 0a 37  |%PDF-1.5.%.7|
+  25 50 44 46 2d 31 2e 35  0a 25 20 20 20 20 0a 37  |%PDF-1.5.%.7|
 0010  37 20 30 20 6f 62 6a 0a  3c 3c 0a 2f 4c 65 6e 67  |7 0 obj.<<./Leng|
 0020  74 68 20 32 36 32 38 20  20 20 20 20 20 0a 2f 46  |th 2628  ./F|
 0030  69 6c 74 65 72 20 2f 46  6c 61 74 65 44 65 63 6f  |ilter /FlateDeco|

https://www.virustotal.com/gui/file/0ae3b229fdd763a0571463dc98e02010752bb0213a672db6826afcd72ccaf291

The scary-looking files and hosts being accessed are just Adobe Reader
and Chrome behaving in a manner indistinguishable from spyware. Upload
any PDF file with links in it and you'll see the same picture. Even the
original report for d_jss_paper.pdf from poweRlaw_0.70.6 says "no
sandboxes flagged this file as malicious".

I think that the few non-major antivirus products that "detected" the
original file remembered a low-quality checksum of a different file,
and this whole thread resulted from a checksum collision. 0x043BC33F
(71025471) is what, four bytes? Doesn't seem to be a standard CRC-32 or
the sum of all bytes modulo 2^32, though.

I cannot prove a negative, but I invite infosec people with more PDF
experience to comment further on the issue.

-- 
Best regards,
Ivan

[*] Colin seems to have used the Debian build of TeX Live 2017 to
generate it, which is non-trivial but possible to reproduce by
installing it from Debian Snapshots on top of Stretch. The resulting
file has a different hash (for valid reasons), the same behaviour, but
zero detections:
https://www.virustotal.com/gui/file/f7b0e0400167e06970ac61fcadfda29daec1c2ee685d4c9ff805e375bcffc985/behavior

Trying a "binary search" by removing PDF objects or replacing byte
ranges with ASCII spaces was also a dead end: any change results in no
detections.

[**] PDF 1.5 specification, section 3.1.2:

>> Comments (other than the %PDF−1.4 and %%EOF comments described in
>> Section 3.4, “File Structure”) have no semantics.

https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.5_v6.pdf#G8.1860480

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

Re: [R-pkg-devel] Possible malware(?) in a vignette

[Ivan Krylov via R-package-devel]

Apologies for being insufficiently clear. By "a file straight from NOAA" I 
meant a completely different PDF, 
, 
that gives the same SHA-256 hash whether downloaded by VirusTotal 

 or me, comes from a supposedly trusted source, and still makes Acrobat Reader 
behave like it's infected, show a crashed Firefox on the screenshot and drop a 
number of scary-looking files. Surely there will be a difference between 
reading an infected file and a non-infected file?

27 января 2024 г. 15:10:53 GMT+03:00, Bob Rudis  пишет:
>Ivan: do you know what mirror NOAA used at that time to get that version of
>the package? Or, did they pull it "directly" from cran.r-project.org
>(scare-quotes only b/c DNS spoofing is and has been a pretty solid attack
>vector)?

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

Re: [R-pkg-devel] Possible malware(?) in a vignette

[Ivan Krylov via R-package-devel]

В Sat, 27 Jan 2024 03:52:01 -0500
Bob Rudis  пишет:

> Two VT sandboxes used Adobe Acrobat Reader to open the PDF and the PDF
> seems to either had malicious JavaScript or had been crafted
> sufficiently to caused a buffer overflow in Reader that then let it
> perform other functions on those sandboxes.

Let's talk package versions and SHA256 hashes of
poweRlaw/inst/doc/d_jss_paper.pdf.

poweRlaw version 0.70.4:
Packaged: 2020-04-07 14:55:32 UTC
Date/Publication: 2020-04-07 16:10:02 UTC
SHA-256(poweRlaw/inst/doc/d_jss_paper.pdf):
96535de112f471c66e29b74c77444b34a29b82d6525c04d477ed2d987ea6ccae

Not previously uploaded to VirusTotal, currently checks out clean:
https://www.virustotal.com/gui/file/96535de112f471c66e29b74c77444b34a29b82d6525c04d477ed2d987ea6ccae

poweRlaw version 0.70.5:
Packaged: 2020-04-23 15:36:49 UTC
Date/Publication: 2020-04-23 16:40:06 UTC
SHA-256(poweRlaw/inst/doc/d_jss_paper.pdf):
5f827302ede74e1345fba5ba52c279129823da3c104baa821d654ebb8d7a67fb

Not previously uploaded to VirusTotal, also checks out clean:
https://www.virustotal.com/gui/file/5f827302ede74e1345fba5ba52c279129823da3c104baa821d654ebb8d7a67fb/behavior

For some reason, the Zenbox report shows a browser starting up and
someone (something?) moving the mouse:
https://vtbehaviour.commondatastorage.googleapis.com/5f827302ede74e1345fba5ba52c279129823da3c104baa821d654ebb8d7a67fb_Zenbox.html?GoogleAccessId=758681729565-rc7fgq07icj8c9dm2gi34a4cckv23...@developer.gserviceaccount.com&Expires=1706348766&Signature=KSTxSZJJUUv0FOA51Kwuot89ep4PKUDTY6tHL7kTyG7VwaMlF8VjmU90loeF4ytLBxKjkEtAk%2Ffr39xFrTTyOym3mehtc3HLyT9DS3C5qGa9OPVcu%2BfQfd8qr%2BRubBWb3SKNnhGpi%2Bn%2BTDhaiRx3PilEz%2BwVGiukfNUzWGBlGweG%2BmR1Y%2F0fIgDxJ3eyZ8KwTaocbywMoOLJeC1GSmoW8VYUAnFS2bb8P9Jt%2Bs%2F0axvAkc0M2pmSN3s2lpMq8u5P%2FZZ8yRIMdmv%2B1kUR5ajBdIa%2FHV8Vw8xAdNjZID6ozwAsmBOOizJmHgzr4zh1tX4V65qmcz8D3jctvDRKsuEqXA%3D%3D&response-content-type=text%2Fhtml;#overview

Lots of file activity. I think that all of it can be attributed to
either normal Acrobat Reader activity or normal Chrome activity.

Then we come to poweRlaw version 0.70.6:
Packaged: 2020-04-24 10:44:31 UTC
Date/Publication: 2020-04-25 07:30:12 UTC
SHA-256(inst/doc/d_jss_paper.pdf):
9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9

The Web Archive capture version 20201205222617 for the address
https://cran.r-project.org/web/packages/poweRlaw/vignettes/d_jss_paper.pdf
has the same SHA-256 hash.

This file is being disputed because some antivirus applications flag it:
https://www.virustotal.com/gui/file/9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9/behavior

The behaviour is exactly the same as the one from version 0.70.5:
browser opens with a link to a wrong DOI. Some links are followed.
https://vtbehaviour.commondatastorage.googleapis.com/9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9_Zenbox.html?GoogleAccessId=758681729565-rc7fgq07icj8c9dm2gi34a4cckv23...@developer.gserviceaccount.com&Expires=1706347808&Signature=Kv1LXUGvDe988Br0pU1AMlttjYY1K9sDwouvZrlzAVSspkdOGS9Ow%2Bg%2F3VjnQLEshx08QqgOHZzQcghownumPDUJLBbEHbOk6KG9IZSH43rxkYhTIy%2BYT5PfNFIupevbJA5XrnJHrm1wKho2%2BDb4t8vA4cgOJJY0UahXTbIMKUeUmPCKAzx9W5kYKj55WhNDrIPrEuni9EeGWkFV45kPr%2BBwYfl2hK4%2BWv6K78CB7zJtzFltF6P3pewafn5Lg3M3AY5YcZ4TryXi01t0dq04Fha83fLRP7JUkmcfpAJauA48Ct0XN7RdCRPSogb0TAGwG%2BDstxNzLAphOEsVju9LUQ%3D%3D&response-content-type=text%2Fhtml;#dropped-info

I've uploaded a decompressed version (prepared using qpdf in.pdf
--stream-data=uncompress out.pdf) of the same file to VirusTotal, and
there are no detections. Zero detections, but the behaviour is the same:
some files are "dropped", but all of them relate to cache in Acrobat
Reader (which is nowadays a piece of Chrome) and Chrome itself:
https://www.virustotal.com/gui/file/5acbc41f103c88a801db36fa72f01d4fa81b9afa1879c36235b1f5373d46ee1a/behavior

Finally, there's poweRlaw version 0.80.0:
Packaged: 2024-01-25 10:39:42 UTC
Date/Publication: 2024-01-25 18:00:02 UTC
SHA-256(inst/doc/d_jss_paper.pdf):
17c252a38e6c9bcfab90a69070b17c5e9d8a1713b7bb376badaeba28b3a38739
Same zero flags, same behaviour of starting the browser, same "dropped"
files in the cache:
https://www.virustotal.com/gui/file/17c252a38e6c9bcfab90a69070b17c5e9d8a1713b7bb376badaeba28b3a38739/behavior
https://vtbehaviour.commondatastorage.googleapis.com/17c252a38e6c9bcfab90a69070b17c5e9d8a1713b7bb376badaeba28b3a38739_Zenbox.html?GoogleAccessId=758681729565-rc7fgq07icj8c9dm2gi34a4cckv23...@developer.gserviceaccount.com&Expires=1706348864&Signature=UjXMjCvz0uTjS1sqyr5y%2FOwluE%2BskW9F2XupXuOs5JgODlsL1BuwJcWJ56xddQNEtKDHDOaXoRfNxynsffmSaza4yJD9hvPJ6%2BrNMibbB8hojY53g07WKnCd3wdaOmOHEqIP7Md06QWD4CnLEN0KlRvWdsUUA%2F9YTB1bAVqkIR%2FtiaJcRrOTAmdG%2F9Hwrq4xpiEBaFZzO%2FsQPVj3dzNS1LQEXOHFAfnOTaC1LlbBfn9QQWCPib%2FpCOL7huVYqIFSm%2FO8VHWv67JD1qwcTOY7JSl8XPw1ueyumRpF5xF1rpWYCPjC1awU8tho25A2COA7f7LSkku0BRqkuHYW3kuZaw%3D%3D&response-content-type=text%2Fhtml;#dropped-info

I've also uploaded a PDF that came

Re: [R-pkg-devel] How to deal with issues when using devtools::check_rhub(), rhub::check(), and web form

[Ivan Krylov via R-package-devel]

В Wed, 24 Jan 2024 16:14:05 -0800
Carl Schwarz  пишет:

> I tried using the web interface at https://builder.r-hub.io/ to
> select the denebian machines, and it returns a message saying
> 
> We're sorry, but something went wrong.
> If you are the application owner check the logs for more information.

> So how do I tell if this a "Rhub issue" or an issue with my package?

A problem with your package would look more like the check at least
starting and then producing errors. Here, it doesn't look like the
check is even starting.

> Or do I just give up on using Rhub to check the denebian machines?

For a while, Rhub used to offer the only on-demand checking service
specifically on Linux machines (there was Win-builder by Uwe Ligges and
macOS builder by Simon Urbanek, but no "Linux builder"), including
Debian [*]. Now that the funding ran out [**], you can try using
various continuous integration services to run your checks in a Linux
virtual machine. Many of them offer free compute minutes.

I think that you've already fulfilled the requirements of the CRAN
policy by fixing all known problems and having R CMD check --as-cran on
R-devel run for you by Win-Builder (which is what
devtools::check_win_devel() does).

-- 
Best regards,
Ivan

[*]
Named after Debra Lynn and Ian Murdock

[**]
https://github.com/RConsortium/r-repositories-wg/blob/main/minutes/2023-09-07_Minutes.md

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

Re: [R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols

[Ivan Krylov via R-package-devel]

On Mon, 22 Jan 2024 17:14:04 +0100
Tomas Kalibera  wrote:

> Yes, inside a bigger email, reports can get overlooked, particularly 
> when in a thread with a rather different subject. It wasn't
> overlooked this time thanks to Martin.

Then additional thanks goes to Martin, and I'll make sure to report in
the right place if a similar situation happens again.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] lost braces note on CRAN pretest related to \itemize

[Ivan Krylov via R-package-devel]

В Tue, 23 Jan 2024 19:39:54 +0100
Patrick Giraudoux  пишет:

>    \itemize{
>    \item{.}{lm and glm objects can be passed directly as the upper
> scope of term addition (all terms added).

Inside the \itemize and \enumerate commands, the \item command doesn't
take any arguments:
https://cran.r-project.org/doc/manuals/R-exts.html#Lists-and-tables

Instead, it starts a new paragraph with a number (\enumerate) or a
bullet point (\itemize). R CMD check is reminding you that \itemize{
\item{foo}{bar} } is equivalent to \itemize{ \item foo bar } without
any braces.

If you meant to highlight a word by making it an argument of the \item
command, use the \describe command. Here, you're highlighting a dot,
which would be rendered with a bullet point before it, so it's probably
neither semantically nor visually appropriate.

> \value{
>    A \code{\link[sf]{sfc}} object, of POINT geometry, with the
> following columns:
>    \itemize{
>    \item{ID}{ ID number}

The same problem applies here.

Additionally, R CMD check is reminding you that \value{} is implicitly
a special case of a \describe{} environment:
https://cran.r-project.org/doc/manuals/R-exts.html#index-_005cvalue

Since you're already using \item{}{} labels to name the components of
the value, just drop the \itemize{} (but keep its contents). \value{} is
enough.

-- 
Best regards,
Ivan

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