Re: [R-pkg-devel] Debugging M1mac problems [solved]

[Ivan Krylov]

On Sat, 27 Mar 2021 17:26:16 +0300
Ivan Krylov  wrote:

> I'm probably doing something stupid with the file names that usually
> works but isn't guaranteed to work in all cases, but I cannot figure
> it out.

Long story short, the problem turned out to be that I called basename()
and dirname() on paths not guaranteed to exist. Thanks to Tomas
Kalibera for pointing me in the right direction!

I'd wager a guess that I would have reproduced the same issue on an
Intel macOS machine with Big Sur installed (this being the other main
difference between Intel/High Sierra machines where all tests passed
and the M1/Big Sur machine where they failed). The "package check
results" page now shows all "OK" for the updated version, so I must
have fixed it.

I guess the moral of the story is that sometimes, it's easier to fix a
problem than reproduce it for oneself.

-- 
Best,
Ivan

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

Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN with valgrind

[Ivan Krylov]

On Mon, 2 Aug 2021 17:11:14 +
Georgi Boshnakov  wrote:

> What am I missing? Do I need to have a separate library for the
> instrumented R-devel version?

It doesn't look to me like you're missing anything, unless you start
seeing the errors when you start `R -d valgrind` and then run the tests
from your package.

Perhaps AddressSanitizer would be more successful at catching this
particular error? It should be possible run -fsanitize=... shared
libraries with "unsanitized" executables by LD_PRELOAD'ing libasan.
What happens if you run the following?

LD_PRELOAD=libasan.so.3 \
 PKG_CXXFLAGS=-fsanitize=address PKG_LIBS=-fsanitize=address \
 R CMD check rbibutils_VERSION.tar.gz

AddressSanitizer used to have an error where it couldn't start up if
something called malloc() before its constructors had a chance to run,
but it's been fixed in 2017.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Ongoing CXX17 woes

[Ivan Krylov]

On Fri, 6 Aug 2021 15:51:37 -0500
Tim Keitt  wrote:

> CXX17=`${R_HOME}/bin/R CMD config --all | awk '{print $1}' | grep \
> "^CXX17$"`

This seems to output "CXX17" on a machine with no C++17 support. On the
other hand, running `${R_HOME}/bin/R CMD config CXX17` here gives me an
empty string.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] UX for "WARNING unable to translate to native encoding"?

[Ivan Krylov]

On Mon, 16 Aug 2021 09:05:54 +
David Norris  wrote:

> Unicode U+00d7 (times), U+00b1 (plus-minus) and U+03bc (mu) have
> equivalents in Latin-1 encoding, and I have used these without
> difficulty in strings, neither U+2206 (INCREMENT) nor U+0394 (Greek
> Delta) does

But not in some other locale encodings on Windows (e.g. CP-1251), nor
in some single-byte locale encodings on *nix-like systems (e.g.
ru_RU.KOI8-R), which are admittedly used much rarer nowadays than on
Windows. Unless I'm mistaken, the "\u2206t" in your example needs to
become a symbol, and symbols are always translated into the locale
encoding [1] [2].

I would expect this warning to be a problem for CRAN, but I'm just
another package developer, so I could be wrong.

-- 
Best regards,
Ivan

[1]
https://github.com/r-devel/r-svn/blob/9b13376f5e630f584a68d3815da004dc79c059a3/src/main/sysutils.c#L1046-L1052

[2]
https://github.com/r-devel/r-svn/blob/9b13376f5e630f584a68d3815da004dc79c059a3/src/main/sysutils.c#L842

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

Re: [R-pkg-devel] http error handling in packages

[Ivan Krylov]

On Wed, 8 Sep 2021 12:02:51 +1200
obrl soil  wrote:

> I just want to clarify whether the problem is an overly brief error
> message, or my use of stop() in this context? 

I think it's neither: it's perfectly fine to use the R error system to
signal being unable to establish function postconditions, but then the
tests shouldn't fail because of that (yes, including the \donttest{}
ones).

So, in my opinion, both stop() and the error message are okay, but the
example should wrap them in try() / tryCatch() and check the return
value correctly.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Internet resources and Errors

[Ivan Krylov]

On Fri, 24 Sep 2021 07:49:44 -0700
Roy Mendelssohn - NOAA Federal via R-package-devel
 wrote:

> All internet calls are wrapped in 'try()'.  If that shows an error,
> I  write a message to the screen about the error,  and call stop(),
> perhaps with a further message in that call.   Somehow this does not
> appear to meet the standard.Can someone then please tell me what
> I should do instead.

