Re: [R-pkg-devel] CRAN check for package on Sparc Solaris (or other architectures)

[Ben Bolker]

For what it's worth I did install a Solaris VM on one of my machines
so I could run tests.  This does seem a little over the top as a
requirement for all package developers though ... I have easy access
to MacOS and Ubuntu so I usually test there and on win-builder as
well.

In my case, I eventually found that the warnings (related to some
parallelized code) could be reproduced in batch mode but *not* in
interactive mode on Solaris, so I just gave up and disabled the tests
on Solaris via if (Sys.info()["sysname"] != "SunOS")  (shame on me
...)

A wish-list/discussion item for the CRAN maintainers would to be add a
step to the submission process, in between pushing the button to
confirm submission to CRAN and any CRAN maintainers having to look at
the submission/interact with the submitter, would be for the CRAN
results to get posted somewhere the submitter could see them.  If
there were errors or warnings the submission would be automatically
rejected ... if there were notes the submitter would then have to add
a comment/press another button justifying that it was OK to ignore
them ... if the submission was completely clean it could automatically
go on to the CRAN maintainers ...

I don't know what the costs of this would be, beyond implementing it
in the first place. It might encourage more load on the CRAN system by
allowing developers to use it as a test rig (although the
"automatically submit to CRAN if clean" behaviour would certainly
discourage this), but it's hard for me to imagine that it wouldn't be
worth it ...


On Mon, May 25, 2015 at 6:13 PM, Viechtbauer Wolfgang (STAT)
 wrote:
> Hello All,
>
> First of all, thanks to Martin, Hadley, and Dirk (and everybody else 
> involved) for setting up this new mailing list. I am sure this will become a 
> tremendous resource for package developers.
>
> My question is in essence just a repost of what I asked on R-devel a few 
> weeks ago:
>
> https://stat.ethz.ch/pipermail/r-devel/2015-May/071147.html
>
> At the time, the 'metafor' package failed CRAN checks on Sparc Solaris.
>
> To clarify: Before I submit a new version of metafor to CRAN, I check that it 
> passes 'R CMD check --as-cran' on R-devel (both 64- and 32-bit), R-current 
> (whatever version this is at the time), and the oldest version of R specified 
> under 'Depends' (which is currently 3.1.0 for the metafor package) -- so 6 
> checks in total. All of these checks are run on Windows (yes, shoot me).
>
> Admittedly, I screwed up on some package tests (using the 'testthat' package) 
> -- using a few is_identical_to() instead of expect_equivalent() comparisons 
> -- which I shouldn't have done in the first place. But all of these passed 
> the 6 checks that I did. Not so on Sparc Solaris though (and apparently also 
> not on x86_64 Linux with --disable-long-double, but as far as I can tell, 
> http://cran.r-project.org/web/checks/check_results_metafor.html does not 
> indicate such a check).
>
> At any rate, I try to check the package thoroughly before submitting -- but 
> clearly not thorough enough. While my mistake was easy to remedy, the more 
> general question is this: Is there any possibility of checking packages on 
> various architectures, and especially Sparc Solaris, before submitting? Also, 
> I don't know how often it happens that packages pass the various flavors of R 
> on Windows/OSX/Linux but not on Sparc Solaris, so maybe this is really not 
> much of an issue. But I plan on adding additional checks to the package so 
> that code coverage is much higher -- so is CRAN itself then the only place 
> where I can end up running all checks?
>
> Best,
> Wolfgang
>
> --
> Wolfgang Viechtbauer, Ph.D., Statistician
> Department of Psychiatry and Neuropsychology
> School for Mental Health and Neuroscience
> Faculty of Health, Medicine, and Life Sciences
> Maastricht University, P.O. Box 616 (VIJV1)
> 6200 MD Maastricht, The Netherlands
> +31 (43) 388-4170 | http://www.wvbauer.com
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] CRAN check for package on Sparc Solaris (or other architectures)

[Ben Bolker]

Just went back and re-read the mailing list thread -- I think my VM is
Solaris x86, so doesn't address the Sparc Solaris question anyway ...

On Mon, May 25, 2015 at 6:24 PM, Ben Bolker  wrote:
> For what it's worth I did install a Solaris VM on one of my machines
> so I could run tests.  This does seem a little over the top as a
> requirement for all package developers though ... I have easy access
> to MacOS and Ubuntu so I usually test there and on win-builder as
> well.
>
> In my case, I eventually found that the warnings (related to some
> parallelized code) could be reproduced in batch mode but *not* in
> interactive mode on Solaris, so I just gave up and disabled the tests
> on Solaris via if (Sys.info()["sysname"] != "SunOS")  (shame on me
> ...)
>
> A wish-list/discussion item for the CRAN maintainers would to be add a
> step to the submission process, in between pushing the button to
> confirm submission to CRAN and any CRAN maintainers having to look at
> the submission/interact with the submitter, would be for the CRAN
> results to get posted somewhere the submitter could see them.  If
> there were errors or warnings the submission would be automatically
> rejected ... if there were notes the submitter would then have to add
> a comment/press another button justifying that it was OK to ignore
> them ... if the submission was completely clean it could automatically
> go on to the CRAN maintainers ...
>
> I don't know what the costs of this would be, beyond implementing it
> in the first place. It might encourage more load on the CRAN system by
> allowing developers to use it as a test rig (although the
> "automatically submit to CRAN if clean" behaviour would certainly
> discourage this), but it's hard for me to imagine that it wouldn't be
> worth it ...
>
>
> On Mon, May 25, 2015 at 6:13 PM, Viechtbauer Wolfgang (STAT)
>  wrote:
>> Hello All,
>>
>> First of all, thanks to Martin, Hadley, and Dirk (and everybody else 
>> involved) for setting up this new mailing list. I am sure this will become a 
>> tremendous resource for package developers.
>>
>> My question is in essence just a repost of what I asked on R-devel a few 
>> weeks ago:
>>
>> https://stat.ethz.ch/pipermail/r-devel/2015-May/071147.html
>>
>> At the time, the 'metafor' package failed CRAN checks on Sparc Solaris.
>>
>> To clarify: Before I submit a new version of metafor to CRAN, I check that 
>> it passes 'R CMD check --as-cran' on R-devel (both 64- and 32-bit), 
>> R-current (whatever version this is at the time), and the oldest version of 
>> R specified under 'Depends' (which is currently 3.1.0 for the metafor 
>> package) -- so 6 checks in total. All of these checks are run on Windows 
>> (yes, shoot me).
>>
>> Admittedly, I screwed up on some package tests (using the 'testthat' 
>> package) -- using a few is_identical_to() instead of expect_equivalent() 
>> comparisons -- which I shouldn't have done in the first place. But all of 
>> these passed the 6 checks that I did. Not so on Sparc Solaris though (and 
>> apparently also not on x86_64 Linux with --disable-long-double, but as far 
>> as I can tell, 
>> http://cran.r-project.org/web/checks/check_results_metafor.html does not 
>> indicate such a check).
>>
>> At any rate, I try to check the package thoroughly before submitting -- but 
>> clearly not thorough enough. While my mistake was easy to remedy, the more 
>> general question is this: Is there any possibility of checking packages on 
>> various architectures, and especially Sparc Solaris, before submitting? 
>> Also, I don't know how often it happens that packages pass the various 
>> flavors of R on Windows/OSX/Linux but not on Sparc Solaris, so maybe this is 
>> really not much of an issue. But I plan on adding additional checks to the 
>> package so that code coverage is much higher -- so is CRAN itself then the 
>> only place where I can end up running all checks?
>>
>> Best,
>> Wolfgang
>>
>> --
>> Wolfgang Viechtbauer, Ph.D., Statistician
>> Department of Psychiatry and Neuropsychology
>> School for Mental Health and Neuroscience
>> Faculty of Health, Medicine, and Life Sciences
>> Maastricht University, P.O. Box 616 (VIJV1)
>> 6200 MD Maastricht, The Netherlands
>> +31 (43) 388-4170 | http://www.wvbauer.com
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] R CMD check package subdirectory warning on filenames

[Ben Bolker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  It's specific to doc files. In the current version, section 1.4 says:

Documents in inst/doc can be in arbitrary format, however we strongly
recommend providing them in PDF format, so users on almost all
platforms can easily read them. To ensure that they can be accessed
from a browser (as an HTML index is provided), the file names should
start with an ASCII letter and be comprised entirely of ASCII letters
or digits or hyphen or underscore.

  (I didn't know that browsers had trouble accessing file names that
started with a digit?)

  I don't know when this was added ...

  Ben Bolker


On 15-06-18 08:45 AM, Kevin Coombes wrote:
> Hello,
> 
> In putting together my latest package, I'm getting the following
> warning from "R CMD check --as-cran"
> 
> * checking package subdirectories ... WARNING Subdirectory
> 'inst/doc' contains invalid file names: '02oneGeneSims.Rnw'
> '02oneGeneSims.pdf' Please remove or rename the files. See section
> 'Package subdirectories' in the 'Writing R Extensions' manual.
> 
> Having read the recommended section several times and looked
> everywhere I can to read about valid file names, I had a hard time
> figuring out why I was getting this message. Finally, I tried
> removing the "02" from the beginning of the filename, and the
> warning went away.
> 
> I still can't find anyplace in the manual that says "thou shalt
> not start a filename with a digit" or "thou shalt not start a
> filename with the number '0' followed by another digit". In fact,
> the second sentence of the section on Package subdirectories says
> "The code files to be installed must start with an ASCII (lower or
> upper case) letter or digit"
> 
> [1] Why is this restriction here?
> 
> [2] If the restriction must remain, can the warning message be
> improved so it actually tells you what the problem is? Or points to
> a place in the manual that actually tells you what the problem is?
> 
> [3] Since vignettes get listed in the help pages in alphabetical
> order, does this mean I have to call my vignettes "a.Rnw", "b.Rnw"
> and "c.Rnw" to get them listed in the order I want?
> 
> Kevin
> 
> __ 
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJVgsROAAoJEOCV5YRblxUHHtYH/Rv/pnt8LuqnV25r2tIKP2+L
LQJkboYK8OW8doZu0sExS5ObdEMtsNEi60QaIHmGV8I9FTH2J5DdxblgTThyrEsz
Znjr7XAyUiua+05EYeHezxPiSYc7ElOouUiQ3CvPC8YLWOm5vBMxPIKcpJ0mtqiW
XK9DIdvW4pcfLMNiWbPIOyjUKSMGWouN46utRICyIkBQO1z7ZWgAyxEon6bqyoiP
vwpBpdeHtLGo4VFz4D0gLvYUlWpuySG1zGvvzeuMSG25G7WnF6WbqphfCK8jd4GE
PhaqOb6QEpQ1evD7GxoD6uABkgsb8IAGTI88pAsCsTnqNbOtuUtYHlU0stxhOmw=
=fsfi
-END PGP SIGNATURE-

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

Re: [R-pkg-devel] recreating CRAN Testing environment

[Ben Bolker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15-07-20 01:50 PM, Jonathan Callahan wrote:
> I am (hopefully) at the end of a series of back-and-forth
> submissions of a package to the CRAN upload site.
> 
> I have done my best to test things by:
> 
> - using devtools - running "R CMD check --as-cran" on the command
> line - checking my package on OSX, win-builder.R and various 32 and
> 64 bit linux virtual machines at DigitalOcean
> 
> But I have never managed to recreate all of the notes and warning
> messages that the CRAN testing comes up with.
> 
> In an effort to save time and effort on both ends, can anyone
> advise on what I need to do to generate ALL the warning messages
> that the CRAN testing will find?

   The most important thing that you haven't explicitly mentioned is
to test on the most recent development version of R (check out via
Subversion/configure/make/make install from scratch).  Can you adjust
your DigitalOcean settings accordingly?

  Ben Bolker


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJVrTcSAAoJEOCV5YRblxUHNqUIAKMpuDZ5viQSBlyXpIqjtjEW
Na6LhC5O/XcjmmrZHDftXAat2gTrRM0OJAn0cfzSZttdcJKowbMYfJzDWe/5oBCE
QRQ0zwxbJY1cFHFyYR6r1zCe4ah4SzoGt+FmBYjtAKefvjm12tfQubhQlxPxZ1kV
XFIfYTWHmHWNGlhZuokPE/GtdXK5/4MNF/32HxseNBRzc2SWqP3i6VKPnbN7LFgl
xrjXsHQdqU3UaY37D44mInl+qm5y5reRSUi6NO0SrSh2WcVWTnqZ3HsUkFPND5tM
NyzrfhtGN2wISsFq1J+dC87ajyeh6D8LTYBiokUnWQFOj8tPi1Zhff0LuTJi7Vc=
=gytX
-END PGP SIGNATURE-

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

Re: [R-pkg-devel] .tar vs. binary builds

[Ben Bolker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15-08-03 04:31 PM, Glenn Schultz wrote:
> Hello All,
> 
> I have a package which I would like to distribute.  However, there
> are some classes that are not exported if I provide a tar file can
> the user decompress the tar to the source and then export class.  I
> am thinking the answer is year since the tar is source code.
> Conversely, a binary build would prohibit this - correct?
> 
> Best Regards, Glenn __ 
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

  Not really clear what your question is.  If you distribute a source
package/'tarball' (i.e. .tar, typically compressed to .tar.gz) then
users can install via R CMD INSTALL [...] or within R
install.packages("...",repos=NULL).  Then they'll have access to
everything that is exported via your NAMESPACE file.  Can you be more
concrete/specific/clear about what you have in mind?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJVv9KLAAoJEOCV5YRblxUHnokIANorhDR3olkH3zLlt9ZoYMS+
uNuVfRuF9JOhe2BD0C4fEUEkPp0IjnNNcDdP1R6gBSaj8ai+Lq2qOKucwPpll6zr
9q+5jUxKaQJmO6QBzMJODSSflFjZmbwZHhb0QLzDMfn41cAcg18K0uW6SLH91avF
kqPxVGn2sAccBuZtjbjCdPfRHalg/N0rSmvgWDNTtVQhbZJFfAwopgVqVyMKm2wV
K+J2xGd85NAkHCT/1No0ghG5s6/GTXjsfD0O5qJ07Ut5/GwLaWkeS9F9fEHPvziC
XlwOjsaOg8YNpCWi2aycrQYt9zINNTmFsN0Zrg/k+x2Zuoim9QeTHdWnWT8K85I=
=enco
-END PGP SIGNATURE-

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

Re: [R-pkg-devel] .tar vs. binary builds

[Ben Bolker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 15-08-03 06:34 PM, Glenn Schultz wrote:
> Hi Ben,

[Please keep the list cc'd in your replies.]

> Thanks for answering so quickly.  Basically, I want to be able to
  distribute the package to users and testers some are on Mac others
  Windows.  I am looking for the best way to do this but for the time
  being there are some classes which should not be extended.  So the
  .tar being source may allow a user to uncompress the source and
  alter and export a class that needs to be protected from change.
  Basically, I want to open source a mortgage and asset backed
  valuation tool but there are certain classes that for now should not
  changed or extended.

I don't know how expert your users are, or what kind of
social/moral/administrative control you have over what they do with
your code. Building binary packages does strip out some information,
but since R is an interpreted language, the information needed to
change/modify/extend the code would still be present for a
sufficiently motivated user.  You will definitely gain some degree of
security/write-protection through obscurity, but not any real
protection.  R can be obfuscated, but it is not designed for being
locked down; if you really need security, the general advice is to
provide a front-end to the users via a server you control.

> Glenn
> 
> Sent from my iPhone
> 
>> On Aug 3, 2015, at 3:43 PM, Ben Bolker  
>> wrote:
>> 
>>>> On 15-08-03 04:31 PM, Glenn Schultz wrote: Hello All,
>>>> 
>>>> I have a package which I would like to distribute.  However, 
>>>> there are some classes that are not exported if I provide a 
>>>> tar file can the user decompress the tar to the source and 
>>>> then export class.  I am thinking the answer is year since 
>>>> the tar is source code. Conversely, a binary build would 
>>>> prohibit this - correct?
>>>> 
>>>> Best Regards, Glenn 
>>>> __ 
>>>> R-package-devel@r-project.org mailing list 
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> Not really clear what your question is.  If you distribute a source
> package/'tarball' (i.e. .tar, typically compressed to .tar.gz) then
> users can install via R CMD INSTALL [...] or within R
> install.packages("...",repos=NULL).  Then they'll have access to 
> everything that is exported via your NAMESPACE file.  Can you be 
> more concrete/specific/clear about what you have in mind?
> 
>> 
>> __ 
>> R-package-devel@r-project.org mailing list 
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJVv/OIAAoJEOCV5YRblxUHfiMIAJwlKENYU3a2rj3npiJC59XO
ZxeBVBhDnWGrPN9g+w4pimSFZhJ2QD5+WuyA/SiuLN9vlVjBfzo7VGjRBqDopsmt
7/j1ACfx2Jz2uvnUWmb7IRI2uEBR+yIezuQbY0m6gbzKIrDHT8PYXkNvBnRW1EkA
c2T8C5pPocSCwyKCgqPARoCd16+Va6rzV1aCjuhJHk5tgH8a7IampP4dn9w/coRN
CLzJEWpXhzP+9fhSaG5bdLm3cTgDxybPDwPAvkWFhmmKrd3kpf69jMYUxIkyqgu8
HkLX4BT6s5qvURvmT1DyAY2pztJWaX2Gd3n1aEUze91Du8yq85miiGexWUZTDPc=
=uGhT
-END PGP SIGNATURE-

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

Re: [R-pkg-devel] R CMD check yielding different results for me than CRAN reviewer

[Ben Bolker]

The most common scenario is that you're using R-release and the
warnings are coming from the R-devel version, which often has a bunch
of new, additional tests.

The other frequent answer to this question (is there a FAQ list for
this mailing list yet?) is that using CRAN's win-builder service is a
very easy way to get access to the R-release and R-devel tests without
changing anything in your local setup.


On Tue, Jan 26, 2016 at 2:03 PM, Adah Zhang  wrote:
> Hello,
>
> I am running R CMD check (and also with the --as-cran flag), which results
> in all OK's in my 00check.log. However, after submitting the package, the
> CRAN reviewer tells me of a warning/error regarding one of my examples
> (which is easily fix-able if I got the warning myself).
>
> How do I ensure that all warnings, errors, and notes are addressed if I do
> not receive these when running the standard checks or when testing the
> examples myself? Is there a standard order of commands that a CRAN reviewer
> goes through aside from 'R CMD check'?
>
> Thanks,
> Adah
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Is it possible to reverse engineer a package from the installed library directory ?

[Ben Bolker]

 You could take your old install and do this:

  library("your_package")
  funs <- ls(pos="package:your_package")
  dump(funs,"your_package.R")

  that wouldn't recreate documentation, NAMESPACE files, etc., but it 
would be a start.


On 16-03-23 04:43 PM, Paul Hurley wrote:

Several years ago I assembled some of my own most used code into a package,
and had that installed on my machine.  Since then I have lost the source
files, but still have the package installed in an old v2.x R installation.

I now need to use the package in my current R install, which is v3.1, and
won't let me just copy the directory across, as it complains it was build
pre v3.  Is it possible to reverse engineer a package back to R source
files so I can then rebuild it in a new package ?

Thanks

Paul.

--http://www.paulhurley.co.uk

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] Has GitHub been used as a CRAN-style repository?

[Ben Bolker]

   Check out the drat package.

On 16-04-27 09:00 AM, Bruce Hoff wrote:
> Dear All:
> 
> devtools::install_github() is great but, as I understand it, limited to
> installing from source code.  Is there any precedent for using a public
> repository like GitHub as a CRAN-style repository, so that one can install
> like so:
> 
> install.packages("mypackage", repos= "https://github.com/myrepo/mypackage";)
> 
> ?
> This would allow the distribution of packages that need compilation without
> requiring that the user set up a build system and would leverage R's
> ability to find and install dependencies (by stringing together multiple
> URLs in the 'repos' parameter).  Of course there's a greater burden on the
> package provider, who has to build their package for Mac and Windows.
> 
> It strikes me that this could be a good way to decentralize CRAN, allowing
> it to be maintained by package owners rather than a central authority.
> 
> I searched around but could not find examples of people using Github in
> this way.
> 
> Bruce Hoff
> Sage Bionetworks
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Data for unit testing in packages

[Ben Bolker]

  I usually put it in inst/testdata and access it via system.file()


On 16-05-20 01:45 PM, carlos cinelli wrote:
> Do you guys have any suggestions on how to store data for unit testing?
> 
> I am implementing some methods to estimate matrix entries from the
> marginals.  The input of the function is the row and column sums and the
> output is a N x N matrix.
> 
> What I am doing today is constructing the expected output by hand.
> 
> One example I am testing is a 7 x 7 matrix, which is fine to just put the
> code to create it on the test script.
> 
> However, I also want to create tests on larger examples, say a 1000 x 1000
> matrix, in which it would not be very handy to leave the code on the script.
> 
> Do you have any suggestions or best practices for that?
> 
> Best,
> 
> Carlos
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Warning that are Unintentionally OS-Specific (Maybe Bug in warning?)

[Ben Bolker]

   Digging into the code (specifically by setting
options(warn=2,error=recover), I see that the warning is happening
during this call:

tmp.results <- parallel::mclapply(X = conc.dose, FUN =
pk.nca.intervals,
intervals = data$intervals, options = data$options)

Since mclapply "relies on forking and hence is not available on Windows
unless ‘mc.cores = 1’" (from ?mclapply), I can imagine that it's *not*
actually being run in parallel on Windows.  It also wouldn't surprise me
at all if it took a little bit of care to make sure that warnings were
correctly passed back from code chunks run in parallel.

  This StackOverflow post seems to ask the same question as yours:

http://stackoverflow.com/questions/21486658/warnings-suppressed-with-mclapply-in-r

  based on the discussion there, it seems as though it might be worth
bringing this up on r-devel/submitting a bug report ...

   Ben Bolker




On 16-07-20 03:13 PM, Bill Denney wrote:
> Hi François,
> 
> I thought that was the issue, too, but I confirmed it wasn't that by
> adding a print statement right above the warning in my code. The print
> statement displays the message even when the warning (one line below
> with no conditionals between) doesn't show anything.
> 
> Also, why would it behave differently when options(warn=1) is set rather
> than the default of options(warn=0)?
> 
> Thanks,
> 
> Bill
> 
> 
> On 7/20/2016 3:06 PM, François Michonneau wrote:
>> Hi Bill,
>>
>>The problem is not with the warning() function but with your if()
>> test that triggers the warning. It probably has something to do with
>> slight differences in rounding. I suggest you use debug() or browser()
>> on each platform to see why your condition is TRUE or FALSE.
>>
>>Cheers,
>>-- François
>>
>> On Wed, Jul 20, 2016 at 2:42 PM, Bill Denney  wrote:
>>> Hi,
>>>
>>> I'm developing the PKNCA package, and I've got an odd difference between
>>> warning behavior on different operating systems that I can't figure out.
>>>
>>> When I run the following code on Windows 10 (with R 3.3.0), I get the
>>> following warning:
>>>
>>> library(PKNCA)
>>> source("https://raw.githubusercontent.com/billdenney/pknca/master/tests/testthat/generate.data.R";)
>>>
>>> tmpconc <- generate.conc(2, 1, 0:24)
>>> tmpconc$conc <- 0
>>> tmpdose <- generate.dose(tmpconc)
>>> myconc <- PKNCAconc(tmpconc, conc~time|treatment+ID)
>>> mydose <- PKNCAdose(tmpdose, dose~time|treatment+ID)
>>> mydata <- PKNCAdata(myconc, mydose)
>>> myresult <- pk.nca(mydata)
>>>
>>> Warning messages:
>>> 1: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
>>>Too few points for half-life calculation (min.hl.points=3 with only 0
>>> points)
>>> 2: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
>>>Too few points for half-life calculation (min.hl.points=3 with only 0
>>> points)
>>>
>>> When I run the code on Linux (Ubuntu 16.04 with R 3.3.1), I do not get a
>>> warning.  When I run the code on Linux after "options(warn=1)", I get
>>> the
>>> warning.  I have confirmed that the same code path is taken in both
>>> Windows
>>> and Linux by simply inserting a print statement next to the warning. 
>>> The
>>> actual warning code is:
>>>
>>>  warning(sprintf(
>>>"Too few points for half-life calculation (min.hl.points=%g
>>> with only
>>> %g points)",
>>>min.hl.points, nrow(dfK)))
>>>
>>> This platform inconsistency is causing issues with my package because
>>> the
>>> package expects the warnings, and the user should know about the
>>> warnings.
>>> I've got test cases expecting the warnings, and they fail everywhere but
>>> Windows
>>> (https://cran.r-project.org/web/checks/check_results_PKNCA.html).
>>>
>>> Does anyone have an idea why warnings may behave differently on Windows
>>> compared to non-Windows platforms?  Is this a bug in R somewhere? 
>>> (I've not
>>> been able to make a simpler example that triggers the issue,
>>> unfortunately.)
>>>
>>> Thanks,
>>>
>>> Bill
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Possible mis-spelled words ...

[Ben Bolker]

Previous conversation on r-devel:

https://stat.ethz.ch/pipermail/r-devel/2014-December/070237.html

Martin Mächler suggests that a patch to R-devel would be welcome:

> I agree that some customization possibility would be great here.
> Maybe it'll be sufficient to allow a short list of about a dozen
> words in the DESCRIPTION itself, e.g., with an item
>
>   Extrawords: rowMedians, rowRanks


On 16-07-21 05:48 PM, Rolf Turner wrote:
> 
> I just had a revision of a package built by win-builder, as a way of
> exposing it to a rigorous check before uploading it to CRAN.
> 
> The 00check.log contained the note:
> 
>> Possibly mis-spelled words in DESCRIPTION:
>>   Delaunay (4:8, 10:29)
>>   Voronoi (4:46, 11:5)
>>   triangulations (12:28)
> 
> The spellings are, as far as I can tell correct.  Is there a way of
> telling the package checker that these spellings are OK?
> 
> I have a very vague recollection of having seen something about this
> topic on this mailing list, but a search of the archives turned up
> nothing.  Nor could I find anything about "mis-spellings" in "Writing R
> Extensions".
> 
> I don't like leaving a package in a state in which the package checker
> produces NOTES.  Is there anything that I can do about this one?   Other
> than remove the offending words, which I am reluctant to do.
> 
> cheers,
> 
> Rolf Turner
>

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

Re: [R-pkg-devel] Source code of an existing package

[Ben Bolker]

 Easiest way:

  library(boot)
  boot.ci

Alternatively, go to https://cran.r-project.org/package=boot ,
download the tarball, unpack it, and look around in the R/ directory.

On 16-08-10 09:42 PM, Marcelo Carvalho Fernandes wrote:
> Hi all!
> 
> I am interested in seeing the source code of the boot.ci() function of the 
> boot package.
> 
> Is it possible to have such source code? How?
> 
> Thanks in advance,
> 
> ---
> Marcelo Carvalho Fernandes
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Including Rcpp in an existing package

[Ben Bolker]

 A mistake that I have made repeatedly is forgetting to add an
appropriate UseDynLib() call to the NAMESPACE file.

On 16-12-22 02:15 PM, Duncan Murdoch wrote:
> On 22/12/2016 1:55 PM, Glenn Schultz wrote:
>> All,
>> My package was not initially built with the rcpp use in mind.  I have
>> to include C++ source code for a particular project so I will have
>> edit the description file add src files, etc.  by hand.  I an going
>> over the rcpp documentation now and reviewing the R documentation on
>> extensions as well.  Is there anything in particular that I should
>> keep in mind while doing this or is this relatively straightforward.
> 
> It should be pretty straightforward.  There are lots of examples of
> packages that do it (not all of which are simple); see the list of
> "reverse " on https://CRAN.R-project.org/package=Rcpp (where  is
> Depends, Imports, Suggests, or LinkingTo).
> 
> Duncan Murdoch
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] warning from win_build

[Ben Bolker]

  I think this is a ggplot2-related issue.  Matt Dowle posted about it:

http://blog.h2o.ai/2016/12/behind-the-scenes-of-cran/


On 16-12-29 01:16 PM, Roy Mendelssohn - NOAA Federal wrote:
> Hi All:
> 
> I am working on a new submission of my xtractomatic package  (the
> main change being the use of https).  I develop on a Mac.  When I run
> on the Mac:
> 
> devtools::check()
> 
> I get no errors, notes, or warnings.  However, when I run
> devtools::build_win(), the response I get back isL
> 
> 
>> * checking for unstated dependencies in vignettes ... OK * checking
>> package vignettes in 'inst/doc' ... OK * checking re-building of
>> vignette outputs ... WARNING Error in re-building vignettes: ... 
>> Quitting from lines 248-261 (Usingxtractomatic.Rmd) Error:
>> processing vignette 'Usingxtractomatic.Rmd' failed with
>> diagnostics: (converted from warning) Calling 'structure(NULL, *)'
>> is deprecated, as NULL cannot have attributes. Consider
>> 'structure(list(), *)' instead. Execution halted
>> 
> 
> So this error is from my Vignette.  The offending lines appear to
> be:
> 
>> ```{r topotagPlot, fig.align = 'center', fig.width = 6, fig.height
>> = 4, warning = FALSE} require("ggplot2") alldata <- cbind(tagData,
>> topo) alldata$lon <- alldata$lon - 360 z <- ggplot(alldata, aes(x =
>> lon,y = lat)) + geom_point(aes(colour = mean), size = 2.) + 
>> scale_shape_manual(values = c(19, 1)) z + geom_polygon(data = w,
>> aes(x = long, y = lat, group = group), fill = "grey80") + 
>> theme_bw() + scale_colour_gradient("Depth") + coord_fixed(1.3, xlim
>> = xlim, ylim = ylim) + ggtitle("Bathymetry at marlin tag
>> locations")
>> 
>> ```
>> 
> 
> 
> Now the vignette builds fine on my machine,  and  I can run it by
> "hand"  (as an R Notebook, executing each chunk) and it works also.
> Looking at the offending code chunk,  I can honestly say I have no
> idea what the error message is referring to.When I run by hand,
> I have checked that both tagData and topo are properly defined.  But
> is that the problem,  is the error message from the  cbind?
> 
> Thanks for any help.
> 
> -Roy
> 
> 
> ** "The contents of this message do not reflect
> any position of the U.S. Government or NOAA." ** 
> Roy Mendelssohn Supervisory Operations Research Analyst NOAA/NMFS 
> Environmental Research Division Southwest Fisheries Science Center 
> ***Note new street address*** 110 McAllister Way Santa Cruz, CA
> 95060 Phone: (831)-420-3666 Fax: (831) 420-3980 e-mail:
> roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
> 
> "Old age and treachery will overcome youth and skill." "From those
> who have been given much, much will be expected" "the arc of the
> moral universe is long, but it bends toward justice" -MLK Jr.
> 
> __ 
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] warning from win_build

[Ben Bolker]

  Sorry, correction/clarification to my last post: it's *not* a bug in
ggplot2, rather apparently (?) it's something in base R that has broken
tests in both data.table and ggplot2. (Since your code calls ggplot,
though, it's presumably in there somewhere, and (?) not your problem.)

  cheers
Ben



On 16-12-29 01:16 PM, Roy Mendelssohn - NOAA Federal wrote:
> Hi All:
> 
> I am working on a new submission of my xtractomatic package  (the
> main change being the use of https).  I develop on a Mac.  When I run
> on the Mac:
> 
> devtools::check()
> 
> I get no errors, notes, or warnings.  However, when I run
> devtools::build_win(), the response I get back isL
> 
> 
>> * checking for unstated dependencies in vignettes ... OK * checking
>> package vignettes in 'inst/doc' ... OK * checking re-building of
>> vignette outputs ... WARNING Error in re-building vignettes: ... 
>> Quitting from lines 248-261 (Usingxtractomatic.Rmd) Error:
>> processing vignette 'Usingxtractomatic.Rmd' failed with
>> diagnostics: (converted from warning) Calling 'structure(NULL, *)'
>> is deprecated, as NULL cannot have attributes. Consider
>> 'structure(list(), *)' instead. Execution halted
>> 
> 
> So this error is from my Vignette.  The offending lines appear to
> be:
> 
>> ```{r topotagPlot, fig.align = 'center', fig.width = 6, fig.height
>> = 4, warning = FALSE} require("ggplot2") alldata <- cbind(tagData,
>> topo) alldata$lon <- alldata$lon - 360 z <- ggplot(alldata, aes(x =
>> lon,y = lat)) + geom_point(aes(colour = mean), size = 2.) + 
>> scale_shape_manual(values = c(19, 1)) z + geom_polygon(data = w,
>> aes(x = long, y = lat, group = group), fill = "grey80") + 
>> theme_bw() + scale_colour_gradient("Depth") + coord_fixed(1.3, xlim
>> = xlim, ylim = ylim) + ggtitle("Bathymetry at marlin tag
>> locations")
>> 
>> ```
>> 
> 
> 
> Now the vignette builds fine on my machine,  and  I can run it by
> "hand"  (as an R Notebook, executing each chunk) and it works also.
> Looking at the offending code chunk,  I can honestly say I have no
> idea what the error message is referring to.When I run by hand,
> I have checked that both tagData and topo are properly defined.  But
> is that the problem,  is the error message from the  cbind?
> 
> Thanks for any help.
> 
> -Roy
> 
> 
> ** "The contents of this message do not reflect
> any position of the U.S. Government or NOAA." ** 
> Roy Mendelssohn Supervisory Operations Research Analyst NOAA/NMFS 
> Environmental Research Division Southwest Fisheries Science Center 
> ***Note new street address*** 110 McAllister Way Santa Cruz, CA
> 95060 Phone: (831)-420-3666 Fax: (831) 420-3980 e-mail:
> roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
> 
> "Old age and treachery will overcome youth and skill." "From those
> who have been given much, much will be expected" "the arc of the
> moral universe is long, but it bends toward justice" -MLK Jr.
> 
> __ 
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] UseR! Session: Navigating the jungle of R packages.

[Ben Bolker]

  I definitely read the task views and advise others to do so.  I
don't know how representative my little corner of the world is,
though.

  I have an embryonic task view on mixed models at
https://github.com/bbolker/mixedmodels-misc/blob/master/MixedModels.ctv
but the perfect is the enemy of the good ...


On Fri, Feb 10, 2017 at 9:56 AM, J C Nash  wrote:
> We'd be more than happy to have you contribute directly. The goal is not
> just an
> information session, but to get some movement to ways to make the package
> collection(s)
> easier to use effectively. Note to selves: "effectively" is important -- we
> could make
> things easy by only recommending a few packages.
>
> Best, JN
>
>
> On 2017-02-10 09:29 AM, Michael Dewey wrote:
>>
>> Dear all
>>
>> That seems an interesting session. I am the maintainer of one of the CRAN
>> Task Views (MetaAnalysis) and will attend
>> unless I am successful in the draw for Wimbledon tickets.
>>
>> Just in case I strike lucky one question I would have raised from the
>> floor if I were there would have been "Does anyone
>> read the Task Views?". Since I started mine I have received only a couple
>> of suggestions for additions including a very
>> abrupt one about a package which had been included for months but whose
>> author clearly did not read before writing. So I
>> would ask whether we need to focus much energy on the Task Views.
>>
>> So, maybe see you there, maybe not.
>>
>>
>> On 16/01/2017 14:57, ProfJCNash wrote:
>>>
>>> Navigating the Jungle of R Packages
>>>
>>> The R ecosystem has many packages in various collections,
>>> especially CRAN, Bioconductor, and GitHub. While this
>>> richness of choice speaks to the popularity and
>>> importance of R, the large number of contributed packages
>>> makes it difficult for users to find appropriate tools for
>>> their work.
>>>
>>> A session on this subject has been approved for UseR! in
>>> Brussels. The tentative structure is three short
>>> introductory presentations, followed by discussion or
>>> planning work to improve the tools available to help
>>> users find the best R package and function for their needs.
>>>
>>> The currently proposed topics are
>>>
>>> - wrapper packages that allow diverse tools that perform
>>>   similar functions to be accessed by unified calls
>>>
>>> - collaborative mechanisms to create and update Task Views
>>>
>>> - search and sort tools to find packages.
>>>
>>> At the time of writing we have tentative presenters for
>>> the topics, but welcome others. We hope these presentations
>>> at useR! 2017 will be part of a larger discussion that will
>>> contribute to an increased team effort after the conference
>>> to improve the the support for R users in these areas.
>>>
>>>
>>> John Nash, Julia Silge, Spencer Graves
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] UseR! Session: Navigating the jungle of R packages.

