[R-pkg-devel] CMake on CRAN Systems

Dear Sameh, Regarding your question about the MPCR package and the use of CMake : on a Mac, you have to look for the cmake executable in more than one place because it is not guaranteed to be on the $PATH. As

[R-pkg-devel] CMake on CRAN Systems

Hi All, We recently encountered an installation issue with our package on CRAN. We've been depending on CMake, assuming it is readily available by default, but it appears to be only available on the M1mac system but not on the others. Should we include the CMake installation within our

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

Speaking as a potential user of such a package, I wonder if that information could be put in a help page for the entire package? I've seen several packages that do such a "global" overview. I realize there might be a Suggests: entry in the DESCRIPTION file but not everyone knows how to find it

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

On Tue, 16 Jan 2024 23:53:15 +0100 Sebastian Meyer wrote: > There is a note on your help page that says > > These data are **not** immediately available in the `eglhmm` package. > > which seems to be in line with the check warning. OK. Thanks. Now that you have pointed this out, it's all

Re: [R-pkg-devel] Additional Issues: Intel

On Wed, 17 Jan 2024, Hugh Parsonage wrote: My package grattan fails the Intel[1] check with Error: segfault from C stack overflow I am unable to immediately see where in the test suite this error has occurred. I seek advice on how to fix this error. The only hunch I have is that the

Re: [R-pkg-devel] current docker image for ASAN

On 16 January 2024 at 15:54, Steven Scott wrote: | Greetings everyone, though I expect this message is mainly for Dirk. | | CRAN checks of my bsts/Boom package generate an ASAN error that the CRAN | maintainers have asked me to look into. I recall doing this before (this | error has been there

[R-pkg-devel] current docker image for ASAN

Greetings everyone, though I expect this message is mainly for Dirk. CRAN checks of my bsts/Boom package generate an ASAN error that the CRAN maintainers have asked me to look into. I recall doing this before (this error has been there for several years now) via a docker image that Dirk had set

[R-pkg-devel] Additional Issues: Intel

My package grattan fails the Intel[1] check with Error: segfault from C stack overflow I am unable to immediately see where in the test suite this error has occurred. I seek advice on how to fix this error. The only hunch I have is that the package uses C code and includes structs with

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

There is a note on your help page that says These data are **not** immediately available in the `eglhmm` package. which seems to be in line with the check warning. Best wishes, Sebastian Meyer Am 16. Januar 2024 23:13:22 MEZ schrieb Rolf Turner : > >In a package that I am updating, I have a

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

In a package that I am updating, I have a data documentation file monoCyteSim.Rd. In this file, two data sets are documented: bivarSim and ccSim. The usage section is; > \usage{ > bivarSim > ccSim > } Since the data are lazy-loaded I *don't* wrap the names of the data sets in

Re: [R-pkg-devel] test failure: oldrel

> On Jan 17, 2024, at 3:46 AM, Josiah Parry wrote: > > Hey folks! I've received note that a package of mine is failing tests on > oldrel. > > Check results: > https://www.r-project.org/nosvn/R.check/r-oldrel-windows-x86_64/arcgisutils-00check.html > > I think I've narrowed it down to the

Re: [R-pkg-devel] checking CRAN incoming feasibility

On 17 January 2024 at 09:42, Simon Urbanek wrote: | that check always hangs for me (I don't think it likes NZ ;)), so I just use | | _R_CHECK_CRAN_INCOMING_REMOTE_=0 R CMD check --as-cran ... You can also set it in Renviron files consulted just for checks: $ grep INCOMING_=

Re: [R-pkg-devel] checking CRAN incoming feasibility

Ralf, that check always hangs for me (I don't think it likes NZ ;)), so I just use _R_CHECK_CRAN_INCOMING_REMOTE_=0 R CMD check --as-cran ... Cheers, Simon > On Jan 16, 2024, at 6:49 PM, Rolf Turner wrote: > > > On Tue, 16 Jan 2024 16:24:59 +1100 > Hugh Parsonage wrote: > >>> Surely the

Re: [R-pkg-devel] test failure: oldrel

Thanks for the update! Ill be submitting a change in the coming days and will report back :) On Tue, Jan 16, 2024 at 12:12 Dirk Eddelbuettel wrote: > > On 16 January 2024 at 10:28, Josiah Parry wrote: > | Oddly making the change has made CI happy. > | >

Re: [R-pkg-devel] test failure: oldrel

On 16 January 2024 at 10:28, Josiah Parry wrote: | Oddly making the change has made CI happy.  | https://github.com/R-ArcGIS/arcgisutils/actions/runs/7543315551/job/20534063601 | | It may be that the issue was OS related but I'm unsure since only oldrel for | windows and macos check results

Re: [R-pkg-devel] test failure: oldrel

Oddly making the change has made CI happy. https://github.com/R-ArcGIS/arcgisutils/actions/runs/7543315551/job/20534063601 It may be that the issue was OS related but I'm unsure since only oldrel for windows and macos check results are published

Re: [R-pkg-devel] checking CRAN incoming feasibility

В Tue, 16 Jan 2024 08:47:07 + David Hugh-Jones пишет: > If I understand correctly, the current procedure is that the client > downloads every package name from CRAN, and then checks its name is > unique. This is not the only check that relies on utils::available.packages(). In particular,

[R-pkg-devel] test failure: oldrel

Doesn't seem to be the case as it moderately easy to check (especially when you happen to have local images of r-base around anyway): edd@rob:~$ for v in 4.3.2 4.2.2 4.1.3 4.0.5 3.6.3 3.5.3 3.4.4 3.3.3; do echo -n "R ${v}: "; docker run --rm -ti r-base:${v} Rscript -e 'as.POSIXct(Sys.Date(),

[R-pkg-devel] test failure: oldrel

Hey folks! I've received note that a package of mine is failing tests on oldrel. Check results: https://www.r-project.org/nosvn/R.check/r-oldrel-windows-x86_64/arcgisutils-00check.html I think I've narrowed it down to the way that I've written the test which uses `as.POSIXct(Sys.Date(), tz =

Re: [R-pkg-devel] checking CRAN incoming feasibility

On 16.01.2024 06:49, Rolf Turner wrote: On Tue, 16 Jan 2024 16:24:59 +1100 Hugh Parsonage wrote: Surely the software just has to check that there is web connection to a CRAN mirror. Nope! The full code is in tools:::.check_package_CRAN_incoming (the body of which filled up my entire

Re: [R-pkg-devel] checking CRAN incoming feasibility

If I understand correctly, the current procedure is that the client downloads every package name from CRAN, and then checks its name is unique. Wouldn’t it be faster (for both parties) to check name uniqueness directly on the server? Writing: wyclif.substack.com Book: www.wyclifsdust.com On