I think that the important part is to catch that stop() in your _tests
or examples_, so that a stop() raised by a connection error
inside the code of your package wouldn't fail your \example{} block or a
test in tests/*.R.

Good:
R/myfunction.R: if (connection_failed) stop(informative_message)

Bad:
man/myfunction.Rd:
\example{ myfunction(foo) }

(During CRAN testing, connection fails, the exception reaches the R CMD
check process and fails the test.)

Good:
man/myfunction.Rd
\example{ try(myfunction(foo)) # may fail because of connection errors }

Here, the exception is raised but handled. Bonus points if you use
tryCatch(...) and only catch the "connection failed" conditions,
allowing all other errors to propagate and still fail the tests. It's
possible if you construct a condition object (x <- simpleError(...))
and append to its class(): class(x) <- c(class(x),
'connection_failed'). The resulting error can still be raised with
stop(x). tryCatch() will then be able to call your handler only for
connection_failed errors.

Raising an exception is a valid way of dealing with connection errors
for functions that rely on outside world to fulfil their promise.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Tests run without --as-cran and not with

[Ivan Krylov]

On Fri, 24 Sep 2021 21:48:12 +0200
Jan van der Laan  wrote:

> my tests run fine when run with R CMD check, but not with R CMD check
> --as-cran

<...>

> pandoc then calls R again with a script which is part of the package

Part of R CMD check --as-cran is placing fake R and Rscript executables
on the PATH (but currently not on Windows):

https://github.com/r-devel/r-svn/blob/98f33a2a7b22f400d51220162cf400a0cfdc9aaf/src/library/tools/R/check.R#L279

https://github.com/r-devel/r-svn/blob/98f33a2a7b22f400d51220162cf400a0cfdc9aaf/src/library/tools/R/check.R#L6297-L6323

Does the pandoc script use the R_HOME variable to call the correct R
executable?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] multithreading in packages

[Ivan Krylov]

В Thu, 7 Oct 2021 21:58:08 -0400 (EDT)
Vladimir Dergachev  пишет:

>* My understanding from reading documentation and source code is
> that there is no dedicated support in R yet, but there are packages
> that use multithreading. Are there any plans for multithreading
> support in future R versions ?

Shared memory multithreading is hard to get right in a memory-safe
language (e.g. R), but there's the parallel package, which is a part of
base R, which offers process-based parallelism and may run your code on
multiple machines at the same time. There's no communication _between_
these machines, though. (But I think there's an MPI package on CRAN.)

>* pthread or openmp ? I am particularly concerned about
> interaction with other packages. I have seen that using pthread and
> openmp libraries simultaneously can result in incorrectly pinned
> threads.

pthreads-based code could be harder to run on Windows (which is a
first-class platform for R, expected to be supported by most packages).
OpenMP should be cross-platform, but Apple compilers are sometimes
lacking; the latest Apple likely has been solved since I've heard about
it. If your problem can be made embarrassingly parallel, you're welcome
to use the parallel package.

>* control of maximum number of threads. One can default to openmp 
> environment variable, but these might vary between openmp
> implementations.

Moreover, CRAN-facing tests aren't allowed to consume more than 200%
CPU, so it's a good idea to leave the number of workers in control of
the user. According to a reference guide I got from openmp.org, OpenMP
implementations are expected to understand omp_set_num_threads() and
the OMP_NUM_THREADS environment variable.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Checking package in Windows fails

[Ivan Krylov]

On Mon, 15 Nov 2021 17:15:14 +0100
Ben Engbers  wrote:

> I don't know why I have to explicitly include 'library("rex")' in
> the code since I have added rex to the Imports in the DESCRIPTION

Have you added the corresponding importFrom(...) [1] commands to your
NAMESPACE file?

> pi <- pingr::is_online()
> va <- grepl(re, input)

> if (pi && va && (get_URL <-httr::GET(input))$status ==200)

Theoretically, this invites a class of errors known as "time-of-check
to time-of-use" [2]: the user may go offline after the
pingr::is_online() check but before the httr::GET() request uses the
remote resource. But that's not what's causing you problems.

The problem here is that pingr's definition of "is online" differs from
"is able to fetch the URL you're testing", and I'm afraid it's
impossible to solve in the general sense. What you could do instead is
use tryCatch() to handle the error originating from curl and return
something else instead.

Or maybe letting the error propagate is the right idea. It may be bad
for reproducibility when a function silently returns something
completely different after the user goes offline. Then you would have
to handle the error in your tests instead of the function. A simple
option is wrapping the whole block of test code in try(), but that would
handle all errors, including real bugs.

A more complicated solution would be to handle the connection errors
specifically, construct error objects of class "connection_error",
signal them from the function and only handle those when testing via
tryCatch(..., connection_error = ...). This would let you both (1)
correctly propagate connection errors to the user instead of silently
returning the URL itself and (2) not crash the tests despite that.
See ?conditions for more information on that topic.

-- 
Best regards,
Ivan

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

[2] https://en.wikipedia.org/wiki/TOCTOU

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

Re: [R-pkg-devel] Checking package in Windows fails

[Ivan Krylov]

On Wed, 17 Nov 2021 00:20:44 +0100
Ben Engbers  wrote:

> I don't edit the NAMESPACE file by hand. It is created by roxygen2.

Right. In that case, use an @importFrom tag:
https://roxygen2.r-lib.org/articles/namespace.html#imports

-- 
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 submission error when running tests in testthat

[Ivan Krylov]

On Wed, 24 Nov 2021 16:37:44 + (UTC)
Nathan Green via R-package-devel  wrote:

> An irrecoverable exception occurred. R is aborting now ...

It seems that some of your dependencies which use compiled code
manage to crash the R process on CRAN Mac machines. Since testthat
normally hides most output from you and it doesn't get a chance to
produce useful output on R process crash, it's hard to determine where
the crash occurs, especially with testthat's backtrace being so long.

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

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

-- 
Best regards,
Ivan

[*]
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories

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

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

[Ivan Krylov]

On Thu, 25 Nov 2021 12:33:01 +0100
Gábor Csárdi  wrote:

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

Indeed you're right, R CMD check truncating the output is the main
problem here. With a full traceback, it would at least be possible to
see which dependency crashes R on CRAN Macs. I should have been more
clear in my e-mail.

By "testthat hiding output" I mean that there's no *.Rout[.fail] files
for every file in tests/testthat/*.R with line-by-line output of the
test code. In cases when R itself crashes in the middle of the test run,
these *.Rout.fail files could be useful to find out which line caused
the crash. With testthat, crashing the R process during tests results
in a single testthat.Rout.fail:

> > library(testthat)
> > library(package_name)
...
> > test_check("package_name")
> 
>  *** caught segfault ***
> address (nil), cause 'memory not mapped'
> 
> Traceback:
>  1: .C("foo")
>  2: eval(code, test_env)
...
> 23: test_dir("testthat", package = package, reporter = reporter, ..., 
> load_package = "installed")
> 24: test_check("package_name")
> An irrecoverable exception occurred. R is aborting now ...

Here, the traceback makes the answer obvious, but it's not always so.
With serious heap corruption, it's possible to get just:

> > test_check("package_name")
> free(): invalid pointer
> Aborted

With no indication of the call or the file causing the crash.

You are right that this is not the main problem here: if the test
output wasn't truncated by R CMD check, we would know the origin of the
crash, even without testthat.

-- 
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 find source of devtool::check() warnings in R code

[Ivan Krylov]

On Thu, 9 Dec 2021 11:10:36 -0500
Steve Gutreuter  wrote:

>   Warning: replacing previous import ‘pROC::cov’ by ‘stats::cov’ 
> when loading ‘screenr’
>   Warning: replacing previous import ‘pROC::var’ by ‘stats::var’ 
> when loading ‘screenr’
>   Warning: replacing previous import ‘pROC::smooth’ by 
> ‘stats::smooth’ when loading ‘screenr’

Could the reason be that you depend on lme4 (and import all of it)
while it Depends: on stats, causing it to be attached [1] when your
package imports it?

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies

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

Re: [R-pkg-devel] Different behavior from devtools::check and install.packages() under Linux and Windows

[Ivan Krylov]

On Tue, 14 Dec 2021 08:48:23 -0500
Steve Gutreuter  wrote:

> Error in set_makevars(.new, .path, makevars_file, assignment = 
> .assignment) :
>    Multiple results for CXX11FLAGS found, something is wrong.FALSE

set_makevars is a function from the "withr" package:
https://github.com/r-lib/withr/blob/main/R/makevars.R

This could be a bug in devtools or one of its dependencies. Try
producing a traceback() and contacting the respective package
developers. Does a simple R CMD check work for 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] Possible bug report/false positive

[Ivan Krylov]

On Wed, 5 Jan 2022 17:15:20 -0300
Igor L  wrote:

>   Found the platform-specific device:
>'X11'

> how to solve it?

One of the tricks that work (in the sense that calls to functions using
non-standard evaluation don't result in warnings about "Undefined
global functions or variables") is to declare the variables locally,
inside the function:

protocolo <- X1 <- X2 <- ... X21 <- NULL
var <- readr::read_csv2(...) ...

Alternatively, since you know that the file always has 21 columns,
you can pass the variable to `colnames<-` instead of dplyr::rename,
together with a vector of column names you already have in the
nomes.colunas vector. This way, you won't need to declare the 21 dummy
variable.

By the way, you shouldn't declare at least download.file and unzip
functions as global variables. Instead, import them from the utils
package in your NAMESPACE (or using the @importFrom Roxygen tag, if you
use Roxygen).

There are other ways the package code could be improved:

 - There doesn't seem to be a need for the dynamically-named variable
   you create using assign(paste0('pedidos', i), var) and remove soon
   after; you can just use `var` instead of get(paste0('pedidos', i)).
 - If you're worried about leaving temporary variables around, move
   the loop body into a separate function so that anything you don't
   return from it would be cleaned up automatically.
 - You can future-proof your package by creating the URLs with
   
paste0('https://dadosabertos-download.cgu.gov.br/FalaBR/Arquivos_FalaBR_Filtrado/Arquivos_csv_',
   year, '.zip') instead of hard-coding their list. It seems likely to
   me that once the 2022 Right to Information Law report is available,
   it'll have a predictable URL. If not, then you'll update the
   package (as you were going to anyway).
 - If you need to iterate over indices in a vector, use for (idx in
   seq_along(vector)) instead of for (i in vector) and match() to
   find the index. Though in this case, the code can be modified to
   avoid the need for the index in the loop body.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] should I increase the version number when resubmitting a package that failed incoming tests?

[Ivan Krylov]

On Thu, 17 Feb 2022 20:53:50 +
Daniel Kelley  wrote:

> My question is: should I retain the same version number, or should I
> bump the number?

CRAN policy currently says:

"Increasing the version number at each submission reduces confusion so
is preferred even when a previous submission was not accepted."



I don't think you'd be penalised for incrementing a version, anyway,
and there doesn't seem to be a formal cool-down period for
resubmissions. It's reasonable to reupload once you're confident you've
addressed 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] table lacks "summary" attribute

[Ivan Krylov]

On Sat, 5 Mar 2022 16:54:08 -0800
alexios galanos  wrote:

> * checking HTML version of manual ... NOTE
> Found the following problems:
> DCCfilter-class.Rd:7:1: Warning:  lacks "summary" attribute
> 
> Any pointers/documentation on this?

This seems to be the new check for HTML documentation validity as part
of accessibility enhancements in R. As far as I'm aware, HTML5 doesn't
_require_ tables to have summaries, nor does Rd provide a way to
specify them. This could be a bug in Tidy-html5, except it's been
apparently fixed in 2016: https://github.com/htacg/tidy-html5/issues/377

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] What is best practice for handling false negatives on CRAN submission tests?

[Ivan Krylov]

On Sat, 19 Mar 2022 12:14:30 +
Daniel Kelley  wrote:

> Would I be sensible to wait a couple of weeks for a reply?

I agree with Duncan, I'd wait for days, not weeks.

> I ask because the schedule would have oce being auto-removed from
> CRAN early next month, and I worry a bit about that happening because
> of an email that went missing, or because I was unclear on how to
> communicate with CRAN.

>From your description, I think you're doing everything right. I've seen
individual reviewers reject a package after a review by mistake (during
a heroic struggle against a ~100-package long "newbies" queue), but not
the automated system.

The pressure is real, I hope you manage to resolve the problems on time!

> Anyway, the email I got back from CRAN told me that oce-1.7.2 had
> failed initial tests.  However, the email makes it seem that those
> tests had actually been passed.

> package oce_1.7-2.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> Windows:
> 
> Status: OK

> Debian:
> 
> Status: OK

This does seem like it shouldn't be have auto-rejected the package,
though if I go take a look at the installation logs, I see compiler
warnings:

https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_20220317_190259/Debian/00install.out

"Variable set but not used" is mostly harmless, but should be easy to
fix, likely by removing said variable.

https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_20220317_190259/Windows/00install.out

"Comparison of integer expressions of different signedness: 'unsigned
int' and 'long int'" could be more serious in corner cases (files
of size > 2G). Typically, the variable being compared to ftell() should
be defined as the same type as the return value of ftell().

Unfortunately, I don't know whether these were the reason for rejection.

> Last released version's CRAN status: OK: 3, NOTE: 6, WARNING: 1,
> ERROR: 3

This is also normal, especially if you explained that you fixed the
previously failing tests in the submission comment.

> Best regards,
> CRAN teams' auto-check service
> Flavor: r-devel-windows-x86_64
> Check: CRAN incoming feasibility, Result: NA
> Maintainer: 'Dan Kelley '

Hmm, where does this come from? The NA result looks ominous.
 
> Flavor: r-devel-windows-x86_64
> Check: Overall checktime, Result: NOTE
> Overall checktime 14 min > 10 min

Is this from the reverse dependency check? Does this mean it needs to
take less 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] handling of byte-order-mark on r-devel-linux-x86_64-debian-clang machine

[Ivan Krylov]

On Tue, 5 Apr 2022 20:20:37 +0200
Tomas Kalibera  wrote:

> I've rewritten the paragraphs, biasing towards users who have UTF-8
> as the native encoding as this is going to be the majority.

Thank you!

> But the level of detail I think needs to remain as long as these
> features are supported - the level of detail is based on numerous
> questions and bug reports.

Of course, all these features have their use cases and it's important
to stay backwards compatible, including the documentation.

I would also like to apologise to Dan for leading him on a wild goose
chase that didn't bring him passing read.csv-related tests in the end.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Two problems with fda

[Ivan Krylov]

On Mon, 25 Apr 2022 15:06:28 -0500
Spencer Graves  wrote:

> GitHub action reports, <<'"pdflatex"' not found>> with 
> vignettes.

No personal experience with GitHub Actions, but have you tried
following the advice by Gábor Csárdi from a few days ago?

https://stat.ethz.ch/pipermail/r-package-devel/2022q2/007970.html

You probably need to declare that your workflow needs tinytex installed
(as described at
),
but if you get different advice from more experienced people, follow
that first.

> (1.2) We don't  know what in the vignettes require pdflatex, so we
> cannot easily remove that.

This line sets the output format of the vignette to PDF:

https://github.com/JamesRamsay5/fda/blob/master/vignettes/monotoneFunctions.Rmd#L5

> "fRegress.Rd:325:22: Warning: nested emphasis "

This is a new check, which runs HTML Tidy on the HTML version of the
manual. If you install HTML Tidy on your local machine and a recent
enough version of R (R-4.2 is good enough, and so was R-devel for a few
weeks), you'll get the same check on your local machine, too.

> (2.1) We cannot find any "nested emphasis" to fix in this.
> (2.2) We don't know what the numbers "325:22" mean.

Row and column number in the HTML file, I beleive. Use R CMD Rdconv to
produce an HTML file from man/fRegress.Rd, or use help(fRegress, help =
'html') to see it. If I check the HTML documentation on my machine, my
HTML file ends up slightly different, and the error is found on line
313 instead:

The fRegress fit object
case:

A code tag is apparently not allowed inside another code tag. I guess
this means that \code{} is not allowed inside \item{} any more, since
the original source line for that is:

\item{The \code{fRegress} fit object case:}

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Issue with HTML version of manual

[Ivan Krylov]

В Thu, 28 Apr 2022 03:59:01 -0700
Arkajyoti Saha  пишет:

> Please let me know if this attachment works,

It worked for me, but didn't work for anyone else: R-package-devel
strips out most kinds of attachments. Is this the same file?
https://github.com/ArkajyotiSaha/RandomForestsGLS/blob/main/man/RFGLS_predict.Rd

It looks like Tidy-HTML5 disagrees with tools::toHTML/tools::Rd2HTML
about validity of some attributes: according to the HTML5 standard (e.g.
), these
HTML element attributes must be replaced by CSS properties now.

I think that tools::toHTML/tools::Rd2HTML will have to be changed to
silence these warnings. Nothing you could fix on your end.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] moving from C to C++ with Rcpp in R package

[Ivan Krylov]

В Thu, 2 Jun 2022 15:06:44 +0200
THIOULOUSE JEAN  пишет:

> "object '_ade4_RVrandtestCpp' not found").

> static const R_CallMethodDef CallEntries[] = {
> {"_ade4_RVrandtestCpp", (DL_FUNC) &_ade4_RVrandtestCpp, 3},
> {NULL, NULL, 0}
> };

Almost there. Since you're using the fixes = 'C_' argument to
useDynLib, you need to .Call() the variable called C__ade4_RVrandtestCpp
in your R code, not _ade4_RVrandtestCpp.

You can verify the symbol name by installing the package and searching
for it in the package namespace:

grep(
 'rv.*randtest', ls(loadNamespace('ade4'), all = TRUE),
 ignore.case = TRUE, value = TRUE
)

Unfortunately, this means editing RcppExports.R, which (I think)
prevents you from enjoying the way Rcpp::compileAttributes() sets
everything up for 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] Warning: attribute "width" not allowed for HTML5

[Ivan Krylov]

On Tue, 14 Jun 2022 12:56:27 -0500
Spencer Graves  wrote:

> Warning:  escaping malformed URI reference

This part is actually important. If you look at the generated HTML for
nuclearWeaponStates.Rd, you can see that Tidy complains about the
following link:

https://www.americansecurityproject.org/ASP%20Reports/Ref%200072%20-%20North%20Korea’s%20Nuclear%20Program%20.pdf

The Unicode apostrophe, "’", should be properly URL-encoded, just like
the spaces. I think that the appropriate encoding for it would be:

https://www.americansecurityproject.org/ASP%20Reports/Ref%200072%20-%20North%20Korea%E2%80%99s%20Nuclear%20Program%20.pdf

As pointed out by others, the  stuff is generated by R and can't
be helped for 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] URL checks

[Ivan Krylov]

On Thu, 30 Jun 2022 10:00:53 +1000
Greg Hunt  wrote:

> With a little more experimenting, the 503 response from the wiley DOI
> lookup does seem to come from CloudFlare, there is a "server:
> cloudflare" header.

Unfortunately, CloudFlare also returns the 503 status code with the
"server: cloudflare" header in case of connectivity issues between
CloudFlare and the upstream server:
https://support.cloudflare.com/hc/en-us/articles/115003011431/#503error

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] URL checks

[Ivan Krylov]

Greg,

I realise you are trying to solve the problem and I thank you for
trying to make the URL checks better for everyone. I probably sound
defeatist in my e-mails; sorry about that.

On Thu, 30 Jun 2022 17:49:49 +1000
Greg Hunt  wrote:

> Do you have evidence that even without the use of HEAD that
> CloudFlare is rejecting the CRAN checks?

Unfortunately, yes, I think it's possible:

$ curl -v 
https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages
# ...skipping TLS logs...
> GET /hc/en-us/articles/219949047-Installing-older-versions-of-packages HTTP/2 
> Host: support.rstudio.com
> User-Agent: curl/7.64.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 403
< date: Thu, 30 Jun 2022 08:13:01 GMT

CloudFlare blocks are probabilistic. I *think* the reason I got a 403
is because I didn't visit the page with my browser first. Switching
from HEAD to GET might also increase the traffic flow, leading to more
blocks from hosts not previously blocking the HEAD requests.

CloudFlare's suggested solution would be Private Access Tokens [*], but
that looks hard to implement (who would agree to sign those tokens?)
and leaves other CDNs.

> The CDN rejecting requests or flagging the service as temporarily
> unavailable when there is a communication failure with its upstream
> server is much the same behaviour that you would expect to see from
> the usual kinds of protection that you'd apply to a web server (some
> kind of filter/proxy/firewall) even without a CDN in place.

My point was different. If the upstream is actually down, the page
can't be served even to "valid" users, and the 503 error from
CloudFlare should fail the URL check. On the other hand, if the 503
error is due to the check tripping a bot detector, it could be
reasonable to give that page a free pass.

How can we distinguish those two situations? Could CloudFlare ask for a
CAPTCHA first, then realise that the upstream is down and return
another 503?

Yes, this is a sensitivity vs specificity question, and we can trade
some false positives (that we get now) for some false negatives
(letting a legitimate error status from a CDN pass the test) to make
life easier for package maintainers. Your suggestions are a step in the
right direction, but there has to be a way to make them less fragile.

-- 
Best regards,
Ivan

[*]
https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/

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

Re: [R-pkg-devel] Warning... unable to translate 'Ekstrm' to a wide string; Error... input string 1 is invalid

[Ivan Krylov]

On Tue, 19 Jul 2022 12:32:20 -0500
Spencer Graves  wrote:

> Can someone provide me with a link to the correct development 
> version of help('iconv')?  The current version includes the exact 
> offending "\x" strings that I have.  

http://svn.r-project.org/R/trunk/src/library/base/man/iconv.Rd

It still does, because it works with byte strings the right way: by
passing them to iconv(), which is designed to work with bytes in
"unknown" encodings.

In contrast, your use of arbitrary bytes with gsub() is invalid,
because gsub() assumes that the strings match their declared encoding:
UTF-8, Latin-1, or the native locale encoding. (See ?Encoding.)

When you write "Ekstr\xf8m", you get a string that consists of Latin-1
bytes but has the wrong encoding property set. Given this string,
gsub() and friends will break on a UTF-8 system (because "r\xf8m" is
not a valid UTF-8 sequence of bytes), while iconv() will not.

Depending on the desired semantics of subNonStandardCharacters(), you
might be able to avoid the failures with the useBytes argument, or you
might silently return invalid data in some corner cases. Is the "x"
argument supposed to be bytes in arbitrary encoding, or properly decoded
characters that might include those that don't map to ASCII?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Misspelled words in descrition and tar.gz inside folder

[Ivan Krylov]

On Tue, 9 Aug 2022 13:38:33 -0700
Edward Wei  wrote:

> 1. My misspelled words are just referencing names of packages and
> programming terms etc. Is there a way to get around this or should I
> omit them from my description and put them somewhere else.

If you can, mention them in the comments to the CRAN submission.

> 2. I wanted to confirm this, but the tar.gz for CRAN submission
> SHOULD NOT be in the folder of the directory for my package.

Check your R CMD build process. There seemed to have been an
avfintools.tar.gz file in the package directory at the time when you
were preparing the package tarball. If you prefer to build the package
in the current directory (i.e. by running R CMD build .) or otherwise
need that file there, use .Rbuildignore to prevent it from ending up
inside the tarball. For example, you can put \.tar\.gz$ on a line there
to skip all files with names ending with .tar.gz.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] No package called 'scales' (r-oldrel-windows)

[Ivan Krylov]

В Tue, 23 Aug 2022 12:39:33 -0500
Paul Hibbing  пишет:

> It has errored for r-oldrel-windows with "there is no package called
> 'scales'" (see
> https://www.r-project.org/nosvn/R.check/r-oldrel-windows-ix86+x86_64/PAutilities-00install.html).

I think it's a hiccup on the testing machine. There doesn't seem to be
anything you would be able to fix on your side: you correctly declare
PAutilities to depend on the "scales" package, and yet the machine
running the test doesn't have it installed.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error checking in an independent C code and printing (perror, printf, etc.)

[Ivan Krylov]

Hello Jiří and welcome to the mailing list!

On Tue, 6 Sep 2022 14:48:02 +1200
"Jiří Moravec"  wrote:

> That brings me to a problem: How to do error handling in C without
> the use of various <...> R-specific print functions?

(Assuming that's what you meant...)

One way would be to introduce callbacks from the R-independent part to
the R-interfacing part, but I can imagine this to require tedious
boilerplate. Also, many of R's entry points can raise an error
condition (e.g. if an allocation fails), which would result in a
longjmp() away from your code. Any resource not known to R's garbage
collector is going to be leaked in this situation.

I think you're actually allowed to format strings using sprintf and
friends; only actual printing to stdout/stderr is disallowed because
the user may be using e.g. Rgui on Windows and not see it at all. If
you need to print error messages, you can pass them to the R side as
strings, probably in storage allocated by the caller to avoid leaks on
errors. Error codes are of course an option too, but can be less
informative if not accompanied by an explanation of what went wrong.

(It's considered polite for package code to use R's message system not
only because of the stdout/Rgui problem mentioned above, but also
because it gives the user an option to run your code with
suppressMessages() and disable the verbose output. When the R code
directly calls cat() or the C code prints directly to console, that
option disappears.)

To summarise, R would accept any option where only R is interacting
with the user (or doing other I/O). If neither of this is satisfying,
can you provide a bit more details on the kind of error handling you're
looking for?
 
> This is my first time writing into mailing list, hopefully I am doing 
> everything ok.

Indeed you are!

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Examples taking too long depend on object that takes a while to generate

[Ivan Krylov]

On Wed, 14 Sep 2022 12:31:49 -0400
Duncan Murdoch  wrote:

> It's also possible to put .R files in the data directory, and they
> are executed to create the data object.  I think that happens at the
> time when you call data() rather than at install time, so it might
> not be helpful.

Some time ago I was hoping to compress a package of mine by generating a
dataset during a data() call instead loading it from an .rda file, but
it turned out that the .R file is executed during R CMD build:
https://github.com/r-devel/r-svn/blob/03df313ad37456c6a62158328d4e373408ce4d59/src/library/tools/R/build.R#L794

-- 
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 - how to replicate the error

[Ivan Krylov]

On Tue, 20 Sep 2022 03:28:09 +
"Zhang, Xueqiong"  wrote:

> I don’t have a linux box, and was not able to check it via
> r-hub-linux-platforms since some of bioc dependencies are not
> installed on r-hub. What should I do for the error check, any ideas?

There are Debian builds for both x86_64 and arm64, so it should be
possible to set up a virtual machine on your Mac that would be
relatively quick thanks to hardware virtualisation. For example, you
could start with a Dockerfile for an R-hub builder [1], add the missing
Bioconductor packages and try to reproduce the error there.

This way lies a lot of work, though. Worst case scenario, after you're
done setting up the virtual machine, the test may pass.

> I am thinking error from debian was caused by tempdir()? this is the
> code of how I created the temp folder  fd_out =
> as.character(paste0(tempdir(), "/", "outputs", "/")) . The error will
> go away if I change the code to fd_out = tempdir()?

Doesn't look likely to me. True, you could use file.path(tempdir(),
'outputs') instead of paste0(...), but that shouldn't cause any
differences between two POSIX-compatible systems that both use a
forward slash as a directory separator.

An error due to file paths would look like "file not found", or tests
for file paths being equivalent failing due to a spurious slash or
something. Your error looks different:

> Error in `select(., -c(id, seq_num))`: Can't subset columns that
> don't exist.
> x Column `id` doesn't exist.

Try instrumenting your tests to produce more output around that line?
(Not sure how to do that with testthat.) Since we don't see the code,
we can't say much else. Where does that data.frame come from? What
could be the reasons for it to miss an "id" column? Does seq_num exist
there too?

> Also, tempdir() is something like this
> "/var/folders/_p/vkt5cmsn2559zqnyhpdwnnsrgn/T//RtmpUHe1uR" .  I
> wonder if the double slashes doesn’t recognized by linux?

No, that's not the problem. POSIX allows an operating system to treat a
double slash in the beginning of a path specially, but on Linux,
multiple slashes anywhere are equivalent to a single slash:

cd usr///bin && pwd
# /usr/bin

-- 
Best regards,
Ivan

[1] https://github.com/r-hub/rhub-linux-builders

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

Re: [R-pkg-devel] Help - Shiny app on CRAN

[Ivan Krylov]

В Mon, 26 Sep 2022 19:14:04 +0400
"Jahajeeah, Havisha"  пишет:

> * checking extension type ... ERROR
> Extensions with Type 'Shiny application' cannot be checked.

Since you're writing a package, you can either specify Type: Package in
the DESCRIPTION file, or omit the field entirely:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-types

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Unable to create manual

[Ivan Krylov]

On Mon, 26 Sep 2022 10:50:01 -0700
Edward Wei  wrote:

> 1. Where do I run "make check"?

In the directory where R is built from source. If you're using a binary
build of R, this isn't applicable.

> 3. I get this back when I run the "tools::testInstalledPackages(scope
> = "base")" on my RGUI.
> 
> Error: testing 'utils' failed
> 
> Where may I find the error log for this?

testInstalledPackages() creates output files in the current directory.
Does list.files(pattern = 'utils|Rout\\.fail') give you anything useful?

-- 
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 - Shiny app on CRAN

[Ivan Krylov]

It might be easier to help you if you show us your package by
publishing the source code somewhere.

On Mon, 26 Sep 2022 22:22:48 +0400
"Jahajeeah, Havisha"  wrote:

> CIvalue2: no visible global function definition for 'qt'
> andgm11: no visible binding for global variable 'ParticleSwarm'
> andgm11: no visible global function definition for 'tail'
> app: no visible global function definition for 'shinyApp'
> dbgm12: no visible binding for global variable 'ParticleSwarm'

It sounds like your NAMESPACE file isn't properly set up to import the
functions you're using. For the package to work correctly, it should
contain lines

importFrom(stats, qt)
importFrom(utils, tail)
importFrom(shiny, shinyApp)

and so on for every function you use that's not in base.

See Writing R Extensions section 1.5:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Specifying-imports-and-exports

> Objects in \usage without \alias in documentation object 'Plots':
>   'plots'

A single Rd file can describe multiple functions, but they should be
both mentioned in the \usage{} section and as an \alias{}. Do you
export two different objects (functions?) named "plots" and "Plots", or
is one of those an error?

> Bad \usage lines found in documentation object 'BackgroundValues':
>   gm11(x0), epgm11(x0), tbgm11(x0), igm11(x0), gm114(x0)

The \usage{} section must exactly match the definition of the function
(but you can omit default values of the arguments if they're too large
and not very informative), without any other words or punctuation.

Once your package passes the automated tests, a human volunteer will go
over your package to make sure that it fits the CRAN policy (not
providing a link because you've already read it when you submitted the
package), which includes having good documentation for every function
you export.

See Writing R Extensions section 2 for more information on this:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-R-documentation-files

I've also noticed that you're showing us an error message from the CRAN
pre-test infrastructure. You can get these errors (and start fixing
them) faster without spending time waiting for the test result by
running R CMD check --as-cran your_package.tar.gz on your own 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] How to decrease time to import files in xlsx format?

[Ivan Krylov]

On Tue, 4 Oct 2022 15:29:54 -0300
Igor L  wrote:

> The problem is that importing files in xlsx format is time consuming.

Do the openxlsx or XLConnect packages fare any better?

> plan(strategy = future::multicore(workers = 4))

As far as I understand the documentation, multicore only works on
POSIX-compatible operating systems when not running under RStudio (and
even then, some macOS APIs may be not fork()-safe). Which operating
system are you running? Does it get any better if you use
future::multisession?

Have you tried profiling the code? Do you see it using 100% of one
core in some kind of task manager?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Identify Original Column Names of Model Matrix

[Ivan Krylov]

On Mon, 10 Oct 2022 08:00:04 +
Dario Strbenac  wrote:

> It requires input data to be in one-hot encoding, which is created by
> Matrix::sparse.model.matrix. For further analysis, such as variable
> importance, is there a way to identify which original feature each
> column of a sparse.model.matrix result was derived from?

?Matrix::sparse.model.matrix seems to recommend
MatrixModel::model.Matrix for this reason. The latter function returns
an object with additional slots `assign` and `contrasts`, which should
make it possible to recover the original columns.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Problems with news in ‘NEWS’

[Ivan Krylov]

В Wed, 12 Oct 2022 20:16:20 -0500
Spencer Graves  пишет:

> I copied NEWS to NEWS.md and tried to format it as described in:
> 
> 
> https://r-pkgs.org/other-markdown.html#news
> 
> 
> Sadly, I still get the same error.  It seems to be ignoring
> my NEWS.md file and continuing to tell me I haven't fixed NEWS.

Does it help to remove the NEWS after you've created NEWS.md in the
root directory of your package? In theory, NEWS.md takes precedence
over everything except inst/NEWS.Rd, but maybe that's not the case when
checking the package.

For the record, both the plain text format R expects in the NEWS file
and the Markdown format for NEWS.md are described in help(news).

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Invalid UTF-8

[Ivan Krylov]

В Mon, 17 Oct 2022 11:07:25 +0200
Göran Broström  пишет:

> warning: invalid UTF-8 in comment [-Winvalid-utf8]
> (It's my name)
> 
> So I wonder: How do I make valid UTF-8 in comment?

The file GB_zeroin.c is saved in Latin-1 encoding. The warning should
go away once you convert it to UTF-8.

-- 
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 package build- C compilation issue related to math.h

[Ivan Krylov]

On Wed, 19 Oct 2022 23:39:57 +0100
Vincent Plagnol  wrote:

> gcc-12 -I"/home/hornik/tmp/R/include" -DNDEBUG   -I/usr/local/include
> -DUSE_TYPE_CHECKING_STRICT -D_FORTIFY_SOURCE=2   -fpic  -g -O2 -Wall
> -Wstrict-prototypes -pedantic -mtune=native  -c VP_gamma.c -o
> VP_gamma.o

> /usr/include/x86_64-linux-gnu/bits/mathcalls.h:85:1: error:
> expected ‘;’ before ‘extern’ 

> It is painful to debug because I don't have a debian machine.
> Furthermore the issue seems to be in the file called at line 22 of
> gsl_math.h which is #include 

For what it's worth, I couldn't reproduce the problem when compiling
VP_gamma.c from https://github.com/vplagnol/ExomeDepth on two of my
Debian machines with older GCC versions; you might actually need GCC 12
to see it.

I see that VP_gamma.c includes config.h before including gsl_math.h.
Typically, config.h should be automatically generated by the configure
script and may contain different definitions on different systems.
Somebody else has a similar problem, also in math.h, also with a file
that includes config.h before math.h:
https://github.com/vplagnol/ExomeDepth/issues/50

I think that config.h defines something in its /* Substitute gsl
functions for missing system functions */ section that confuses the
glibc math.h machinery. If you have to include config.h in a source
file, it might help to process the system headers first.