[Ben Bolker]

  I don't have a problem with this, but there are a few challenges.

 - continuity: there used to be an R wiki, but it eventually disappeared
(http://wiki.r-project.org now redirects to the main www.r-project.org page)
 - actual contributions: I never got much feedback or contributions to
http://glmm.wikidot.com/glmmFAQ (which is now moved to
https://github.com/bbolker/mixedmodels-misc/blob/master/glmmFAQ.rmd ).
If individual task view maintainers wanted to post their stuff on
GitHub, it would make it easy for *some* users (those with a bit more
technical facility) to raise issues and submit pull requests ...)


On 17-02-11 12:09 PM, Spencer Graves wrote:
> Hi, Ben et al.:
> 
> 
>   What do you think about converting the Task Views into a wiki?
> 
> 
>   The Wikimedia rules do pretty well in inviting anyone to
> contribute material, ensuring that it is noteworthy and high quality,
> and managing any conflicts -- and no one person has to be responsible
> for any specific thing.
> 
> 
>   Spencer Graves
> 
> 
> On 2017-02-10 10:51 AM, Ben Bolker wrote:
>>I definitely read the task views and advise others to do so.  I
>> don't know how representative my little corner of the world is,
>> though.
>>
>>I have an embryonic task view on mixed models at
>> https://github.com/bbolker/mixedmodels-misc/blob/master/MixedModels.ctv
>> but the perfect is the enemy of the good ...
>>
>>
>> On Fri, Feb 10, 2017 at 9:56 AM, J C Nash  wrote:
>>> We'd be more than happy to have you contribute directly. The goal is not
>>> just an
>>> information session, but to get some movement to ways to make the
>>> package
>>> collection(s)
>>> easier to use effectively. Note to selves: "effectively" is important
>>> -- we
>>> could make
>>> things easy by only recommending a few packages.
>>>
>>> Best, JN
>>>
>>>
>>> On 2017-02-10 09:29 AM, Michael Dewey wrote:
>>>> Dear all
>>>>
>>>> That seems an interesting session. I am the maintainer of one of the
>>>> CRAN
>>>> Task Views (MetaAnalysis) and will attend
>>>> unless I am successful in the draw for Wimbledon tickets.
>>>>
>>>> Just in case I strike lucky one question I would have raised from the
>>>> floor if I were there would have been "Does anyone
>>>> read the Task Views?". Since I started mine I have received only a
>>>> couple
>>>> of suggestions for additions including a very
>>>> abrupt one about a package which had been included for months but whose
>>>> author clearly did not read before writing. So I
>>>> would ask whether we need to focus much energy on the Task Views.
>>>>
>>>> So, maybe see you there, maybe not.
>>>>
>>>>
>>>> On 16/01/2017 14:57, ProfJCNash wrote:
>>>>> Navigating the Jungle of R Packages
>>>>>
>>>>> The R ecosystem has many packages in various collections,
>>>>> especially CRAN, Bioconductor, and GitHub. While this
>>>>> richness of choice speaks to the popularity and
>>>>> importance of R, the large number of contributed packages
>>>>> makes it difficult for users to find appropriate tools for
>>>>> their work.
>>>>>
>>>>> A session on this subject has been approved for UseR! in
>>>>> Brussels. The tentative structure is three short
>>>>> introductory presentations, followed by discussion or
>>>>> planning work to improve the tools available to help
>>>>> users find the best R package and function for their needs.
>>>>>
>>>>> The currently proposed topics are
>>>>>
>>>>> - wrapper packages that allow diverse tools that perform
>>>>>similar functions to be accessed by unified calls
>>>>>
>>>>> - collaborative mechanisms to create and update Task Views
>>>>>
>>>>> - search and sort tools to find packages.
>>>>>
>>>>> At the time of writing we have tentative presenters for
>>>>> the topics, but welcome others. We hope these presentations
>>>>> at useR! 2017 will be part of a larger discussion that will
>>>>> contribute to an increased team effort after the conference
>>>>> to improve the the support for R users in these areas.
>>>>>
>>>>>
>>>>> John Nash, Julia Silge, Spencer Graves
>>>>>
>>>>> __
>>>>> R-package-devel@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Ben Bolker]

On 17-03-15 11:09 AM, J C Nash wrote:
> Possibly tangential, but has there been any effort to set up a Sparc
> testbed? It
> seems we could use a network-available (virtual?) machine, since this
> platform is
> often the unfortunate one. Unless, of course, there's a sunset date.
> 
> For information, I mentioned SPARC at our local linux group, and
> apparently there
> are a couple of folk who have them running, but I didn't find out the
> state of the
> OS etc.
> 
> JN

  The virtual machine platforms I know of (admittedly not a complete
list!) only support Solaris on x86, e.g.

https://community.oracle.com/thread/2569292



> 
> 
> On 2017-03-15 10:40 AM, Avraham Adler wrote:
>> Hello.
>>
>> The Delaporte package works properly on all R-core platforms except
>> Solaris SPARC, where it  compiles properly but fails a number of its
>> tests [1]. Not having access to a SPARC testbed, I'm limited in what
>> kind of diagnostics I can do. One thing I have noticed is that a lot
>> of the failures occur when I am passing non-default logicals (like
>> lower tail or log). For example, the first failure at that link is
>> when "log = true" is supposed to be passed, but the SPARC answers are
>> the unlogged values. Of the 22 failed tests, 12 of them pass logicals.
>>
>> I'll bring an example of how it is coded below, and if anyone
>> recognizes where SPARC specifically goes wrong, I'd appreciate. I
>> guess, if I absolutely had to, I could convert the logical to an
>> integer in C and pass the integer to Fortran which should work even
>> for SPARC, but I'd prefer not to if I could help it.
>>
>> Thank you,
>>
>> Avi
>>
>> [1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
>>
>> *Example Code*
>>
>> R code:
>>
>> ddelap <- function(x, alpha, beta, lambda, log = FALSE){
>>   if(!is.double(x)) {storage.mode(x) <- 'double'}
>>   if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
>>   if(!is.double(beta)) {storage.mode(beta) <- 'double'}
>>   if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
>>   if(any(x > floor(x))) {
>> warning("Non-integers passed to ddelap. These will have 0
>> probability.")
>>   }
>>   .Call(ddelap_C, x, alpha, beta, lambda, log)
>> }
>>
>> C code:
>>
>> void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
>> double *l, int nl,
>>   int *lg, double *ret);
>>
>> extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
>> lg){
>>   const int nx = LENGTH(x);
>>   const int na = LENGTH(alpha);
>>   const int nb = LENGTH(beta);
>>   const int nl = LENGTH(lambda);
>>   SEXP ret;
>>   PROTECT(ret = allocVector(REALSXP, nx));
>>   ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
>> nl, LOGICAL(lg), REAL(ret));
>>   UNPROTECT(1);
>>   return(ret);
>> }
>>
>> Fortran: (not posting ddelap_f_s as that doesn't handle the logging)
>>
>> subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
>> name="ddelap_f")
>>
>> integer(kind = c_int), intent(in), value :: nx, na, nb, nl
>> ! Sizes
>> real(kind = c_double), intent(in), dimension(nx) :: x
>> ! Observations
>> real(kind = c_double), intent(out), dimension(nx):: pmfv
>> ! Result
>> real(kind = c_double), intent(in):: a(na), b(nb),
>> l(nl)! Parameters
>> logical(kind = c_bool), intent(in)   :: lg
>> ! Log flag
>> integer  :: i
>> ! Integer
>>
>> !$omp parallel do default(shared) private(i)
>> do i = 1, nx
>> if (x(i) > floor(x(i))) then
>> pmfv(i) = ZERO
>> else
>> pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
>>  b(mod(i - 1, nb) + 1), l(mod(i -
>> 1, nl) + 1))
>> end if
>> end do
>> !$omp end parallel do
>>
>> if (lg) then
>> pmfv = log(pmfv)
>> end if
>>
>> end subroutine ddelap_f
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Ben Bolker]

I completely agree that testing on SPARC Solaris is valuable, however
much of a nuisance it is.  But I also agree that it would be great if
we could find a way to provide a publicly accessible SPARC Solaris
testing framework.

On Thu, Mar 16, 2017 at 6:49 AM, Uwe Ligges
 wrote:
>
>
> On 15.03.2017 18:30, Ben Bolker wrote:
>>
>>
>>
>> On 17-03-15 11:09 AM, J C Nash wrote:
>>>
>>> Possibly tangential, but has there been any effort to set up a Sparc
>>> testbed? It
>>> seems we could use a network-available (virtual?) machine, since this
>>> platform is
>>> often the unfortunate one. Unless, of course, there's a sunset date.
>>>
>>> For information, I mentioned SPARC at our local linux group, and
>>> apparently there
>>> are a couple of folk who have them running, but I didn't find out the
>>> state of the
>>> OS etc.
>>>
>>> JN
>>
>>
>>   The virtual machine platforms I know of (admittedly not a complete
>> list!) only support Solaris on x86, e.g.
>
>
> Yes, you cannot emulate a Sparc in an efficient way on an amd64 platform.
>
> I take the opportunity to repeat why testing on *Sparc Solaris* gives many
> benefits:
>
> - this way we cover big- and little-endian platforms (i.e. for future
> stability so that it works on what appear to be still esoteric such as ARM
> based architectures or so)
> - we cover one of the commercial unixes, i.e. we see
>   + how stuff works on the the typically rather old toolchains
>   + and what happens in on gnu/gcc-setups and how much GNUisms are used
>
> Best,
> Uwe Ligges
>
>
>
>>
>> https://community.oracle.com/thread/2569292
>>
>>
>>
>>>
>>>
>>> On 2017-03-15 10:40 AM, Avraham Adler wrote:
>>>>
>>>> Hello.
>>>>
>>>> The Delaporte package works properly on all R-core platforms except
>>>> Solaris SPARC, where it  compiles properly but fails a number of its
>>>> tests [1]. Not having access to a SPARC testbed, I'm limited in what
>>>> kind of diagnostics I can do. One thing I have noticed is that a lot
>>>> of the failures occur when I am passing non-default logicals (like
>>>> lower tail or log). For example, the first failure at that link is
>>>> when "log = true" is supposed to be passed, but the SPARC answers are
>>>> the unlogged values. Of the 22 failed tests, 12 of them pass logicals.
>>>>
>>>> I'll bring an example of how it is coded below, and if anyone
>>>> recognizes where SPARC specifically goes wrong, I'd appreciate. I
>>>> guess, if I absolutely had to, I could convert the logical to an
>>>> integer in C and pass the integer to Fortran which should work even
>>>> for SPARC, but I'd prefer not to if I could help it.
>>>>
>>>> Thank you,
>>>>
>>>> Avi
>>>>
>>>> [1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
>>>>
>>>> *Example Code*
>>>>
>>>> R code:
>>>>
>>>> ddelap <- function(x, alpha, beta, lambda, log = FALSE){
>>>>   if(!is.double(x)) {storage.mode(x) <- 'double'}
>>>>   if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
>>>>   if(!is.double(beta)) {storage.mode(beta) <- 'double'}
>>>>   if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
>>>>   if(any(x > floor(x))) {
>>>> warning("Non-integers passed to ddelap. These will have 0
>>>> probability.")
>>>>   }
>>>>   .Call(ddelap_C, x, alpha, beta, lambda, log)
>>>> }
>>>>
>>>> C code:
>>>>
>>>> void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
>>>> double *l, int nl,
>>>>   int *lg, double *ret);
>>>>
>>>> extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP
>>>> lg){
>>>>   const int nx = LENGTH(x);
>>>>   const int na = LENGTH(alpha);
>>>>   const int nb = LENGTH(beta);
>>>>   const int nl = LENGTH(lambda);
>>>>   SEXP ret;
>>>>   PROTECT(ret = allocVector(REALSXP, nx));
>>>>   ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
>>>> nl, LOGICAL(lg), REAL(ret));
>>>>   UNPROTECT(1);
>>>>   return(ret);
&g

Re: [R-pkg-devel] R Package Submission Problem

[Ben Bolker]

Also from the CRAN submission guidelines:

> If there are warnings or notes you cannot eliminate (for example
because you believe them to be spurious) send an explanatory note as
part of your covering email, or as a comment on the submission form.

  This would apply to your spelling issues.


On 17-09-27 03:29 PM, Uwe Ligges wrote:
> More important:
> 
> Checking should be performed on sources prepared by 'R CMD build'.
> 
> So at first prepare the sources via R CMD build and then check yourself
> prior to submission following the CRAN policies. And *really* read that.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> 
> On 27.09.2017 21:02, MTurgeon wrote:
>> Hi Younathan,
>>
>> You can ignore the first note: it simply says that this is a new package.
>>
>> The second note highlights a few possible problems with your
>> DESCRIPTION file. It flags the word "Plasmode" as being possibly
>> misspelled; if it isn't, you can ignore the comment. Then it points
>> out that the Title field contains the name of the package; as per CRAN
>> policy, you shouldn't do that (cf. the manual,
>> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file).
>>
>>
>> Finally, the third note says that there is a file in the tarball that
>> shouldn't be there, namely Plasmode.Rproj. You can control what is
>> omitted from the tarball using the .Rbuildignore file. In particular,
>> you could add the following line:
>>
>> ^Plasmode\.Rproj$
>>
>> Max
>>
>>
>> On 2017-09-27 11:47 AM, Abdia, Younathan wrote:
>>> Hi,
>>>
>>> My name is Younathan and I am trying to submit it but every time it
>>> gives me message that my package does not pass the incoming checks
>>> automatically and it gives me 3 NOTES. I tried to fix them but I am
>>> unable to do so. If possible do you know how to take care of the 3
>>> Notes. The three notes are as following:
>>>
>>> * checking CRAN incoming feasibility ... NOTE
>>> Maintainer: 'Younathan Abdia '
>>>
>>> New submission
>>>
>>> Possibly mis-spelled words in DESCRIPTION:
>>>    Plasmode (3:8)
>>>
>>> The Title field starts with the package name.
>>>
>>> The build time stamp is missing.
>>>
>>>
>>> * checking DESCRIPTION meta-information ... NOTE
>>>
>>> Checking should be performed on sources prepared by 'R CMD build'.
>>>
>>> * checking top-level files ... NOTE
>>>
>>> Non-standard file/directory found at top level:
>>>
>>>    'Plasmode.Rproj'
>>>
>>> You can also see the NOTES by clicking on the link.
>>>
>>> https://win-builder.r-project.org/incoming_pretest/170927_165838_Plasmode_010/00check.log
>>>
>>>
>>> Please let me know if there is any question or concern. Thank you for
>>> help.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Younathan
>>>
>>>
>>>
>>> The information in this e-mail is intended only for t...{{dropped:6}}
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Semantic versioning and maintenance releases

[Ben Bolker]

On 17-10-25 03:47 PM, Duncan Murdoch wrote:
> On 25/10/2017 2:23 PM, Shivaram Venkataraman wrote:
>> Hello
>>
>> We have an R package that uses semantic versioning -- i.e. version
>> numbers
>> are of the form major_version.minor_version.patch_version
>>
>> One of the ways we use the patch_versions is to make maintenance releases
>> or security fixes that users can apply without worrying about any
>> functionality changes. For example if our users were on 1.6.2 it is often
>> easier for them to upgrade to 1.6.3 which has a security fix rather than
>> 1.7.0
>>
>> On the other hand our development continues towards the next minor
>> version
>> and we sometimes have cases where say 1.6.3 is released after 1.7.0.
>>
>> While running `R CMD check --as-cran` for version 1.6.3 we find that this
>> leads to a warning which looks like 'Insufficient package version
>> (submitted:
>> 1.6.3, existing: 1.7.0)'.
>>
>> Our question is whether it is okay to upload these maintenance
>> releases to
>> CRAN and if there is some way we can mark that the version numbers follow
>> semantic versioning.
> 
> CRAN won't accept 1.6.3 after 1.7.0 has been published there.  It
> requires version numbers to be increasing.  There's no provision for the
> scheme you're following.
> 
> Even if there were, it's not easy for a user to ask to install any
> version but the latest one.  They'd need to work out the URL and
> download the tarball and build it from source.  install.packages() has
> no provision for handling this automatically.

  If an older version *were* on CRAN (I understand why this isn't
feasible), devtools::install_version() would take care of some of the
fussy bits (although it still requires having the build tools installed).

  You can use the 'ref' argument in devtools::install_github to point
your users to a tag/release number ...

> I'd suggest that you put the patch releases for older versions on Github
> or some other repository, and explain how users can install directly
> from there.
> 
> Duncan Murdoch
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Using ggplot2 within another package

[Ben Bolker]

  For some reason that I don't remember, an R core member once told me 
that they prefer x <- y <- NULL to utils::globalVariables(c("x","y")) - 
although I have also encountered problems with that strategy in edge cases.


 Here's an example from StackOverflow from today where for some reason 
I don't understand, evaluation of function arguments interacts with 
non-standard/lazy evaluation within a dplyr function such that 'foo' 
works while 'x$foo' doesn't ... don't know if it's a similar case.


https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198

On 4/22/21 5:19 PM, Kevin R. Coombes wrote:

Thanks.

Obviously, long. long ago, (in a galaxy not far enough away), Paul's
suggestion of using "aes_string" was the correct one, since "aes" uses
non-standard evaluation. (And to quote somebody from an R fortune
cookie, "The problem with non-standard evaluation is that it is
non-standard.") But teh documentation at the end oft he link provided by
Robert explivityl tells you not to do that, since "aes_string is
deprecated".  And reading more carefully into the manual page for
aes_string, one does indeed find the statement that the function is
"soft deprecated". I'm not sure what that means, other than someone on
the development team doesn't like it.

Instead, the vignette says you should
     importFrom("rlang", ".data")
in your NAMESPACE, and write
     ggplot(myData, aes(x = .data$myX, y = .data$myY))

And now my dinosaur question: That looks like using one non-standard
hack to cover up the problems with another non-standard hack. Why the
heck  is that any better for the developer than writing
     ggplot(myData, aes(x = myData$myX, y = myData$myY))

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

It's time to tell those kids to get off of my lawn.
    Kevin

On 4/22/2021 4:45 PM, Robert M. Flight wrote:

Kevin,

This vignette from ggplot2 itself gives the "officially recommended"
ways to avoid the warnings from R CMD check

https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html


Cheers,

-Robert

On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
mailto:paul.sav...@univ-fcomte.fr>> wrote:

 Hi Kevin,

 I was faced to the same problem and I used 'aes_string()' instead
 of 'aes()'. You can then just write the name of the columns
 containing the data to plot as character strings.

 Example:

 myPlot <- function(myData, ...) {
     # get ready
     ggplot(myData, aes_string(x = "myX", y = "myY")) +
        # add my decorations
        theme_bw()
 }

 It is probably already the case for your function but you need to
 include #' @import ggplot2 in your function preamble (if I am not
 wrong).

 Kind regards
 Paul

 - Mail original -
 De: "Kevin R. Coombes" mailto:kevin.r.coom...@gmail.com>>
 À: "r-package-devel" mailto:r-package-devel@r-project.org>>
 Envoyé: Jeudi 22 Avril 2021 22:28:55
 Objet: [R-pkg-devel] Using ggplot2 within another package

 Hi,

 I'm trying to help clean up an R package for someone else to
 submit to
 CRAN. He has used ggplot2 to implement a plotting function for the
 kinds
 of things that his packages generates. His plotting routine basically
 looks like (after changing names to protect the innocent):

 myPlot <- fucntion(myData, ...) {
     # get ready
     ggplot(myData, aes(x = myX, y = myY)) +
    # add my decorations
    theme_bw()
 }

 Of course, "R CMD check --as-cran" complains that there is no global
 binding for "myX" or "myY" since they are columns defined in the
 data.frame "myData".

 What is the best way to work around this issue?

 Of course, dinosaurs like myself might be tempted to suggest just
 using
 plain old "plot", so I don't need to see those suggestions.

 Do I just ignore the usual ggplot conventions and write "myData$myX"
 inside "aes"  in order to appease the CRAN checker? Or is there some
 tidy-er way to solve this problem?

 Thanks,
    Kevin

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

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




[[alternative HTML version deleted]]

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



__

Re: [R-pkg-devel] Using ggplot2 within another package

[Ben Bolker]

  It seems that what we need is really ignoreLocalVariables() rather 
than globalVariables() ... ?


On 4/24/21 4:56 PM, Bill Dunlap wrote:
Has there been any thought given to an alternative to globalVariables 
that would flag certain arguments to certain functions as being 
evaluated in a non-standard way.  E.g.,

     usesNSE(FUN="with.default", ARGUMENTS="expr")
     usesNSE(FUN="lm", ARGUMENTS=c("weights","subset","offset"))
     usesNSE(FUN="~") # missing ARGUMENTS means all args are NSE
This information would be stored in the environment that contains FUN.

-Bill

On Sat, Apr 24, 2021 at 6:18 AM Martin Maechler 
mailto:maech...@stat.math.ethz.ch>> wrote:


 >>>>> Ben Bolker
 >>>>>     on Thu, 22 Apr 2021 17:27:49 -0400 writes:

     > For some reason that I don't remember, an R core member once
told me
     > that they prefer x <- y <- NULL to
utils::globalVariables(c("x","y")) -

That could have been me.  Even though I think I still have some
globalVariables() statements in some of my package sources, I've
decided that it *harms* really, notably for relatively common
variable names such
as "x":   It declares them "global"
{ for the purpose of codetools::globalVariables() } everywhere,
i.e. for all functions in the package namespace and that
basically kills the reliability of  globalVariables() checking
for the whole package.


     > although I have also encountered problems with that strategy
in edge cases.

well, when?


  Honestly, I don't remember. Something with order of evaluation and 
the fact that a variable existed and was set to NULL in the package 
namespace screwing things up.




     > Here's an example from StackOverflow from today where for
some reason
     > I don't understand, evaluation of function arguments
interacts with
     > non-standard/lazy evaluation within a dplyr function such
that 'foo'
     > works while 'x$foo' doesn't ... don't know if it's a similar
case.

     >

https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198

<https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198>


{ ceterum censeo ... to use NSE (non-standard-evaluation) for
   user convenience and to call this (together with really good
   ideas)  "tidy" has been one of the biggest euphemisms in the
history of
   statistical computing ...  but yes, that's just my personal opinon  }

     > On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
     >> Thanks.
     >>
     >> Obviously, long. long ago, (in a galaxy not far enough
away), Paul's
     >> suggestion of using "aes_string" was the correct one, since
"aes" uses
     >> non-standard evaluation. (And to quote somebody from an R
fortune
     >> cookie, "The problem with non-standard evaluation is that it is
     >> non-standard.") But teh documentation at the end oft he link
provided by
     >> Robert explivityl tells you not to do that, since "aes_string is
     >> deprecated".  And reading more carefully into the manual
page for
     >> aes_string, one does indeed find the statement that the
function is
     >> "soft deprecated". I'm not sure what that means, other than
someone on
     >> the development team doesn't like it.
     >>
     >> Instead, the vignette says you should
     >>    importFrom("rlang", ".data")
     >> in your NAMESPACE, and write
     >>    ggplot(myData, aes(x = .data$myX, y = .data$myY))
     >>
     >> And now my dinosaur question: That looks like using one
non-standard
     >> hack to cover up the problems with another non-standard
hack. Why the
     >> heck  is that any better for the developer than writing
     >>    ggplot(myData, aes(x = myData$myX, y = myData$myY))
     >>
     >> or using Dirk Eddelbuettel's suggestion of calling
utils::globalVariables ??
     >>
     >> It's time to tell those kids to get off of my lawn.
     >>   Kevin
     >>
     >> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
     >>> Kevin,
     >>>
     >>> This vignette from ggplot2 itself gives the "officially
recommende

Re: [R-pkg-devel] autotesting on GitHub with Travis or ...?

[Ben Bolker]

  GitHub Actions

  ?usethis::use_github_action

  Probably start here if you are moving from Travis: 
https://deanattali.com/blog/migrating-travis-to-github/


On 5/13/21 8:00 PM, Spencer Graves wrote:

Hello, All:


   What are the current recommendations for automatic testing of an 
R package on GitHub?



   Section 19.3 in the current version of "R Packages" describes 
"Checking after every commit with Travis".  It recommends Travis.  It 
says to use Travis, first "Run usethis::use_travis()".[1]



   However, 'help("use_travis", package="usethis")' says it's 
deprecated, but I don't understand what is recommended as an alternative.



   What do you suggest?


   Thanks,
   Spencer Graves


[1]
https://r-pkgs.org/r-cmd-check.html?q=travis#travis

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


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

Re: [R-pkg-devel] Puzzling error from win-builder

[Ben Bolker]

   Without thinking about it very much, my first guess would be that 
this is a transient problem on win-builder, i.e. the caret package is 
temporarily unavailable for some reason (e.g. because some update step 
hung); a new version of the package was published *fairly* recently 
(2021-05-15), although I would find my explanation more compelling if 
the update was more recent (and if the CRAN page for caret wasn't 
showing that the Windows binaries have all been updated to the current 
version).


  As a hackish way to explore this further, you could find a different 
CRAN package that depends on caret, edit the DESCRIPTION file to 
substitute your e-mail address as maintainer, and submit it to 
win-builder (if you don't edit the DESCRIPTION then the package 
maintainer, not you, will get the e-mail saying that the build is done; 
I don't know if this is allowed by win-builder rules but even if not it 
seems like a minor transgression).


On 5/26/21 5:12 PM, Jonathan Gilligan wrote:

I have a puzzling error from win-builder for a package.

My package is https://github.com/jonathan-g/datafsm, also 
https://cran.r-project.org/web/packages/datafsm. I am preparing a 
bug-fix release to CRAN to fix an error that CRAN recently identified in 
the previous release of this package (see 
https://cran.r-project.org/web/checks/check_results_datafsm.html).


The package passes R CMD check with no errors or warnings, and one note 
(harmless) on win-builder for R-devel 
(https://win-builder.r-project.org/8mp9LN00YVw4/00check.log) and 
R-oldrelease 
(https://win-builder.r-project.org/1K21X458WtYt/00check.log), but for 
R-release, win-builder has two errors in running tests and building a 
vignette (https://win-builder.r-project.org/exK86Fkyir2s/00check.log), 
all of which say the CRAN caret package is not available for Windows x64:



* checking for unstated dependencies in 'tests' ... OK
* checking tests ...
** running tests for arch 'i386' ... [7s] OK
   Running 'testthat.R' [6s]
** running tests for arch 'x64' ... [6s] ERROR
   Running 'testthat.R' [6s]
Running the tests in 'tests/testthat.R' failed.
Complete output:
   > library(testthat)
   > library(datafsm)
   >
   > test_check("datafsm")
   == Failed tests 

   -- Error (test_mainfunc.R:7:9): evolve_model() returns correct type 
of object --
   Error: DLL 'caret' not found: maybe not installed for this 
architecture?

   Backtrace:
   x
    1. +-datafsm::evolve_model(cdata, cv = FALSE) test_mainfunc.R:7:8
    2. \-base::loadNamespace(x)
    3.   \-base::library.dynam(lib, package, package.lib)
   -- Error (test_mainfunc.R:14:3): evolve_model() returns warnings 
and errors 
   Error: DLL 'caret' not found: maybe not installed for this 
architecture?

   Backtrace:
   x
    1. +-testthat::expect_warning(evolve_model(cdata, cv = FALSE), 
"did not supply a data.frame") test_mainfunc.R:14:2
    2. | \-testthat:::quasi_capture(enquo(object), label, 
capture_warnings)

    3. |   +-testthat:::.capture(...)
    4. |   | \-base::withCallingHandlers(...)
    5. |   \-rlang::eval_bare(quo_get_expr(.quo), quo_get_env(.quo))
    6. +-datafsm::evolve_model(cdata, cv = FALSE)
    7. \-base::loadNamespace(x)
    8.   \-base::library.dynam(lib, package, package.lib)
      [ FAIL 2 | WARN 0 | SKIP 0 | PASS 3 ]
   Error: Test failures
   Execution halted
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in 'inst/doc' ... OK
* checking re-building of vignette outputs ... [10s] WARNING
Error(s) in re-building vignettes:
--- re-building 'datafsm_introduction.Rmd' using rmarkdown
Quitting from lines 173-175 (datafsm_introduction.Rmd)
Error: processing vignette 'datafsm_introduction.Rmd' failed with 
diagnostics:

DLL 'caret' not found: maybe not installed for this architecture?
--- failed re-building 'datafsm_introduction.Rmd'

--- re-building 'FRD_vignette.Rmd' using rmarkdown_notangle
--- finished re-building 'FRD_vignette.Rmd'

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

Error: Vignette re-building failed.
Execution halted


My package declares the "caret" package as an import in DESCRIPTION, so 
I am puzzled what this error from win-builder means and how to fix it. 
If R CMD check got this far, and installed the package for testing 
without reporting missing dependencies, why is it suddenly unable to use 
the caret package for testing the package, but only for the x64 
architecture? Is this something I am doing wrong, or is it a bug in 
win-builder?


Is anyone else finding problems with win-builder reporting errors about 
CRAN packages not being available?


For what it's worth, the package passes R CMD check with no errors or 
warnings or notes under GitHub actions (Windows, MacOS, and Ubuntu), on 
rhub (Debian, Fedora, Ubuntu, MacOS, and Windows except for R-devel 
under Windows, where R CMD check fails with a message about BioConducto

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Ben Bolker]

   That all sounds exactly right.
  GPL >= 2 allows you to use the material without asking permission as 
long as your package is compatibly licensed (e.g. also GPL).
  Under normal circumstances it would be polite to ask permission, but 
if the reason for doing this is that the maintainer is unreachable in 
the first place ...


 If you want to try a little harder, it seems quite possible that you 
can reach the matrixcalc maintainer at the (personal) e-mail address 
shown in this page:


https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042

  (Possibly an identity confusion, but I rate that as unlikely based on 
other facebook snooping)


  I don't think a short, polite e-mail request would be out of bounds, 
they can always ignore it or tell you to go away.


  cheers
   Ben Bolker

On 6/2/21 1:15 PM, Ben Staton wrote:

Hello,

Thank you for your detailed list of solutions.

I was initially tempted to go with option 1 (move matrixcalc to suggests
and check for its existence before using functions that rely on it), but as
mentioned, this is not a long term fix.

I unfortunately can't take on the responsibilities of option 2 (becoming
the package maintainer) -- there is much that this package does that I do
not understand, and do not wish to feign authority!

I plan to take option 3 (copy the needed functions into my package). There
are only three functions I need from matrixcalc, and all three are fairly
simple (is.square.matrix
<https://rdrr.io/cran/matrixcalc/src/R/is.square.matrix.R>,
is.symmetric.matrix
<https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and
is.positive.definite
<https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>) and there
is only one function in postpack that needs them. I plan to define them
within the postpack function. matrixcalc is licensed under GPL >= 2 and
based on my scan of the license text, this is allowed. Is that correct?

Regarding option 4 (contacting the matrixcalc maintainer), the original
email from CRAN mentioned that they have attempted to contact the package
author with no response.

Thank you!

On Wed, Jun 2, 2021 at 9:52 AM J C Nash  wrote:


I just downloaded the source matrixcalc package to see what it contained.
The functions
I looked at seem fairly straightforward and the OP could likely develop
equivalent features
in his own code, possibly avoiding a function call. Avoiding the function
call means NAMESPACE etc. are not involved, so fewer places for getting
into
trouble, assuming the inline code works properly.

JN


On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:

On 02/06/2021 12:13 p.m., Ben Staton wrote:

Hello,

I received an email notice from CRAN indicating that my R package
('postpack') will be archived soon if I do not take any action and I

want

to avoid that outcome. The issue is not caused by my package, but

instead a

package that my package depends on:

"... package 'matrixcalc' is now scheduled for archival on 2021-06-09,
and archiving this will necessitate also archiving its strong reverse
dependencies."

Evidently, xyz has been returning errors on new R builds prompting CRAN

to

list it as a package to be archived. My package, 'postpack' has
'matrixcalc' listed in the Imports field, which I assume is why I

received

this email.

I want to keep 'postpack' active and don't want it to be archived. I

still

need package 'matrixcalc' for my package, but not for most functions.

Could

I simply move package 'matrixcalc' to the Suggests list and submit the

new

version to CRAN to remove the "Strong Reverse Dependency" issue that
triggered this email to avoid CRAN from archiving my package?


That's part of one solution, but not the best solution.

If you move it to Suggests, you should make sure that your package

checks for it before every use, and falls back to

some other calculation if it is not present.  Be aware that once it is

archived, almost none of your users will have it

available, so this is kind of like dropping the functions that it

supports.


Another solution which would be great for the community might be for you

to offer to take over as maintainer of

matrixcalc.  Then you'd fix whatever problems it has, and you wouldn't

need to worry about it.  I haven't looked at the

issues so I don't know if this is feasible.

A third choice would be for you to copy the functions you need from

matrixcalc into your own package so you can drop the

dependency.  This is generally legal under the licenses that CRAN

accepts, but you should check anyway.


A fourth choice would be for you to contact the matrixcalc maintainer,

and help them to fix the issues so that

matrixcalc doesn't get archived.  They may or may not be willing to work

with you.


I'd say my third choice is the best choice in the short term, and 2nd or

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Ben Bolker]

  Write to the CRAN maintainers and let them know about the situation, 
hopefully that would prevent archiving.


On 6/2/21 4:16 PM, Ben Staton wrote:

Hi Everyone, thank you all for your responses.

I agree that I can replicate the three functions within matrixcalc that I
need with ease, even without copying and pasting the original code found in
that package and thus not creating any licensing issues.

I have checked the CRAN incoming boards (here
<https://lockedata.github.io/cransays/articles/dashboard.html>), and they
actually have a new version of matrixcalc coming through so hopefully this
issue will be resolved without my intervention.

On a related note, suppose that this issue does not get resolved before the
archival date, and my package gets archived. What would be the path for me
to have CRAN remove it from the archived list? Is it basically (1) fix the
issue that caused initial archival and (2) resubmit?

Thank you,
Ben

On Wed, Jun 2, 2021 at 12:48 PM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:


   The CRAN maintainers almost certainly have tried to contact the
maintainer.  You can ask if he plans to fix the bug.  If not, if it's
that easy to fix, you could offer to both the maintainers of both
matrixcalc and CRAN to take over maintenance.


   Spencer


On 6/2/21 2:41 PM, Roy Mendelssohn - NOAA Federal via R-package-devel
wrote:

After looking up matrixcalc on CRAN,  I would recommend contacting the

maintainer,  who is listed as:



Frederick Novomestky 



The reason I say this is what is blowing up the package in the nightly

builds is a careless error in one Example:



> x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4,

ncol=4, byrow=TRUE )

  Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4,

ncol = 4, :

   data length differs from size of matrix: [12 != 4 x 4]



That should be pretty easy for the maintainer to fix and to resubmit.

-Roy



On Jun 2, 2021, at 10:36 AM, Ben Staton  wrote:

My package uses the MIT license, so would that not meet the

compatibility

requirements?

I will attempt to reach out to the package author - thanks for your

help!


On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:


 That all sounds exactly right.
GPL >= 2 allows you to use the material without asking permission as
long as your package is compatibly licensed (e.g. also GPL).
Under normal circumstances it would be polite to ask permission, but
if the reason for doing this is that the maintainer is unreachable in
the first place ...

   If you want to try a little harder, it seems quite possible that you
can reach the matrixcalc maintainer at the (personal) e-mail address
shown in this page:



https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042


(Possibly an identity confusion, but I rate that as unlikely based

on

other facebook snooping)

I don't think a short, polite e-mail request would be out of bounds,
they can always ignore it or tell you to go away.

cheers
 Ben Bolker

On 6/2/21 1:15 PM, Ben Staton wrote:

Hello,

Thank you for your detailed list of solutions.

I was initially tempted to go with option 1 (move matrixcalc to

suggests

and check for its existence before using functions that rely on it),

but

as

mentioned, this is not a long term fix.

I unfortunately can't take on the responsibilities of option 2

(becoming

the package maintainer) -- there is much that this package does that

I do

not understand, and do not wish to feign authority!

I plan to take option 3 (copy the needed functions into my package).

There

are only three functions I need from matrixcalc, and all three are

fairly

simple (is.square.matrix
<https://rdrr.io/cran/matrixcalc/src/R/is.square.matrix.R>,
is.symmetric.matrix
<https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and
is.positive.definite
<https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>) and

there

is only one function in postpack that needs them. I plan to define

them

within the postpack function. matrixcalc is licensed under GPL >= 2

and

based on my scan of the license text, this is allowed. Is that

correct?


Regarding option 4 (contacting the matrixcalc maintainer), the

original

email from CRAN mentioned that they have attempted to contact the

package

author with no response.

Thank you!

On Wed, Jun 2, 2021 at 9:52 AM J C Nash  wrote:


I just downloaded the source matrixcalc package to see what it

contained.

The functions
I looked at seem fairly straightforward and the OP could likely

develop

equivalent features
in his own code, possibly avoiding a function call. Avoiding the

function

call means NAMESPACE etc. are not involved, so fewer places for

getting

into
trouble, assuming the inline code works properly.

JN


On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:

On 02/06/2021 12:13 p.m., Ben Staton wrote:

He

Re: [R-pkg-devel] pairwiseAlignment

[Ben Bolker]

   I'm not sure this is the right venue for your question (the mailing 
list is for package *development*).  You might try opening an issue at 
the package bug-report site:


https://github.com/Bioconductor/Biostrings/issues

or asking on https://www.biostars.org/ forum (where there are a lot of 
bioinformatics people)


 You may be asked to provide a reproducible example (e.g. by simulation 
or random generation ...)


  cheers
   Ben Bolker

On 6/16/21 9:14 PM, csmatyi wrote:

Hello,

I am trying to align two sequences, in DNAString format using the R command 
pairwiseAlignment.
I keep getting this error:

pairwiseAlignment(si,sj)
Error in .Call2("XStringSet_align_pairwiseAlignment", pattern, subject,  :
   max(nchar(pattern) * nchar(subject)) is too big (must be <= 2147483647)

The 2 DNAstrings are si and sj, and are 108,007 bp and 120,698 bp long, 
respectively.

Can someone help me? Are the sequences too long perchance?

Thanks, Matthew

Sent with [ProtonMail](https://protonmail.com/) Secure Email.
[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] How to sent possible bug report to maintainer

[Ben Bolker]

  I did some web searching. "Xiang Lyu Purdue" doesn't turn up anything 
current/useful, but there appears to be someone with the same name in 
the Biostats PhD program at Berkeley 
 
, who *might* be the same person. You could politely e-mail them and 
ask. (This is the detective work that Jeff Newmiller is talking about.)


  You could also try to track down the co-authors of the package (you 
can find their institutional affiliations from the papers associated 
with the package).


On 6/18/21 8:29 PM, mai zhou wrote:

Dear developers,

I was trying to send an email to the maintainer of package tpAUC,
on the information page, he/she has the address ly...@purdue.edu
But my email bounced back.

Can anyone tell me how I can contact him/her for a question/report?

Mai Z


This is what I got:

Address not found
Your message wasn't delivered to *ly...@purdue.edu* because the address
couldn't be found, or is unable to receive mail.

[[alternative HTML version deleted]]

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



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

[R-pkg-devel] weird C stack traces from win-builder, due to brms/rstan load?

[Ben Bolker]

 I'm running into trouble checking a new release of the 'broom.mixed' 
package <https://cran.r-project.org/web/packages/broom.mixed/index.html> 
on win-builder.  I think it is some kind of rstan problem.


  The broom.mixed package loads the brms package, and loads several 
pre-computed objects from the brms package; I don't think it actually 
tries to run anything of the functions from brms during the check process.


  At several points during checking (see 
<https://win-builder.r-project.org/LsDDMqpnX52n/00check.log>), I get 
voluminous "C stack trace" outputs: once when "Checking dependencies in 
R code", once when calling require(brms) as part of an example, once 
when running the tests (not easy to determine the precise location, and 
once when building the vignettes).


  The trace starts like this:

 C stack trace ===

SETCAR [0x0x6c838a90+32]

ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 [0x0x6ac093ff+1151]
ZN4Rcpp6Module12classes_infoEv [0x0x6ac07467+327]
Z20Module__classes_infoP7SEXPREC [0x0x6abe1c4a+74]
Rf_NewFrameConfirm [0x0x6c7a7d18+33960]
R_initAssignSymbols [0x0x6c7f3259+53849]
Rf_eval [0x0x6c7fcd31+369]
...

  and goes on for a while.

  R CMD check runs fine on Linux with recent r-devel.

  Has anyone seen this?  Other than scrubbing all references to brms 
and rstan (a second try with one of the brms references avoided instead 
runs into trouble when loading rstan ...), I don't see what I can do ...


<https://win-builder.r-project.org/YArr24tuYZ8G/00check.log>

  cheers
   Ben Bolker

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

Re: [R-pkg-devel] weird C stack traces from win-builder, due to brms/rstan load?

[Ben Bolker]

On 7/5/21 2:01 PM, Duncan Murdoch wrote:

On 05/07/2021 10:32 a.m., Ben Bolker wrote:

   I'm running into trouble checking a new release of the 'broom.mixed'
package <https://cran.r-project.org/web/packages/broom.mixed/index.html>
on win-builder.  I think it is some kind of rstan problem.

    The broom.mixed package loads the brms package, and loads several
pre-computed objects from the brms package; I don't think it actually
tries to run anything of the functions from brms during the check 
process.


    At several points during checking (see
<https://win-builder.r-project.org/LsDDMqpnX52n/00check.log>), I get
voluminous "C stack trace" outputs: once when "Checking dependencies in
R code", once when calling require(brms) as part of an example, once
when running the tests (not easy to determine the precise location, and
once when building the vignettes).

    The trace starts like this:

 C stack trace ===

SETCAR [0x0x6c838a90+32]
ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 
[0x0x6ac093ff+1151]

ZN4Rcpp6Module12classes_infoEv [0x0x6ac07467+327]
Z20Module__classes_infoP7SEXPREC [0x0x6abe1c4a+74]
Rf_NewFrameConfirm [0x0x6c7a7d18+33960]
R_initAssignSymbols [0x0x6c7f3259+53849]
Rf_eval [0x0x6c7fcd31+369]
...

    and goes on for a while.

    R CMD check runs fine on Linux with recent r-devel.

    Has anyone seen this?  Other than scrubbing all references to brms
and rstan (a second try with one of the brms references avoided instead
runs into trouble when loading rstan ...), I don't see what I can do ...

<https://win-builder.r-project.org/YArr24tuYZ8G/00check.log>



What error do you get before the stack trace?

The Z... names look like C++ entry points to overloaded functions or 
methods.  There's a command line function (c++filt) that will usually 
turn those into their original readable form.  It's not working for me 
on the names you've got; maybe because I'm on a Mac, and that was 
compiled on Windows.  Perhaps someone else knows how to demangle those 
names?


Duncan Murdoch


  No obvious errors at all before the stack trace. I'm pretty sure that 
the stack trace is caused by the *act of loading the rstan package*.


  I guess the next thing to do would be to make a dummy package that 
does *nothing* but try to load rstan ... ?


=---

Here's the start of the text the first time this appears:

* checking dependencies in R code ... NOTE

 C stack trace ===
SETCAR [0x0x6c838a90+32]

ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 [0x0x6ac093ff+1151]
---


  Here is another example:


Error(s) in re-building vignettes:
--- re-building 'broom_mixed_intro.rmd' using rmarkdown

Attaching package: 'dplyr'

The following objects are masked from 'package:stats':

filter, lag

The following objects are masked from 'package:base':

intersect, setdiff, setequal, union

Loading required package: brms
Loading required package: Rcpp

 C stack trace ===

SETCAR [0x0x6c838a90+32]




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

[R-pkg-devel] clarification about missing suggested packages.

[Ben Bolker]

  We are working on a resubmission of a package 
(https://github.com/glmmTMB/glmmTMB/issues/721 for people who want all 
the gory details). Our last hurdle is that one of the packages in 
"Suggests:", DHARMa, is currently unavailable on Solaris, even though it 
in good standing on CRAN 
<https://cran.r-project.org/web/packages/DHARMa/index.html>. (This stems 
from a circular dependency: DHARMa can't be built on Solaris because the 
_previous_ version of glmmTMB, which DHARMa imports, had a bug on 
Solaris ...)


  We have been testing on r-hub's solaris platform, where DHARMa is 
similarly unavailable. We can only pass tests if we set 
_R_CHECK_FORCE_SUGGESTS_=false; otherwise we get an error that says some 
suggested packages are missing.


  It is my understanding that the CRAN maintainers can either

   * test with _R_CHECK_FORCE_SUGGESTS_=false and yell at us if we have 
used any missing/unavailable packages unconditionally or


   * test with _R_CHECK_FORCE_SUGGESTS_=true and ensure that all 
suggested packages are installed


but that it would be unreasonable to reject package A because it has a 
Suggests: dependency on package B that is in good standing on CRAN but 
is not available on a particular CRAN testing platform, as long as 
package A only uses package B conditionally.


  Thoughts/opinions/evidence?

  cheers
Ben Bolker

---
From the current CRAN policy:

Packages on which a CRAN package depends should be available from a 
mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’ 
fields are not from such a repository, where to obtain them at a 
repository should be specified in an ‘Additional_repositories’ field of 
the DESCRIPTION file (as a comma-separated list of repository URLs) or 
for other means of access, described in the ‘Description’ field.


A package listed in ‘Suggests’ or ‘Enhances’ should be used 
conditionally in examples or tests if it cannot straightforwardly be 
installed on the major R platforms. (‘Writing R Extensions’ recommends 
that they are always used conditionally.)


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

[R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Ben Bolker]

  In the process of trying to get a package to build successfully on 
r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files 
to the vignette directory.  One of these was collectbox.sty, which 
triggers the NOTE


---
NOTE
The following files contain a license that requires
distribution of original sources:
  ‘collectbox.sty’
---

  The licensing/copyright information in collectbox.sty is as follows:


%% The original source files were:
%%
%% collectbox.dtx  (with options: `collectbox.sty')
%%
%% IMPORTANT NOTICE:
%%
%% For the copyright see the source file.
%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from collectbox.sty.
%%
%% For distribution of the original source see the terms
%% for copying and modification in the file collectbox.dtx.
%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
%% in the same archive or directory.)
%% Copyright (C) 2012 by Martin Scharrer 
%% 
%% This work may be distributed and/or modified under the
%% conditions of the LaTeX Project Public License, either version 1.3
%% of this license or (at your option) any later version.
%% The latest version of this license is in
%%   http://www.latex-project.org/lppl.txt
%% and version 1.3 or later is part of all distributions of LaTeX
%% version 2005/12/01 or later.

   So I put collectbox.dtx into the inst/misc directory in the package. 
Fine.


 Now, what do I need to do to (1) make sure that my DESCRIPTION file is 
correct and (2) hopefully, suppress the NOTE so I don't have to explain 
it to the CRAN maintainers every time?


* Do I change the LICENCE line (which is currently AGPL-3)? According to 
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing it would 
seem I would have to switch to "file LICENCE" (adding a 
"Licence_is_FOSS: yes"), where "LICENCE" contains something like


package code licensed under AGPL-3; file vignettes/collectbox.sty is 
under the LaTeX Project Public License (source provided in 
misc/collectbox.dtx)


? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?

* Do I just include the files without comment, since I have complied (as 
far as I can tell) with the terms of the LPPL?


* Is there a way to signal to R CMD check that I *have* complied with 
the terms?


  cheers
   Ben Bolker

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

Re: [R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Ben Bolker]

  AGPL was chosen by my colleagues.  I'll pass on the information.

On 7/13/21 6:40 PM, Steven Scott wrote:
I'll let others discuss the technical details of how to set up the 
licence files.  I want to make sure you know that using AGPL is a good 
way to ensure that nobody in tech uses your package.  Maybe that's 
intended, but when I was at Google the ONLY software we were 
specifically prohibited from using was code released under AGPL. I won't 
try to convince you of that being a good or bad thing, but wanted to 
make sure you were aware of it.


On Tue, Jul 13, 2021 at 2:11 PM Ben Bolker <mailto:bbol...@gmail.com>> wrote:



    In the process of trying to get a package to build successfully on
r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files
to the vignette directory.  One of these was collectbox.sty, which
triggers the NOTE

---
NOTE
The following files contain a license that requires
distribution of original sources:
    ‘collectbox.sty’
---

    The licensing/copyright information in collectbox.sty is as follows:


%% The original source files were:
%%
%% collectbox.dtx  (with options: `collectbox.sty')
%%
%% IMPORTANT NOTICE:
%%
%% For the copyright see the source file.
%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from collectbox.sty.
%%
%% For distribution of the original source see the terms
%% for copying and modification in the file collectbox.dtx.
%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
%% in the same archive or directory.)
%% Copyright (C) 2012 by Martin Scharrer mailto:mar...@scharrer-online.de>>
%% 
%% This work may be distributed and/or modified under the
%% conditions of the LaTeX Project Public License, either version 1.3
%% of this license or (at your option) any later version.
%% The latest version of this license is in
%% http://www.latex-project.org/lppl.txt
<http://www.latex-project.org/lppl.txt>
%% and version 1.3 or later is part of all distributions of LaTeX
%% version 2005/12/01 or later.

     So I put collectbox.dtx into the inst/misc directory in the
package.
Fine.

   Now, what do I need to do to (1) make sure that my DESCRIPTION
file is
correct and (2) hopefully, suppress the NOTE so I don't have to explain
it to the CRAN maintainers every time?

* Do I change the LICENCE line (which is currently AGPL-3)?
According to
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing
<https://cran.r-project.org/doc/manuals/R-exts.html#Licensing> it would
seem I would have to switch to "file LICENCE" (adding a
"Licence_is_FOSS: yes"), where "LICENCE" contains something like

package code licensed under AGPL-3; file vignettes/collectbox.sty is
under the LaTeX Project Public License (source provided in
misc/collectbox.dtx)

? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?

* Do I just include the files without comment, since I have complied
(as
far as I can tell) with the terms of the LPPL?

    * Is there a way to signal to R CMD check that I *have* complied with
the terms?

    cheers
     Ben Bolker

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Ben Bolker]

  Thanks very much.  In the end I gave up and removed the offending
LaTeX files, as the goal of this was to get the package to build on
r-hub's Fedora platform, and it seems more promising to work with the
r-hub folks to get a sufficiently complete LaTeX installation
available there (as the required files seem to be present on every
_other_ Linux platform I've tried). (For future readers/references,
the  huxtable package is driving these requirements.)

  cheers
   Ben Bolker

On Thu, Jul 15, 2021 at 9:49 PM Hadley Wickham  wrote:
>
> On Wed, Jul 14, 2021 at 9:11 AM Ben Bolker  wrote:
> >
> >
> >In the process of trying to get a package to build successfully on
> > r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files
> > to the vignette directory.  One of these was collectbox.sty, which
> > triggers the NOTE
> >
> > ---
> > NOTE
> > The following files contain a license that requires
> > distribution of original sources:
> >‘collectbox.sty’
> > ---
> >
> >The licensing/copyright information in collectbox.sty is as follows:
> >
> >
> > %% The original source files were:
> > %%
> > %% collectbox.dtx  (with options: `collectbox.sty')
> > %%
> > %% IMPORTANT NOTICE:
> > %%
> > %% For the copyright see the source file.
> > %%
> > %% Any modified versions of this file must be renamed
> > %% with new filenames distinct from collectbox.sty.
> > %%
> > %% For distribution of the original source see the terms
> > %% for copying and modification in the file collectbox.dtx.
> > %%
> > %% This generated file may be distributed as long as the
> > %% original source files, as listed above, are part of the
> > %% same distribution. (The sources need not necessarily be
> > %% in the same archive or directory.)
> > %% Copyright (C) 2012 by Martin Scharrer 
> > %% 
> > %% This work may be distributed and/or modified under the
> > %% conditions of the LaTeX Project Public License, either version 1.3
> > %% of this license or (at your option) any later version.
> > %% The latest version of this license is in
> > %%   http://www.latex-project.org/lppl.txt
> > %% and version 1.3 or later is part of all distributions of LaTeX
> > %% version 2005/12/01 or later.
> >
> > So I put collectbox.dtx into the inst/misc directory in the package.
> > Fine.
> >
> >   Now, what do I need to do to (1) make sure that my DESCRIPTION file is
> > correct and (2) hopefully, suppress the NOTE so I don't have to explain
> > it to the CRAN maintainers every time?
> >
> > * Do I change the LICENCE line (which is currently AGPL-3)? According to
> > https://cran.r-project.org/doc/manuals/R-exts.html#Licensing it would
> > seem I would have to switch to "file LICENCE" (adding a
> > "Licence_is_FOSS: yes"), where "LICENCE" contains something like
> >
> > package code licensed under AGPL-3; file vignettes/collectbox.sty is
> > under the LaTeX Project Public License (source provided in
> > misc/collectbox.dtx)
> >
> > ? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?
> >
> > * Do I just include the files without comment, since I have complied (as
> > far as I can tell) with the terms of the LPPL?
>
> It's my understanding that the goal of the license field is to list
> one license that the entire package can be distributed under (i.e. is
> compatible with all licenses in the package). As long as you believe
> that LPPL is compatible with the AGPL-3, then it's fine to keep the
> license as AGPL-3.
>
> I don't believe it would be correct to use "AGPL-3 + file LICENSE` as
> R-exts only lists three uses of file LICENSE, none of which apply to
> your case:
>
> > If a package license restricts a base license (where permitted, e.g., using 
> > GPL-3 or AGPL-3 with an
> > attribution clause), the additional terms should be placed in file LICENSE 
> > (or LICENCE), and the
> > string ‘+ file LICENSE’ (or ‘+ file LICENCE’, respectively) should be 
> > appended to the corresponding
> > individual license specification.
>
> > The optional file LICENSE/LICENCE contains a copy of the license of the 
> > package...
> > Whereas you should feel free to include a license file in your source 
> > distribution, please do not arrange to
> install yet another copy of the GNU COPYING or COPYING.LIB files ...
> > Since files named LICENSE or LICENCE will be installed, do

Re: [R-pkg-devel] Using parallel:::sendMaster &c. despite warnings

[Ben Bolker]

  Patches to parallel could certainly be *considered*, but people will 
probably want to argue about the details quite a bit.  I would suggest 
presenting/discussing your ideas for modification on r-devel before 
posting them as a 'wishlist' item to the R bug tracker. (If an R-core 
member participates in the discussion on r-devel and is convinced of the 
utility and harmlessness of your modifications the last step might be 
unnecessary).


  cheers
   Ben Bolker


On 7/23/21 1:17 PM, David Norris wrote:

My understanding about this issue with progressr is that it is nontrivial, and will 
take author Henrik Bengtsson some time & thought to resolve.
OTOH if patches to 'parallel' were welcome, I could embed my solution in a 
modified version of parallel::mclapply by introducing 1 or 2 new parameters 
(e.g., mc.prog=NULL) to support progress reporting consistently with the 
existing interface.

From: Duncan Murdoch 
Date: Friday, July 23, 2021 at 11:26 AM
To: Hugh Parsonage , David Norris 

Cc: "r-package-devel@r-project.org" 
Subject: Re: [R-pkg-devel] Using parallel:::sendMaster &c. despite warnings

On 23/07/2021 10:59 a.m., Hugh Parsonage wrote:
Happily, package parallel is open-source. If you would like to make
use of the unexported functions, you could copy the source code with
acknowledgement into your package.

There's a good chance that wouldn't work, because parallel is a base
package.  Base packages can work with R internals and user-written
packages can't.

Probably David's best course of action is to submit patches where
necessary so that he doesn't need ::: access.  The original motivation
appeared to be avoiding inefficiency in a contributed package; if
there's a patch that can fix that, it could be available in a few days.
   If it needs changes to the parallel package (e.g. exposing functions
that are currently internal), that will take much longer, and needs a
strong argument why the current API isn't sufficient.

Alternatively, he can go ahead and use :::, but just not expect his
package to be on CRAN.  There are other ways to distribute packages.

Duncan Murdoch

   Naturally this might be a lot of
work and risks different behaviour between your package and parallel,
but neither might be that terrible for you.  And certainly would be
better than trying to pretend that the functions you want are exported
from parallel.



On Fri, 23 Jul 2021 at 23:09, David Norris <mailto:da...@precisionmethods.guru> 
wrote:

I can confirm that getFromNamespace() does indeed circumvent the WARNING.
I might otherwise prefer ':::', however, for making its 'bad intentions' so 
clear.
I was very much aware of the cautionary language under `?readChild`, but 
wondered whether *in practice* more liberal community policies might be in 
force pending the maturation of the futureverse.
Although the sparse history of the relevant file hardly supports 
"might-break-at-any-time" alarmism, I do note that the last commit (in May 
2020) introduced an argument sendMaster(raw.asis=TRUE) that I am actually using.
https://github.com/wch/r-source/commits/trunk/src/library/parallel/R/unix/mcfork.R

(Also agree with Yohann that ideally one might support Windows with a warning 
such as data.table issues regarding my Mac's non-support for OpenMP.)

Best, David

From: Sebastian Meyer <mailto:seb.me...@fau.de>
Organization: Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
Date: Friday, July 23, 2021 at 8:05 AM
To: David Norris <mailto:da...@precisionmethods.guru>, 
"mailto:r-package-devel@r-project.org"; <mailto:r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] Using parallel:::sendMaster &c. despite warnings

Am 23.07.21 um 13:19 schrieb David Norris:
Because parallelized progress reporting in the futureverse.org incurs latencies 
too great for my application 
(https://github.com/HenrikBengtsson/progressr/issues/118), I have found it 
necessary to implement my own progress reporting using some of the non-exported 
functionality from `parallel`. (I do appreciate that Windows lacks the fork() 
system call, and will not support this. But am willing to make this an OS_type: 
unix-only package.)

Of course, I get a WARNING for this:

── R CMD check results  precautionary 0.2.6 
Duration: 6m 41.8s

❯ checking dependencies in R code ... WARNING
   Unexported objects imported by ':::' calls:
 ‘parallel:::readChild’ ‘parallel:::selectChildren’
 ‘parallel:::sendMaster’
 See the note in ?`:::` about the use of this operator.
 Including base/recommended package(s):
 ‘parallel’

Is this warning an absolute deal-killer on CRAN? Is there a 'correct' way to do 
`:::` that avoids the warning altogether?

The 'parallel' functions your package intends to access seem to be
intention

[R-pkg-devel] advice on reminders/nags to CRAN maintainers

[Ben Bolker]

  Wondering about etiquette/if I should start over again with a package 
submission. tl;dr, the package has been 'waiting' since 30 July (I 
responded the same day to the queries that were sent).


  For what it's worth, the 'pretest-waiting-recheck' message below was 
sent from *a* CRAN maintainer, but hitting "reply-all" in my mail client 
only included the "cran-submissi...@-rproject.org" address. Maybe my 
mail client is misconfigured → supposed to respond to the sender as well 
as the Reply-To: address? I could poke the individual CM who sent it 
personally, but I'm loath to do that unnecessarily ...



   thoughts?
   Ben Bolker

---

(Some previous history omitted here for brevity; there had been a bit of 
back-and-forth about this package previously.)


  07/30: Submitted version 1.1.2.2 of the glmmTMB package.  Got a 
"pretest-waiting-recheck" message asking us to confirm that we had 
addressed issues; I responded the same day.


  08/04, 08/06: Tried to confirm that the message was received (maybe I 
was too pushy?) -- no answer that I have seen.


  The CRAN queue in general seems to be moving OK 
(foghorn::cran_incoming(), 'archive' folder filtered out, sorted by 
time: 57 total, 45 from today or yesterday).


   package  versioncran_folder time
   
 1 BIRDS0.2.1  pending 2021-07-21 17:01:00
 2 glmmTMB  1.1.2.2waiting 2021-07-30 20:29:00
 3 PEcAn.logger 1.8.0  waiting 2021-08-05 18:58:00
 4 IPDFileCheck 0.7.4  waiting 2021-08-06 11:15:00
 5 R6   2.5.1  waiting 2021-08-06 22:27:00
 6 ibdreg   0.3.3  pending 2021-08-06 23:41:00
 7 mark 0.2.0  waiting 2021-08-08 23:25:00
 8 DataGraph1.2.3  pending 2021-08-09 03:11:00
 9 tibble   3.1.4  waiting 2021-08-09 05:46:00

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

Re: [R-pkg-devel] Expired Incoming Package

[Ben Bolker]

  That would be my best guess.

On 8/23/21 3:19 PM, Reed A. Cartwright wrote:

If my submission is no longer visible using foghorn::cran_incoming(), that
means it has expired and I should resubmit, right?

--
Reed A. Cartwright, PhD
Associate Professor of Genomics, Evolution, and Bioinformatics
School of Life Sciences and The Biodesign Institute
Arizona State University
==
Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA
Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
85287-5301 USA
Office: Biodesign B-220C, 1-480-965-9949
Website: http://cartwrig.ht/

[[alternative HTML version deleted]]

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



--

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

Re: [R-pkg-devel] Solaris Support

[Ben Bolker]

  I think you're stuck with what you get as far as compilers go (see 
below), but it shouldn't be a deal-breaker for CRAN.


The list of CRAN test platforms 
<https://cran.r-project.org/web/checks/check_flavors.html> indicates 
that the platform uses the Oracle Developer Studio 12.6 compiler , but 
the DETAILS 
<https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86> say 
"GCC is used for packages linking to Rcpp|cpp11|StanHeaders, rgdal/sf 
(GDAL is only compilable with g++) and about 40 others."


  So if you link to one of those packages or the undisclosed 40 others, 
you will get GCC (details below).  If not, or if you're not sure, you 
should indicate in your submission message that your package only works 
with GCC on Solaris. According to the CRAN policies 
<https://cran.r-project.org/web/packages/policies.html>


Package authors should make all reasonable efforts to provide 
cross-platform portable code. Packages will not normally be accepted 
that do not run on at least two of the major R platforms. [I believe 
"the major R platforms" means {MacOS, Windows, Linux} but I don't think? 
this is explicitly defined anywhere.]


  So, at least as far as publicly viewable policies go, the CRAN 
maintainers would be able to ask you to make "all reasonable efforts". 
(In my opinion, figuring out how to make your package work properly with 
ODS 12.6 would take more than a "reasonable" effort, but .. ???)


  cheers
   Ben Bolker



=
Where these compilers cannot be used, use
GCC 5.2.0 from OpenCSW, with config.site:
CC="/opt/csw//bin/gcc"
CFLAGS=-O2
CPPFLAGS="-I/opt/csw/include -I/usr/local/include"
FC="/opt/csw//bin/gfortran"
FFLAGS=-O2
CXX="/opt/csw//bin/g++"
CXXFLAGS=-O2
LDFLAGS="-L/opt/csw/lib -L/usr/local/lib"
R_LD_LIBRARY_PATH="/usr/local/lib:/opt/csw/lib:/home/ripley/developerstudio12.6/lib:/usr/openwin/lib"




On 8/23/21 3:31 PM, Reed A. Cartwright wrote:

What is the proper way to indicate that a package submitted to CRAN
requires the gcc compiler on Solaris? I haven't been able to find any
information about how to indicate that in a way that the CRAN builders will
pick up on it.

--
Reed A. Cartwright, PhD
Associate Professor of Genomics, Evolution, and Bioinformatics
School of Life Sciences and The Biodesign Institute
Arizona State University
==
Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA
Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
85287-5301 USA
Office: Biodesign B-220C, 1-480-965-9949
Website: http://cartwrig.ht/

[[alternative HTML version deleted]]

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] (no subject)

[Ben Bolker]

  You can go to the URL that is at the bottom of every message from 
this list <https://stat.ethz.ch/mailman/listinfo/r-package-devel> and 
search for "unsubscribe" in the page ...


On 9/3/21 1:13 PM, Krishan Gupta wrote:

Please please stop sending emil to me. i want to not recieve more mails.

*Best regards,*

*Krishan Gupta*
*PhD scholar, the Sengupta Laboratory*

[[alternative HTML version deleted]]

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


  cheers
   Ben Bolker

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

[R-pkg-devel] Solaris segfaults

[Ben Bolker]

  I may have asked something like this before, but ...

The glmmTMB package is currently segfaulting (on the very first example) 
on its CRAN Solaris checks

https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html


> ## Comparing variance-covariance matrix with manual computation
> data("sleepstudy",package="lme4")
> fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)

 *** caught segfault ***
address 4539ec45, cause 'memory not mapped'
---



 We have to submit a new version to CRAN soon; we will most likely beg 
the CRAN maintainers' indulgence for having it fail on Solaris, but it 
would be nice to fix it if we can.


   The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because 
the package uses Rcpp.


  The package builds/checks fine on the r-hub `solaris-x86-patched` 
platform, which is identical as far as I can tell **except** 32-bit 
rather than 64-bit.


  Short of installing 64-bit Solaris in a VM (which I have not done yet 
because of random compatibility/command-line bullshittery that put me 
off), does anyone have any wisdom to share for diagnosing and/or 
guessing what the problem is?


  Here are some links to similar errors, none of them seem terribly 
useful/relevant.


https://github.com/gagolews/stringi/issues/94
https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html

  glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen, 
CppAD, TMB) - the problem could be somewhere in there (the TMB package 
runs no tests and very few examples on CRAN, so there could be problems 
there that only get flagged when we try glmmTMB examples).


More discussion at
 https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings) 
if anyone is interested.


  cheers
   Ben Bolker

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

Re: [R-pkg-devel] Solaris segfaults

[Ben Bolker]

 I think I got confused by the fact that the second line of

https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
is "Solaris 10 on ix64/x64".

  I interpreted that as "64-bit Solaris".  On the other hand the rest 
of the information in that file says that the default ODS compiler used 
is a 32-bit build; it doesn't say anything about the build of the 
alternative gcc compiler (which is used for packages with Rcpp etc.) 
Other comments farther down in the file (about versions of Java, 
protobuf used) do suggest that the system is indeed 32-bit.


 If the CRAN Solaris platform is indeed 32-bit, then I really have no 
idea why checks are failing on CRAN but succeeding on r-hub (but I also 
feel better about not trying to fix it ...)


  I do appreciate the provision of the resources for setting up a 
virtual Solaris box - I don't recall exactly what hurdle I encountered 
last time I tried, it was probably some weird idiosyncratic thing.


  For the record I haven't tried valgrind recently, but the CRAN 
versions of the valgrind tests weren't throwing any errors ... 
https://cran.r-project.org/web/checks/check_issue_kinds.html


  thanks
   Ben Bolker


On 9/15/21 2:19 AM, Gábor Csárdi wrote:

Hi Ben,

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

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

Best,
Gabor

On Wed, Sep 15, 2021 at 1:51 AM Ben Bolker  wrote:


I may have asked something like this before, but ...

The glmmTMB package is currently segfaulting (on the very first example)
on its CRAN Solaris checks
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html


  > ## Comparing variance-covariance matrix with manual computation
  > data("sleepstudy",package="lme4")
  > fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)

   *** caught segfault ***