I had a related problem recently: MinGW was complaining about a
strftime call in bundled code that wasn't reachable from R anyway, so I
decided to patch it out using the preprocessor. The correct way to do
so is to #include the system header first, then re-#define the function
to nothing:
https://github.com/aitap/Ropj/commit/a7d6cec19d11d47d731fbadbf8735660e534efaa

Otherwise the re-definition affects the system header where the
function is declared and the result is syntactically invalid.

>   [[alternative HTML version deleted]]

Sorry, the mailing list ate the HTML version of your e-mail, and the
plain text version automatically prepared by your mailer is not easy to
read: https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008578.html

Please post in plain text.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How ton print in the console from Rcpp

[Ivan Krylov]

В Thu, 20 Oct 2022 12:43:30 +0200
Elysée Aristide  пишет:

> What I understood is that it is better to use Rcpp functions. So I
> used:
> 
> Rcpp::Rcout << "beta: \n";
> Rcpp::print(betacpp);
> Rcpp::Rcout << "log-likelihood: " << llh << "\n";

This seems to be a right way of printing from Rcpp code.

> checking compiled code ... WARNING
> File ‘CDatanet/libs/CDatanet.so’:
>   Found ‘___assert_rtn’, possibly from ‘assert’ (C)
> Objects: ‘CDincomInfo.o’, ‘CDincomInfo.rho.o’, ‘Homophily.o’,
>   ‘RcppExports.o’, ‘SARTIncomplet.o’