address 4539ec45, cause 'memory not mapped'
---



   We have to submit a new version to CRAN soon; we will most likely beg
the CRAN maintainers' indulgence for having it fail on Solaris, but it
would be nice to fix it if we can.

 The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because
the package uses Rcpp.

The package builds/checks fine on the r-hub `solaris-x86-patched`
platform, which is identical as far as I can tell **except** 32-bit
rather than 64-bit.

Short of installing 64-bit Solaris in a VM (which I have not done yet
because of random compatibility/command-line bullshittery that put me
off), does anyone have any wisdom to share for diagnosing and/or
guessing what the problem is?

Here are some links to similar errors, none of them seem terribly
useful/relevant.

https://github.com/gagolews/stringi/issues/94
https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html

glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen,
CppAD, TMB) - the problem could be somewhere in there (the TMB package
runs no tests and very few examples on CRAN, so there could be problems
there that only get flagged when we try glmmTMB examples).

More discussion at
   https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings)
if anyone is interested.

cheers
 Ben Bolker

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

__
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

[Ben Bolker]

  I think you're not supposed to stop().

  You should just proceed with the other tests (skipping any 
tests/examples that depend on access to the inaccessible internet 
resources, or values derived from the failing call, to work)


  Does that help?

On 9/24/21 10:49 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:

Hi All:

I am getting dinged again on CRAN  (just Solaris for some reason),  and the 
problem is how to exit if there is a failure of accessing the resource,  I know 
it has been discussed here before,  but I just am not understanding what is 
desired to end properly. As I have been reminded:

'Packages which use Internet resources should fail gracefully with an 
informative message
if the resource is not available or has changed (and not give a check warning 
nor error).'

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.  The point is I have 
checked that the access to the internet resources has worked,  i have seen that 
it hasn't,  now what should be the steps to take to exit gracefully.

I also want to add to what others have said about the frustrations of dealing 
with Solaris.  I have spent a fair amount of time getting things to  work with 
Solaris which no one uses.  In this instance the package test is only failing 
on Solaris.   Not a good use of limited time IMO.

Thanks for any advice.

-Roy



**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] [External] Formula modeling

[Ben Bolker]

  There's a Formula package on CRAN 
 that's 
designed for this use case.


  lme4 and nlme don't use it, but implement their own formula 
manipulation machinery. (The cleanest version of this machinery is 
actually in glmmTMB at 
https://github.com/glmmTMB/glmmTMB/blob/master/glmmTMB/R/reformulas.R .)


  I would probably recommend Duncan's or Richard's approach, but if you 
want to keep your original syntax then the Formula package is probably 
the way to go.



On 10/7/21 5:58 PM, Duncan Murdoch wrote:
I don't work with models like this, but I would find it more natural to 
express the multiple formulas in a list:


   list(d ~ p + x + y, s ~ p + w + y, p ~ z + y)

I'd really have no idea how either of the proposals below should be parsed.

Of course, if people working with models like this are used to working 
with notation like yours, that would be a strong argument to use your 
notation.


Duncan Murdoch

On 07/10/2021 5:51 p.m., Richard M. Heiberger wrote:
I am responding to a subset of what you asked.  There are packages 
which use multiple formulas

in their argument sequence.


What you have as a single formula with | as a separator
q | p | subject | time | rho ~ p + x + y | p + w + y | z + y
I think would be better as a comma-separated list of formulas

q , p , subject , time , rho ~ p + x + y , p + w + y , z + y

because in R notation | is usually an operator, not a separator.

lattice uses formulas and the | is used as a conditioning operator.

nlme and lme4 can have multiple formulas in the same calling sequence.

lme4 is newer.  from its ?lme4-package
‘lme4’ covers approximately the same ground as the earlier ‘nlme’
  package.

lme4 should probably be the modelyou are looking for for the package 
design.



On Oct 07, 2021, at 17:20, pikappa.de...@gmail.com wrote:

Dear R-package-devel subscribers,



My question concerns a package design issue relating to the usage of
formulas.



I am interested in describing via formulas systems of the form:



d = p + x + y

s = p + w + y

p = z + y

q = min(d,s).



The context in which I am working is that of market models with, 
primarily,

panel data. In the above system, one may think of the first equation as
demand, the second as supply, and the third as an equation 
(co-)determining
prices. The fourth equation is implicitly used by the estimation 
method, and
it does not need to be specified when programming the R formula. If 
you need

more information bout the system, you may check the package diseq.
Currently, I am using constructors to build market model objects. In a
constructor call, I pass [i] the right-hand sides of the first three
equations as strings, [ii] an argument indicating whether the 
equations of
the system have correlated shocks, [iii] the identifiers of the used 
dataset
(one for the subjects of the panel and one for time), and [iv] the 
quantity
(q) and price (p) variables. These four arguments contain all the 
necessary

information for constructing a model.



I would now like to re-implement model construction using formulas, 
which

would be a more regular practice for most R users. I am currently
considering passing all the above information with a single formula 
of the

form:



q | p | subject | time | rho ~ p + x + y | p + w + y | z + y



where subject and time are the identifiers, and rho indicates whether
correlated or independent shocks should be used.



I am unaware of other packages that use formulas in this way (for 
instance,

passing the identifiers in the formula), and I wonder if this would go
against any good practices. Would it be better to exclude some of the
necessary elements for constructing the model? This might make the 
resuting
formulas more similar to those of models with multiple responses or 
multiple
parts. I am not sure, though, how one would use such model formulas 
without
all the relevant information. Is there any suggested design 
alternative that

I could check?



I would appreciate any suggestions and discussion!



Kind regards,

Pantelis


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Crmh%40temple.edu%7C21a51d63bc6242e5e24908d989d84fce%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637692385020500219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UKazmoIzXSn8DDQY3diUTPmVIg1cfTI3e1roXyo2DMQ%3D&reserved=0 



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



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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistic

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

[Ben Bolker]

  FWIW there is some machinery in the glmmTMB package for querying, 
setting, etc. the number of OpenMP threads.


https://github.com/glmmTMB/glmmTMB/search?q=omp

On 10/9/21 11:45 AM, Vladimir Dergachev wrote:



On Sat, 9 Oct 2021, Jeff Newmiller wrote:

Keep in mind that by embedding this decision into your package you may 
be consuming a resource (cores) that may be more efficiently allocated 
by an application-level partitioning. of available resources. I for 
one am not a fan of this kind of thinking, and it makes system 
requirements for your package more complex even if you allow me to 
disable it.


That's right, and this is why I was asking about any present or future 
plans for R support - if there was a way to find out how many threads R 
should use, I would use that.


So far, it looks like the most portable way is to use OpenMP and let the 
user set an appropriate environment variable if they want to restrict 
thread usage. I could use the same OpenMP variable for pthreads as well.


This is pretty common on clusters anyway, with openmp environment 
variables set automatically to the number of cores user requested.


I would probably also add a function to the package to report the number 
of threads being used. Not sure whether it would be a good idea to 
report this during package loading (and not sure what is the right way 
to display a message during package load either).


best

Vladimir Dergachev

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] Using \donttest with R >= 4.0.0