Since you don't call assert() yourself (which, in theory, shouldn't
matter as R packages are compiled with #define NDEBUG), it must be one
of the C++ template classes you're using. They may contain calls to
assert() or an equivalent, which get inlined inside your binary during
compilation. It might be even inside the implementation of the C++
standard library, which would be completely outside your control.

I'm not sure, but it could be possible to explain this situation to
CRAN as a false-positive. In order to find out further, you'll need
someone with a macOS computer or experience in cross-platform
development to either disassemble the existing binary or take the
compilation pipeline apart in order to find out where the calls to
___assert_rtn originate.

-- 
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 issue on CRAN: Package pdftex.def Error

[Ivan Krylov]

В Sun, 30 Oct 2022 14:48:05 +0100
r...@nbenn.ch пишет:

> It seems like when building the PDF manual, an image that should be
> included is not found and then things fall apart, causing both the
> error and note. For all I know, the image should be there unter
> `man/figures/`.

Is it the following change?

https://github.com/eth-mds/ricu/commit/b4ac31a2cc22da236e56ce9875b2d799ae172d46

The updated Rd file now says "\figure{man/figures/sofa-sep-3-1.png}".
According to WRE 2.7, paths to the figures should be specified relative
to man/figures. In other words, in order to reference
man/figures/sofa-sep-3-1.png, use \figure{sofa-sep-3-1.png}.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Best way to restore an archived CRAN package

[Ivan Krylov]

В Sun, 30 Oct 2022 16:56:03 +0900
"Stefan Angrick"  пишет:

> Writing code to digest the new data format is straightforward, so I'd
> like to bring the package back. Unfortunately I'm unable to reach the
> original author, so I'm unsure how to proceed.
> 
> Does CRAN allow for people other than the original author to bring
> back a package?

According to the CRAN policy [*], it should be possible to submit the
fixed package under the original name with an explanation that the
previous maintainer is unavailable:

>> Explain any change in the maintainer’s email address and if possible
>> send confirmation from the previous address (by a separate email to
>> cran-submissi...@r-project.org) or explain why it is not possible.

Disclaimer: I've never done this myself.

For the record, the author's GitHub and Twitter accounts are trivial to
find; there is a bit of activity in the former (only once in 2022), and
the last update in the latter was in 2020.

> In either case, how would the original package author be acknowledged?

Make sure to mention Eric Persson in the Authors: field of the
DESCRIPTION file as a full author, but not the maintainer.

You will also need to make sure that the examples never crash, even if
there's no connection to the Internet, which may have been part of the
original reason the package had been archived.

-- 
Best regards,
Ivan

[*] 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] Examples with CPU time is greater than elapsed time.

[Ivan Krylov]

On Sat, 5 Nov 2022 22:41:45 +0800
Jiaming Yuan  wrote:

>Examples with CPU time > 2.5 times elapsed time

> I'm wondering what the note is trying to tell me and how can I
> resolve it with confidence.

Henrik Bengtsson already gave a good explanation of the problem.

Not sure what exactly is the right thing to do, but one way to get rid
of this warning could be to pass the argument nthread =
min(parallel::detectCores(), 2) to the xgb.cv invocation (if you
already use the parallel package anywhere) or maybe to hard-code the
use of only one thread in the example.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Ivan Krylov]

В Mon, 7 Nov 2022 12:30:35 +0400
"Jahajeeah, Havisha"  пишет:

> After loading the package on CRAN, when I try to upload file (xlsx or
> xls) the following error appears:
> 
> Error: cannot open the connection

Do you mean uploading files into your Shiny application, or somewhere
else?

Have you tried following this guide?
https://shiny.rstudio.com/articles/debugging.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] Error uploading file on CRAN

[Ivan Krylov]

В Mon, 7 Nov 2022 14:55:06 +0400
"Jahajeeah, Havisha"  пишет:

> The Greymodels package loads data from spreadsheets and each model
> accepts a set of data and outputs the  values. However, the package
> is unable to do that because of the error: cannot open connection.

Thank you for clarifying the problem!

The guide at https://shiny.rstudio.com/articles/debugging.html is full
of useful things to try when a Shiny app is misbehaving. I could try to
write an instruction for you to follow here, but it would end up being
a paraphrase of this guide. If you follow the guide, you should be able
to find out (1) which of your read_excel calls is failing, (2) what is
its argument and (3) what actually ends up at that path at the time of
the call. Once you know this information, the solution may become
obvious, or at least there may be something for us to give you more
pointers about.

While there is a chance that someone else will come along, run your
package on their machine and reproduce the problem, there's also a
significant chance that no one will do that. Meanwhile, these steps are
relatively simple and may help you solve the problem right away.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] vignettes - size of pdf

[Ivan Krylov]

В Fri, 11 Nov 2022 12:54:52 +
"Grose, Daniel"  пишет:

> * checking sizes of PDF files under 'inst/doc' ... WARNING
>   'gs+qpdf' made some significant size reductions:
>  compacted 'cpop.pdf' from 805Kb to 547Kb
>   consider running tools::compactPDF(gs_quality = "ebook") on these
> files
> 
> I do not understand how I can do this given that the pdf is produced
> when installing the package. Any ideas ?

I think that the PDF file is built during R CMD build, not (only) R CMD
INSTALL. At the very least, the source package currently on CRAN
contains both the *.pdf and the *.ltx files under inst/doc:
https://github.com/cran/cpop/tree/master/inst/doc

Does it help to pass the --compact-vignettes=gs+qpdf argument to R CMD
build? It seems to be off by default.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How ton print in the console from Rcpp

[Ivan Krylov]

В Sun, 13 Nov 2022 11:29:21 +
Elysée Aristide  пишет:

> The only difference I saw is that all those packages put
> 
> #define NDEBUG
> 
> after #include .
> I did the same thing without understanding :)

Glad you got it working! If you're curious why it helped, see
.

I wouldn't have guessed this to be the problem, because I "knew" that R
CMD INSTALL defines NDEBUG during compilation in order to prevent
assert() from crashing the process. Indeed, it's easy to verify that
RcppArmadillo removes the NDEBUG preprocessor symbol:

https://github.com/RcppCore/RcppArmadillo/search?q=NDEBUG&type=code

Seeing the search results, I can't help but wonder whether Armadillo
still makes any decisions based on this preprocessor definition,
though. Is the whole of Armadillo included as part of the package?
Shouldn't there be other mentions of NDEBUG besides the "#undef NDEBUG"
and the package changelog?

I don't see NDEBUG mentioned in the Armadillo source repo, either:
https://gitlab.com/search?search=NDEBUG&nav_source=navbar&project_id=6604173&search_code=true&repository_ref=11.4.x

Could the #undef NDEBUG line be safely removed now without affecting
the debugging tests performed by Armadillo?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Too many processes spawned on Windows and Debian, although only 2 cores should be used

[Ivan Krylov]

В Wed, 16 Nov 2022 07:29:25 +0100
Riko Kelter  пишет:

> if (nzchar(chk) && chk == "TRUE") {
>  # use 2 cores in CRAN/Travis/AppVeyor
>  num_workers <- 2L
> }

The check in parallel:::.check_ncores is a bit different:

chk <- tolower(Sys.getenv("_R_CHECK_LIMIT_CORES_", ""))
if (nzchar(chk) && (chk != "false")) # then limit the workers

Unless you actually set _R_CHECK_LIMIT_CORES_=FALSE on your machine
when running the checks, I would perform a more pessimistic check of
nzchar(chk) (without additionally checking whether it's TRUE or not
FALSE), though copy-pasting the check from parallel:::.check_ncores
should also work.

Can we see the rest of the vignette? Perhaps the problem is not with
the check. For example, a piece of code might be implicitly spawning a
new cluster, defaulting to all of the cores instead of num_workers.

>   [[alternative HTML version deleted]]

Unfortunately, the plain text version of your message prepared by your
mailer has all the code samples mangled:
https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008647.html

Please compose your messages to R mailing lists in plain text.

-- 
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 to remove/archive package from CRAN

[Ivan Krylov]

В Wed, 23 Nov 2022 13:50:01 +
Kopperud  пишет:

> Is it possible to request for a package to be removed/archived from
> CRAN? 

The policy implies it should be possible:

>> Packages will not normally be removed from CRAN: however, they may
>> be archived, including at the maintainer’s request. 

I think you need to contact c...@r-project.org to ask for the archival.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Note on submission Found the following files/directories: 'NUL'

[Ivan Krylov]

В Fri, 25 Nov 2022 09:59:10 +
"ROTOLO, Federico /FR"  пишет:

> When submitting my package parfm, I get the following note
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: for non-standard things in the check directory, Result: NOTE
>   Found the following files/directories:
> 'NUL'
> so that my submission is rejected.
> 
> I cannot find any file or directory called NUL in my package.
> Do you have any suggestion?

The file gets created during the check when you call sink('NUL'):
https://github.com/cran/parfm/blob/8c3f45291514aedde67cecf0b090ddd3487f3ada/R/parfm.R#L260-L299

It mostly works on Windows, where "nul" with any extension in any
directory is the null file, but it creates a file named 'NUL' on other
operating systems. It also breaks the non-default sink, if any was set
up by the user.

Does optimx::optimx produce output that can't be turned off otherwise?
(Does it help to set control$trace = 0?) Have you tried
suppressMessages() or capture.output() with nullfile()?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Note on submission Found the following files/directories: 'NUL'

[Ivan Krylov]

В Fri, 25 Nov 2022 13:10:39 +0300
Ivan Krylov  пишет:

> It also breaks the non-default sink, if any was set up by the user.

That's not correct, I'm sorry. sink() maintains a stack of diversions
and will automatically restore the user-chosen sink(), if any was set
up, when you call sink(NULL).

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Ivan Krylov]

On Sun, 27 Nov 2022 20:29:10 +0400
"Jahajeeah, Havisha"  wrote:

> The Greymodels package has been debugged and the updated package has
> been published on Github.

Congratulations on getting it working!
 
> I would be very much grateful if the app could be updated on CRAN.

Please do it the same way you had uploaded the package initially after
changing the Version: field in the DESCRIPTION file to a higher value.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Missing link or links in documentation object

[Ivan Krylov]

В Mon, 28 Nov 2022 15:34:53 +0100
Ibon Tamayo  пишет:

> \code{\link[R6::R6Class]{R6::R6Class}}

I think you need only one colon in the first argument of
\link[pkg:foo]{bar}:
https://cran.r-project.org/doc/manuals/R-exts.html#Cross_002dreferences

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Logical Inconsistency of check regarding URL?

[Ivan Krylov]

Dear Michael,

On Tue, 29 Nov 2022 08:19:40 +0100
"Dr. habil. Michael Thrun"  wrote:

> URL:  https://www.deepbionics.org (moved to
> https://mthrun.github.io/index)
> From: DESCRIPTION
> Status: 301
> Message: Moved Permanently

> Please change http --> https, add trailing slashes, or follow moved
> content as appropriate. "

The "HTTPS and trailing slashes" part is a red herring. The idea is to
only have URLs in your package that return HTTP code 200.
The website https://www.deepbionics.org redirects to
https://mthrun.github.io/index, which is, strictly speaking, against
the letter of the rules [1]. Websites that redirect from http://... to
https://... and from .../website/path to .../website/path/ (and the
other way around) are a common cause of such redirects, which is why Uwe
mentioned it (I think), but this isn't the reason for the redirection at
https://www.deepbionics.org.

I think you could make the argument that https://www.deepbionics.org is
the canonical URL for the website and the way it _currently_ works (by
returning a 301 redirect to https://mthrun.github.io/index) is an
implementation detail that should be ignored, but I don't know whether
CRAN reviewers would agree. I think it should be possible to set up
your domain and GitHub Pages to serve mthrun.github.io at the address
www.deepbionics.org without a redirection [2], but I've never tried it
myself.

> First, do we not communicate with CRAN anymore through the submission
> procedure of the package? If not, which is the correct line of
> communication in such a case?

There was a case once when the reviewer was mistaken (they were in the
process of heroically clearing out the "newbies" queue that almost
reached 80 packages, aged 10 days and more, all by themselves, so a
certain amount of fatigue was to be expected) and I was able to argue
my way out of a rejection by replying to the reviewer. I think that the
way to go is to either submit a package with requested changes and an
incremented version or to reply-to-all and argue the case for the
package as it is now.
 
> Third, why can I have a CRAN package "DataVisualizations" with this
> URL online, another one named "GeneralizedUmatrix" uploaded the same
> day with the same URL, which both are OK, but the URL in
> "DatabionicSwarm" is not?

Has anything changed recently regarding the way your domain is set up?
It really is strange that the check passed for one of the packages but
not the other.

> Fifth, why do we need https/TLS/SSL?   

I think you're right (see also: depriving an existing website of its
certificate as a means of censorship), but the browser makers may end
up destroying TLS-less workflow for us in a few years. Thankfully, it's
not a requirement of CRAN to have only HTTPS links. I probably
shouldn't continue this topic because the question of "how the Web
should function" tends to result in pointlessly heated debates.

-- 
Best regards,
Ivan

[1] https://cran.r-project.org/web/packages/URL_checks.html

[2]
https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Ivan Krylov]

В Wed, 30 Nov 2022 13:43:21 +0400
"Jahajeeah, Havisha"  пишет:

> but now I am getting the following error:
> 
> An error has occurred!
> 
> Couldn't normalize path in `addResourcePath`, with arguments:
> `prefix` = 'AdminLTE-2.0.6'; `directoryPath` =
> 'D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE'

Thank you for providing the exact error message!

Could you please provide more information on _how_ you're getting the
error? In particular, (1) what do you do (lines of code you execute,
buttons you click and so on) before you get the error and (2) what you
expect to happen instead of the error? See also: a long guide on asking
technical questions [*]. It can be impossible to help with an error
message without the steps required to obtain it.

I can see that your package depends on shinydashboard, but I don't see
any calls to addResourcePath in your code. Is there a traceback you
could show us?

-- 
Best regards,
Ivan

[*] http://www.catb.org/~esr/faqs/smart-questions.html#beprecise

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Ivan Krylov]

В Wed, 30 Nov 2022 14:17:54 +0400
"Jahajeeah, Havisha"  пишет:

> To run the app, we use:
> 
> install.packages("Greymodels")
> library(Greymodels)
> run_app()
> 
> The app worked fine on Monday. Today it is showing error.
> 
> Please see below  traceback()
> 
> 13: execCallbacks(timeoutSecs, all, loop$id)
> 12: run_now(timeoutMs/1000, all = FALSE)
> 11: service(timeout)
> 10: serviceApp()
> 9: ..stacktracefloor..(serviceApp())
> 8: withCallingHandlers(expr, error = doCaptureStack)
> 7: domain$wrapSync(expr)
> 6: promises::with_promise_domain(createStackTracePromiseDomain(),
>expr)
> 5: captureStackTraces({
>while (!.globals$stopped) {
>..stacktracefloor..(serviceApp())
>}
>})
> 4: ..stacktraceoff..(captureStackTraces({
>while (!.globals$stopped) {
>..stacktracefloor..(serviceApp())
>}
>}))
> 3: runApp(x)
> 2: print.shiny.appobj(x)
> 1: (function (x, ...)
>UseMethod("print"))(x)

Thanks!

Does the D:/RCompile/CRANpkg/lib/4.2/shinydashboard/AdminLTE directory
exist? Has someone touched the shinydashboard package installation?
Does it help to remove and install shinydashboard again?

Please keep the R-pkg-devel list in the recipients  when replying (use
"reply to 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] Error uploading file on CRAN

[Ivan Krylov]

В Wed, 30 Nov 2022 16:10:22 +0400
"Jahajeeah, Havisha"  пишет:

> How do I fix this problem? Kindly advise.

I think I know what could be the problem.

Your run_app function calls shiny::shinyApp(ui, server, options =
list(launch.browser = TRUE)). Here, `ui` is an object of class
"shiny.tag". I think that the file paths get cached in the `ui` object
when the binary package is built, and when the package is run on a
different computer, the loading process fails.

Does it work if you run install.packages('Greymodels', type = 'source')?
If this works around the problem, you'll need to change the definition
of `ui` into a function to make sure it runs after the package is
installed: https://github.com/cran/Greymodels/blob/master/R/app_ui.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] Error uploading file on CRAN

[Ivan Krylov]

On Mon, 5 Dec 2022 11:14:19 +0400
"Jahajeeah, Havisha"  wrote:

> Will a binary package resolve the above issue?

Due to an interaction between the way R binary packages work and the
way you have implemented the Greymodels:::ui variable, this binary
package will only work on your computer. (And, well, on other computers
where the library path is the same.) A better workaround would be to
ask your users to install the source package instead of installing the
binary package when one is available for their platform.

The code that creates the `ui` variable in your package is evaluated
when the binary package is built by CRAN (or you). The resulting object
contains file paths that are only valid on CRAN computers (or your
computer). You need that code to run on users' computers after the
package is installed, not on CRAN computers (or your computer) when
it's built. In order to achieve that, you need to change the definition
of the `ui` variable into a function. The function doesn't even have to
take arguments; you can just prepend function() to the right-hand side
of the assignment. Inside the `run_app` function, call that function
instead of referring to that variable. This will make sure that the
temporary object created by `ui()` contains the file paths from the
user's computer.

-- 
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 fails on Debian

[Ivan Krylov]

On Fri, 9 Dec 2022 17:29:21 +
Stephen Coleman  wrote:

> ``outlierComponentFactory.h:37:15: error: ‘unique_ptr’ in namespace
> ‘std’ does not name a template type``.

Does it help to explicitly #include  in
outlierComponentFactory.h in order to provide the definition of the
template class unique_ptr?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Do you run R on Fedora or Debian?

[Ivan Krylov]

On Sat, 10 Dec 2022 14:00:22 -0800
Roy Mendelssohn - NOAA Federal via R-package-devel
 wrote:

> cache_setup(temp_dir = TRUE)

Unfortunately, it prints a path under tempdir() for me on my Debian
oldstable machine.

I see that the error came from the "donttest" check from an extra test
that's not on by default with --as-cran. Unfortunately, not even
running _R_CHECK_DONTTEST_EXAMPLES_=true \
_R_CHECK_THINGS_IN_OTHER_DIRS_=TRUE R CMD check --as-cran \
--run-donttest rerddapXtracto_1.1.3.tar.gz reproduces the issue for me.

As a measure of last resort, could it help to manually go over
rerddapXtracto examples and see if any are wrapped in \donttest{} and
may be missing a cache setting?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Do you run R on Fedora or Debian?

[Ivan Krylov]

On Sat, 10 Dec 2022 14:00:22 -0800
Roy Mendelssohn - NOAA Federal via R-package-devel
 wrote:

> CRAN has sent me a notice about the following:
> 
> https://www.stats.ox.ac.uk/pub/bdr/donttest/rerddapXtracto.out
> 
> I can not reproduce it.  I test on my Mac,  the cache space is
> properly handled  (by a package outside mine).  Same with Debian on
> r-hub.  I installed Fedora on a virtual machine, no problem  (it is
> assigned a space in /tmp).

I've trace()d rerddap:::gen_key to notify me when a file with the cache
key of 4f8f83808465a7f7619285e9871747af is being downloaded. Since
digest::digest defaults to serialize = TRUE, this should only work with
R-to-be-4.3.0 (I compiled R-devel r83400, same as in the failed check):

library(rerddapXtracto)
trace(
 rerddap:::gen_key,
 quote({
  if(digest::digest(ky) == '4f8f83808465a7f7619285e9871747af') {
   cat('\n\nFound a match\n\n')
   str(url); str(args); print(ky); str(digest::digest(ky))
   message('\n\nFound a match\n\n')
  }
 }),
 at = 3
)
example(rxtracto)
example(rxtracto_3D)
example(rxtractogon)

Surprisingly, there were no hits. I also tried copying and pasting all
code from the vignette and even uncommenting the code marked as
\dontrun{}, also with no results.

The code that actually creates these files lives in the rerddap
package. The page at

says that packages are checked in parallel. What if an unlucky reverse
dependency of rerddap was being checked at the same time as your
package, making rerddapXtracto get its NOTE?

I cleaned ~/.cache/R, put the rerddap source package in a directory and
ran:

(res <- tools::check_packages_in_dir(
 '.', check_args = '--run-donttest', reverse = list(recursive = TRUE),
 check_env = c(
  "_R_CHECK_DONTTEST_EXAMPLES_=true",
  "_R_CHECK_THINGS_IN_OTHER_DIRS_=true"
 )
))

I got a NOTE for plotdap!

* checking for new files in some other directories ... NOTE
Found the following files/directories:
  ‘~/.cache/R’ ‘~/.cache/R/rerddap’
  ‘~/.cache/R/rerddap/1b43b4335f06b318b914ba2cc2f88872.nc’
  ‘~/.cache/R/rerddap/4f8f83808465a7f7619285e9871747af.nc’
  ‘~/.cache/R/rerddap/8cb244e059b86865b7933a3d9b72fe16.csv’

Looking at the examples for plotdap::add_griddap and
plotdap::add_tabledap, I think that they may be responsible for the
NOTE, because there's no pre-example cache setup and teardown. I also
finally got a match from my tracing code by running
example(add_griddap).

There's more than one way to do it right; my favourite would be to wrap
the pre-example code and post-example code in \dontshow{}, changing the
cache settings in the first block and restoring them in the second one.
Everywhere else I would use on.exit(), but examples are special in
their relationship with autoprinting and crashing there being
disallowed, making this approach feasible.

-- 
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 on Description/Citing Feedback

[Ivan Krylov]

On Fri, 16 Dec 2022 10:06:44 -0800
Michael Topper  wrote:

>- I understand the Description portion of the DESCRIPTION file
> needs to be edited, but I'm a little confused as to what I am
> supposed to add and how. Do I need to include a citation to the
> published paper of modelsummary

Yes, exactly.

>   - Arel-Bundock, Vincent (2022). “modelsummary: Data and Model
>   Summaries in R.” Journal of Statistical Software, 103(1), 1-23.
>   doi:10.18637/jss.v103.i01
> https://doi.org/10.18637/jss.v103.i01.’

Translating that in the "authors (year) " format, we get:

  Arel-Bundock, V. (2022) 

Use this form to reference the paper in the Description: field of your
DESCRIPTION.

> What would be most helpful:
> 
>- If there is any other Description file from another package that
>contains an example of what to do in such a situation, this would
> be greatly appreciated!

My own package received the same feedback on initial submission as
yours, so here's what I did: https://CRAN.R-project.org/package=cmocean

When you include documentation from a different package into one of your
own, mentioning the documentation authors in the Authors@R: field is
the right thing to do. If you want to be 100% sure, check whether parts
of documentation you're including could have been authored by other
people mentioned as contributors to modelsummary.

Hope this helps!

>   [[alternative HTML version deleted]]

Here's how we see your e-mail:
https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008746.html

Unfortunately, when you compose your messages in HTML, we only get the
plain text version automatically generated by your mailer, which may be
not a perfect representation of your message. Composing your messages to
R-package-devel in plain text will prevent them from being mangled.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How do I enable to show data in inst/extdata in data() || lazy load

[Ivan Krylov]

On Mon, 19 Dec 2022 20:59:27 +0530
Sanjeev Sariya  wrote:

> ... I have created a .Rd file.
> I'm interested in listing this file in data() ...

My understanding is that data() is for R-level objects, and so is
help(), most likely.

One way to solve this could be to write a script that imports the file
from inst/extdata using the facilities provided by your package and put
it in a file under data/, then document the resulting object. I think
that if you build your package with --no-resave-data, it will remain an
R script that will be run during the data() call. (By default, your R
script will be run during R CMD build and its output will be packaged
into a gzip-compressed RData file.)

This might go against the guidance at
,
which says:

>> R code should be if possible “self-sufficient” and not make use of
>> extra functionality provided by the package, so that the data file
>> can also be used without having to load the package or its namespace

Do you need this to be a file? Could it be a pre-parsed R object
instead?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How do I enable to show data in inst/extdata in data() || lazy load

[Ivan Krylov]

В Tue, 20 Dec 2022 05:28:49 +0530
Sanjeev Sariya  пишет:

> I need to provide an external data/file in the R package. This has
> come as a request from F1000 journal editors.

Would the journal editors agree to have this data in the form of an R
object? Is it a strict requirement to have this file in a given format?

> What do you call this step? How do I do this?

See Writing R Extensions, section 1.1.6 "Data in packages":
https://cran.r-project.org/doc/manuals/R-exts.html#Data-in-packages

I don't want to rewrite it all in this e-mail, but if you're having
trouble with a specific step, feel free to ask for guidance.

-- 
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 fixing problems for new R package

[Ivan Krylov]

В Tue, 20 Dec 2022 10:45:38 +1300
Anna Carolina Resende  пишет:

> * checking CRAN incoming feasibility ... [5s/25s] NOTE
> Maintainer: ‘Anna Carolina Resende ’
> 
> I read online that it's a note for CRAN so they can check that the
> maintainer made changes, could you confirm that that is the case?

Yes, that's exactly right.

> However, when testing in Fedora, I get another note saying:
> 
> * checking HTML version of manual ... NOTE
> Skipping checking HTML validation: no command 'tidy' found
> 
> I've tried updating the HTML Tidy on my mac as I read online that
> should solve this issue, but nothing changed.

What do you mean by testing in Fedora? If you're running a Fedora
GNU/Linux virtual machine on your Mac in order to test your package,
you'll need to install HTML Tidy inside that virtual machine. If you're
using someone else's package check service (e.g. R-hub), this may
indicate a problem with their setup (but not your package).

If these are the only two NOTEs you're getting, it looks to me like
your package doesn't have any problems, congratulations!

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Suppress R pop up message when using package OpenCL

[Ivan Krylov]

(Sorry about the previous message.)

В Thu, 22 Dec 2022 10:10:42 +0100
Quirin Stier  пишет:

> Any ideas how to get rid of the message popping up?

You seem to be right that it's a package development question.
Currently, as long as there's a non-empty build log, OpenCL will show
it using R_ShowMesssage, or complain that it couldn't:

https://github.com/cran/OpenCL/blob/bcfcca930bffeac7f03f8ab1f9513d38fefe078b/src/ocl.c#L212-L224

I don't think that R_ShowMessage can be trapped in a portable way. In
the Windows GUI frontend, R_ShowMessage is implemented as a pop-up
window. If you run your program in Rterm, the log should be be printed
to the console instead of creating a pop-up window, so that could be a
quick (but far from perfect) workaround.

An improvement to the source code of OpenCL would be to replace the
R_ShowMessage calls with Rprintf("%s\n", message);, which at least can
be caught using capture.output().

I don't think that we have a C equivalent of message() (to be caught
using suppressMessages()). message() itself is implemented entirely in
R, both raising the condition and providing a default handler.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Current recommendations re. GitHub Action?