[Ben Bolker]

  (This crossed with Martin Ondrus's reply).

  In the past few years CRAN screeners have gotten more strict about 
\dontrun{}; a first-round screening often comes back requesting that 
\dontrun{}, and commented-out examples, not be used.


https://stat.ethz.ch/pipermail/r-package-devel/2018q3/003084.html
https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002811.html

  Guido, perhaps the screening is being applied differently in your case?

  Another strategy, albeit one that is a little bit annoying/requires 
some more machinery, is to store pre-computed objects in 
inst/example-data, then do something like



fitted_model <- readRDS(system.file("example-data", "fit1.rds", package 
= "my_pkg"))


 the object (which takes too long to fit as part of a testing flow) 
then becomes available for showing how methods apply to it.


  cheers
   Ben


On 11/16/21 2:56 PM, Guido Schwarzer wrote:

Am 16.11.21 um 20:16 schrieb Martin Ondrus:


Hi Duncan,

That's a fair point, and I think making the examples run quicker probably
makes the most sense. I have bad experiences with using dontrun - my
package always gets flagged. Although not ideal, it's probably better to
include some very fast running examples rather than none at all. 
Appreciate

your advice/help!


I have been using dontrun for a long time (and I am still using it) 
without any real issues. Initially, I used it to get rid of runtime 
notes impeding submission to CRAN. Now I am also using it for additional 
features, e.g., to describe some additional analyses / figure layouts.


I always check my packages under R-devel on 
https://win-builder.r-project.org/ before submission to CRAN. If this 
does not trigger any notes, the package is good to go.


Best, Guido

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics

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

[R-pkg-devel] nit-picking about CRAN repository policy

[Ben Bolker]

  Folks,

  CRAN has recently set up an auxiliary 'noSuggests' test platform that 
tests that packages are using suggested packages conditionally, as 
recommended in Writing R Extensions, and as (sort of) specified in the 
CRAN repository policy.


  Specifically, the CRP (revision 5236) says:

> A package listed in ‘Suggests’ or ‘Enhances’ should be used 
conditionally in examples or tests if it cannot straightforwardly be 
installed on the major R platforms. (‘Writing R Extensions’ recommends 
that they are always used conditionally.)


  One of my packages failed on the 'noSuggest' test platform 
<https://www.stats.ox.ac.uk/pub/bdr/noSuggests/bbmle.out> because two 
suggested packages were used unconditionally in the vignette. There are 
two reasons (IMO) that this should *not* have triggered a threat of 
archiving:


  (1) the unconditional package use was in a vignette, not in examples 
or tests
  (2) the relevant packages (AICcmodavg and MuMIn) are available on 
CRAN and install easily on Linux/Windows/MacOS (they are R-only, no 
compiled code or extra requirements, binaries are available on CRAN).


   Is it worth suggesting to CRAN maintainers that either they refine 
their 'noSuggests' test so that it conforms to the wording in the CRP, 
or that they change the CRP wording to something stricter like


> Any package listed in ‘Suggests’ or ‘Enhances’ should be used 
conditionally in examples, tests, and vignettes.


 ?

  cheers
Ben Bolker

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

Re: [R-pkg-devel] DOI / URL issues in package vignettes

[Ben Bolker]

On 2022-05-18 6:56 a.m., Ivan Krylov wrote:

В Wed, 18 May 2022 12:06:03 +1000
Joshua Wiley  пишет:


curl -I -L https://doi.org/10.1037/met434

gives the below on my system, which (I think?) means you get the
expected redirect for a DOI and then a 403 forbidden error.  On the
win-builder.r-project.org service (which is fantastic) I get a status
400 bad request.

For other DOIs, I am regularly getting a 503 service unavailable
status from both curl on my machine and winbuilder, but working fine
in browser (e.g., for:   https://doi.org/10.1002/sim.7171).


Many journals employ overzealous anti-robot protection systems that
discriminate against URL checks performed by R, but as long as the DOI
itself is correct, the package is likely to be accepted by CRAN despite
the NOTE resulting from the failing check. You can mention it in the
submission comment to be sure.


  And there was a previous discussion on the list here:

https://hypatia.math.ethz.ch/pipermail/r-package-devel/2022q2/008042.html

__
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

[Ben Bolker]

 The help pages are at

https://github.com/wch/r-source/blob/trunk/src/library/base/man/iconv.Rd

or the equivalent at https://github.com/r-devel/r-svn

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

  they still have \x examples in them, but maybe the use of \x is not 
flagged in the particular context of those examples?



On 2022-07-19 1:32 PM, Spencer Graves wrote:

Hi, Bill, Tomas, et al.:


On 7/19/22 12:10 PM, Bill Dunlap wrote:

Have you tried changing the \x's in that file with \u's?

 > qx <- c("\xf6", "\xf8", "\xdf", "\xfc")
 > Encoding(qx) <- "latin1"
 > qu <- c("\uf6", "\uf8", "\udf", "\ufc")
 > Encoding(qu)
[1] "UTF-8" "UTF-8" "UTF-8" "UTF-8"
 > qx == qu
[1] TRUE TRUE TRUE TRUE



I have not tried anything yet for three reasons:


  1.  I don't know that I have access to anything that can do the 
proper test that's required, so I can know if I've fixed it or not.



  I'm not sure what you need.  AFAIK r-hub's test platforms are still 
down, but win-builder and





  2.  Tomas' blog included examples that seemed to say to replace 
"\xa0" with "\u00a0", NOT "\ua0", and I don't know if this difference 
matters or not.



  3.  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.  If I know the fix in 
the correct development version of help('iconv'), I can copy that.  
Without that, I'm being asked to correct something that may not have 
been corrected in the development version of the base package.



  There are \x's in the examples there




  Thanks,
  Spencer



(charToRaw shows that qu and qx are not byte-for-byte identical: '==' 
coerces the latin1 strings to utf-8.)


-Bill

On Tue, Jul 19, 2022 at 9:38 AM Spencer Graves 
> wrote:


    Hi, Tomas:


    On 7/19/22 2:20 AM, Tomas Kalibera wrote:
 >
 > On 7/19/22 08:37, Spencer Graves wrote:
 >> Hello:
 >>
 >>
 >>   What's the recommended fix for "Warning in
    gsub(gsLi$pattern,
 >> gsLi$replacement, xo) : unable to translate 'Ekstrm' to a 
wide
 >> string; Error in gsub(gsLi$pattern, gsLi$replacement, xo) : 
input

 >> string 1 is invalid"?
 >>
 >>
 >>   This is in:
 >>
 >>
 >>
https://github.com/sbgraves237/Ecfun/blob/master/man/subNonStandardCharacters.Rd


 >>
 >>
 >>
 >>   R-devel is now rejecting some non-ASCII characters that it
 >> previously accepted;  see below.
 >
 > Please see
 >
https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions


 >
 >
 > Looking at the code I guess you should change the strings in icx
    to use
 > \u escapes instead of \x. The use of \x as it is there was 
probably
 > correct when the code was ran in Latin-1 encoding, but not in 
other

 > encodings. Using \u would make it portable. Feel free to ask more
    if my
 > guess is wrong and reading the blog post doesn't help.


           "subNonStandardCharacters.Rd" copies examples from:


https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/iconv



           This file still contains "\x" in 5 places. What's the
    recommended
    fix?  Replace "\x" with "\u00" everyplace?


           I could try that, but I don't know if I have access to
    platforms that
    would tell me if I fixed it or not ;-)


           Thanks very much.
           Spencer Graves

 >
 > Best
 > Tomas
 >
 >
 >
 >>
 >>
 >>   Thanks,
 >>   Spencer Graves
 >>
 >>
 >>  Forwarded Message 
 >> Subject: CRAN package Ecfun and its reverse dependencies
 >> Date: Wed, 13 Jul 2022 06:34:24 +0100
 >> From: Prof Brian Ripley mailto:rip...@stats.ox.ac.uk>>
 >> Reply-To: c...@r-project.org
 >> To: veronica.vincio...@brunel.ac.uk
    ,
 >> spencer.gra...@effectivedefense.org
    , hamedhas...@gmail.com
    ,
 >> dennis.pran...@gmail.com 
 >> CC: c...@r-project.org
 >>
 >> Dear maintainers,
 >>
 >> This concerns the CRAN packages
 >>
 >>   BDWreg DWreg Ecdat Ecfun gk
 >>
 >> maintained by one of you:
 >>
 >>   Dennis Prangle mailto:dennis.pran...@gmail.com>>: gk
 >>   Hamed Haselimashhadi mailto:hamedhas...@gmail.com>>: BDWreg
 >>   Spencer Graves mailto:spencer.gra...@effectivedefense.org>>: Ecfun Ecdat
 >>   Veronica Vinciottimailto:veronica.vincio...@brunel.ac.uk>>: DWre

Re: [R-pkg-devel] Package ‘wflo’ was removed from the CRAN repository.

[Ben Bolker]

  * Automatic unarchiving *might* happen because someone on the CRAN 
team happens to read this thread, but you will improve your odds greatly 
by e-mailing c...@r-project.org with as polite a request as you can 
manage ...


 * My guess is that nothing will happen until you resubmit (FWIW the 
NOTE definitely seems like something CRAN would object to, so you should 
fix it before resubmitting ...)


  good luck,
   Ben Bolker

On 9/22/22 4:15 PM, Carsten Croonenbroeck wrote:

Hi Lluís,

thanks for the clarification. And kudos to your detective flair. I’m serious 
about that, as I would never have found out about this chain of events.

Well, there are no error or warnings to fix, so I think it would be best if 
someone from the CRAN team could “unarchive” wflo since there is no problem 
there and none of the events that were set in motion were due to any of my 
doings. Actually, I don’t really agree to have to resubmit, and my time for 
doing so is very limited. Maybe in the next few weeks or so.

Best

Carsten


Von: Lluís Revilla [mailto:lluis.revi...@gmail.com]
Gesendet: Donnerstag, 22. September 2022 15:33
An: Carsten Croonenbroeck
Cc: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] Package ‘wflo’ was removed from the CRAN repository.

Hi Carsten,

This seems to be an unfortunate chain of events between different packages: 
RcppMLPACK -> emstreeR -> wflo

Package RcppMLPACK was archived on 2021-12-20 as issues were not corrected 
despite reminders.
This resulted in the package emstreeR being archived on 2021-12-20 as requires 
archived package 'RcppMLPACK'.
Which also resulted in your package, wflo, being archived.
Later, emstreeR was unarchived on 2022-03-21 after a successful submission 
improving the dependencies (probably removing the dependency to RcppMLPACK).
You can see the source of this info on 
https://cran.r-project.org/src/contrib/PACKAGES.in

About the emails, usually maintainers whose package depends on a package that 
is about to be removed receive an email with a date by which they should fix 
the problems.
But, as I am not part of the CRAN team I cannot check it.

I would recommend preparing a new submission with all the errors and warnings 
fixed.
Note that I think the package will be checked as a new package.

Best,

Lluís





On Thu, 22 Sept 2022 at 13:17, Carsten Croonenbroeck 
mailto:carsten.croonenbro...@uni-rostock.de>>
 wrote:
Hi,

I was really, really, really surprised to learn today that my package “wflo” 
was removed from CRAN almost a year ago!