[Ivan Krylov]

On Mon, 2 Jan 2023 19:18:33 -0600
Spencer Graves  wrote:

> However, Ubuntu failed with devel and oldrel1, complaining,
> "there is no package called ‘rcmdcheck’".

If we start from the error message and work backwards, it's easy to see
that `rcmdcheck` fails to install because it depends on `curl`, which
also fails to install. `curl` fails to install because the virtual
machine running the GitHub Action doesn't have libcurl headers
installed; there's even an error message about that, but it's not fatal:

- ANTICONF ERROR ---
Configuration failed because libcurl was not found. Try installing:
 * deb: libcurl4-openssl-dev (Debian, Ubuntu, etc)
 * rpm: libcurl-devel (Fedora, CentOS, RHEL)
If libcurl is already installed, check that 'pkg-config' is in your
PATH and PKG_CONFIG_PATH contains a libcurl.pc file. If pkg-config
is unavailable you can set INCLUDE_DIR and LIB_DIR manually via:
R CMD INSTALL --configure-vars='INCLUDE_DIR=... LIB_DIR=...'


I don't have enough experience in the abstraction layers involved, but
if you stuff a `sudo apt install libcurl4-openssl-dev` (which should
run as a system command line, just like the "Install system
dependencies" step) somewhere before the "Install dependencies" step,
it should work.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] S3 generic/method consistency false positive when dplyr imported

[Ivan Krylov]

On Wed, 4 Jan 2023 15:54:52 -0500
"Aaron A. King"  wrote:

> Why does inclusion of *dplyr* in the import list appear to trigger
> these warnings when they were not there before?

I think that's because dplyr itself contains an S3 generic named
"filter", and having a package namespace loaded (not even attached) is
enough to take its registered S3 methods into consideration for method
dispatch. Here we have an opposite situation, though, and your
functions aren't registered as S3 methods. Will your function still be
called if you artificially construct a wrong object and feed it to
dplyr::filter while your package namespace is attached?

library(YOURPACKAGE)
dplyr::filter(structure(list(), class = 'traj'))

Additionally, stats::filter doesn't seem to be an S3 generic, so that's
one thing that the check gets confused about.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] S3 generic/method consistency false positive when dplyr imported

[Ivan Krylov]

On Thu, 5 Jan 2023 17:58:47 -0500
"Aaron A. King"  wrote:

> However, since the S3 dispatch system is not itself confused, I
> suppose it must be the case that the S3 generic/method consistency
> checker itself is confused.  I wonder, how does the checker decide
> when to throw a NOTE?  Is it a simple pattern-matching system,
> something like "If X.Y is exported, where X is a generic and Y is any
> string and X.Y is not declared as an S3 method, then throw NOTE"?

The aim of the check is a bit different: "if an S3 method for generic X
and class Y exists, and the formal arguments of X.Y don't extend the
formal arguments of X in a certain way, then throw a NOTE", but then
something gets wrong about deciding whether X.Y is an S3 method, and
once filter.mean is decided to be an S3 method, of course it doesn't
match the formals of filter.

This function is even a public API of the tools package, see
?tools::checkS3methods:
https://github.com/r-devel/r-svn/blob/b57918fd104962415a752ea7db12dcf4f3f5219f/src/library/tools/R/QC.R#L2310-L2560

> When I follow your suggestion above, I get
> 
> library(pomp)
> dplyr::filter(structure(list(), class = 'traj'))
> 
> Error in UseMethod("filter") :
> no applicable method for 'filter' applied to an object of class "traj"

Interesting. I wonder if there's are other remaining ways to confuse
the S3 dispatch system into thinking your function is an S3 method that
the check is supposed to guard against. For instance, the following is
likely to work with your package:

library(pomp)
library(dplyr)
identical(filter.traj, getS3method('filter', 'traj'))
# as long as there's a visible 'filter' generic, getS3method will
# locate filter.traj as the method

...despite the method lookup seems to (correctly) fail, as you've just
demonstrated. But on older versions of R, this used to wrongly resolve
the call:

library(Ropj)
read <- function(x, ...) UseMethod('read')
identical(read.opj, getS3method('read','opj')) # works in R-devel
# [1] TRUE
read(structure(0, class = 'opj')) # calls read.opj in old R
# Error in read_opj(file, encoding, tree) :
#   Expecting a single string value: [type=double; extent=1].

I'm afraid I'm out of my depth here. The old, wrong behaviour seems to
match the R language definition
.
The current behaviour seems to do the right thing™ by letting the
functions opt into being methods, but then getS3method() seems to
contradict what actually gets called. Should we be fixing the
documentation, the implementation, or the check?

Can you try stepping through tools::checkS3methods('pomp') (or
tools::checkS3methods(dir = 'path/to/source/directory')) to see where
'filter' appears in the list of generics and where the 

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] S3 generic/method consistency false positive when dplyr imported

[Ivan Krylov]

(Sorry for the unfinished message. I've got to do something about my
mailer to make it harder to send them accidentally.)

On Fri, 6 Jan 2023 11:21:49 +0300
Ivan Krylov  wrote:

> to see where 'filter' appears in the list of generics and where the

filter.traj function gets matched to it as a method?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Problem with NEWS file

[Ivan Krylov]

On Sat, 7 Jan 2023 15:02:18 +0700
Thierry Denoeux  wrote:

> The NEWS file is a text file created by TextEdit on Mac with UTF-8
> encoding, so I don’t see how there could be hidden special characters
> in it.

The problem is that the NEWS files are supposed to have a certain
format (documented in help(news)). For a long time, this hasn't been
enforced, but now there are checks in place that require NEWS to be
written to specifications.

I think that your line can be transformed as follows in order to parse
correctly:

Changes in version 2.0.0

 * Implementation of radial basis function neural network classifiers,
   as well as functions to express the outputs of trained logistic
   regression or feed-forward neural network classifiers as
   Dempster-Shafer mass functions. These methods are based on an
   interpretation of the operations performed in neural networks as the
   combination of weights of evidence by Dempster's rule (see: "T.
   Denoeux, Logistic Regression, Neural Networks and Dempster-Shafer
   Theory: a New Perspective. Knowledge-Based Systems 176:54-67, 2019").

You can also write an inst/NEWS.Rd file in Rd format.

As you can see from reading ?news, it is preferred to provide a
bulleted list of the changes.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Ivan Krylov]

On Sat, 7 Jan 2023 20:43:10 -0500
"Kevin R. Coombes"  wrote:

> (1) How is it possible that the same code works error 
> free in the RStudio contexts, but fails in the attempt to build the
> package?

When knitting the vignette from RStudio, it uses the package you
already have installed. When knitting the vignette from R CMD build, it
uses the code it's about to package. Could it be that your source code
is different from the copy installed in your library?

> (2) Any suggestions on how to debug something that only
> throws an error from "R CMD build" would be most welcome.

R CMD build --no-build-vignettes should let you proceed and get a
tarball that could be installed. Hopefully you'll be able to reproduce
the error then.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Failed CRAN tar.gz upload to CRAN

[Ivan Krylov]

В Fri, 13 Jan 2023 08:54:50 +
Chris Brien  пишет:

> I am getting the following response when I try to upload
> growthPheno_2.1.17.tar.gz:
> 
> Detected package information [non-editable]
> In case of errors reupload the package or contact cran team

That's not an error. This message is to inform you that the following
fields have been extracted from your DESCRIPTION file and aren't
supposed to be edited by hand. Is there a better way to phrase that?

Do you see anything out of place in the form? If the form content seems
OK, click the "Submit package" button near the bottom of the page to
continue.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Failed CRAN tar.gz upload to CRAN

[Ivan Krylov]

On Fri, 13 Jan 2023 21:51:01 +
Chris Brien  wrote:

> the package files is being dropped as well. It replaces my file name
> with "No file chosen".  Consequently I cannot continue submit the
> package.

I understand that this behaviour is counter-intuitive, but that seems
to be the way it's supposed to work. Package submission is a multi-step
process:

Step 1 involves providing your name, your e-mail address and the
package file. Once uploaded, the package file stays somewhere at CRAN,
at least for a while.

Step 2 involves making sure that you've uploaded the right package.
You're shown your name, e-mail address, the optional comment and the
fields from the DESCRIPTION file. The "Package:" file upload field
should be empty because CRAN already has a copy of the file.

Pressing the "Re-upload the package/Edit information" will repeat the
step 1 and take you back to the same place, just before the step 2. In
order to progress, you need to press the "Submit package" button below
the form, despite the "Package:" file upload field is empty.

Do the "Title:", "Description:", "Authors(s):" fields contain the
information for your package? Does the "Submit package" button work for
you? Are there any other messages there?

Perhaps the CRAN submission form should show some indication that the
file has been uploaded near the file entry field during step 2?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] corrupted NAMESPACE file

[Ivan Krylov]

В Fri, 20 Jan 2023 08:41:25 -0600
Spencer Graves  пишет:

> ** byte-compile and prepare package for lazy loading
> Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
>1:1: unexpected input