Telling from the output at https://CRAN.R-project.org/package=wflo, this is due 
to my package being “Archived on 2021-12-20 as requires archived package 
'emstreeR'.” However, emstreeR is in no way archived (see 
https://CRAN.R-project.org/package=emstreeR). Clicking “check results archive”, 
it says that there is only a note

Result: NOTE
 Namespace in Imports field not imported from: ‘rgdal’
  All declared Imports should be used.

which is indeed correct, I don’t use rgdal anymore. What now, remove the rgdal 
import and resubmit? How come I wasn’t informed, my E-Mail is running 
perfectly. Very puzzling…

Best

Carsten

 [[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

Re: [R-pkg-devel] Found the following (possibly) invalid URLs:

[Ben Bolker]

  I get a 404.

On 2022-09-29 4:50 p.m., Roy Mendelssohn - NOAA Federal via 
R-package-devel wrote:

In testing a new version of one of my package on win builder,   I get the 
following:

Found the following (possibly) invalid URLs:
.
.
.
   URL: 
https://www.integratedecosystemassessment.noaa.gov/regions/california-current-region/index.html
 From: inst/doc/Using_rerddap.html
 Status: 404
 Message: Not Found

It is only in the vignette as a place to look up more about a project,  it is 
never actually accessed,  moreover at least from my home computer it is valid 
URL that I reach. I know I can include something about this in cran-comments,  
but I would prefer not generating any notes so human intervention isn't needed. 
 Any suggestions?  Can others test the URL to see if they have problems 
reaching it.

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

[Ben Bolker]

  Right now as.POSIXlt.Date() is just

function (x, ...)
.Internal(Date2POSIXlt(x))

How expensive would it be to throw a warning when '...' is provided by 
the user/discarded ??


Alternately, perhaps the documentation could be amended, although I'm 
not quite sure what to suggest. (The sentence Liam refers to, "Dates 
without times are treated as being at midnight UTC." is correct but 
terse ...)



On 2022-10-10 4:50 p.m., Alexandre Courtiol wrote:

Hi Simon,

Thanks for the clarification.

 From a naive developer point of view, we were initially baffled that the
generic as.POSIXlt() does very different things on a character and on a
Date input:

as.POSIXlt(as.character(foo), "Europe/Berlin")
[1] "1992-09-27 CEST"

as.POSIXlt(foo, "Europe/Berlin")
[1] "1992-09-27 UTC"

Based on what you said, it does make sense: it is only when creating the
date/time that we want to include the time zone and that only happens when
we don't already work on a previously created date.
That is your subtle but spot-on distinction between "parsing" and
"changing" the time zone.

Yet, we do find it dangerous that as.POSIXlt.Date() accepts a time zone but
does nothing of it, especially when the help file starts with:

Usage
as.POSIXlt(x, tz = "", ...)

The behaviour is documented, as Liam reported it, but still, we will almost
certainly not be the last one tripping on this (without even adding the
additional issue of as.POSIXct() behaving differently across OS).

Thanks again,

Alex & Liam




On Mon, 10 Oct 2022 at 22:13, Simon Urbanek 
wrote:


Liam,

I think I have failed to convey my main point in the last e-mail - which
was that you want to parse the date/time in the timezone that you care
about so in your example that would be


foo <- as.Date(33874, origin = "1899-12-30")
foo

[1] "1992-09-27"

as.POSIXlt(as.character(foo), "Europe/Berlin")

[1] "1992-09-27 CEST"

I was explicitly saying that you do NOT want to simply change the time
zone on POSIXlt objects as that won't work for reasons I explained - see my
last e-mail.

Cheers,
Simon



On 11/10/2022, at 6:31 AM, Liam Bailey 

wrote:


Hi all,

Thanks Simon for the detailed response, that helps us understand a lot

better what’s going on! However, with your response in mind, we still
encounter some behaviour that we did not expect.


I’ve included another minimum reproducible example below to expand on

the situation. In this example, `foo` is a Date object that we generate
from a numeric input. Following your advice, `bar` is then a POSIXlt object
where we now explicitly define timezone using argument tz. However, even
though we are explicit about the timezone the POSIXlt that is generated is
always in UTC. This then leads to the issues outlined by Alexandre above,
which we now understand are caused by DST.


``` r
#Generate date from numeric
 #Not possible to specify tz at this point
 foo <- as.Date(33874, origin = "1899-12-30")
 dput(foo)
#> structure(8305, class = "Date")

 #Convert to POSIXlt specifying UTC timezone
 bar <- as.POSIXlt(foo, tz = "UTC")
 dput(bar)
#> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
#> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =

c("POSIXlt",

#> "POSIXt"), tzone = "UTC")

 #Convert to POSIXlt specifying Europe/Berlin.
 #Time zone is still UTC
 bar <- as.POSIXlt(foo, tz = "Europe/Berlin")
 dput(bar)
#> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
#> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =

c("POSIXlt",

#> "POSIXt"), tzone = "UTC")
```


We noticed that this occurs because the tz argument is not passed to

`.Internal(Date2POSIXlt())` inside `as.POSIXlt.Date()`.


Reading through the documentation for `as.POSIX*` we can see that this

behaviour is described:


   > “Dates without times are treated as being at midnight UTC.”

In this case, if we want to convert a Date object to POSIX* and specify

a (non-UTC) timezone would the best strategy be to first coerce our Date
object to character? Alternatively, `lubridate::as_datetime()` does seem to
recognise the tz argument and convert a Date object to POSIX* with non-UTC
time zone (see second example below). But it would be nice to know if there
are subtle differences between these two approaches that we should be aware
of.


``` r
foo <- as.Date(33874, origin = "1899-12-30")
dput(foo)
#> structure(8305, class = "Date")

#Convert to POSIXct specifying UTC timezone
bar <- lubridate::as_datetime(foo, tz = "UTC")
dput(as.POSIXlt(bar))
#> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
#> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =

c("POSIXlt",

#> "POSIXt"), tzone = "UTC")

#Convert to POSIXct specifying Europe/Berlin
bar <- lubridate::as_datetime(foo, tz = "Europe/Berlin")
dput(as.POSIXlt(bar))
#> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
#> year = 92L, wday = 0L, yday = 270L, isdst = 1L, zone = "CEST",
#>

Re: [R-pkg-devel] How to reduce examples in a package that takes more than 5 seconds to run?

[Ben Bolker]

On 2022-12-15 9:57 a.m., Brian G. Peterson wrote:

On 12/15/22 08:34, Ismail Otoakhia wrote:
The R package 'ardl.nardl' has some examples that take more than 5 
seconds
to run. I was advised by the CRAN team to reduce the run time to less 
than

5 seconds.

How can this be achieved?


- you can lower the amount of data in the example

- you can use a faster method than your default method

- you can wrap the example in a dontrun tag so it will not run during 
checking




  If your example involves something like a fitted model object that 
takes a long time to compute, you can pre-compute the model fit and 
store the object in an inst/testdata directory, then use something like


fitted_model <- readRDS(system.file("testdata", "my_example.rds", 
package = "mypackage"))


to retrieve it


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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

[Ben Bolker]

On 2023-01-08 1:38 p.m., Spencer Graves wrote:



On 1/8/23 11:36 AM, Kevin Coombes wrote:
I have been using R-Forge for many years for package development. And 
I have been using GitLab for other projects almost as long.


However, over the past few months, the R-Forge support seems to be 
decaying, and I now have several projects that won't currently build 
there because of various items that appear to need fixing at their 
end. So, I am actively exploring what it will take to move packages 
and projects to git.



   R-Forge was wonderful for me when I started using it.  Then 
several years ago, I started having problems like you described.  A few 
years ago I migrated from R-Forge to GitHub.



   One problem I encountered in the transition:  On R-Forge, I had 
multiple packages in the same R-Forge project.  I had to split them 
apart for GitHub.




I already know how to use a git client to clone a Subversion 
repository from R-Forge (using "git svn"). And how to change the 
remote origin to push it to a new git location. (And I  may also be 
willing to lose the revision history if it is going to make the 
transition easier.)


I am now at the step of understanding the recent changes at GitLab 
with respect to support for "Educational" or "Open Source" status, 
especially in terms of how many monthly minutes of CI/CD time I can 
use for free. When working on a new package, I tend to make lots of 
small commit-pushes, and it sounds like each one of those will eat up 
minutes. So, any advice on how to manage that issue would be greatly 
appreciated.



   When I first got into Subversion, I remember Doug Bates saying, 
"Commit early and often."  The word "Commit" doesn't mean the same in 
Git as in Subversion, so I would encourage you to "Git push early and 
often."



   There may be limits on free use of GitHub, but I'm not aware of 
them:  If you want a private account, you need to pay for that, but the 
charges for that are not much.


  The free tier of Github allows 2000 minutes/month of continuous 
integration testing for private repos, and unlimited (???) for public 
repos.  (2000 minutes/month is more than I've ever needed.)


  Furthermore, it's pretty easy to set up github actions so that it 
only runs tests if you ask it to (by appending e.g. "[run ci]" to your 
commit message), or in opt-out mode (i.e., skip tests if "[skip ci]" is 
in your commit message).





   If anyone knows anything different from what I've just said, I 
hope they will disabuse my of this part of my ignorance.



   Spencer



Best,
   Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves 
> wrote:


           If you use GitHub, I highly recommend using "GitHub
    Action" as
    described by Wickham and Bryan, R Packages:


    https://r-pkgs.org/code.html#code-style
    


           I'm not sure the best way to get it set up, but I have
    all my
    packages on GitHub configured so each "push" that changes anything 
has

    "R CMD Check" run on 5 different platforms:  The release version of
    R on
    the latest Windows, macOS, and Ubuntu plus the development version 
and
    the most recent old release on Ubuntu.  I rarely run R CMD check 
on my

    local machine anymore:  I just "git commit" and "git push".  Then
    GitHub
    Action manages testing on those 5 platforms.


           To be precise, I do "git status" before "git push" to
    make sure I
    have "committed" everything I want to commit before I "git push". 
    And I
    do "git pull" to make sure a collaborator hasn't "pushed" 
something new

    I should look at before I "git push".


           Finally, I want to thank again Gábor Csárdi who helped me
    greatly get
    past problems I hand with "GitHub Action" for my "sos" package.  He
    provided example workflows in:



https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml 



           I also needed LaTeX support, for which Gábor suggested
    the following:


    https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages





           Spencer Graves


    On 1/8/23 9:11 AM, Kevin R. Coombes wrote:
 > A very helpful answer. For some reason (probably because I have an
 > ancient perl script that automates the steps i take when building
    and
 > checking packages), I keep forgetting that the "tools" package
    let's me
 > do these things from within R.
 >
 > I had already isolated the offending line ("plot(obj)") inside
    the chunk
 > where the error occurred, and removed any additional arguments. I
 > wrapped that line in a "try" command followed by a conditional
 > "traceback()" to find the problem.  This allowed the pa

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

[Ben Bolker]

  Seems pretty mysterious to me! (No cryptic NOTEs anywhere in the 
logs, other than the inevitable "Note_to_CRAN_maintainers")


  I will be curious to see if anyone else finds something, but my guess 
is a hiccup on the CRAN end (i.e., you'll end up sending e-mail to the 
CRAN maintainers to clarify what's going on)



On 2023-01-22 1:51 p.m., Klaus Schliep wrote:

  Dear all,

I try to submit a new version of the package phangorn and got the mail back:

"Dear maintainer,

package phangorn_2.11.0.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/phangorn_2.11.0_20230122_175755/Windows/00check.log



Status: OK
Debian: <
https://win-builder.r-project.org/incoming_pretest/phangorn_2.11.0_20230122_175755/Debian/00check.log



Status: OK"

I am kind of puzzled as to what the problem is, but it might well be that I
missed something? I appreciate any suggestions.

Kind regards,
Klaus Schliep




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] CRAN Packages over 5 MB & Time Length for Manual Inspection

[Ben Bolker]

  Out of curiosity, what was the recently added package?

  It looks like the previous version of your package from about a year 
ago is only a 1.2MB tarball.  Also out of curiosity, what caused the 
increase?


  cheers
   Ben Bolker

On 2023-01-29 1:53 p.m., EcoC2S - Irucka Embry wrote:

Greetings!

I submitted my USA.state.boundaries package on 6 January 2023 and Uwe 
responded back letting me know that it was over the 5 MB CRAN threshold. 
I responded back to Uwe letting him know that as of that date there were 
52 CRAN packages over 5 MB. As of today (29 January 2023), there are 
actually 53 CRAN packages over 5 MB.


As I heard no response back from Uwe, I re-submitted my 
USA.state.boundaries package on 12 January and 21 January. As of today, 
I have not heard any response back from Uwe or any other CRAN team 
volunteer.


There are 2 questions:

1) How long should it take to receive a response back from a CRAN team 
volunteer after a manual inspection of a CRAN package?


2) Why has my package been denied acceptance to CRAN while a new package 
over 5 MB has been allowed to be hosted on CRAN recently?


Thank you in advance.

Irucka Embry




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Package submission rejected as it fails checks on Debian

[Ben Bolker]

  Not important (of course) but where does the 5000 kWh per tree number 
come from?  Is that (dry weight) x (50% carbon per dry weight) / (carbon 
content of CO2 emissions per kWh) ?


https://www.epa.gov/energy/greenhouse-gas-equivalencies-calculator#results

  If we say 200 watts x 15 minutes (allowing us to take up the whole 
server for checking on 5 different platforms) we have .05 kWh. Let's say 
we do this 300 times/year for a package, so 15 kWh. Hard to get 'tree 
equivalents' from the EPA web site, but this is equivalent to 1.2 
gallons of petrol/gasoline consumption (0.011 metric tonnes)



On 2023-02-23 12:59 p.m., Duncan Murdoch wrote:

Hi Martin.

I think your calculations are way off.  A one-tonne tree contains about 
5000 kWh of energy.  A typical computer server uses about 200 watts, and 
can process many jobs simultaneously on different cores, but let's say 
the whole server is dedicated to the Github action.  Then it would 
consume 1 kWh in 5 hours, and would take about 10 days to consume 1% of 
a tree.


Duncan Murdoch

On 23/02/2023 11:29 a.m., Martin Maechler wrote:

Spencer Graves
 on Tue, 21 Feb 2023 05:25:39 -0600 writes:


 > On 2/21/23 2:34 AM, Vasileios Nikolaidis wrote:
 >> Yes, with all this I can think where I may have messed up. So 
thanks for
 >> the help, at least it verified it is indeed an issue with the 
code. As
 >> far as OSs, I use Ubuntu variants a lot and (on several 
machines) but
 >> these days I have easier access to Windows (with WSL2 btw). I 
also like
 >> a strict compiler (and linker), there is usually a reason why 
they are
 >> strict. So if it is not obvious from examining the code,  I 
will set up

 >> something (be it WSL, VM or Docker) for testing.


 > If you have NOT tried "GitHub Action" yet, I highly recommend it.
 > For my packages, every time I do "git push", it automatically 
runs "R
 > CMD build / check" on 5 different platforms -- with no further 
effort on

 > my part other than checking the results.

[ Sorry, but for once I'd like to raise this here ...]:

well... how many "trees" does that cost every time you push?
I guess it will be less than one, but I'd also guess it be more
than 1% of one.. and even if that was more than reality, ...

I hope you are all aware that even though this looks "free", all
this mostly unnecessary (rebuilding some of the things *every*
time from scratch, downloading lots of stuff, even though from a
closeby server) traffic and server run time will partly be paid
by the kids and grand kids of people living in Bangladesh,
Polynesia, ... (and maybe even in say Amsterdam)
Global Warming *is* a threat, and we living in rich nations letting run
more and more computer networks and servers (cooling, heating,
gray energy including lots of CO2 produce by building construction, ...)
does add to it.

[[[yes, I may be partly wrong,  and
 no, it's a loss of time if we start a flame/mud/... war here 
about this;

 just consider it a small outlier voice ...
]]]


 > It should be easy to get something to work following the 
instructions
 > in Wickham and Bryan, R Packages[1] or copying the code from 
another
 > package.[2] If that fails, you might be able to get help from 
this list.
 > I got valuable suggestions from Dir Eddelbuettel and Duncan 
Murdoch.



 > I don't know if any version of Debian is available on GitHub 
Action.
 > However, if CRAN is rejecting your package on GitHub Action, a 
question

 > about that to this list might help make it available.  If you have
 > special Ubuntu configuration issues that are not provided in the
 > standard GitHub Action configurations, asking here might help 
you with

 > that.


 > Hope this helps,
 > Spencer Graves


 > [1]


 > https://r-pkgs.org


 > [2] e.g.,


 > https://github.com/JamesRamsay5/fda

 >>
 >> Thanks again,
 >>
 >> Vasilis
 >>
 >>
 >>
 >> Στις 2023-02-20 23:09, Dirk Eddelbuettel έγραψε:
 >>> On 20 February 2023 at 22:37, Vasileios Nikolaidis wrote:
 >>> | Thanks for taking the time to check it. The hint about the 
virtual

 >>> | 'layer' class is valuable.
 >>> | I will look into it.
 >>>
 >>> Sounds good, glad to have been of assistance.  On a lark, I 
also tried

 >>> your
 >>> most recent CRAN release, and it installs and loads fine here.
 >>>
 >>> | PS I am tempted to set up a Debian test platform to speed 
up fixing the

 >>> | package.
 >>> | (Or abandon submitting the package to CRAN alltogether.)
 >>>
 >>> I love working on Linux. And these days I hear from some 
friends that

 >>> having
 >>> WSL2 on a (recent enough) Windows computer is also good as it 
effectively
 >>> gives a second machine with Ubuntu on it.  Docker can also be 
helpful,

 >>> as are
 >>> the online resources -- rhub has helped me with both macos 
and windows

[R-pkg-devel] FAIL output in CRAN checks?

[Ben Bolker]

  I don't know that I've ever seen this one before: a result of FAIL 
for a CRAN check.


  There's a WARNING which I already know about, but this build seems to 
get hung up on "checking re-building of vignette outputs ..." (which 
takes about 70/95 seconds on most other platforms)


https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/lme4-00check.html 



  Does anyone have ideas about this? Is this something I should worry 
about/try to diagnose and fix?  (r-hub does appear to have a 
fedora/clang platform)


  For what it's worth:

> rhub::platforms()
Error in curl::curl_fetch_memory(url, handle = handle) :
  Peer certificate cannot be authenticated with given CA certificates: 
[builder.r-hub.io] SSL certificate problem: certificate has expired


  I guess I could report that ...


  cheers

   Ben Bolker

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

[R-pkg-devel] URL timeout in win-builder check: suggestions?

[Ben Bolker]

  I have a URL in my documentation that got a timeout error from 
win-builder, possibly because of some kind of service provider filtering 
of bots (I think there was a previous issue with Cloudflare links?)


  I can get to it fine interactively/in a browser.

  This link is a harmless bit of fluff (click through if you want to 
see), but I don't want it causing hiccups in my CRAN submission (i.e., I 
could take it out if necessary but would prefer not to ...)


Suggestions?

===
* checking CRAN incoming feasibility ... NOTE
Maintainer: '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


__
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

[Ben Bolker]

  I would try running them on https://win-builder.r-project.org/ . If 
the Windows timings are OK on that platform I think you can make a good 
case to CRAN that you've done your best ...


On 2023-03-14 9:52 a.m., Chris Brien wrote:

Dear list members.

I have run into a problem with examples from my package growthPheno 
(https://github.com/briencj/growthPheno) that take more than 10 s to execute on 
two flavours under r-devel. The following is the details.log:

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
   Maintainer: 'Chris Brien mailto:chris.br...@adelaide.edu.au'

Flavor: r-devel-windows-x86_64
Check: examples, Result: NOTE
   Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
   probeSmooths 13.56 0.15 13.73
   traitSmooth 13.03 0.10 13.13

When I run the examples on laptop and a desktop running Windows 10 under 
r-devel with all packages updated, the elapsed times were 4.26 and 4.45, 
respectively i.e. much less than on the CRAN platforms. These timings were 
achieved using the following function call from RStudio (2022.12.0 Build 353):


devtools::check("growthPheno", manual=FALSE, check_dir="D:/Analyses/R",

+ args="--as-cran", env_vars = c(NOT_CRAN = "false"))

I have also submitted the package to rhub using the following command:

  rhub::check_for_cran(path = "growthPheno_2.1.18.tar.gz",
env_vars = c(`_R_CHECK_FORCE_SUGGESTS_` = "false",
`_R_CHECK_CRAN_INCOMING_USE_ASPELL_` = "false"),
email = "chris.br...@adelaide.edu.au") with the following 
results for timing:

The timing results were:

Examples with CPU (user + system) or elapsed time > 5s
   user system elapsed
 probeSmooths   6.50 0.09   6.64
traitSmooth 6.02 0.03  6.04

While these are higher than the timings on my machines, they are half those 
reported on in the details.log resulting from my CRAN submission.

In order to be able to pass the CRAN tests, I have reduced the examples so that 
the timings on my laptop are (sessionInfo is below):

   user system elapsed
probeSmooths2.320.062.45
traitSmooth 3.470.093.73

and, using rhub::check_for_CRAN, the timings > 5 s are:

 user system elapsed
probeSmooths 5.16  0.07 6.42

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.

Cheers,

  Chris

Chris Brien
Adjunct Associate Professor in Statistics, UniSA STEM| web page
Senior Biostatistician, Australian Plant Phenomics Facility | researcher profile

---

sessionInfo()

R Under development (unstable) (2023-03-13 r83977 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default


locale:
[1] LC_COLLATE=English_Australia.utf8  LC_CTYPE=English_Australia.utf8
[3] LC_MONETARY=English_Australia.utf8 LC_NUMERIC=C
[5] LC_TIME=English_Australia.utf8

time zone: Australia/Adelaide
tzcode source: internal

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
  [1] tidyselect_1.2.0   viridisLite_0.4.1  dplyr_1.1.0viridis_0.6.2
  fields_14.1
  [6] fastmap_1.1.1  xopen_1.0.0promises_1.2.0.1   digest_0.6.31
  rpart_4.1.19
[11] dotCall64_1.0-2mime_0.12  lifecycle_1.0.3cluster_2.1.4 
 ellipsis_0.3.2
[16] processx_3.8.0 magrittr_2.0.3 compiler_4.3.0 rlang_1.0.6   
 Hmisc_5.0-1
[21] tools_4.3.0utf8_1.2.3 yaml_2.3.7 data.table_1.14.8 
 knitr_1.42
[26] prettyunits_1.1.1  htmlwidgets_1.6.1  curl_5.0.0 pkgbuild_1.4.0
 dae_3.2.15
[31] plyr_1.8.8 RColorBrewer_1.1-3 JOPS_0.1.15pkgload_1.3.2 
 miniUI_0.1.1.1
[36] foreign_0.8-84 withr_2.5.0purrr_1.0.1desc_1.4.2
 nnet_7.3-18
[41] grid_4.3.0 fansi_1.0.4urlchecker_1.0.1   profvis_0.3.7 
 xtable_1.8-4
[46] colorspace_2.1-0   ggplot2_3.4.1  scales_1.2.1   MASS_7.3-58.3 
 cli_3.6.0
[51] rmarkdown_2.20 crayon_1.5.2   generics_0.1.3 remotes_2.4.2 
 rstudioapi_0.14
[56] sessioninfo_1.2.2  cachem_1.0.7   SemiPar_1.0-4.2stringr_1.5.0 
 maps_3.4.1
[61] base64enc_0.1-3vctrs_0.5.2devtools_2.4.5 callr_3.7.3   
 rcmdcheck_1.4.0
[66] Formula_1.2-5  htmlTable_2.4.1testthat_3.1.7 SpATS_1.0-18  
 glue_1.6.2
[71] spam_2.9-1 ps_1.7.2 

Re: [R-pkg-devel] Replacing dplyr by stats functions

[Ben Bolker]

    If you use Depends: in your package I think this is unavoidable 
(but, I don't think these should be counted against you as warnings by 
CRAN - they're "Warnings" not "WARNINGs" :-) )


   The only way I know of to avoid this would be to Import: rather than 
Depend:, and import only the functions you need.



On 2023-04-19 4:36 a.m., A. Kucharski wrote:

Hi,

I am developing my own package. I have a problem with its new version. Checking 
on the CRAN server gives 2 warnings like this (critpath is my package):
Warning: replacing previous import 'dplyr::lag' by 'stats::lag' when loading 
'critpath'
Warning: replacing previous import 'dplyr::filter' by 'stats::filter' when 
loading 'critpath'

On my machine these warnings show up during Check but before Build starts so at 
the end I get a message that the number of warnings is 0. I don't use lag or 
filter at all in my package although I use both of these packages. Reordering 
the dplyr and stats package names in the Depends of the Description file didn't 
help. Is it a problem with my code or a conflict between those two packages? 
Please help me remove these warnings.

Best regards

Adam

Wysłane z aplikacji Poczta dla systemu Windows


[[alternative HTML version deleted]]

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


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

[R-pkg-devel] new/slightly mysterious CRAN warnings

[Ben Bolker]

  Submission of most recent version of lme4 threw a NOTE on CRAN's 
Debian platform that we had not seen when running "R CMD check 
--as-cran" with the most recent SVN checkout, nor when submitted to 
win-builder/R-devel.  These are legitimate issues (all now fixed), but 
we were taken by surprise because they weren't detected on any platforms 
we tested on.


  So far, archaeology in the R code base/Github mirror about recent 
changes to tools::checkS3methods, or about environment variables, hasn't 
been entirely successful, although based on


grep Sys.getenv src/library/tools/R/QC.R  | sed -e 's/.*Sys.getenv("//' 
| sed -e 's/"[,)].*//' | sort | uniq


it looks like we *might* want to set

_R_CHECK_S3_METHODS_SHOW_POSSIBLE_ISSUES_

when testing ...

  This is mostly a heads-up/documentation for anyone who might be 
interested.



Debian: 



 R Under development (unstable) (2023-04-20 r84291)

 NOTE
Mismatches for apparent methods not registered:
print:
  function(x, ...)
print.bootWarnings:
  function(x, verbose)

format:
  function(x, ...)
format.perc:
  function(probs, digits)

Apparent methods for exported generics not registered:
  ngrps.default
See section ‘Registering S3 methods’ in the ‘Writing R Extensions’
manual.

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

Re: [R-pkg-devel] Acknowledging small functions from another package

[Ben Bolker]

  In fact Martin Maechler added this in 2021:

https://github.com/wch/r-source/blob/trunk/src/library/utils/R/str.R#L19-L21

## A pearl from ggplot2 et al.  NB: often needs '(.)' :%||% ( 
 )

## *not exported* [should rather be in 'base' than exported here]
`%||%` <- function(L,R) if(is.null(L)) R else L


On 2023-05-04 5:59 a.m., David Hugh-Jones wrote:

Thank you both. This sounds sensible. Yeah, add my vote for `base::%||%`!!


David


On Thu, 4 May 2023 at 10:00, Duncan Murdoch 
wrote:


On 04/05/2023 4:53 a.m., Ivan Krylov wrote:

On Thu, 4 May 2023 09:21:17 +0100
David Hugh-Jones  wrote:


One of my packages copy-pasted some small functions (stuff like
`%||%` for is.null) from ggplot2. (Both packages are MIT-licensed.)

What is an appropriate way to acknowledge this in the DESCRIPTION
Author: or Authors@R section?


One way would be to mention Hadley Wickham:


https://github.com/tidyverse/ggplot2/commit/ef2f944863a0db8841bf628e9eb4a9faef5049e6#diff-8f53135445ab98749043fa52e438346bb9acae8e0185aa95f186d0aa021bb7e0

(`git blame` will also tell you that he later moved this function to a
different file).

I think that person('ggplot2 authors', role = 'cph', comment = 'The
%||% operator') is also fine, just like e.g. unitizer package mentions
the code taken from R itself.

You can also find this operator in multiple base R packages, currently
unexported (maybe some day...). They mention in the comments that the
operator is adapted from ggplot2.


I'd probably use role = "ctb" instead for "ggplot2 authors", and include
Posit PBC as a copyright holder (as ggplot2 does).  Presumably you or
others are also copyright holders for your package and should also have
role = "cph" added so it doesn't give the impression that Posit owns
everything.

Duncan Murdoch




[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] masked from 'package:utils':,, ?

[Ben Bolker]

   This is harmless and should be accepted by CRAN (if masking existing 
functions were illegal half of the tidyverse would be banned ...).  It's 
there because it needs to be defined in order to enable the ??? alias 
for findFn().  sos:::"?" (and experimentation) show that use of a single 
? is passed through to the original 'utils' version.



On 2023-05-23 4:59 p.m., Spencer Graves wrote:




Hello, All:


  CRAN checks for sos on 8 of the 13 platforms complain about the 
following:



The following object is masked from 'package:utils':

    ?


  This is code that Duncan Murdoch contributed to this package 
around 2009.  I have no idea how to fix this.  It's only a NOTE, so 
CRAN would probably accept it.  However, I felt a need to ask about 
this before I submitted the package to CRAN without asking this group 
for suggestions.



  What do you think?
  Thanks,
  Spencer Graves

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


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

Re: [R-pkg-devel] Public URLs for help for versions of base packages

[Ben Bolker]

  Nice! (I like "A longer description will go here eventually.")

 It would be cute/handy to have navigation links available for "go to 
this help page in the next (previous) version of R" (if it's not a huge 
pain)


On 2023-06-30 11:10 a.m., David Hugh-Jones wrote:

OK, so I took Jeff's hint and did this myself!

https://github.com/hughjonesd/r-help

Sample page for ?plot from the first version of R (at least, the first
version that is on svn):

https://hughjonesd.github.io/r-help/0.60/base/plot.html

Not everything is guaranteed to work, so please report bugs if you find any.

Cheers,
David


On Fri, 30 Jun 2023 at 13:23, David Hugh-Jones 
wrote:



There are plenty of places to find current docs. I think it’s fine to have
versioned ones also. I agree it would be a good idea to clearly signal
“hey, this is an old version” - indeed I’ve been bitten by that in python
before. I’m working on this now… will see what I can do.

Does anyone happen to know if it’s possible to create 00index files
without installing the relevant package? (Loading R 0.60 is challenging…)

D



On Fri, 30 Jun 2023 at 13:02, Duncan Murdoch 
wrote:


On 30/06/2023 7:57 a.m., David Hugh-Jones wrote:

Static web pages get indexed by google.


Isn't that an argument against having static pages?  If I do a Google
search for "R lm" I think it's better to find the current docs rather
than dozens of obsolete versions.  It's rare that someone wants to see
changes across versions, so doing that should take extra work.

Duncan Murdoch



David


On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch mailto:murdoch.dun...@gmail.com>> wrote:

 Why store them?  Download the source on demand, and convert it.

Seems

 pretty simple.

 Duncan Murdoch

 On 30/06/2023 1:19 a.m., David Hugh-Jones wrote:
  > This is for the rcheology package. I run a Shiny web app which
 lets you
  > examine changes to functions across R versions:
  >
  > https://hughjonesd.shinyapps.io/rcheology/
 
  >
  > Manually storing and converting the Rd might be possible, but it
 would be
  > burdensome in terms of data (and my time). And if the Rd spec has
 changed
  > across versions, that’s another problem.
  >
  > More generally, shouldn’t there be publicly available versioned
  > documentation? Python has had this for a long time.
  >
  > David
  >
  >
  > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller
 mailto:jdnew...@dcn.davis.ca.us>>
  > wrote:
  >
  >> Sure. On your computer. Install the old version of R and let it
 serve the
  >> relevant docs.
  >>
  >> Dunno of anyone doing this historical dive online for you
 though. Why
  >> would you want preformatted docs if you didn't have those old
 versions
  >> installed?
  >>
  >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones <
  >> davidhughjo...@gmail.com >

wrote:

  >>> That’s useful to know. But is there anywhere with preformatted
 HTML pages?
  >>>
  >>> Cheers, D
  >>>
  >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov
 mailto:krylov.r...@gmail.com>> wrote:
  >>>
   On Thu, 29 Jun 2023 20:22:47 +0100
   David Hugh-Jones mailto:davidhughjo...@gmail.com>> wrote:
  
  > I'm looking for a source of online help for R base
  > packages, which covers all versions (for some reasonable

value of

  > "all"). So e.g. the equivalent of `?lm` for R 4.1.0.
  
   These live in the R source tree, under src/library:
   https://svn.r-project.org/R/trunk/src/library/
 
  
   For the actual releases of R, you may have to go looking at

the

   branches inside that repository, e.g., the following command:
  
   svn log \
  
  
  >>


https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd
<
https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd


  
   ...should tell you the history of ?lm until the latest
 R-4.1-patched.
  
   Do the Git mirrors track these release branches? The branching
 model of
   Subversion [*] is different from the Git model, so perhaps

not.

  
   --
   Best regards,
   Ivan
  
   [*]
 https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
 >
  >> --
  >> Sent from my phone. Please excuse my brevity.
  >>
  >> __
  >> R-package-devel@r-project.org
  mailing list
  >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
 

Re: [R-pkg-devel] Package PowerSDI NOTES

[Ben Bolker]

  See also

https://ropensci.org/blog/2022/01/21/ropensci-news-digest-january-2022/#to-quote-or-not-to-quote-non-existing-words-in-description

https://stat.ethz.ch/R-manual/R-patched/library/utils/html/aspell-utils.html

On 2023-07-18 3:11 p.m., Duncan Murdoch wrote:

On 18/07/2023 12:37 p.m., Gabriel Constantino Blain wrote:

Dears,
I submitted my R package to CRAN.
However, it didn't pass the CRAN checks because of 2 notes:
Note 1:
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: NOTE
   Maintainer: 'Gabriel Constantino Blain '
   New submission
 Possibly misspelled words in DESCRIPTION:
 EP (14:45)
 NASAPOWER (11:18)
 OperatSDI (12:9)
 PowerSDI (7:18, 13:9)
 SPEI (3:31, 7:50, 10:20)
 SPI (3:23, 7:42, 10:12)
 ScientSDI (9:19)
 evapotranspitation (13:44)
 subperiods (15:76)
Note 2:
Flavor: r-devel-windows-x86_64
Check: examples, Result: NOTE
   Examples with CPU (user + system) or elapsed time > 10s
  user system elapsed
   ScientSDI 82.71   0.75   88.00
   Reference 29.75   0.05   29.80
   Accuracy  10.02   1.11   11.12
Flavor: r-devel-linux-x86_64-debian-gcc
Check: examples, Result: NOTE
   Examples with CPU (user + system) or elapsed time > 5s
   user system elapsed
   ScientSDI 52.674  0.176  57.765
   Reference 20.749  0.148  20.898
   Accuracy   6.001  0.024   6.024

Regarding note 1, not all the words are misspelled,
EP, SPI and SPEI are acronyms
OperatSDI and ScientSDI are functions of my package
PowerSDI is the name of my package's name
  NASAPOWER is the project's name.


Writing R Extensions section 1.1.1 describes some rules for quoting 
non-English words.  I think they imply OperatSDI, ScientSDI and PowerSDI 
should be in single quotes.  I am not sure whether that also applies to 
your other non-English words.


Duncan Murdoch



Regarding note 2, I don't know what's wrong. Is it related to the time 
to run the examples (>5s)? If is it so, it is not an error. There are 
so many calculations that it does take some time to do it.


The package is available at https://github.com/gabrielblain/PowerSDI
I really appreciate any help you can provide.
Best regards
Gabriel

[[alternative HTML version deleted]]

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


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


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

[R-pkg-devel] "Version contains leading zeroes" note: clarity

[Ben Bolker]

  Hi folks,

  I got the dreaded

Version contains leading zeroes

NOTE from a package check - the version was 0.0.1.000.

until I dug into the code and found the regex "(^|[.-])0[0-9]+" I didn't 
realize the restriction was on leading zeroes *within a version 
component* - I was interpreting it as leftmost in the whole version 
(i.e., the initial 0).


  I eventually found the documentation in ?package_version (feels like 
it should also be pointed to somewhere in Writing R Extensions?


Numeric versions are sequences of one or more non-negative
 integers, usually (e.g., in package ‘DESCRIPTION’ files)
 represented as character strings with the elements of the sequence
 concatenated and separated by single ‘.’ or ‘-’ characters.  R
 package versions consist of at least two such integers, an R
 system version of exactly three (major, minor and patchlevel).

Doesn't say anything about leading zero(e)s here ...

  "Zeroes" looks weird to me, but I see that "zeroes" is used on 26 
lines in .Rd files in the R code base, while "zeros" is used on 36 lines 
... so close to a tie. (Maybe someone wants to clean this up ... ? 
Maybe a mini-project for the R bug sprint at the end of the summer?


  Also, I'm sure this has been asked a few 100 times but: a new-to-CRAN 
maintainer triggers a NOTE.  Is there any way that a new user would know 
that this was informational only?  (There is also a 
Note_to_CRAN_maintainers 
<https://github.com/r-devel/r-svn/blob/0252cdbf14c73acd26ae2090df3c04aa6118b523/src/library/tools/R/check.R#L6009>: 
wouldn't that be more appropriate here?)


  cheers
   Ben Bolker

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

Re: [R-pkg-devel] LICENSE file in an R package for CRAN submission

[Ben Bolker]

   You have two choices:

* put LICENSE in your .Rbuildignore file so that it shows up on Github 
but is excluded from the package


* follow the instructions in 
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing to refer to 
LICENSE in your DESCRIPTION file. However, CRAN generally prefers that 
you use a standard license ("GPL-2", "GPL-3"), to make it easier for 
them to know that you've really complied with their openness 
requirements, and that you *not* include a license file that is 
redundant with that spec:


> Whereas you should feel free to include a license file in your source 
distribution, please do not arrange to install yet another copy of the 
GNU COPYING or COPYING.LIB files but refer to the copies on 
https://www.R-project.org/Licenses/ and included in the R distribution 
(in directory share/licenses). Since files named LICENSE or LICENCE will 
be installed, do not use these names for standard license files. To 
include comments about the licensing rather than the body of a license, 
use a file named something like LICENSE.note.


On 2023-08-09 11:06 a.m., Emanuele Cordano wrote:

Dear list,

is there a way to put the LICENSE file within an R package like in Github,
I have an R package on Github with a a LICENSE file compliant to Github and
containing the text of the licence citing in the DESCRIPION file. But when
I check the package , I obatained the following output:

* checking top-level files ... NOTE
File
   LICENSE

is not mentioned in the DESCRIPTION file.

How can I solve this?
Thank you
best
Emanuele Cordano


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] LICENSE file in an R package for CRAN submission

[Ben Bolker]

In case you're thinking of putting the package on CRAN, note also from 
the CRAN policy https://cran.r-project.org/web/packages/policies.html:


> Packages with licenses not listed at 
https://svn.r-project.org/R/trunk/share/licenses/license.db will 
generally not be accepted.


On 2023-08-09 11:15 a.m., Ben Bolker wrote:

    You have two choices:

* put LICENSE in your .Rbuildignore file so that it shows up on Github 
but is excluded from the package


* follow the instructions in 
https://cran.r-project.org/doc/manuals/R-exts.html#Licensing to refer to 
LICENSE in your DESCRIPTION file. However, CRAN generally prefers that 
you use a standard license ("GPL-2", "GPL-3"), to make it easier for 
them to know that you've really complied with their openness 
requirements, and that you *not* include a license file that is 
redundant with that spec:


 > Whereas you should feel free to include a license file in your source 
distribution, please do not arrange to install yet another copy of the 
GNU COPYING or COPYING.LIB files but refer to the copies on 
https://www.R-project.org/Licenses/ and included in the R distribution 
(in directory share/licenses). Since files named LICENSE or LICENCE will 
be installed, do not use these names for standard license files. To 
include comments about the licensing rather than the body of a license, 
use a file named something like LICENSE.note.


On 2023-08-09 11:06 a.m., Emanuele Cordano wrote:

Dear list,

is there a way to put the LICENSE file within an R package like in 
Github,
I have an R package on Github with a a LICENSE file compliant to 
Github and
containing the text of the licence citing in the DESCRIPION file. But 
when

I check the package , I obatained the following output:

* checking top-level files ... NOTE
File
   LICENSE

is not mentioned in the DESCRIPTION file.

How can I solve this?
Thank you
best
Emanuele Cordano




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

[R-pkg-devel] status of "possibly invalid URL/403 error" NOTEs?

[Ben Bolker]

  I have a package whose documentation includes the reference 
\doi{10.1137/18M1186411} which redirects here:

https://epubs.siam.org/doi/10.1137/18M1186411

Running R CMD check --as-cran on the package gives

Found the following (possibly) invalid URLs:
  URL: https://epubs.siam.org/doi/10.1137/18M1186411
From: man/llig.Rd
Status: 403
Message: Forbidden

  I can access this perfectly well in the browser.

  Is there any way to avoid this (other than, say, including the URL in 
a form that does *not* provide a link so that R CMD check won't try to 
access it? (As Uwe Ligges says 
[here](https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005195.html) 
(for a more obviously problematic case), "mention the URL in plain text 
but not link"


  Here Hadley Wickham says that these NOTEs can be ignored

https://twitter.com/hadleywickham/status/1358170607314235392

but "Hadley said it on twitter" is not an ideal source. The CRAN 
repository policy says that packages must pass checks without 
"significant" notes, but it's always hard to know what's significant and 
what's not ...


  There's a thread here: 
https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005171.html


   Tangentially: is there a more convenient way to search the 
r-package-devel archives than googling (e.g.) 
"site:https://stat.ethz.ch/pipermail/r-package-devel  403" ?


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

Re: [R-pkg-devel] Suppressing compiler warnings?

[Ben Bolker]

  This also doesn't answer your question, but:

A trick that the TMB package uses to help users is to suggest that they 
add "CXXFLAGS += -Wno-ignored-attributes" to their `.R/Makevars` file. 
This means that *they* don't have to see useless warnings when compiling 
code.


  In your case I don't know if there is a compiler flag that is 
equivalent to your pragma, or you could add your own macro/#ifdef 
(CXXFLAGS += -DSUPPRESS_WARNINGS) so that *you* don't have to see the 
warning messages. (If CRAN doesn't want to see all the warnings that's 
their problem ...)



On 2023-08-14 8:59 a.m., Mark Padgham wrote:


On 14/08/2023 14:43, Dirk Eddelbuettel wrote:

On 14 August 2023 at 11:51, Mark Padgham wrote:
| An update of a package of mine got immediately kicked off CRAN because
| an externally-bundled file which had not been changed for years, and
| which included "pragma clang system_header" to suppress warnings. The
| concern is fair enough. Removing that nevertheless now generates a heap
| of warnings which CRAN will have to wade through / grep to assess
| whether any are of concern. These can be easily suppressed by replacing
| cheap "system_header" with targeted suppression of just two classes of
| warnings for that bundled header file only. But I guess this is also
| forbidden? Should I now just leave those warnings, and rely on CRAN's
| grep policies to assess them? Is there any public list of what such 
grep

| policies might be? (And no, I can't adapt the code to remove the
| warnings, because most are "zero-as-null-pointer-constant", but the "0"
| is actually better than nullptr the way the code is constructed. The
| rest are - currently - unimportant deprecation warnings, all of one
| specific class.)

It is in the CRAN Repostory Policy:

    - Packages should not attempt to disable compiler diagnostics, nor to
  remove other diagnostic information such as symbols in shared 
objects.


Per 'svn blame' it goes back to commit 4049 from Apr 2019, but a 
commit from

Nov 2017 has 'memtion (sic!) not disabling compiler diagnostics'.

FWIW I have had to do it for BH and RcppEigen for some time leading to 
both
of them 'spamming' package users with a lot of noise. I don't 
particularly

like that, but I also do not have too many choices here.

Dirk


Thanks Dirk! I've seen also that a couple of tidyverse and r-lib pkgs
bundle the same header, and they also do nothing to suppress this
compiler spam. But gee it would be good to have some "official"
reference for what compiler warnings CRAN are likely to complain about,
and which ones they'll ignore!

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] What happened to mlr3proba on CRAN?

[Ben Bolker]

Based on 
https://cran-archive.r-project.org/web/checks/2022/2022-05-16_check_results_mlr3proba.html


  it looks like there were problems with the code (possibly harmless, 
but very unlikely to be exactly as intended) when R started throwing an 
error when vectors of length >1 were used with the && operator; this 
happened with R 4.3.0


https://cran-archive.r-project.org/web/checks/2022/2022-05-16_check_results_mlr3proba.html

\subsection{SIGNIFICANT USER-VISIBLE CHANGES}{
\itemize{
  \item Calling \code{&&} or \code{||} with LHS or (if evaluated) 
RHS of

  length greater than one is now always an error, with a report of
  the form
\preformatted{'length = 4' in coercion to 'logical(1)'}

  Since the errors weren't corrected, the package was archived.

  You can find the maintainer's email in the DESCRIPTION file here: 
https://cran.r-project.org/src/contrib/Archive/mlr3proba/mlr3proba_0.4.9.tar.gz 
  if you want to follow up with them ...


  cheers
   Ben Bolker


On 2023-10-08 5:28 p.m., Dr. Franz Király wrote:

Dear all,

can someone explain to me what exactly happened to mlr3proba on CRAN?
https://cran.r-project.org/web/packages/mlr3proba/index.html

Thanks
Franz


[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Check warning around sprintf: Compiled code should not call entry points which might terminate R nor write to stdout/stderr instead of to the console, nor use Fortran I/O nor system

[Ben Bolker]

  You may also be able to use Rprintf ? 
https://teuder.github.io/rcpp4everyone_en/060_printing_massages.html


On 2023-11-18 8:07 p.m., Iris Simmons wrote:

Yes, the reason for the error is the use of sprintf. You can instead use
snprintf where n is the maximum number of bytes to write, including the
terminating nul character. For example:

char msg[8191];
snprintf(msg, 8191, "criteria: error (%d) -> %s\n", inErr, errStr);
Rf_error(msg);

or however large you made the error string.


On Sat, Nov 18, 2023, 20:01 Iago Giné-Vázquez 
wrote:


Dear all,

I am updating a CRAN-archived R package, so it can get back to CRAN. But
there is a warning produced in Linux OS that I am not sure to understand
and I do not know how to solve, even after looking at ‘Writing portable
packages’ in the ‘Writing R Extensions’ manual and after searching in the
web. The warning is


* checking compiled code ... WARNING
File ‘ccckc/libs/ccckc.so’:
Found ‘sprintf’, possibly from ‘sprintf’ (C)
Object: ‘criteria.o’

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor use Fortran I/O
nor system RNGs nor [v]sprintf.
See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.


The package contains both C and Fortran code and in the criteria.c there
is only a sprintf use, as follows:

sprintf(msg,"criteria: error (%d) -> %s\n", inErr, errStr);
Rf_error(msg);
May be the reason of the warning the next line the ‘Writing R Extensions’
manual?


Use ofsprintfandvsprintfis regarded as a potential security risk and

warned about on some platforms.[82](
https://cran.r-project.org/doc/manuals/R-exts.html#FOOT82)R CMD
checkreports if any calls are found.

If that is the reason, is there any alternative to the use of sprintf?
Anyway, what can I do?

Thanks you in advance for your time.

Kind regards,
Iago

Sent with [Proton Mail](https://proton.me/) secure email.
 [[alternative HTML version deleted]]

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



[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Question regarding finding the source file location without R-packages outside of R-Studio

[Ben Bolker]

Not sure, but I think the 'here' package might do what you want. It's
tidyverse-affiliated but pretty stable

On Thu, Nov 23, 2023, 2:39 PM Tony Wilkes  wrote:

> Hi everyone,
>
> I have a question. I hope it's not a stupid question.
>
> Suppose you'd want to perform version control and project isolation. You'd
> create a project folder (let's call it "MyProject"), and place all the R
> packages you need for that project inside a subfolder (let's say
> "MyProject/MyLibrary"). Now you create and run an R-script in "MyProject".
> install.packages(), library(), etc. all have a lib.loc argument to specify
> the library path. So one can manually specify the path of your project, and
> then you'd have your project isolation and version control fully set-up.
>
> But if I want to set-up the library path automatically, to make it
> portable, I would need to determine the script location. In RStudio I can
> use the 'rstudioapi' package, which is very stable, and so does not really
> require version control. But for outside R-Studio, I have not found a very
> stable package that also works.
> I prefer not using external R packages that requires version control (i.e.
> a package that changes often-ish): you'd need the package to access the
> project library, but the project library to access the package.
>
> This brings me to my actual question: is it possible to determine the
> source file location of an R script outside of R-Studio, without resorting
> to R packages ? Or else use an R package that is VERY stable (i.e. doesn't
> change every (half) a year, like tidyverse packages tend to do)?
> commandArgs() used to contain the script path (apparently), but it doesn't
> work for me.
>
> By the way: I wish to get the script path in an interactive session.
>
> Thank you in advance.
>
> Kind regards,
>
> Tony
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] NOTE: Examples with CPU time > 2.5 times elapsed time

[Ben Bolker]

Wow.

On Mon, Dec 4, 2023, 5:43 PM Ivan Krylov  wrote:

> Dear Artur,
>
> You've got a well-written package. There are some parts I wasn't able
> to understand (e.g. changing the class of a variable by reference using
> SET_CLASS and later changing it back), but there are no obvious places
> where a mistake could be hiding.
>
> On Fri, 1 Dec 2023 23:43:32 +
> Artur Araujo  wrote:
>
> > Examples with CPU time > 2.5 times elapsed time
> > user system elapsed  ratio
> > contour.TPCmsm 2.605  0.132   0.108 25.343
>
> I managed to reproduce this, but not before compiling R-devel r85646
> on a Debian Testing virtual machine using clang-17 and flang-17 with
> libomp-17-dev installed. In particular, this doesn't seem to happen
> with latest R-devel built using (much older versions of) the GNU
> toolchain.
>
> There was a false start where I saw pthread_create breakpoints hit
> inside libpango while contour() was running, but that couldn't be your
> problem because examples run with the pdf() device active. Instead,
> when source()ing the TPmsm-Ex.R file, the breakpoint fired elsewhere:
>
> ### Name: as.data.frame.survTP
> ### Title: as.data.frame method for a survTP object
> ### Aliases: as.data.frame.survTP
> ### Keywords: manip metho  [TRUNCATED]
>
> Breakpoint 7, __pthread_create_2_1 (newthread=0x7fff5a70,
> attr=0x7fff5a78, start_routine=0x775882a0 <__kmp_launch_worker()>,
> arg=0x572d9e80)
> at ./nptl/pthread_create.c:623
> (gdb) bt
> #0  __pthread_create_2_1 (newthread=0x7fff5a70, attr=0x7fff5a78,
> start_routine=0x775882a0 <__kmp_launch_worker()>, arg=0x572d9e80)
> at ./nptl/pthread_create.c:623
> #1  0x775879b4 in __kmp_create_worker () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/z_Linux_util.cpp:795
> #2  0x77518899 in __kmp_allocate_thread () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_runtime.cpp:4677
> #3  0x7751078a in __kmp_allocate_team () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_runtime.cpp:5384
> #4  0x77511813 in __kmp_fork_call () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_runtime.cpp:2122
> #5  0x774ffc81 in __kmpc_fork_call () at
> build-llvm/tools/clang/stage2-bins/openmp/runtime/src/kmp_csupport.cpp:300
> #6  0x7465100e in cens2 (pT1=, pE1=,
> pS=, pE=, pn=,
> tfunc=,
> pcorr=, pdistpar=, cfunc= out>, pcenspar=, pstate2prob=) at dgpTP.c:83
> #7  dgpTP (n=, corr=, dist=,
> distpar=, modelcens=, censpar= out>,
> state2prob=) at dgpTP.c:178
> #8  0x55645cba in R_doDotCall (fun=0x0, nargs=nargs@entry=7,
> cargs=cargs@entry=0x7fff63b0, call=call@entry=0x573b62b8)
> at ../../../R-svn/src/main/dotcode.c:1498
> (gdb) frame 6
> #6  0x7465100e in cens2 (pT1=, pE1=,
> pS=, pE=, pn=,
> tfunc=,
> pcorr=, pdistpar=, cfunc= out>, pcenspar=, pstate2prob=) at dgpTP.c:83
> 83  #pragma omp parallel num_threads(global_num_threads)
> (gdb) p global_num_threads
> $4 = 8
>
> Not sure why the CPU time gets counted for the contour() example
> instead of as.data.frame.survTP - do libomp threads not get counted
> until they terminate or something? - but since the contour.TPCmsm
> example directly follows as.data.frame.survTP, the call to dgpTP here
> must be the culprit.
>
> I would like to suggest a new diagnostic for the CPU time / elapsed
> time tests. If any examples have been found to exceed the time ratio
> limit and R is running on Linux with a special environment variable
> set, the examples should be re-run under a debugger. The debugger
> should set a breakpoint on the clone _system call_ (ideally, all system
> calls that can create threads or child processes) and print a C-level
> backtrace when it fires. Ideally, it should call something like
> R_ConciseTraceback to obtain an R-level traceback too, but it's not an
> API (at least yet) and I'm not sure it's generally safe to do this in
> the middle of an R call. If there is interest, I can try to see if gdb
> can be scripted to make this happen. I think it must be a ptrace
> debugger and not an LD_PRELOAD wrapper because there are too many ways
> to start threads and processes. For example, with libomp,
> pthread_create() breakpoints fire while clone() breakpoints do not,
> despite something later does make the clone() system call.
>
> This won't help if the threads get started separately and only later
> get utilised in a different example, but I wasn't able to put the
> output of `perf report` for good use when debugging similar problems in
> a different package. Other ideas for tracing the CPU usage culprits are
> also welcome.
>
> --
> Best regards,
> Ivan
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-

Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Ben Bolker]

 FWIW the R-windows FAQ says:

Yet another complication is a 260 character limit on the length of the 
entire path name imposed by Windows. The limit applies only to some 
system functions, and hence it is possible to create a long path using 
one application yet inaccessible to another. It is sometimes possible to 
reduce the path length by creating a drive mapping using subst and 
accessing files via that drive. As of Windows 10 version 1607 and R 4.3, 
one can remove this limit via Windows registry by setting 
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled 
to 1. Long paths still may not always work reliably: some applications 
or packages may not be able to work with them and Windows cannot execute 
an application with long path as the current directory.


  I'm having trouble finding the specific check for path lengths > 100 
in the R source tree.  It would be helpful to have the exact wording of 
the NOTE/WARNING (?) that is thrown ...  (I know I could make my own 
mini-package with a long path length in it somewhere but ...)


  cheers
   Ben Bolker

On 2023-12-12 2:57 p.m., Simon Urbanek wrote:

Justin,

now that you clarified what you are actually talking about, this is a question 
about the CRAN policies, so you should really direct it to the CRAN team as it 
is their decision (R-devel would be appropriate if this was a limitation in R 
itself, and R-package-devel would be appropriate if you wanted help with 
refactoring to adhere to the policy). There are still path limits on various 
platforms (even if they are becoming more rare), so I'd personally question the 
source rather than the policy, but then your email was remarkably devoid of any 
details.

Cheers,
Simon



On Dec 13, 2023, at 6:03 AM, McGrath, Justin M  wrote:

When submitting a package to CRAN, it is required that path names be shorter 
than 100 bytes, with the reason that paths longer than that cannot be made into 
portable tar files. This error is reported by `R CMD check --as-cran`. Since 
this pertains only to developing packages, this seemed like the appropriate 
list, but if you don't think so, I can instead ask on R-devel.

Best wishes,
Justin


From: Martin Maechler 
Sent: Tuesday, December 12, 2023 10:13 AM
To: McGrath, Justin M
Cc: r-package-devel@r-project.org
Subject: Wrong mailing list: [R-pkg-devel] Could the 100 byte path length limit 
be lifted?


McGrath, Justin M
on Tue, 12 Dec 2023 15:03:28 + writes:



We include other software in our source code. It has some long paths so a few 
of the files end up with paths longer than 100 bytes, and we need to manually 
rename them whenever we pull in updates.
The 100 byte path limit is from tar v7, and since
POSIX1.1988, there has not been a path length limit. That
standard is 35 years old now, so given that there is
probably no one using an old version of tar that also
wants to use the latest version of R, could the 100 byte
limit be lifted? Incidentally, I am a big proponent of
wide, long-term support, but it's hard to see that this
change would negatively impact anyone.



Best wishes,
Justin


Wrong mailing list:

This is a topic for R-devel,  not at all R-package-devel,
but be more accurate in what you are talking about, only between
the line I could read that it is about some variants of using
'tar'.

Best regards,
Martin
---

Martin Maechler
ETH Zurich  and  R Core team

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



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


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

Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Ben Bolker]

  Thanks. Pursuing this a bit further, from ?tar "Known problems":

 The handling of file paths of more than 100 bytes.  These
were unsupported in early versions of ‘tar’, and supported in
one way by POSIX ‘tar’ and in another by GNU ‘tar’ and yet
another by the POSIX ‘pax’ command which recent ‘tar’
programs often support.  The internal implementation warns on
paths of more than 100 bytes, uses the ‘ustar’ way from the
1998 POSIX standard which supports up to 256 bytes (depending
on the path: in particular the final component is limited to
100 bytes) if possible, otherwise the GNU way (which is
widely supported, including by ‘untar’).

  This issue is reminiscent of the "invalid uid value replaced ..." 
warning, which has happened to me a lot but which CRAN has never 
actually flagged when I've submitted a package:


https://stackoverflow.com/questions/30599326/warning-message-during-building-an-r-package-invalid-uid-value-replaced-by-that

 (By the way, this thread now seems firmly on-topic for r-pkg-devel, 
even if the ultimate answers must come from the CRAN maintainers ...)


  cheers
   Ben



On 2023-12-12 3:41 p.m., Duncan Murdoch wrote:
I don't know what the warning looks like, but the ?tar help page 
discusses the issues.


Duncan Murdoch

On 12/12/2023 3:10 p.m., Ben Bolker wrote:

   FWIW the R-windows FAQ says:

Yet another complication is a 260 character limit on the length of the
entire path name imposed by Windows. The limit applies only to some
system functions, and hence it is possible to create a long path using
one application yet inaccessible to another. It is sometimes possible to
reduce the path length by creating a drive mapping using subst and
accessing files via that drive. As of Windows 10 version 1607 and R 4.3,
one can remove this limit via Windows registry by setting
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
to 1. Long paths still may not always work reliably: some applications
or packages may not be able to work with them and Windows cannot execute
an application with long path as the current directory.

    I'm having trouble finding the specific check for path lengths > 100
in the R source tree.  It would be helpful to have the exact wording of
the NOTE/WARNING (?) that is thrown ...  (I know I could make my own
mini-package with a long path length in it somewhere but ...)

    cheers
 Ben Bolker

On 2023-12-12 2:57 p.m., Simon Urbanek wrote:

Justin,

now that you clarified what you are actually talking about, this is a 
question about the CRAN policies, so you should really direct it to 
the CRAN team as it is their decision (R-devel would be appropriate 
if this was a limitation in R itself, and R-package-devel would be 
appropriate if you wanted help with refactoring to adhere to the 
policy). There are still path limits on various platforms (even if 
they are becoming more rare), so I'd personally question the source 
rather than the policy, but then your email was remarkably devoid of 
any details.


Cheers,
Simon


On Dec 13, 2023, at 6:03 AM, McGrath, Justin M 
 wrote:


When submitting a package to CRAN, it is required that path names be 
shorter than 100 bytes, with the reason that paths longer than that 
cannot be made into portable tar files. This error is reported by `R 
CMD check --as-cran`. Since this pertains only to developing 
packages, this seemed like the appropriate list, but if you don't 
think so, I can instead ask on R-devel.


Best wishes,
Justin


From: Martin Maechler 
Sent: Tuesday, December 12, 2023 10:13 AM
To: McGrath, Justin M
Cc: r-package-devel@r-project.org
Subject: Wrong mailing list: [R-pkg-devel] Could the 100 byte path 
length limit be lifted?



McGrath, Justin M
 on Tue, 12 Dec 2023 15:03:28 + writes:


We include other software in our source code. It has some long 
paths so a few of the files end up with paths longer than 100 
bytes, and we need to manually rename them whenever we pull in 
updates.

The 100 byte path limit is from tar v7, and since
POSIX1.1988, there has not been a path length limit. That
standard is 35 years old now, so given that there is
probably no one using an old version of tar that also
wants to use the latest version of R, could the 100 byte
limit be lifted? Incidentally, I am a big proponent of
wide, long-term support, but it's hard to see that this
change would negatively impact anyone.



Best wishes,
Justin


Wrong mailing list:

This is a topic for R-devel,  not at all R-package-devel,
but be more accurate in what you are talking about, only between
the line I could read that it is about some variants of using
'tar'.

Best regards,
Martin
---

Martin Maechler
ETH Zurich  and  R Core team

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



_

Re: [R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols

[Ben Bolker]

  Are you sure the issue that CRAN has is the library sizes, and not 
the issues flagged by the "LTO" platform 
 ?


https://www.stats.ox.ac.uk/pub/bdr/LTO/rar.out

  I would check with CRAN for clarification before you spend a lot of 
time trying to reduce package sizes. As you point out, lots of packages 
on CRAN have package sizes large enough to trigger this note -- it is my 
impression that CRAN only object if the large package size is considered 
unnecessary; some of the *inappropriate* reasons for large package size 
are listed in the repository policy 



===
Packages should be of the minimum necessary size. Reasonable compression 
should be used for data (not just .rda files) and PDF documentation: 
CRAN will if necessary pass the latter through qpdf.


As a general rule, neither data nor documentation should exceed 5MB 
(which covers several books). A CRAN package is not an appropriate way 
to distribute course notes, and authors will be asked to trim their 
documentation to a maximum of 5MB.


Where a large amount of data is required (even after compression), 
consideration should be given to a separate data-only package which can 
be updated only rarely (since older versions of packages are archived in 
perpetuity).


Similar considerations apply to other forms of “data”, e.g., .jar files.

Source package tarballs should if possible not exceed 10MB. It is much 
preferred that third-party source software should be included within the 
package (as e.g. a vendor.tar.xz file) than be downloaded at 
installation: if this requires a larger tarball a modestly increased 
limit can be requested at submission.



On 2024-01-20 2:38 p.m., Johann Gaebler wrote:

Hi everyone,

I received the following message regarding  `rar` 
, a package that I put up on CRAN two 
days ago:


Dear maintainer,

Please see the problems shown on
.

Please correct before 2024-02-02 to safely retain your package on CRAN.


The issue is that the compiled libraries are too large. The Mac CRAN checks 
turned up the following note:


installed size is  8.9Mb
sub-directories of 1Mb or more:
  libs   8.7Mb


I have not been able to reproduce the issue either locally or on any machine I 
have ready access to. I have built it on some of the Rhub and R-Project build 
systems, and the same issue (with very different `libs` sizes) came up on some 
of them:

• (RHub) Ubuntu Linux 20.04.1 LTS, R-release, GCC: 18.2Mb,
• (RHub) Fedora Linux, R-devel, clang, gfortran: 6.8Mb,
• (R-Project) r-release-macosx-arm64: 8.5Mb.

Based on trying to read up about this, it seems that this is a pretty common problem 
 
for compiled packages because of debugging symbols getting inserted into the shared 
library file. Using the fix from that blog post where you modify the Makevars to 
strip debugging symbols from the shared library seems to solve the issue on those 
build systems, so I feel reasonably confident that this is what’s going on.

Apparently many, many existing packages on CRAN have the same issue. However, 
I’m very new to R package development, so I’m not exactly sure what to do. I 
have two questions:

1. Is there anything I need to “fix” here, or should I just make contact with 
the CRAN folks and bring the fact that this is being caused by debugging 
symbols to their attention?
2. Regardless of whether or not I have to fix this issue for CRAN, is there a 
way to strip out the debugging symbols that comports with CRAN policies? The 
method suggested in the blog post above (adding a phony target in `Makevars` 
that strips the shared library) seems not to be CRAN-compliant, but I could be 
mistaken about that. (In particular, I had to modify it locally to get it to 
run, so I’m not sure what the platform-independent version of it looks like.)

Thanks in advance for the help!

Sincerely,
Johann D. Gaebler
[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Ben Bolker]

https://github.com/r-lib/revdepcheck does the 'step 3 twice' part.


  I have had a few issues with it 
 but overall it's been 
very helpful.


https://github.com/HenrikBengtsson/revdepcheck.extras may also be useful.

On 2024-01-30 10:56 a.m., Ivan Krylov via R-package-devel wrote:

Hello R-package-devel,

What would you recommend in order to run reverse dependency checks for
a package with 182 direct strong dependencies from CRAN and 66 from
Bioconductor (plus 3 more from annotations and experiments)?

Without extra environment variables, R CMD check requires the Suggested
packages to be available, which means installing...

revdepdep <- package_dependencies(revdep, which = 'most')
revdeprest <- package_dependencies(
  unique(unlist(revdepdep)),
  which = 'strong', recursive = TRUE
)
length(setdiff(
  unlist(c(revdepdep, revdeprest)),
  unlist(standard_package_names())
))

...up to 1316 packages. 7 of these suggested packages aren't on CRAN or
Bioconductor (because they've been archived or have always lived on
GitHub), but even if I filter those out, it's not easy. Some of the
Bioconductor dependencies are large; I now have multiple gigabytes of
genome fragments and mass spectra, but also a 500-megabyte arrow.so in
my library. As long as a data package declares a dependency on your
package, it still has to be installed and checked, right?

Manually installing the SystemRequirements is no fun at all, so I've
tried the rocker/r2u container. It got me most of the way there, but
there were a few remaining packages with newer versions on CRAN. For
these, I had to install the system packages manually in order to build
them from source.

Someone told me to try the rocker/r-base container together with pak.
It was more proactive at telling me about dependency conflicts and
would have got me most of the way there too, except it somehow got me a
'stringi' binary without the corresponding libicu*.so*, which stopped
the installation process. Again, nothing that a bit of manual work
wouldn't fix, but I don't feel comfortable setting this up on a CI
system. (Not on every commit, of course - that would be extremely
wasteful - but it would be nice if it was possible to run these checks
before release on a different computer and spot more problems this way.)

I can't help but notice that neither install.packages() nor pak() is
the recommended way to install Bioconductor packages. Could that
introduce additional problems with checking the reverse dependencies?

Then there's the check_packages_in_dir() function itself. Its behaviour
about the reverse dependencies is not very helpful: they are removed
altogether or at least moved away. Something may be wrong with my CRAN
mirror, because some of the downloaded reverse dependencies come out
with a size of zero and subsequently fail the check very quickly.

I am thinking of keeping a separate persistent library with all the
1316 dependencies required to check the reverse dependencies and a
persistent directory with the reverse dependencies themselves. Instead
of using the reverse=... argument, I'm thinking of using the following
scheme:

1. Use package_dependencies() to determine the list of packages to test.
2. Use download.packages() to download the latest version of everything
if it doesn't already exist. Retry if got zero-sized or otherwise
damaged tarballs. Remove old versions of packages if a newer version
exists.
3. Run check_packages_in_dir() on the whole directory with the
downloaded reverse dependencies.

For this to work, I need a way to run step (3) twice, ensuring that one
of the runs is performed with the CRAN version of the package in the
library and the other one is performed with the to-be-released version
of the package in the library. Has anyone already come up with an
automated way to do that?

No wonder nobody wants to maintain the XML package.



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

[R-pkg-devel] confusion over spellchecking

[Ben Bolker]

  I am working on a package and can't seem to get rid of a NOTE about

Possibly misspelled words in DESCRIPTION:
  glmmTMB (10:88)
  lme (10:82)

on win-builder.

I have set export _R_CHECK_CRAN_INCOMING_USE_ASPELL_=TRUE locally, and 
have tried to set up the .aspell defaults as specified by Dirk 
Eddelbuettel in  his 2017 blog post 



  I get no spelling NOTEs locally or on GH actions.

 The aspell machinery is here:

https://github.com/bbolker/reformulas/tree/main/.aspell

Following Dirk's blog post, here's what's in those files:

$ cat defaults.R
Rd_files <- vignettes <- R_files <- description <-
list(encoding = "UTF-8",
 language = "en",
 dictionaries = c("en_stats", "reformulas"))

$ r -p -e 'readRDS("reformulas.rds")'
[1] "glmmTMB" "lme"


  In the end I think I'm going to suck it up and put those words in 
quotation marks in the definition, but it feels like I *should* be able 
to have them ignored?


  I have three questions:

 (1) am I missing something in how this should be set up?
 (2) is any of this machinery documented anywhere official? (I couldn't 
find the string "spell" anywhere in _Writing R Extensions_ or the CRAN 
repository policy

 (3) If the answer to #2 is 'no', could/should it be?

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

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

[Ben Bolker]

  Hi folks,

  We're in the final stages of preparing a revised version of the 
glmmTMB package for CRAN and are stuck troubleshooting checks on 
win-builder/r-devel.


  Testing is working everywhere *except* win-builder/r-devel. 
Win-builder is OK with r-oldrel and r-devel; the same package is OK on 
GitHub actions with macOS/release, ubuntu/{release, devel} and 
windows/{oldrel, release, devel}: 
https://github.com/glmmTMB/glmmTMB/actions/runs/8316540364


  win-builder/r-devel output is cryptic. It reports:

1. an ERROR in running examples:

Running examples in 'glmmTMB-Ex.R' failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: VarCorr.glmmTMB
> ### Title: Extract variance and correlation components
> ### Aliases: VarCorr.glmmTMB VarCorr
> ### Keywords: internal
>
> ### ** Examples
>
> ## Comparing variance-covariance matrix with manual computation
> data("sleepstudy",package="lme4")
> fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)

(this is the end of this output section.)

2. an ERROR running tests, where the output ends with a cryptic

  Anova: ..

(please try to refrain from snarky comments about not using testthat ...)

3. an ERROR building the vignettes:

--- re-building 'priors.rmd' using rmarkdown
(this is a new vignette, but it builds without a problem everywhere 
else, takes 10 seconds to build locally ...)


Full log is here, at least for a little while: 
https://win-builder.r-project.org/9I5WG5R8WJg3/00check.log


  We could admit defeat and throw ourselves on the CRAN-maintainers' 
mercy, but we would like to resolve these if we can.


  cheers
   Ben Bolker

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

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

[Ben Bolker]

  I think I may actually have figured this out.

  The Matrix package is being updated to version 1.7.0 soon, with 
expected ABI breakage.  This version is **already installed on 
win-builder/r-devel**, so the Matrix/TMB/glmmTMB binary stack fails 
(digging into the logs a bit deeper showed that the *first* instance of 
a call to glmmTMB in any example/test/prior was failing ...)


  I think the only way to solve this is to bump/re-install the version 
of TMB that lives on win-builder.


  For the record, this will probably bite any package that depends on 
Matrix ABI ...


On 2024-03-17 4:42 p.m., Ivan Krylov wrote:

Hi,

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

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


2. an ERROR running tests, where the output ends with a cryptic

Anova: ..

(please try to refrain from snarky comments about not using testthat
...)


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


  I don't know, could be worth a try.







  cheers
   Ben Bolker

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

Re: [R-pkg-devel] Package vulnerabilities

[Ben Bolker]

  FWIW there is a repo for R advisories.

https://github.com/RConsortium/r-advisory-database

 with a front-end here

https://osv.dev/list?ecosystem=CRAN&q=

  At present all of the *reported* vulnerabilities seem to be caused by 
problems with underlying/bundled libraries ...


On 2024-04-03 4:37 p.m., Greg Hunt wrote:

Uwe,
Whether it takes a lot of effort to get malicious code into a company
depends on the pay-off, which can be large relative to the effort.  The
example of the hack before was largely interesting because the priorities
of the package users were fundamentally insecure (higher version number
wins, defaulting to public repositories) and the specific package names
meant that the hack was narrowly targeted, making it less likely to be
discovered than exfiltration code inserted into a widely used package.
Having an identifiable set of package dependencies at any point in time is
a beginning.  Its difficult to effectively control developer behaviour, so
there is a risk there, but what makes it into production can in principle
be identified and controlled.

I had a look at the CVE database, its difficult to identify R package
vulnerabilities there.  Some other searching turned up a couple of
vulnerabilities and some rather promotional blog posts, one of which
asserted that R code is almost always run in controlled environments, which
was sadly hilarious.

Is there a source of vulnerability information for R packages?  Are there
or have there been examples of actually malicious R packages in the wild?


Greg

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Avoid Possibly misspelled words in DESCRIPTION

[Ben Bolker]

  Based on the information in this thread,

https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010558.html

  I don't think there is any way to suppress these notes. (I have been 
meaning to submit a documentation for _Writing R Extensions_ that talks 
about spell-checking options, which AFAICT isn't actually mentioned 
anywhere in the docs ...)


  What do you mean by "already inserted these words in the WORDLIST"?

  cheers
   Ben Bolker


On 2024-04-12 9:18 a.m., Gabriel Constantino Blain wrote:

Hello,
When I apply the devtools::check_win_devel() to my package it shows the 
following message:

Possibly misspelled words in DESCRIPTION:
   Samani (40:21)
   al (38:45)
   et (38:42)
-
I already inserted these words in the WORDLIST.
Should I use 'Samani' and 'et al.' to prevent this message in the text below?

Description: Calculates daily climate water balance for irrigation purposes.  
The package also calculates the reference 'evapotranspiration' using three 
methods, ('Penman and Monteith') Allen et al. (1998,ISBN:92-5-104219-5),
  Priestley and Taylor (1972) ,
   or Hargreaves and Samani (1985) .
   Users may specify a management allowed depletion ('MAD'), which is
   used by the package to suggest when irrigate. It also allows the use of crop 
and water stress coefficients.

Thanks in advance.

[[alternative HTML version deleted]]

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


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

[R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

  The 'dotwhisker' package was archived on CRAN: from 
https://cran.r-project.org/web/packages/dotwhisker/index.html


Package ‘dotwhisker’ was removed from the CRAN repository
...

Archived on 2024-04-12 as requires archived package 'prediction'.

   However, I can't for the life of me see where this dependence could 
come from. Neither the DESCRIPTION file of the last-archived version on 
CRAN 
, 
nor the version on github , seem to 
show any signs of importing prediction ... ?? I suppose there's a 
possibility of a recursive dependence, but in that case why wouldn't the 
direct dependence be reported?


Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1),
Imports: grid, gtable, gridExtra, stats, parameters, performance,
patchwork, margins, dplyr, stringr, ggstance, rlang, purrr
Suggests: ordinal, tibble, knitr, rmarkdown, broom

  What am I missing?

  (I'm concerned because I have packages that Suggest: dotwhisker, and 
the absence of the package from repos is breaking GitHub Actions checks ...)



  (This is cross-posted from an issue on the dotwhisker GH repository: 
https://github.com/fsolt/dotwhisker/issues/115)


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

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

  Thank you! (I know about package_dependencies() but ran into 
precisely the same problem and didn't want to re-implement it ...)


On 2024-04-18 9:11 a.m., Josiah Parry wrote:
Well, after trying to install the package, I believe the issue is 
because margins has been archived.


https://cran.r-project.org/web/packages/margins/index.html 
<https://cran.r-project.org/web/packages/margins/index.html>


You can check recursive dependencies using 
`tools::package_dependencies("pkg", recursive = TRUE)` which would help 
you in this case. I couldn't run it since the package is not available 
on CRAN, however.



On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker <mailto:bbol...@gmail.com>> wrote:


    The 'dotwhisker' package was archived on CRAN: from
https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>

      Package ‘dotwhisker’ was removed from the CRAN repository
      ...

      Archived on 2024-04-12 as requires archived package 'prediction'.

     However, I can't for the life of me see where this dependence
could
come from. Neither the DESCRIPTION file of the last-archived version on
CRAN
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz 
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>,
nor the version on github <https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>>, seem to
show any signs of importing prediction ... ?? I suppose there's a
possibility of a recursive dependence, but in that case why wouldn't
the
direct dependence be reported?

Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1),
Imports: grid, gtable, gridExtra, stats, parameters, performance,
          patchwork, margins, dplyr, stringr, ggstance, rlang, purrr
Suggests: ordinal, tibble, knitr, rmarkdown, broom

    What am I missing?

    (I'm concerned because I have packages that Suggest: dotwhisker,
and
the absence of the package from repos is breaking GitHub Actions
checks ...)


    (This is cross-posted from an issue on the dotwhisker GH
repository:
https://github.com/fsolt/dotwhisker/issues/115
<https://github.com/fsolt/dotwhisker/issues/115>)

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

   Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN 
has apparently just caught up to checking.  What's a little frustrating 
(to me) is that the dependence of prediction on ffbase is *very* soft 
("enhances") ...


On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase was 
no longer available. https://cran.r-project.org/web/packages/ffbase/ 
<https://cran.r-project.org/web/packages/ffbase/>


ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE 
AND FOREST

Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en 
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar 
dossiers volledig digitaal behandelen. Poststukken met de vermelding 
‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan de 
geadresseerde bezorgd./

www.inbo.be <http://www.inbo.be>

///
To call in the statistician after the experiment is done may be no more 
than asking him to perform a post-mortem examination: he may be able to 
say what the experiment died of. ~ Sir Ronald Aylmer Fisher

The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not 
ensure that a reasonable answer can be extracted from a given body of 
data. ~ John Tukey

///

<https://www.inbo.be>


Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:


    Thank you! (I know about package_dependencies() but ran into
precisely the same problem and didn't want to re-implement it ...)

On 2024-04-18 9:11 a.m., Josiah Parry wrote:
 > Well, after trying to install the package, I believe the issue is
 > because margins has been archived.
 >
 > https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>
 > <https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>>
 >
 > You can check recursive dependencies using
 > `tools::package_dependencies("pkg", recursive = TRUE)` which
would help
 > you in this case. I couldn't run it since the package is not
available
 > on CRAN, however.
 >
 >
 > On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
 > <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
 >
 >         The 'dotwhisker' package was archived on CRAN: from
 > https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>
 >   
  <https://cran.r-project.org/web/packages/dotwhisker/index.html

<https://cran.r-project.org/web/packages/dotwhisker/index.html>>
 >
 >           Package ‘dotwhisker’ was removed from the CRAN repository
 >           ...
 >
 >           Archived on 2024-04-12 as requires archived package
'prediction'.
 >
 >          However, I can't for the life of me see where this
dependence
 >     could
 >     come from. Neither the DESCRIPTION file of the last-archived
version on
 >     CRAN
 >   
  <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,

 >     nor the version on github
<https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>
 >     <https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>>>, seem to
 >     show any signs of importing prediction ... ?? I suppose there's a
 >     possibility of a recursive dependence, but in that case why
wouldn't
 >     the
 >     direct dependence be reported?
 >
 >     Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1),
 >     Imports: grid, gtable, gridExtra, stats, parameters, performance,
 >               patchwork, margins, dplyr, st

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

 To clarify, from an off-list conversation:

  AFAICT the chain is

  dotwhisker Imports
 margins, which Imports
   prediction, which Enhances
 ffbase  (archived in 2022 for 'coercion to logical' problems)

 (that conversation also pointed out that Enhances is a dependency *in 
the opposite direction* -- i.e. if A Enhances B, it's not entirely clear 
why the disappearance of B should matter at all ...)




On 2024-04-18 9:35 a.m., Ben Bolker wrote:
    Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN 
has apparently just caught up to checking.  What's a little frustrating 
(to me) is that the dependence of prediction on ffbase is *very* soft 
("enhances") ...


On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase was 
no longer available. https://cran.r-project.org/web/packages/ffbase/ 
<https://cran.r-project.org/web/packages/ffbase/>


ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE 
AND FOREST

Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en 
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar 
dossiers volledig digitaal behandelen. Poststukken met de vermelding 
‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan de 
geadresseerde bezorgd./

www.inbo.be <http://www.inbo.be>

///
To call in the statistician after the experiment is done may be no 
more than asking him to perform a post-mortem examination: he may be 
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher

The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does 
not ensure that a reasonable answer can be extracted from a given body 
of data. ~ John Tukey

///

<https://www.inbo.be>


Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:


    Thank you! (I know about package_dependencies() but ran into
    precisely the same problem and didn't want to re-implement it ...)

    On 2024-04-18 9:11 a.m., Josiah Parry wrote:
 > Well, after trying to install the package, I believe the issue is
 > because margins has been archived.
 >
 > https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>
 > <https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>>
 >
 > You can check recursive dependencies using
 > `tools::package_dependencies("pkg", recursive = TRUE)` which
    would help
 > you in this case. I couldn't run it since the package is not
    available
 > on CRAN, however.
 >
 >
 > On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
 > <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
 >
 >         The 'dotwhisker' package was archived on CRAN: from
 > https://cran.r-project.org/web/packages/dotwhisker/index.html
    <https://cran.r-project.org/web/packages/dotwhisker/index.html>
 >  
 <https://cran.r-project.org/web/packages/dotwhisker/index.html

    <https://cran.r-project.org/web/packages/dotwhisker/index.html>>
 >
 >           Package ‘dotwhisker’ was removed from the CRAN 
repository

 >           ...
 >
 >           Archived on 2024-04-12 as requires archived package
    'prediction'.
 >
 >          However, I can't for the life of me see where this
    dependence
 >     could
 >     come from. Neither the DESCRIPTION file of the last-archived
    version on
 >     CRAN
 >  
 <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,

 >     nor the version on github
    <https://github.com/fsolt/dotwhisker
    <https://github.com/fsolt/dotwhisker>
 >     <https://github.com/fsolt/dotwhisker
    <https://github.com/fsolt

Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN

[Ben Bolker]

On 2024-04-18 9:41 a.m., Uwe Ligges wrote:



On 18.04.2024 15:35, Ben Bolker wrote:
    Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN 
has apparently just caught up to checking.  What's a little 
frustrating (to me) is that the dependence of prediction on ffbase is 
*very* soft ("enhances") ...


No, but CRAN  has still not received an update and asked for this each 
month this year, so in Jan, Feb, and March without a response, so we 
assume prediction is unmaintained. Also, this was escalated to reverse 
depends.


Best,
Uwe Ligges


  Fair enough.  I'm not sure what the last sentence ("this was 
escalated to reverse depends") means though ...


  FWIW I did get an e-mail response from the maintainer two days ago 
suggesting that they were preparing a resubmission ...







On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase 
was no longer available. 
https://cran.r-project.org/web/packages/ffbase/ 
<https://cran.r-project.org/web/packages/ffbase/>


ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR 
NATURE AND FOREST

Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en 
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid 
haar dossiers volledig digitaal behandelen. Poststukken met de 
vermelding ‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan 
de geadresseerde bezorgd./

www.inbo.be <http://www.inbo.be>

///
To call in the statistician after the experiment is done may be no 
more than asking him to perform a post-mortem examination: he may be 
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher

The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does 
not ensure that a reasonable answer can be extracted from a given 
body of data. ~ John Tukey

///

<https://www.inbo.be>


Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:


    Thank you! (I know about package_dependencies() but ran into
    precisely the same problem and didn't want to re-implement it ...)

    On 2024-04-18 9:11 a.m., Josiah Parry wrote:
 > Well, after trying to install the package, I believe the issue is
 > because margins has been archived.
 >
 > https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>
 > <https://cran.r-project.org/web/packages/margins/index.html
    <https://cran.r-project.org/web/packages/margins/index.html>>
 >
 > You can check recursive dependencies using
 > `tools::package_dependencies("pkg", recursive = TRUE)` which
    would help
 > you in this case. I couldn't run it since the package is not
    available
 > on CRAN, however.
 >
 >
 > On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
 > <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
 >
 >         The 'dotwhisker' package was archived on CRAN: from
 > https://cran.r-project.org/web/packages/dotwhisker/index.html
    <https://cran.r-project.org/web/packages/dotwhisker/index.html>
 >  <https://cran.r-project.org/web/packages/dotwhisker/index.html
    <https://cran.r-project.org/web/packages/dotwhisker/index.html>>
 >
 >           Package ‘dotwhisker’ was removed from the CRAN 
repository

 >           ...
 >
 >           Archived on 2024-04-12 as requires archived package
    'prediction'.
 >
 >          However, I can't for the life of me see where this
    dependence
 >     could
 >     come from. Neither the DESCRIPTION file of the last-archived
    version on
 >     CRAN
 > 
 <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,

 >     nor the version on github
    <https://github.com/fsolt/dotwhisker
    <https://github.com/fsolt/

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

[Ben Bolker]

 This is true, and useful.

  Many old-school R users are nervous about coming to rely on tools 
that are controlled by a company that may rescind that availability in 
the future, or may possibly use your code in ways you don't want (I have 
not gone all the way through 
https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement 
...)


   For example, Travis was great for CI for a while then pulled the 
plug on free use for public repos, then everyone jumped to GitHub 
actions ...; Microsoft Open R and MRAN were around for a while and then 
weren't ...


  That doesn't mean one should necessarily avoid these tools; it just 
explains why some people do.


On 2024-05-04 1:43 p.m., Maciej Nasinski wrote:

Hey Vladimir,

Thank you for your answer.
GitHub codespaces are "a separate computer" and are free for students and
the educational sector.
The GitHub codespaces are a cloud service that can be created anytime, with
a specific setup behind it (Dockerfile, settings.json, renv.lock,  ...).
The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB
Memory).
You can destroy and recreate it anytime you want to.
You run GitHub codespaces from a web browser, but as Ivan stated, you may
need a decent computer to handle them, even if all calculations are done on
the cloud.
I use GitHub codespaces for all my University projects with my friends.  It
is great that I do not have to explain many things nowadays to older stuff
as many things are automatic on GitHub codespaces.

KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 18:53, Vladimir Dergachev 
wrote:




On Sat, 4 May 2024, Maciej Nasinski wrote:


Thank you all for the discussion.Then, we should promote "code

awareness" and count on the CRAN Team to continue their great work:)


What do you think about promoting containers?
Nowadays, containers are more accessible, with GitHub codespaces being

more affordable (mostly free for students and the educational sector).

I feel containers can help a little bit in making the R work more

secure, but once more when used properly.

I think it is not a good idea to focus on one use case. Some people will
find containers more convenient some don't.

If you want security, I am sure containers are not the right approach -
get a separate physical computer instead.

 From a convenience point of view containers are only ok as long as you
don't need to interface with outside software, then it gets tricky as the
security keeping things containerized starts interfering with getting work
done. (Prime example: firefox snap on ubuntu)

One situation where containers can be helpful is distribution of
commercial applications. Containers allow you to freeze library versions,
so your app can still run with old C library or a specific version of
Python. You can then _hope_ that containers will have fewer compatibility
issues, or at least you can sell containers to your management on this
idea.

But this is not really a good thing for an open source project like R.

best

Vladimir Dergachev



KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 07:17, Vladimir Dergachev 

wrote:



   On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:

   > Dear Maciej Nasinski,
   >
   > On Fri, 3 May 2024 11:37:57 +0200
   > Maciej Nasinski  wrote:
   >
   >> I believe we must conduct a comprehensive review of all

existing CRAN

   >> packages.
   >
   > Why now? R packages are already code. You don't need poisoned

RDS files

   > to wreak havoc using an R package.
   >
   > On the other hand, R data files contain R objects, which contain

code.

   > You don't need exploits to smuggle code inside an R object.
   >

   I think the confusion arises because users expect "R data files"

to only

   contain data, i.e. numbers, but they can contain any R object,

including

   functions.

   I, personally, never use them out of concern that accidentally

saved

   function can override some functionality and be difficult to

debug. And,

   of course, I never save R sessions.

   If you need to pass data it is a good idea to use some common

format like

   tab-separated CSV files with column names. One can also use MVL

files

   (RMVL package).

   best

   Vladimir Dergachev





[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

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

[Ben Bolker]

   Zenodo and OSF (see e.g. 
) are both non-profit 
organizations that support archiving -- that is, they both make stronger 
guarantees of permanent availability than GitHub does. Possibly Software 
Heritage https://www.softwareheritage.org/features/ ?


  Zenodo has convenient GitHub integration.

On 2024-05-08 4:01 p.m., Josiah Parry wrote:

Thank you, Ivan, for your really thoughtful feedback! I really appreciate
it!

- I'll see if there are any base R packages that support SHA-2 or SHA-3.
- I'll see if I can get the configure.ac to make the appropriate Rscript
call for configure.win.
   - I think the idea of having a single `confgure.ac` file to generate
   both configure and configure.win is nice. Guidance with GitHub
actions and
   ChatGPT is essentially a must for me since my bash is remedial at best.

Regarding the permanent storage requirement, I find it to be very strange.
I've personally never heard of Zenodo until just now! Does the CRAN team
have recommendations for what is considered "as sufficiently reliable?" I
have repos that have persisted for almost 10 years. I think that is
sufficiently reliable!

The requirement to avoid GitHub feels surprisingly anachronistic given how
central it is to the vast majority of software development. The alternative
I can think of is to create a CDN on cloudflare or something to store the
file independently.

Are there any avenues to have CRAN clarify their positions outside of
one-off processes? It would be quite unfortunate to go through all the work
of creating a way to build, store, and retrieve the dependencies only for
CRAN to decide they don't support it.


On Wed, May 8, 2024 at 3:32 PM Ivan Krylov  wrote:


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


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


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

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


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


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


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


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

--
Best regards,
Ivan



[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] No email with confirmation link on resubmission of package

[Ben Bolker]

  Check your spam folder(s) ?

  Try the web form  just in 
case something is wonky with devtools::submit_cran() ?




On 2024-06-05 4:19 a.m., Paul Kabaila wrote:

(1) Today, I submitted my R package to CRAN using
devtools::submit_cran()
which  resulted in an  email from
CRAN Package Submission Form 
cransub...@xmbombadil.wu.ac.at
with a confirmation link,  which I clicked on.

(2) I was then sent an email from
lig...@statistik.tu-dortmund.de
which notified that my package "does not pass the incoming checks 
automatically",
with 0 errors, 0 warnings and 2 notes.


(3) I then fixed the problem for one of the notes and explained the reason for 
the
other note and put this information into the file
cran-comments.md
Then I resubmitted my R package to CRAN using
devtools::submit_cran()

However, this time I did not receive an email with a confirmation link.

Has my package been resubmitted or do I need to resubmit it in some different 
way?

Paul Kabaila


La Trobe University | TEQSA PRV12132 - Australian University | CRICOS Provider 
00115M

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Resubmitting an archived package

[Ben Bolker]

   As far as I know these are all harmless.

  * the first NOTE is for CRAN consumption
  * the rest are false positives



The spell-checking machinery used in package checking is 
under-documented. There are some useful references here


https://github.com/r-lib/usethis/issues/1466
https://ropensci.org/blog/2022/01/21/ropensci-news-digest-january-2022/#to-quote-or-not-to-quote-non-existing-words-in-description
https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000943.html
https://stat.ethz.ch/pipermail/r-package-devel/2017q3/001764.html

 I've been meaning to submit a patch to "Writing R Extensions" that 
would describe this, but so far I haven't. However, I also think that 
win-builder does *not* pay attention to the .aspell/ stuff documented 
above ...




On 2024-06-12 2:12 p.m., Lucas Godoy wrote:

Hello everyone,

Recently, my R package {smile} was archived due to NOTES. At the time, I
was in the final stages of my PhD and unfortunately, I couldn't address the
issue in time to prevent the package from being archived.

Long story short, I fixed the issues, and now the `R CMD check --as-cran`
returns no notes (I'm on a Mac. However, when I submit the package to
"win-builder" to get it checked on Windows, I get the following NOTES:
"* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Lucas da Cunha Godoy '

New submission

Package was archived on CRAN

Possibly misspelled words in DESCRIPTION:
   ISSN (17:54)
   Moraga (13:60)
   al (14:9)
   et (13:67)

CRAN repository db overrides:
   X-CRAN-Comment: Archived on 2024-04-09 as issues were not corrected
 in time."

The "misspelled" words are author names included in the DESCRIPTION file as
references. Also, there is a note that the package is being archived.
I used GitHub workflows to get the package checked on Linux as well (see
here
),
and there I got a note about sub-directories with more than 1Mb. To this
point, I don't believe I can further shrink those directories.

Does anyone have any suggestions on how to fix those issues to get the
package on CRAN?
My session info is below, just in case.

R version 4.3.2 (2023-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Sonoma 14.5

Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib

LAPACK:
/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
  LAPACK version 3.11.0

Thanks a lot,
Lucas.

[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

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

[Ben Bolker]

  I feel like I've seen this go by on a forum or issues list somewhere 
recently, but can't find it again.


  Whatever CRAN is doing, I think that adding purl=FALSE along with 
error=TRUE might help.


On 2024-06-14 1:58 a.m., Roland Fuß wrote:

Hi,

We are seeing this with our ALFAM2 package: 
https://cran.r-project.org/web/checks/check_results_ALFAM2.html


We have many code chunks with knitr option `error=TRUE`. My 
understanding is that CRAN machines should have set 
`_R_CHECK_VIGNETTES_SKIP_RUN_MAYBE_=true` and not check the tangled code 
but I see:


"When sourcing ‘ALFAM2-start.R’:

Error: Missing value(s) in predictor variable(s)

    See above for variables.

    Check these rows: 3

Execution halted"

Before I dive deeper into this and we maybe switch to `eval=FALSE`, is 
my understanding wrong? Or is the setup on the oldrel-macos machines 
different?



Thanks in advance,

Roland



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

Re: [R-pkg-devel] Is R-Forge dead?

[Ben Bolker]

  I don't know about R-forge, but it's perfectly workable to put 
multiple packages within a single repo, with each package in its own 
subdirectory.  You'll run into some headaches occasionally with (e.g.) 
CI machinery that assumes that the head of a git repo is also the 
primary package directory (e.g. 
https://github.com/r-hub/rhub/issues/584) ...


On 2024-07-01 6:04 p.m., Kevin R. Coombes wrote:

Hi,

I have been maintaining packages in R-Forge for many tears. Last week I 
sent an email to r-fo...@r-project.org to report problems with the build 
process. It appears that any changes I have pushed to R-Forge over 
approximately the last two months have resulted in the package remaining 
in the "Building" state, even though the logs suggest that the package 
built successfully on both LINUX and Windows. (Also, four of the six 
affected packages only included changes to the man pages to clean up 
NOTEs from the R cmd checks on old versions at CRAN, where the new 
versions now happily reside.) I have received no response nor 
acknowledgement to my email to R-Forge.


Assuming that R-Forge has finally succumbed to the ravages of entropy, 
does anyone have advice on creating a git project that contains multiple 
R packages? (I really don't want to have to create 20+ new git projects, 
one per package).


Best,
    Kevin

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


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

Re: [R-pkg-devel] cpp11 and "non-API calls to R"

[Ben Bolker]

  Have you contacted the maintainer directly (i.e. by e-mail)?  (Yes, 
they should be paying attention to Github, but trying another channel 
never hurts.)


  My personal experience is that I was succeeded in submitting a 
package update to CRAN even though there were NOTEs of this sort (in 
that case SET_TYPEOF) arising from an upstream package 
<https://github.com/RcppCore/Rcpp/issues/1312>; I explained the issue in 
my cover letter.


  It may take a while to sort out all of the fallout from the 
tightening of the API rules; I think the CRAN maintainers are aware of this.


  cheers
   Ben Bolker


On 2024-07-08 10:24 a.m., Mark Padgham wrote:

Dear R-pkg-dev folk,

The cpp11 package, which was developed yet is no longer maintained by
Jim Hester, now triggers warnings on some CRAN pre-submit checks for
"non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
relevant issue is https://github.com/r-lib/cpp11/issues/355, with a pull
request to resolve at https://github.com/r-lib/cpp11/pull/358. Problem
is the package is now largely inactive, with the PR hanging there for a
month or so unattended. I presume this warning means I can not resubmit
any package depending on cpp11 until this is resolved. But then there
are currently 75 packages potentially affected by this which would then
also be unable to be resubmitted. (Follow the links from the main GitHub
issue for a glimpse of the scale of this problem.)

Any suggestions? In particular, it would be helpful, in this arguably
unusual and quite prominent case, to hear any views from CRAN folk as to
whether everybody dependent on cpp11 will have to wait for resolution
before they'll be able to resubmit? Alternatively, any indication from
anybody in a position to opine on cpp11 status and future maintenance
plans would be great!

Thanks,

Mark

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Segfaults on R-devel

[Ben Bolker]

  I'm pretty sure this is from this R-devel commit:

https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250

 This turns on stricter boundary checking, specifically see 
https://github.com/lme4/lme4/issues/794#issuecomment-2154948145


  Arguably, accessing an element of a zero-length vector is at least 
undefined behaviour, so you shouldn't be doing it ...




On 2024-07-08 6:46 p.m., Claborne, Daniel via R-package-devel wrote:

Seemingly starting with the most recent builds of R-devel, I�ve been getting 
segfaults related to a piece of cpp code that indexes a zero-size 
NumericVector.  Essentially the same as this dummy example:

```
library(Rcpp)

sourceCpp(
   code = '
   #include
   using namespace Rcpp;

   // [[Rcpp::export]]
   NumericVector zeroindex() {
 NumericVector zerosize(0);

 Rcout << zerosize[0] << std::endl;

 return zerosize;
   }
   '
)

zeroindex()
```

On R-release and on previous builds, this returns something like:

```
6.92674e-310
numeric(0)
```

But on current R-devel containers:

```

  *** caught segfault ***

address 0x1, cause 'memory not mapped'



Traceback:

  1: .Call()

  2: zeroindex()



Possible actions:

1: abort (with core dump, if enabled)

2: normal R exit

3: exit R without saving workspace

4: exit R saving workspace
```

It was easy enough to write a catch for the zero-size vector, however I�m 
wondering why the discrepancy between R-devel and previous versions?

Best,
-DMC

[[alternative HTML version deleted]]


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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

Re: [R-pkg-devel] Notes while a new R package submission

[Ben Bolker]

  The first NOTE is irrelevant.  The second NOTE says that you must 
reduce the running time of your examples (so that the longest of them 
takes <10 seconds on the *slowest* CRAN testing platform). This thread 
might be useful: 
https://stat.ethz.ch/pipermail/r-package-devel/2021q4/007521.html


  cheers
   Ben Bolker


On 2024-07-08 6:09 a.m., Mahadi Hassan wrote:

Hello everyone
I need your attention. I have developed a new R package and submitted it to
CRAN. In return main i got two notes they are:

* using log directory 'd:/RCompile/CRANincoming/R-devel/drglm.Rcheck'
* using R Under development (unstable) (2024-07-05 r86875 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
 gcc.exe (GCC) 13.2.0
 GNU Fortran (GCC) 13.2.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* checking for file 'drglm/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'drglm' version '1.0.1'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'MHNayem '

New submission
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'drglm' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for future file timestamps ... OK
* checking 'build' directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking code files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking installed files from 'inst/doc' ... OK
* checking files in 'vignettes' ... OK
* checking examples ... [257s] NOTE
Examples with CPU (user + system) or elapsed time > 10s
 user system elapsed
drglm  93.50  14.34  107.82
drglm.multinom 78.65  13.28   91.89
big.drglm  26.61   1.75   28.36
make.data  25.07   1.78   26.84
* checking for unstated dependencies in 'tests' ... OK
* checking tests ... OK
   Running 'testthat.R'
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes ... OK
* checking re-building of vignette outputs ... [241s] OK
* checking PDF version of manual ... [13s] OK
* checking HTML version of manual ... OK
* DONE
Status: 2 NOTEs



And my submission got cancelled automatically.  Can you tell me how to
solve such notes and how can i resubmit it to CRAN?

[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


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

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

[Ben Bolker]

Dirk Eddelbuettel would tell you to use his 'little r' script instead,
though not sure if it has this particular flexibility. You could wrap R CMD
BATCH in your own script that moved Rplots.pdf where you wanted it ...

On Sun, Jul 28, 2024, 4:05 PM Josiah Parry  wrote:

> Thanks, Duncan!
>
> Is there a way to override this using the command line arguments?
>
> I'd like to be able to have a generalizable way to address this without
> having to modify R source code.
>
> My understanding is that when there is a plot output, R CMD BATCH uses the
> PDF device which is a fair default.
>
> However, there is not any use of `dev.new()` or `pdf()` called anywhere in
> the code.
>
> On Sun, Jul 28, 2024 at 3:44 PM Duncan Murdoch 
> wrote:
>
> > On 2024-07-28 1:48 p.m., Josiah Parry wrote:
> > > Hey folks! I am working with R CMD BATCH and providing a providing a
> > > logfile output e.g.
> > >
> > > R CMD BATCH main.R 2024-07-28.log
> > >
> > > This creates the desired log file with the contents of stdout and
> stderr.
> > >
> > > However, if plots are generated in the process, the plots are stored in
> > > Rplots.pdf.
> > >
> > > Is there a way via command line arguments to change the name of the pdf
> > > output.
> > >
> > > There might be multiple runs of this script and it would be ideal to
> > store
> > > the plot output independently.
> >
> > That's the default filename if you open a PDF device.  Open it
> > explicitly and you can specify any file you like.
> >
> > That is,
> >
> >plot(rnorm(100))
> >
> > will call dev.new() which in a non-interactive session calls pdf().  If
> > you specify
> >
> >dev.new(file = "something.pdf")
> >plot(rnorm(100))
> >
> > the "file" argument will be ignored in an interactive session, but will
> > be used in a non-interactive one.
> >
> > Duncan Murdoch
> >
> >
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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