tools::showNonASCIIfile('https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
# 1: export(AmpPhaseDecomp,

Your NAMESPACE file starts with a U+FEFF ZERO WIDTH NO-BREAK SPACE.
You'll need to remove it, e.g. by re-creating the first line.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Pretest failed and I fail to find out what's the problem

[Ivan Krylov]

On Sun, 22 Jan 2023 19:51:30 +0100
Klaus Schliep  wrote:

> package phangorn_2.11.0.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:

Is this the whole e-mail? There may be a list of problems at the end of
the message, right after the signature ("Best regards, CRAN teams'
auto-check service"). It may be about the time your vignette took to
build on Windows, but I'm not sure about that.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] strange errors (non-ascii symbols) on win-builder R-devel

[Ivan Krylov]

On Tue, 24 Jan 2023 17:33:10 +
Maxim Nazarov  wrote:

> this seems to come from the C code

I'm 99% sure this comes from the following changes to the package:

--- minpack.lm_1.2-2/src/fcn_message.c  2020-03-23 10:54:03.0 +0300
+++ minpack.lm_1.2-3/src/fcn_message.c  2023-01-17 09:30:05.0 +0300
@@ -3,24 +3,24 @@
 char *fcn_message(char *msg, int info, int n, int nit)
 {
 if  (info == 1)
-sprintf(msg, "Relative error in the sum of squares is at most 
`ftol'.");
+Rprintf(msg, "Relative error in the sum of squares is at most 
`ftol'.");
 else if (info == 2)

(And so on for other values of `info`.)

sprintf() takes a string pointer to write into as its first argument.
Rprintf(), on the other hand, prints straight to the R console; its
first argument is the format string. Given a valid pointer to an
uninitialised string instead of the format string, Rprintf prints stack
garbage to the console, ignoring the following arguments. My guess is
that the maintainers either intended to remove the msg argument
altogether or needed to use snprintf() and pass the buffer size to
fcn_message().

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] reproducing cran warnings

[Ivan Krylov]

On Fri, 3 Feb 2023 16:28:23 +
Brad Eck  wrote:

> For example R-devel-debian-gcc is ok on rhub
> https://builder.r-hub.io/status/epanet2toolkit_0.6.1.tar.gz-58c1ce1e316317307679f58450a5e17a
> 
> But not on CRAN:
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/epanet2toolkit-00check.html

Speaking of reproducing the warnings, the CRAN checks pass -Wall
-Wstrict-prototypes -pedantic to the compiler, while on Rhub, only the
UB sanitizer is used without any statical analysis warning flags.

It may be possible to see the extra warnings if you set CFLAGS = -Wall
-Wextra -Wpedantic in ~/.R/Makevars.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to update "SystemRequirements: C++11"?

[Ivan Krylov]

В Mon, 6 Feb 2023 14:46:16 -0600
Winston Chang  пишет:

> 1. Remove "SystemRequirements: C++11" entirely. The problem with this
> is that on systems with older versions of R (3.6 and below, I
> believe), it may try to compile the package with an older C++
> standard, which will fail.
> 2. Update it to "SystemRequirements: C++17". The problem here is
> that on systems that don't have a C++17 compiler, the package won't
> build -- even though the package only actually requires a C++11
> compiler.

One way to resolve that conundrum could be to add a configure script
that detects a C++17/C++14/C++11 compiler known to R and sets that in
Makevars. I haven't published an update on CRAN yet, but R CMD check
seems satisfied with this under multiple versions of R between 3.3 and
R-devel:
https://github.com/aitap/Ropj/commit/e1ed8122d6d9a380a4f7e1505478dd07f4dd83a4

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Problem with package containing spatial data

[Ivan Krylov]

В Wed, 8 Feb 2023 11:32:36 -0300
Igor L  пишет:

> spatial_aisp <- sf::st_read('data-raw/shp_aisp/lm_aisp_2019.shp')
> 
> plot(spatial_aisp) # works
> 
> # Same data from .rda file after use usethis::use_data(spatial_aisp,
> overwrite = TRUE)
> 
> x <- ispdata::spatial_aisp
> 
> plot(x) # do not work

Does this break in a new R session, but start working when you load the
sf namespace? I think that your package needs to depend on sf in order
for this to work. Specifying it in Imports may be enough to make the
plot.sf S3 method available to the user.

You may encounter other problems if you go this way, like R CMD check
complaining that you don't use the package you're importing. Loading
the data from a file on demand would also load the sf namespace and
thus solve the problem.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Unable to load Windows NETIO.SYS and WINSPOOL.DRV DLLs

[Ivan Krylov]

On Sat, 11 Feb 2023 11:19:42 +
David Sterratt  wrote:

> WinDbg output reveals errors loading "NETIO.SYS" and "WINSPOOL.DRV"
> when running "library(RGtk2)":
> 
>0c64:0640 @ 44312812 - LdrpProcessWork - ERROR: Unable to load DLL:
> "NETIO.SYS", Parent Module: "C:\Users\David
> Sterratt\AppData\Local\R\win-library\4.3\RGtk2\libs\x64\RGtk2.dll",
> Status: 0xc135
>...
>0c64:1e5c @ 44312812 - LdrpProcessWork - ERROR: Unable to load DLL:
> "WINSPOOL.DRV", Parent Module: "C:\Users\David
> Sterratt\AppData\Local\R\win-library\4.3\RGtk2\libs\x64\RGtk2.dll",
> Status: 0xc135

The failure to load WINSPOOL.DRV is perplexing (it should normally be
possible to load as it's a system DLL that applications are supposed to
link against in order to be able to print), but NETIO.SYS should
probably be absent from the import list. At least it seems to be linked
against some kernel-related stuff that shouldn't be reachable from
userspace applications.

By removing -lnetio from PKG_LIBS, I was able to load the package and
run some example code from the JSS article, but then Rgui.exe crashed
on exit. I'm running R-4.2.2 and Rtools43 on a Windows 7 machine, which
could also be a source of the difference.

Does the Dependency Walker  provide you
any useful information about the package DLL besides what you already
know? (Some warnings deep in the dependency tree are to be expected.
R.DLL is not on the PATH so won't be automatically found, but other
dependencies should exist.)

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

Re: [R-pkg-devel] Sanitize Input Code for a Shiny App

[Ivan Krylov]

On Sun, 26 Feb 2023 14:36:22 -0500
 wrote:

> What I'd like to be able to do is to sanitize the inputs to ensure
> that it won't to things including installing packages, running system
> commands, reading and writing to the filesystem, and accessing the
> network.  I'd like to allow the user to do almost anything they want
> within R, so making a list of acceptable commands is not
> accomplishing the goal.  

How untrusted will the user be?

You will most likely have to forbid Rcpp and any similar packages (and
likely anything that depends on them), because running arbitrary C++
will definitely include system commands, filesystem I/O and sockets.

To think of it, you will also have to forbid dyn.load(): otherwise it's
relatively easy to compile a ELF shared object that would load on any
64-bit Linux and provide an entry point that performs a system call of
the user's choice.

While the base R packages set R_forceSymbols(dll, TRUE) on their
.C/.Call/.Fortran/.External routines, making them unavailable to a bare
.Call("symbol_name", whatever_arguments, ...), some of the packages
deemed acceptable might provide C symbols without disabling the dynamic
lookup, and those C symbols may be convinced to run user-supplied code
either by mistake of the programmer (user supplies data, programmer
misses a buffer overrun or a use-after-free, suddenly data gets
executed as code; normally not considered a security issue because "the
user is already on the inner side of the airtight hatchway and could
have run system()") or even by design (the C programmer relied on the
R code to provide safety features). CRAN checks with Valgrind and
address-/undefined behaviour sanitizers help a lot against this kind of
C bugs, but they aren't 100% effective. Either way, top-level .C and
friends must be forbidden too. (Forbidding them anywhere in the call
chain will break almost all of R, even lm() and read.table().)

A CRAN package deemed acceptable may still have system() shell
injections in it and other ways to convince it to run user code.

The triple-colon protection can probably be bypassed in lots of clever
ways, starting with a perfectly normal R function `get()` combined with
a package function that has the private symbols visible to it. Similar
techniques may bypass the top-level .C/dyn.load()/system() restrictions.

Will the user be allowed to upload data? I think that R's serialization
engine is not designed to handle untrusted data. It has known stack
overflows [*], so a dedicated attacker is likely to be able to find a
code execution pathway from unserialize().

R code is also data, so a "forbidden" function or call could be
smuggled as data, parsed/deserialized and then evaluated. There are
standard classes in at least one of the base packages that use a lot of
closures, so a print() call on a doctored object can already be running
user-supplied code. You may forbid parse(), but some well-meaning code
inside R or a CRAN package may be convinced to run as.formula() on a
string, which may be enough for an attacker.

Some simple restrictions may be implemented by recursively walking the
return value of parse(user_input), but that ignores the possibility of
attacks on the parser itself. More significant restrictions may require
you to patch R and somehow determine at the point of an unsafe
(socket() / dlopen() / system() / ...) call whether it's
user-controlled or required for R to function normally (or both?).

I think it's a better idea to put the user-controlled process in a
virtual machine or a container or use a sandbox such as firejail or
bubblewrap. Make R run as an unprivileged user (this matters much less
once inside a sandbox, but let's not help the attacker skip privilege
escalation exploits before they try sandbox breakout exploits). Put
some firewall rules into place. Some attackers will doubtlessly try to
run a cryptocurrency miner without destroying the system/sending
spam/breaching your data, so make sure to limit CPU time, the size of
the temporary storage you're giving to the process and the amount of
RAM it can allocate.

In a game of walls and ladders, nothing will give you perfect
protection from attackers breaking out of such a sandbox (have I
mentioned the Spectre-class attack on the branch predictor in most
modern CPUs that makes it (very very hard but) possible to read from
address space not belonging to your process? The rowhammer attack on
non-ECC DRAM that (probabilistically) overwrites memory that is not
yours?), but in this case, the operating system is in a much better
position to restrict the user than R itself. Some languages (like Lua)
have such a tiny standard library that putting them in a sandbox is a
simple exercise, though both parser and bytecode execution
vulnerabilities (which might lead to code execution) still surface from
time to time. (SQLite went through a lot of fuzz-testing before its
authors could say that both its SQL parser and its database file parser
were safe against attac

Re: [R-pkg-devel] CRAN submission - Specified C++11

[Ivan Krylov]

В Mon, 27 Feb 2023 10:25:55 +0100
Riccardo Di Francesco  пишет:

> Specifying C++11 is necessary to make my package work. How can I solve
> this?

Is it C++11 exactly or C++ ≥ 11? If the former, you're 100% right to
specify this (but may have problems in unspecified future when someone
decides to stop supporting C++11). If the latter, the answer is more
complicated, especially if you want your package to continue working on
older versions of R.

My own solution is to use the default C++ standard on R ≥ 3.6.2, i.e.
omit the CXX_STD specification entirely (which is at least C++11 there,
and my code has been tested on C++11 to C++17), but explicitly request
at least C++11 on R ≥ 3.1 using a configure script:
https://github.com/aitap/Ropj/commit/cc94320bd5b8b68c879ff604787e71831fff8108

Prior to R-3.1, there seems to have been no way to ask for C++11, so I
don't expect my code to work there.

See also: this R-pkg-devel thread
https://stat.ethz.ch/pipermail/r-package-devel/2023q1/008870.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] URL timeout in win-builder check: suggestions?

[Ivan Krylov]

В Mon, 13 Mar 2023 10:28:13 -0400
Ben Bolker  пишет:

> Found the following (possibly) invalid URLs:
>URL: https://phdcomics.com/comics/archive.php?comicid=905
>  From: man/pvalues.Rd
>  Status: Error
>  Message: Operation timed out after 60010 milliseconds with 0
> bytes received

Does it happen all the time? I used to binge-read PhD Comics, and they
timed out on me from time to time, but then worked again. Currently, I
can access this URL with a HEAD request using cURL over Tor, which
should have raised a lot of red flags if they were using a bot detector.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Checking timings of packages

[Ivan Krylov]

В Tue, 14 Mar 2023 13:52:13 +
Chris Brien  пишет:

> The difficulty I am having is that I cannot be sure that the timings
> for r-devel-linux-x86_64-debian-gcc and r-devel-windows-x86_64 will
> be under 10 s, as seems to be required, if I were to resubmit the
> package to CRAN with the reduced examples.
> 
> I would be grateful to anyone who can suggest how I might go about
> determining the CRAN timings without submitting the package to CRAN.

I think that win-builder R-devel  is
the same machine as the CRAN r-devel-windows-x86_64 machine (at the very
least, the CPU description of win-builder matches that from
).

-- 
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 submission - Specified C++11

[Ivan Krylov]

[I am taking the liberty of Cc-ing the list again because this kind of
advice could be useful for other people too.]

Dear Riccardo Di Francesco,

В Wed, 15 Mar 2023 08:41:01 +0100
Riccardo Di Francesco  пишет:

>> Please ensure that your functions do not write by default or in
>> yourexamples/vignettes/tests in the user's home filespace (including
>> the package directory and getwd()). This is not allowed by CRAN
>> policies.Please omit any default path in writing functions. In
>> yourexamples/vignettes/tests you can write to tempdir().

> I guess this comes from the configure.R script that writes a Makevars
> file that specifies the appropriate C++ version.
> Did you experience something like this?

The package review is both a defining feature of CRAN and its
rate-limiting step. With the number of CRAN packages rising almost
exponentially and the burden of responsibility only increasing (various
kinds of supply-chain attacks becoming a frequent occurrence over at
the more popular NPM and PyPI repositories), there is increasingly more
reason for CRAN reviewers to fail safe and reject some false positives.

All that is a long way to say that sometimes CRAN reviewers make
mistakes. Does the rejection e-mail tell you whether you can appeal? I
think it says something like "please reply-all and explain", but make
sure to check yourself (i.e. the rules on whether you should
reply-to-all or reply-to-sender may have changed). I have argued my way
out of a rejection once, but only because there was an easy way to show
the mistake on the reviewer's part.

Were there any NOTEs about files being left after the R CMD check
run (or any other NOTEs or WARNINGs)? Does the rejection e-mail tell you
where is the offending write function?

Looking at your package, I see the calls to cat(..., file = ...) and
writeLines(file = ...). You may need to demonstrate in your reply that
they all live under tools/* and are only called during the package
configuration. Any other places where you may be writing to files from
R code? I also see a cat() call in a summary() method; it's probably not
the reason for rejection.

There's also the use of std::ofstream in the C++ code under src/*. Is
the writeOutput() function used anywhere? You could try to demonstrate
that there are no calls to this function, hence there is no way C++
code could write files where it's not welcome to do so.

If there's no way to appeal the rejection, that's more problematic
because the rules say you now have to submit a version of the package
that is different in both the version number and the content. In that
case, (assuming there's really no way for the package to write files in
user directories) hide the writeOutput() function behind an #ifdef or
even remove it if possible (put it on a separate branch if you use it
for other purposes elsewhere) and put the rest of the explanation about
the code under tools/* in the submission comment.

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] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

В Thu, 16 Mar 2023 11:09:16 +
"Ruff, Sergej"  пишет:

> The Check-Function in R shows no Notes, Warnings or Errors, but I am
> not sure if that means that limma will install when installing my
> package from CRAN.

> Currently I am declaring limma like this:
> 
> Suggests:
> 
> limma

install.packages() doesn't install suggested packages by default: the
`dependencies` argument defaults to NA, which means c("Depends",
"Imports", "LinkingTo"), which doesn't include 'Suggests'.

What if you pass dependencies = TRUE? Given the fact that Bioconductor
is absent from getOption('repos') by default, the package will still
not be installed. BiocManager::install() is the supported way to
install packages from Bioconductor:
https://cran.r-project.org/package=BiocManager/vignettes/BiocManager.html#installing-bioconductor-cran-or-github-packages

I think that BiocManager::install('YOUR_PACKAGE', dependencies = TRUE)
will install both your package and limma. It's a bit hard to verify
because your package should live in a repository, but if you'd like to
be sure, spin up a drat  repo
on a local server and add it to options(repos = ...) before trying to
install your package.

> Do I need to declare Bioconductor-dependencies such as Limma
> differently in the Description-File of my Package?
 
No, this is the right way to declare Bioconductor dependencies for CRAN
packages.

> Can CRAN identify that limma is a Bioconductor-Package and will it
> Limma install, when installing my package from CRAN?

The CRAN website will detect the Bioconductor dependency and highlight
it with a different colour, making it a link to the Bioconductor
website. See, e.g., the BiocManager package and its reverse
dependencies: https://CRAN.R-project.org/package=BiocManager

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

On Thu, 16 Mar 2023 17:01:55 +
"Ruff, Sergej"  wrote:

> Last question: How does CRAN work with Bioconductor Dependencies?
> Will CRAN accept limma as a dependency or will my submission be
> rejected?

It's not explicitly spelled out in the CRAN policy
, but
Bioconductor and CRAN are the "mainstream repositories" for the
purposes of the following rule:

>> Packages on which a CRAN package depends should be available from a
>> mainstream repository

(Even non-mainstream repositories are allowed for optional dependencies
if you follow a few additional rules.)

Here's an example of a CRAN package with a strong dependency on a
Bioconductor package: . You
can see the extra instructions for installing the Bioconductor
dependencies in its README.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Should 'methods' be in Imports?

[Ivan Krylov]

On Thu, 16 Mar 2023 11:29:33 -0400
Noah Greifer  wrote:

> Is including these packages filling the DESCRIPTION with unnecessary
> dependencies that are automatically satisfied, or is it being
> helpfully explicit about the packages your package relies on?

Here's a comment from the part of R CMD check that checks for NAMESPACE
dependencies unstated in DESCRIPTION:

>> Not clear whether we want to require *all* namespace package
>> dependencies listed in DESCRIPTION, or e.g. just the ones on
>> non-base packages.  Do the latter for time being ...
>> Actually we need to know at least about S4-using packages,
>> since we need to reinstall if those change.

So the answer is maybe. Personally, I opt for listing even the base
packages explicitly, but it's a choice. Duncan's quote from WRE hints
that this may be enforced in the future.

I do find it a bit strange that not listing methods as a dependency in
DESCRIPTION doesn't lead to complaints from R CMD check, because it
does seem that the code excludes methods (and stats4) from the list of
packages that are currently okay not to declare in DESCRIPTION.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

В Fri, 17 Mar 2023 10:19:37 +
"Ruff, Sergej"  пишет:

> Thats the source of my worries. Will the same error appear when CRAN
> checks the examples of my package? Or should I not be worried?

Yes, part of CRAN checks is running your package without the packages
listed under Suggests:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/README.txt [*]

See WRE 1.1.3.1 for the official guidance on how to handle optional
dependencies that might not be installed:
https://cran.r-project.org/doc/manuals/R-exts.html#Suggested-packages

In short, your code should check the return value of
requireNamespace('limma', quietly = TRUE) before trying to run code
from it. Your code can (and probably should) raise an error if asked to
do something using limma when it's not available, but then in your
tests/vignettes/examples you should check whether limma is available
before trying to run that code.

-- 
Best regards,
Ivan

[*] See also:
https://cran.r-project.org/web/checks/check_issue_kinds.html

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

В Fri, 17 Mar 2023 11:02:18 +
"Ruff, Sergej"  пишет:

> I would like to ask, if I need to add something to the
> DESCRIPTION-file when declaring Bioconductor dependencies for CRAn
> Submission.

Strictly speaking, no. Once you list limma under Suggests, it's
possible and proper to install your package using
BiocManager::install('YOUR_PACKAGE', dependencies = TRUE) and have
limma installed too, as Martin Morgan said above in the thread.

> Some recommend adding biocViews:

This field is required on Bioconductor, not CRAN:
https://contributions.bioconductor.org/description.html?q=biocViews#description-biocviews

> some recommend adding Remotes: bioc::limma

Not a standard R/CRAN field, only used by the remotes package:
https://remotes.r-lib.org/articles/dependencies.html

> Others add Biocmanager to the suggests file

I suppose it could help a user who doesn't initially know to use
BiocManager in order to install your package, and could also be used to
install limma on behalf of your users (with their permission!), but
it's additional work, may be hard to get right (see the CRAN policy
about installing packages and touching user files), and is not required
at all.

> What should I add to my Description File to make sure that limma gets
> installed from Bioconductor when needed?

See Martin Morgan's e-mail above in the thread. In short, tell your
users to install your package using BiocManager::install(...,
dependencies = TRUE) if they want limma to work. They are still free to
install.packages() if they don't want limma or can set things up
themselves.

Move limma to Imports (better) or Depends (may be worse)
if you want limma to be always available, at the cost of always
requiring Bioconductor to be set up to have your package installed.
There are other ways besides BiocManager::install(), but they all
depend on the user having set up Bioconductor repos in their R session
somehow, be it BiocManager::repositories() or setRepositories().

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

В Fri, 17 Mar 2023 12:29:51 +
"Ruff, Sergej"  пишет:

> The problem is that a local installation of my package (via USB-stick
> for example) can´t install the dependencies from CRAN.
> 
> The package works perfectly fine, if the dependencies are
> preinstalled.

This is a similar, but different problem. It is indeed solved by having
your package with its dependencies in a repository.

> So I thought all dependencies would install automatically from CRAN?

The user is allowed to install your package with dependencies = NA
(which means not installing packages listed under Suggests). The
Depends, Imports and LinkingTo will be installed, but not Suggests. The
user will have to pass dependencies = TRUE in order to install the
packages listed under Suggests.

Your package is required to work (in particular, run the examples and
vignettes and pass the tests without errors) without having the
suggested packages installed:
.
You can check whether limma can be loaded and raise an error otherwise,
but your tests, examples and vignettes shouldn't raise errors or
otherwise crash. This is checked by CRAN here:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/README.txt

If your package can't be meaningfully used without limma, do list it as
a strong dependency.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

В Mon, 20 Mar 2023 08:38:41 +
"Ruff, Sergej"  пишет:

> When Limma is üre-installed, I get the following Note:
> 
> 
> "Package suggested but not available for checking: 'limma'".
> 
> 
> Seems like the functions isnt installing limma.
> 
> Is there something I am missing?

No, this is exactly how it's supposed to behave under R CMD check. The
CRAN policy forbids packages to install other packages ("Packages
should not write in the user’s home filespace <...> nor anywhere else
on the file system") except when the user gives permission to do so
("Limited exceptions may be allowed in interactive sessions if the
package obtains confirmation from the user").

Under R CMD check, interactive() is FALSE because there is no user to
ask permission from, so the function correctly decides not to install
the package. The resulting NOTE is the expected result here. The
important part is that your example doesn't crash because it's unable
to load the limma namespace.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Ivan Krylov]

On Mon, 20 Mar 2023 19:32:03 +
"Ruff, Sergej"  wrote:

> but I thought Notes will also cause rejection when submitting a
> package to CRAN. Won´t that be a problem?

True, a NOTE during an automatic check may cause a rejection, but you
won't get this NOTE there. Automatic CRAN pre-tests are done with a
full package set: anything from CRAN and BioConductor that runs on a
given operating system can be loaded.

(This differentiates CRAN from, say, PyPI or NPM: the two latter
ecosystems are much larger and are expected to handle conflicting
dependency requirements. CRAN is small enough to be able to enforce the
rule that every package must play well with the latest version of
everything else.)

There's an additional CRAN check called noSuggests
. You will
get a NOTE there, but it's expected and won't count against you. The
only way avoid this NOTE there is to not have any packages in Suggests:
(or Enhances:).

-- 
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: Rd \usage sections, Result: The \usage entries for S3 methods should use the \method markup and not their full name.

[Ivan Krylov]

On Tue, 21 Mar 2023 23:08:43 +0100
Yohann Foucher  wrote:

> Check: Rd \usage sections, Result: NOTE
>  S3 methods shown with full name in documentation object 'nnet.time':
>'nnet.time'
> 
>  The \usage entries for S3 methods should use the \method markup and
> not their full name.

I have downloaded your package from the CRAN FTP server (under
incoming/archived) and took a look at it. This NOTE is about the
nnet.time function itself (documented in man/nnet.time.Rd), which R CMD
check mistakenly took for a nnet() method on class "time".

This is a problem because you import nnet::nnet, which is an S3
generic, and R is slowly migrating its behaviour in cases like this.
Previously, calling nnet::nnet(structure(..., class = 'time')) would
mistakenly call your nnet.time function, despite it's not intended to
be an S3 method. The idea is to only call S3 methods when they are
registered as such (so, don't call nnet.time in this case), but this
requires writing tests and identifying every case of this pattern
working by mistake. Your nnet.time function is a false positive for
such a test.

It's hard to decide what to do next. Your users would prefer nnet.time
to keep working (so you can't just rename it, especially if you have
other packages depending on it), and CRAN would prefer nnet.time to keep
being not-an-S3-method, but right now it's causing you a NOTE due to
its name.

Did the rejection e-mail say whether you can reply-to-all /
reply-to-sender and explain it's a false positive? Even if you decide
to rename nnet.time and everything else, it would still need to spend
at least one release on CRAN as a deprecated function.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] How to identify what flags "Additional Issues" for UBSAN

[Ivan Krylov]

В Wed, 22 Mar 2023 15:51:54 +
"Kenny, Christopher"  пишет:

> Is there an easy way to identify what is causing the flag?

Unfortunately, it's _all_ the sanitizer errors.

> wilson.cpp:165:34: runtime error: signed integer overflow:
> -2147483648 * -1 cannot be represented in type 'int'

> However, my understanding is that these errors should be expected, as
> the input is controlled from within the package and checking for
> these types of errors in every loop would push against the purpose of
> using C++ for performance here.

You'd be right to think that signed integer overflow just wraps around
on modern CPUs with no adverse effects on the rest of the execution.
Unfortunately, you'd also need to convince the C++ optimiser, and it's
currently allowed to think otherwise.

In C++, signed integer overflow (and other similar errors, such as
casing NaN to an integer) is undefined behaviour, which, according to
the standard, means that anything can happen after that, ranging from
nothing out of order to a crash and also to silent corruption of
important research results. Other languages define integer overflow to
have a more limited impact (wrap the value around or at least guarantee
a crash), but not C and C++. [*]

Thankfully, I only see one spot where you encounter UB, in
src/wilson.cpp line 165, which should be relatively easy to fix by
adjusting your strategy for calculating the maximum number of tries.
(Do you get a NaN when `remaining` is -1? Why is it -1? Or is it 0?)

-- 
Best regards,
Ivan

[*]
Some old gcc version used to launch the game Nethack when certain kinds
of UB were encountered. The situation has improved in some ways since
that and worsened in others: modern C and C++ compilers, especially
Clang, use UB to guide their optimisation efforts, so if the optimiser
can prove "if A is true then UB happens", it optimises with the
assumption that A is false.

Combined with optimizer bugs, this understanding of undefined
behaviour may lead to funny situations where the inability of the
compiler to prove certain facts about the program leads to
mathematically inconsistent results:
https://blog.regehr.org/archives/140

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

Re: [R-pkg-devel] correcting errors in an existing package

[Ivan Krylov]

On Fri, 31 Mar 2023 16:51:40 -0400
Dennis Boos  wrote:

> Also, I keep getting the message in the Rstudio check
> 
> WARNING
>'qpdf' is needed for checks on size reduction of PDFs
> 
> 
> but I got the latest versions of R and Rstudio and was able to get
> qpdf to install and loaded with library(qpdf), but Rstudio still gives
> that message.

Almost there.

The 'qpdf' package interfaces to the same code that the 'qpdf' command
line tool uses to do its job. R CMD check uses the latter, not the
former. It looks like you're on Windows, so you need to install Rtools
in order to get a compatible version of 'qpdf':
https://cran.r-project.org/bin/windows/Rtools/rtools43/rtools.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] What checks are required before uploading a package to CRAN?

[Ivan Krylov]

On Tue, 4 Apr 2023 14:28:52 -0600
John Lawson  wrote:

> ERROR: Access to the path
> 'C:\Inetpub\ftproot\R-devel\daewr_1.2-9.tar.gz' is denied. (perhaps
> you uploaded already and the file has not been processed yet?)
> 
> It has been 4 days since I uploaded the file to R-release, and I get
> automatic emails every other day from Uwe Ligges telling me my package
> has been checked and built.

This might need some help from Uwe Ligges to resolve the package queue
problems.

> What checks are required before uploading the package tar.gz file to
> the cran.r-project.org/submit.html page?

The policy strongly recommends checking the package with R-devel but
doesn't require you to use Win-Builder. You can get R-devel for Windows
from  and run
R CMD check from that.

If you don't want to install additional software, you can use R-hub
 and other package checking services.
They don't run exactly the same software on exactly the same hardware
as CRAN checks, but they do fulfil the requirement to have your package
checked by R-devel.

-- 
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 not passing automatic checks: no clue as to what is causing 2 notes

[Ivan Krylov]

В Wed, 12 Apr 2023 10:05:32 +0200
Gianmarco Alberti  пишет:

> 'CreateProcess' failed to run
> 'd:\rtools43\x86_64-w64-mingw32.static.posix\bin\tidy.exe -language
> en -qe --drop-empty-elements no D:\temp\Rtmp29JsRe\file2426857b24734'

This is a (transient?) problem on the machine running the check:
something completely prevented HTML Tidy from running, even before the
process would have tried to load the required DLLs. Nothing to do with
your package.

> * checking for detritus in the temp directory ... NOTE
> Found the following files/directories: 'lastMiKTeXException'

I think this is a false positive too. Some other package may have
failed to compile its PDF documentation (at the same time?), which
caused MiKTeX to create this file in the temp directory. Your PDF
manual check resulted in an OK.

Does the automatic e-mail include the instructions on where to reply
with this explanation?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] katex

[Ivan Krylov]

On Mon, 24 Apr 2023 18:17:22 +0200
Göran Broström  wrote:

>cannot open file '/usr/lib/R/doc/html/katex/katex.js': No such
> file or directory

> I still get the error with R CMD check --as-cran. What am I
> missing? Obviously /usr/lib/R/doc/html/katex/katex.js (no 'doc'), but
> ...
> 
> I am installing R via apt.

Thank you for mentioning this detail!

At least in Debian packages, R's copy of KaTeX lives in /usr/share: per
Debian policy, "share" is for human-readable files like KaTeX, and
"lib" is for shared libraries, compiled code and the like.

For a copy of R built from source, it's not a problem:
file.path(R.home(), 'doc', 'html') does point to where KaTeX lives.

For a copy of R packaged into *.deb, the right path can be obtained
using file.path(R.home("doc"), "html"):

--- src/library/tools/R/utils.R (revision 84280)
+++ src/library/tools/R/utils.R (working copy)
@@ -1788,7 +1788,7 @@
 ctx <- NULL
 function() {
 if(is.null(fun) && requireNamespace("V8", quietly = TRUE)) {
-dir <- file.path(R.home(), "doc", "html")
+dir <- file.path(R.home("doc"), "html")
 ctx <<- V8::v8("window")
 ctx$source(file.path(dir, "katex", "katex.js"))
 ## Provides additional macros:

This path is also valid for an R build launched from source (without
"make install"). I don't know whether this would break a
differently-packaged build of R, though.

-- 
Best regards,
Ivan

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