Re: [R-pkg-devel] different build tools

[Jeff Newmiller via R-package-devel]

Duncan's point about options is key... the build options set by default in 
devtools etc are generally configured to minimize the time required to identify 
the next big issue to address. Options appropriate for preparing to submit to 
CRAN are slow and inconvenient for developing.

I recommend that you always use option 1 when preparing to share or submit your 
package.

Note that while using support tools like roxygen, devtools, and RStudio are 
common, they are intended to streamline the package development process by 
filling in a lot of busywork details. However, they do not represent the 
official R-supported development process, and may become out-of-date during R 
version transitions.

On May 28, 2024 3:29:41 PM PDT, Duncan Murdoch  wrote:
>On 2024-05-28 6:20 p.m., Boylan, Ross via R-package-devel wrote:
>> There are at  least 4 ways to build a package:
>> 
>>1.  R CMD build
>>2.  pkgbuild::build(), which I  believe calls 1.
>>3.  devtools::build(), which calls 2.
>>4.  RStudio GUI, which calls 3.
>> 
>> I recently discovered these don't all behave the same.  Invoking bootstrap.R 
>> at  the start
>> requires 2 or greater. 
>
>What is bootstrap.R?
>
> And invoking 3 directly produced different behavior than 4,
>> apparently because of  different defaults for the clean_doc option of 2.
>> 
>> Similar remarks apply to R CMD check.
>> 
>> I'm puzzled by the plethora of tools and options.  In particular I had 
>> assumed that if check
>> and build worked in RStudio, I'd get the same results from R CMD.  I assume 
>> the latter is
>> used on CRAN, and so it would be reasonable to expect the package would 
>> build there.
>> 
>> Can anyone help me understand what's going on?  More specifically, what are 
>> the design
>> goals of the different tools.  Clearly if devtools::build were the same as 
>> pkgbuild:build there
>> would be no reason for the former to exist.
>> 
>
>pkgbuild, devtools and RStudio are all products of Posit, so it would make 
>sense to ask your question in one of their forums.
>
>By the way, RStudio has project and global options that affect its builds; the 
>default uses devtools, but I generally deselect that, and go straight to 1.
>
>Duncan Murdoch
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

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

[Jeff Newmiller via R-package-devel]

so... your suggestion is not for CRAN, but for R-Core, who makes changes to 
R

On May 18, 2024 6:03:55 PM PDT, "Richard M. Heiberger"  wrote:
>exactly. when the --as-cran detects the need for that NOTE, it could prefix 
>the initial instance of that NOTE with information about
>updating the tidy installation on the package writer'smachine.
>
>Sent from my iPhone
>
>> On May 18, 2024, at 20:20, Duncan Murdoch  wrote:
>>
>> I don't think that will ever happen.  It only happens when a user tries an 
>> "--as-cran" check, but doesn't have a current version of tidy installed.  
>> CRAN does have the up-to-date versions installed, so they won't see this.
>>
>> Duncan Murdoch
>>
>>> On 2024-05-18 5:10 p.m., Richard M. Heiberger wrote:
>>> this is a suggestion to CRAN.
>>> when checking a package and discovering these messages about html5, can you 
>>> generate an informational message about tidy with a link to updating tidy?
>>> thank you
>>> Rich
>>> Sent from my iPhone
> On May 17, 2024, at 15:32, Marc Girondot via R-package-devel 
>  wrote:

 Here is the solution to update tidy to a recent version:
 https://www.html-tidy.org/

 Marc
> Le 17/05/2024 à 17:59, Zeinab Mashreghi a écrit :
> Hi,
>
> Thanks for all the suggestions and help.
>
> Yes, I'm using an Apple computer. The tidy version was from 2006. I 
> submitted the package without any issues.
>
> Thanks again!
>
> Zeinab
>
> From: Ivan Krylov 
> Date: Thursday, May 16, 2024 at 12:27 PM
> To: Zeinab Mashreghi 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission 
> Note
> Notice: This is external email. Verify the sender and use caution with 
> any content.
>
>
> � Thu, 16 May 2024 16:01:45 +
> Zeinab Mashreghi  �:
>
>> checking HTML version of manual ... NOTE
>> Found the following HTML validation problems:
>> All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type"
>> attribute
>> All.data.html:12:1 (All.data.Rd:10): Warning: 

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

[Jeff Newmiller via R-package-devel]

What is a "right side window"? Are you mixing up what R does and what RStudio 
does? I think I agree with Ivan that this is a question about the environment 
in which you are loading the package rather than anything in the package itself.

On March 7, 2024 11:21:06 AM PST, "Ruff, Sergej"  
wrote:
>So, in  the previous version of the package when we type ?bootGSEA, it opens 
>the documentation in webpage (google, firefox…) and when we type ?pkg-function 
>opens to the right side window, but now it just opens in the right side 
>window. I was wondering why does it not open in webpage now.
>
>
>Von: Ruff, Sergej
>Gesendet: Donnerstag, 7. März 2024 17:56:20
>An: Hadley Wickham
>Cc: r-package-devel@r-project.org
>Betreff: AW: [EXTERN] Re: [R-pkg-devel] @doctype is deprecated. need help for 
>r package documentation
>
>
>the package is currently available under: 
>https://github.com/klausjung-hannover/bootGSEA/blob/main/R/bootGSEA.r
>
>
>line 1-31 contains the package information.
>
>
>#' Package contains functions that repeates GSEA using bootstrap samples of 
>gene sets. Bootstrap results are
>#' aggregated to a new ranking score. The score can be compared to the gene set
>#' ranking resulting from the standard GSEA.
>#'
>#' So far the functions included in the package are:
>#' \itemize{
>#'   \item \code{\link{aggr.boot.GO}} Aggregate boostrap GO analysis
>#'   \item \code{\link{aggr.boot.Pathway}} Write a \code{genind} Aggregate 
>boostrap pathway analysis
>#'   \item \code{\link{aggr.multiomics}} Multiomics Integration analysis
>#'   \item \code{\link{boot.GO}} Bootstrap GO analysis
>#'   \item \code{\link{boot.pathway}} Bootstrap Pathway analysis
>#'   \item \code{\link{compareRank}} Visualisation of bootstrap GO analyses
>#'   \item \code{\link{histDiff}} Visualization of difference in ranks
>#'   \item \code{\link{plotRank}} Visualisation of bootstrap pathway analyses
>#' }
>#'
>#' \tabular{ll}{
>#' Package: \tab bootGSEA\cr
>#' Type: \tab Package\cr
>#' Version: \tab 1.0\cr
>#' Date: \tab 2024-03-05\cr
>#' License: \tab GPL (>= 3)\cr
>#' }
>#'
>#' @author Shamini Hemandhar Kumar, Klaus Jung 
>(\email{shamini.hemandhar.kumar@@tiho-hannover.de})(\email{klaus.jung@@tiho-hannover.de})
>#'
>#' Maintainer: Shamini Hemandhar Kumar 
>(\email{shamini.hemandhar.kumar@@tiho-hannover.de})
>#' @aliases bootGSEA
>#' @title Robustness evaluation of gene set enrichment analysis (GSEA)
>#' @keywords Robustness GSEA
>"_PACKAGE"
>
>
>
>Von: Hadley Wickham 
>Gesendet: Donnerstag, 7. März 2024 16:02:15
>An: Ruff, Sergej
>Cc: r-package-devel@r-project.org
>Betreff: [EXTERN] Re: [R-pkg-devel] @doctype is deprecated. need help for r 
>package documentation
>
>Do you have a pointer to the roxygen2 comments that you're using?
>Hadley
>
>On Thu, Mar 7, 2024 at 5:38 AM Ruff, Sergej 
>mailto:sergej.r...@tiho-hannover.de>> wrote:
>Hello,
>
>I need help with a package I am currently developing called bootGSEA.
> I noticed that when I try ‘?bootGSEA’ it goes to the help page in R itself 
> but not to the html page (we had this issue last time as well but we solved 
> it by adding a documentation to the package itself to the R file) like from 
> the before version of the package.
>I tried “_PACKAGE” in the documentation of the package section as @doctype is 
>depreceated, but it still doesn’t seem to solve the issue. Do you have any 
>idea on this?
>
>
>[[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing 
>list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>--
>http://hadley.nz
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

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

[Jeff Newmiller via R-package-devel]

Remove leading periods from all file names in the tar.gz. Use .Rbuildignore to 
handle such files in your dev directory if you need them. Maybe also look at 
[1].

 [1] 
https://stackoverflow.com/questions/40950799/r-cmd-check-error-how-to-get-rid-of-hidden-files-and-directory-in-devel-r-pack

On March 5, 2024 5:34:36 PM PST, "Richard M. Heiberger"  wrote:
>Almost.
>
>I used 
>prompt(".__global__")
>to create file
>man/.__global__.Rd
>
>This file does not appear in the tar.gz file, but without a note of rejection.
>When I checked my disk directory directly
>R CMD check RcmdrPlugin.HH
>the file was rejected with
>
>Found the following hidden files and directories:
>  .DS_Store
>  R/.DS_Store
>  man/.__global__.Rd
>These were most likely included in error. See section ‘Package
>structure’ in the ‘Writing R Extensions’ manual.
>
>I looked there
>Section 1.1 says that the acceptable characters are
>A-Za-z0-9._!#$%&+,;=@^(){}'[]
>and "." and _ are explicitly included.
>
>What should I try next?
>
>
>> On Mar 5, 2024, at 18:21, Duncan Murdoch  wrote:
>> 
>> On 05/03/2024 5:41 p.m., Richard M. Heiberger wrote:
>>> My package is being rejected by auto-check
>>> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
>>> Check: for missing documentation entries, Result: WARNING
>>>  Undocumented code objects:
>>>'.__global__'
>>>  All user-level objects in a package should have documentation entries.
>>>  See chapter 'Writing R documentation files' in the 'Writing R
>>>  Extensions' manual.
>>> The problem is that the string'.__global__'  is not in the package.
>>> I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.
>>> Can someone help me understand why a non-existent string is being detected?
>> 
>> That's the variable modified by the `globalVariables()` function.  So it may 
>> well exist in your package.  I'd guess the problem is that your package 
>> exports functions by giving a pattern for the names instead of listing each 
>> one separately, and it matches that variable.
>> 
>> Duncan Murdoch
>> 
>> 
>> 
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Changing package maintainers

[Jeff Newmiller via R-package-devel]

Are you aware of this [1]? J. Random Lurker may not be a reliable source, and 
actual CRAN repo maintainers are probably a bit busy...

[1] https://cran.r-project.org/web/packages/policies.html#Submission

On February 8, 2024 8:37:50 AM PST, Josiah Parry  wrote:
>I intend to change the maintainer of my package {sfdep}
>https://cran.r-project.org/package=sfdep.
>Is the process as simple as submitting a new release where the DESCRIPTION
>file changes who has the role of `aut`?
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Warnings from upstream C library in CRAN submission

[Jeff Newmiller via R-package-devel]

Type conversions are always a bit risky... this one appears to be likely to 
corrupt data. If they actually intended to truncate values like this then they 
should have cast explicitly.

Looks like you need to report this to the SUNDIALS maintainers.

On February 3, 2024 7:38:35 AM PST, Satyaprakash Nayak  
wrote:
>Hi
>
>I had a package 'sundialr' which was archived from CRAN. It is an interface
>to some of the solvers in SUNDIALS ODE Solving library. I have fixed the
>issue which was related to emails being forwarded from the maintainer's
>email address.
>
>The repository code can be found at - https://github.com/sn248/sundialr
>
>I have updated the upstream library and now I am getting the following
>warnings from CRAN which are all related to the upstream library. The
>package compiles without any other issues and can be used.
>
>Flavor: r-devel-windows-x86_64
>Check: whether package can be installed, Result: WARNING
>  Found the following significant warnings:
>./sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from
>'long long unsigned int' to 'long unsigned int' changes value from
>'14695981039346656037' to '2216829733' [-Woverflow]
>./sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from
>'long long unsigned int' to 'long unsigned int' changes value from
>'1099511628211' to '435' [-Woverflow]
>sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from
>'long long unsigned int' to 'long unsigned int' changes value from
>'14695981039346656037' to '2216829733' [-Woverflow]
>sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from
>'long long unsigned int' to 'long unsigned int' changes value from
>'1099511628211' to '435' [-Woverflow]
>sundials/sundials/sundials_profiler.c:71:24: warning: function
>declaration isn't a prototype [-Wstrict-prototypes]
>  See 'd:/RCompile/CRANincoming/R-devel/sundialr.Rcheck/00install.out' for
>details.
>  Used C++ compiler: 'g++.exe (GCC) 12.3.0'
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: whether package can be installed, Result: WARNING
>  Found the following significant warnings:
>sundials/sundials/sundials_profiler.c:71:41: warning: a function
>declaration without a prototype is deprecated in all versions of C
>[-Wstrict-prototypes]
>  See '/srv/hornik/tmp/CRAN/sundialr.Rcheck/00install.out' for details.
>  Used C++ compiler: 'Debian clang version 17.0.6 (5)'
>
>I am hesitant to change anything in the SUNDIALS library C code because I
>don't understand the consequences of changing anything there.
>
>Any help will be kindly appreciated.
>
>Thank you.
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

[Jeff Newmiller via R-package-devel]

This is a narrow view of the world. As has been mentioned here by Tomas, the 
issue at this point is that a very widely-used operating system does not allow 
the absolute path to be longer than 254 characters unless users make 
possibly-breaking changes to their OS configuration. If a user is currently 
working in a directory with a path that is 150 characters long, and you try to 
un-tar a package there, it will work. If they are in a directory path that is 
170 characters long, then the un-tar will fail. They then have to do some 
research and discover that they have to share the total absolute path length 
with the package creators, and they become accustomed to working in directories 
with path length no longer than 154 characters.

Now you want to propose giving the entire path length budget plus 2 to the 
package developers. Not gonna happen. And Dirk wants 50 more characters. Then 
the user working at 150 characters tries to un-tar a package with paths 150 
characters long and 150 user plus 150 package gets you to 300 characters and 
what used to work for them stops working suddenly.

I think a package developer can figure out how to shorten their internal paths 
easier than thousands of users can restructure their historically useful 
directory structures or break their existing software. I vote no to both of 
these proposals.

Eventually, Microsoft is going to virtualize running old Windows APIs, and once 
people migrate away from the old API then this stupid problem will go away. But 
as it is we are stuck.

On December 13, 2023 7:27:42 AM PST, "McGrath, Justin M" 
 wrote:
>I'm not even asking for that. I'm asking for the decades old ustar 
>comparability, which is 255 characters, at most. In practice it is slightly 
>less than that. ustar is older than R itself. There is no one using R who 
>doesn't have ustar compatible tar.
>
>
>From: Dirk Eddelbuettel 
>Sent: Wednesday, December 13, 2023 8:59 AM
>To: Tomas Kalibera
>Cc: McGrath, Justin M; Ben Bolker; Martin Maechler; 
>r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel]  Wrong mailing list: Could the 100 byte path length 
>limit be lifted?
>
>
>On 13 December 2023 at 15:32, Tomas Kalibera wrote:
>| Please don't forget about what has been correctly mentioned on this
>| thread already: there is essentially a 260 character limit on Windows
>| (see
>| 
>https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-YZg5PVpulgNXCVfVklP442UG_0ofB8omMLlMq5dNadF9RP_6uofnrT6IbZpG1fpvjmAtLyAm1Y9rbc$
>| for more). Even if the relative path length limit for a CRAN package was
>| no longer regarded important for tar compatibility, it would still make
>| sense for compatibility with Windows. It may still be a good service to
>| your users if you keep renaming the files to fit into that limit.
>
>So can lift the limit from 100 char to 260 char ?
>
>Dirk
>
>--
>dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?

[Jeff Newmiller via R-package-devel]

Rhub is not CRAN. Please include a link to your source package if you want 
help. If there is actually a bug in Rhub then this NUL error may not reflect 
the response you will get from CRAN if and when you submit.

On December 13, 2023 12:58:41 AM PST, Friedemann von Lampe 
 wrote:
>Hi,
>
>when trying to update my package on CRAN it is rejected, because it gets a 
>note during checks on Debian:
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: for non-standard things in the check directory, Result: NOTE
>Found the following files/directories:
>'NUL'
>
>There is no such file in my folder and therefore it can't be removed. With 
>Windows everything is OK.
>As far as I understood, this is a problem with Rhub? 
>(https://github.com/clessn/locateip/issues/99)
>
>Or what can I do, to fix this problem and get my package update submitted to 
>CRAN?
>
>Thanks,
>Friedemann von Lampe
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] [External] circular suggested packages

[Jeff Newmiller via R-package-devel]

Richard ... they are by different maintainers. They also are built with 
completely different underlying technologies... creating a bitmap is easy, 
deciphering one is difficult and may not be necessary in the same workflow and 
there may be different compiled code available optimized for different use 
cases (clean vs with optical interference) so it makes perfect sense to me.

On November 7, 2023 12:01:01 PM PST, "Richard M. Heiberger"  
wrote:
>Why are these functins in two different packages?
>On the surface it looks like qrcode is a transformation function and opencv is 
>its inverse.
>
>> On Nov 7, 2023, at 14:55, Thierry Onkelinx  wrote:
>>
>> Dear all,
>>
>> The qrcode package converts text into a qrcode image. The opencv package is
>> able to convert images with a qrcode into the text. opencv has a unit test
>> that uses qrcode to generate a test image. Hence it lists qrcode as a
>> suggested package.
>>
>> Would it be OK to implement the same unit test in qrcode? And thus
>> requiring qrcode to list opencv as a suggested package. I know this is not
>> allowed when depending or importing packages.
>>
>> Best regards,
>>
>> ir. Thierry Onkelinx
>> Statisticus / Statistician
>>
>> Vlaamse Overheid / Government of Flanders
>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
>> FOREST
>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
>> thierry.onkel...@inbo.be
>> Havenlaan 88 bus 73, 1000 Brussel
>> 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
>> ///
>>
>> 
>>
>> [[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

-- 
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] Rmarkdown fails if (quote) r (space) is used

[Jeff Newmiller via R-package-devel]

A code chunk does always begin with a triple backtick at the beginning of a 
line. The term for what you encountered is "inline code" used to embed computed 
results into the markdown text as though you had typed them directly.

Check out 
https://www.r-bloggers.com/2017/12/how-to-show-r-inline-code-blocks-in-r-markdown
 for relevant discussion.

On November 3, 2023 7:54:22 AM PDT, J C Nash  wrote:
>I've spent a couple of hours with an Rmarkdown document where I
>was describing some spherical coordinates made up of a radius r and
>some angles. I wanted to fix the radius at 1.
>
>In my Rmarkdown text I wrote
>
>   Thus we have `r = 1` ...
>
>This caused failure to render with "unexpected =". I was using Rstudio
>at first and didn't see the error msg.
>
>If I use "radius R" and `R = 1`, things are fine, or `r=1` with no space,
>but the particular "(quote) r (space)" seems to trigger code block processing.
>
>Perhaps this note can save others some wasted time.
>
>I had thought (obviously incorrectly) that one needed ```{r something}
>to start the code chunk.
>
>JN
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Fortune candidate Re: Issue with R Package on CRAN - OpenMP and clang17

[Jeff Newmiller via R-package-devel]

ROFL! Seconded!

The quote itself has a bit of greybeard smell to it, but the "ran out of stuff 
to delete at 100GB with 1000 out of 6000 targets compiled" had me in stitches.

On October 31, 2023 10:16:10 AM PDT, Dirk Eddelbuettel  wrote:
>
>On 31 October 2023 at 19:58, Ivan Krylov wrote:
>| [...] The computers that helped launch the first
>| people into space had 2 kWords of memory, but nowadays you need more
>| than 256 MBytes of RAM to launch a bird into a pig and 10 GBytes of
>| storage in order to compile a compiler. This is what progress looks
>| like.
>
>Fortune!!
>
>Dirk
>

-- 
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] Failing to write config file in linux

[Jeff Newmiller via R-package-devel]

Installed packages may not be modified because they are permitted to be 
installed with read-only access. You have no option to proceed in this 
direction.

Configuration files are normally stored in the user's working directory. 
Dotfiles are a common convention in *nix operating systems, but in Windows the 
conventions are a bit different. The most general solution is to allow the user 
to specify an R option in .Rprofile [1], but you can setup defaults depending 
on the user's OS to back that up in case they don't actually take the steps to 
do that.

[1] https://stat.ethz.ch/R-manual/R-devel/library/base/html/options.html

On October 22, 2023 9:52:50 AM PDT, "Keshav, Krishna"  wrote:
>Hi,
>
>My package is failing on linux based systems because of an attempt to write in 
>a location of package. One of the core features that we would like user to 
>have is to modify the values in the config file, for which package has a 
>function for user to provide modified config. In future, they should be able 
>to provide individual parameters for the config for which also we will be 
>writing to config in package directory /inst/ so that it can later be fetched. 
>I understand that policy doesn’t allow writing to home directory. Is there a 
>workaround for this? Or what could be other potential solutions to explore.
>
>Snippet –
>https://github.com/GarrettLab/CroplandConnectivity/blob/923a4a0ca4a0ce8376068ee80986df228ea21d80/geohabnet/R/params.R#L57
>
>Error –
> ── Failure ('test-parameters.R:38:3'): Test 6: Test to set new 
> parameters.yaml ──
> Expected `set_parameters(new_param_file)` to run without any conditions.
> ℹ Actually got a  with text:
> cannot create file 
> '/home/hornik/tmp/R.check/r-release-gcc/Work/build/Packages/geohabnet/parameters.yaml',
>  reason 'Read-only file system'
>
>
>Best Regards,
>Krishna Keshav
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Problem persists, was Re: Problem compressing vignettes for CRAN

[Jeff Newmiller via R-package-devel]

R could care less about what is in PATH... there is however a difference 
between Windows parsing PATH and how CMD lets you quote things interactively.

The whole point of PATH is to let you or R provide simple program names like 
qpdf without knowing where they are... Windows takes over and looks up where 
the program actually is based on the contents of PATH. How you get things into 
that environment variable can vary depending on which software you are using 
(CMD and R are two possible options), but the actual content is handled by the 
operating system (which is why PATH on Linux is formatted differently than PATH 
on Windows).

On October 9, 2023 8:22:17 AM PDT, Michael Dewey  
wrote:
>Dear Ivan (and list)
>
>Using Ivan's advice I traced the problem to a difference of opinio between 
>Microsoft and R about paht names. I had mistakenly enclosed parts of the names 
>in "" which was fine for MS but not R. Sys.which() was my saviour here.
>
>Many thanks to Ivan for broadening my knowledge of useful functions like 
>Sys.which().
>
>Michael
>
>On 09/10/2023 08:51, Ivan Krylov wrote:
>> On Sun, 8 Oct 2023 16:47:41 +0100
>> Michael Dewey  wrote:
>> 
>>> Following on from Ivan's advice I have now installed qpdf and
>>> Ghostview. I have checked that they are both on my path by typing
>>> their name at the command line and verifying they open.
>> 
>>> I then built the package with the --compress-vignettes=both and then
>>> checked it with --as-cran I still get a complaint that it needs qpdf
>>> to check compression.
>> 
>> While running R, does Sys.which('qpdf') return the path to qpdf.exe?
>> Does Sys.getenv('PATH') match your expectations?
>> 
>>> I notice that in the Writing R Extensions manual in section 1.6.1 it
>>> states "The full path to the qpdf command can be supplied as
>>> environment variable R_QPDF ..."
>>> 
>>> Is that a typo for "must be supplied"?
>> 
>> Well, R tries to resolve the path to qpdf.exe using Sys.which(), so it
>> must work if it's on the %PATH%, but if all else fails, setting this
>> environment variable should help.
>> 
>>> If it is where can I find the answers to questions about how R
>>> accepts Windows paths? Do I need to enclose parts of names containing
>>> spaces in "" signs?
>> 
>> It always depends on how the final command line is built by a
>> particular function, but it should work by taking plain file paths
>> without any escaping and quotation. The directory separators shouldn't
>> matter either.
>> 
>> (tools::compactPDF uses system2(), so it quotes the path to the
>> executable by itself.)
>> 
>>> Does it mean the path up to, in this case, bin or must I include
>>> qpdf.exe after it?
>> 
>> It must be the full path to the executable, including the final
>> qpdf.exe.
>> 
>>> I assume I do not need to do anything special to get it to find
>>> Ghostscript?
>> 
>> tools::compactPDF() expects gswin64c.exe or gswin32c.exe on the PATH.
>> If it's not there, R_GSCMD must be set to the full path to the
>> executable. Judging by the NOTE you've received, it's Ghostscript that
>> performed most of the compaction in your case.
>> 
>

-- 
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] Warning: a function declaration without a prototype is deprecated in all versions of C

[Jeff Newmiller via R-package-devel]

This error arises because you are not declaring the function properly before 
you call it... likely because you have not included the appropriate header file 
or because you have typoed the function call.

If you provide a link to your package someone may point you more precisely to 
your error, but this is a pretty basic C language question rather than an R 
package question so it isn't technically on topic here.

On September 26, 2023 12:58:25 AM PDT, Sameh Abdulah 
 wrote:
>Dear Colleagues,
>
>
>I've encountered a warning in my package that states:
>
>'warning: a function declaration without a prototype is deprecated in all 
>versions of C [-Wstrict-prototypes].'
>
>This warning originates from one of the libraries I depend on, specifically 
>OpenBLAS. So, I have no control to fix it inside OpenBLAS.
>
>I'm not sure how to resolve this issue.
>
>
>Best regards,
>--Sameh"
>
>

-- 
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] R_orderVector1 - algo: radix, shell, or another?

[Jeff Newmiller via R-package-devel]

You asked how order works. From the R source you can follow which C functions 
are executed, and since you seem familiar with C you can answer your own 
question.

On September 24, 2023 11:10:53 AM PDT, Jan Gorecki  wrote:
>Hi Jeff,
>
>Yes I did. My question is about R_orderVector1 which is part of public R C
>api.
>Should I notice something relevant in the source of R's order?
>
>Best
>Jan
>
>On Sun, Sep 24, 2023, 17:27 Jeff Newmiller  wrote:
>
>> Have you read the output of
>>
>> order
>>
>> entered at the R console?
>>
>>
>> On September 24, 2023 1:38:41 AM PDT, Jan Gorecki 
>> wrote:
>> >Dear pkg developers,
>> >
>> >Are there any ways to check which sorting algorithm is being used when
>> >calling `order` function? Documentation at
>> >https://stat.ethz.ch/R-manual/R-devel/library/base/html/sort.html
>> >says it is radix for length < 2^31
>> >
>> >On the other hand, I am using R_orderVector1, passing in double float
>> >smaller than 2^31. Short description of it states
>> >"Fast version of 1-argument case of R_orderVector".
>> >Should I expect R_orderVector1 follow the same algo as R's order()? If so
>> >it should be radix as well.
>> >
>> >
>> https://github.com/wch/r-source/blob/ed51d34ec195b89462a8531b9ef30b7b72e47204/src/main/sort.c#L1133
>> >
>> >If there is no way to check sorting algo, could anyone describe which one
>> >R_orderVector1 uses, and if there is easy API to use different ones from
>> C?
>> >
>> >Best Regards,
>> >Jan Gorecki
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> >__
>> >R-package-devel@r-project.org mailing list
>> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>

-- 
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] R_orderVector1 - algo: radix, shell, or another?

[Jeff Newmiller via R-package-devel]

Have you read the output of

order

entered at the R console?


On September 24, 2023 1:38:41 AM PDT, Jan Gorecki  wrote:
>Dear pkg developers,
>
>Are there any ways to check which sorting algorithm is being used when
>calling `order` function? Documentation at
>https://stat.ethz.ch/R-manual/R-devel/library/base/html/sort.html
>says it is radix for length < 2^31
>
>On the other hand, I am using R_orderVector1, passing in double float
>smaller than 2^31. Short description of it states
>"Fast version of 1-argument case of R_orderVector".
>Should I expect R_orderVector1 follow the same algo as R's order()? If so
>it should be radix as well.
>
>https://github.com/wch/r-source/blob/ed51d34ec195b89462a8531b9ef30b7b72e47204/src/main/sort.c#L1133
>
>If there is no way to check sorting algo, could anyone describe which one
>R_orderVector1 uses, and if there is easy API to use different ones from C?
>
>Best Regards,
>Jan Gorecki
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] roxygen style documentation for data sets

[Jeff Newmiller via R-package-devel]

I thought roxygen supported documenting NULL constants for data.

I do think roxygen ought to be able to co-exist with Rd files... but the claim 
that documenting data requires Rd files smells fishy to me.

On September 21, 2023 1:30:11 PM PDT, Michael L Friendly  
wrote:
>I am an RStudio user, and I could see this as a plugin somewhere, but I don't 
>want to create a package just for this.
>
>I'd rather that my code could be adopted somewhere in the framework of 
>devtools/usethis/ ... 
>
>It's so obvious that this tool should be there somewhere, particularly since 
>RStudio makes it hard to work with .Rd files, except those generated by 
>devtools (which shouldn't be
>edited). E.g., I have many legacy .Rd files for data. I can't select example 
>code and click Run, as one can do with roxygen documentation in .R files.
>
>-Michael
>
>-Original Message-
>From: Duncan Murdoch  
>Sent: Thursday, September 21, 2023 3:58 PM
>To: Michael L Friendly ; r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] roxygen style documentation for data sets
>
>Hi Michael.
>
>I don't know if you're an RStudio user, but this seems ideal as the basis for 
>an RStudio plug-in.  Just install it, then when you want to generate docs for 
>some dataset defined in R code, move to the start of the definition and hit 
>some hot key to insert the documentation skeleton ahead of the data definition.
>
>Duncan Murdoch
>
>On 21/09/2023 12:33 p.m., Michael L Friendly wrote:
>> I have many datasets in a some of my packages, and always used 
>> `utils::promptData()` to generate the skeleton of a man/data.Rd file.
>> Now that I've switched to roxygen style, I have found no simple 
>> equivalent. In fact, with RStudio tools for generating documentation for 
>> functions, it is surprising that documenting data has been overlooked.
>> 
>> I solved this problem by simply editing `utils::promptData()` to replace .Rd 
>> style with equivalent roxygen tags.
>> 
>> The result in now in a gist, 
>> https://gist.github.com/friendly/14f3ee1464213bb0b9fbcb489468383b
>> I called this function `use_data_doc()`, because I thought it would be a 
>> welcome addition to the usethis package.
>> 
>> I hope that someone on this list can advise how to make such a function 
>> available to all R package developers.
>> 
>> -Michael
>> 
>> ---
>> Michael Friendly Email: friendly AT yorku DOT ca
>> Professor, Psychology Dept.
>> York University  Voice: 416 736-2100 x66249
>> 4700 Keele StreetWeb: http://www.datavis.ca | 
>> @datavisFriendly
>> Toronto, ONT  M3J 1P3 CANADA
>> 
>> 
>>  [[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

-- 
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] [Tagged] Re: roxygen style documentation for data sets

[Jeff Newmiller via R-package-devel]

None of us here are lawyers, but a simple google search should take you to 
discussions such as [1]. There is a long history of debates about the upsides 
and downsides of restricting how people can use your source code.

My short take is that a GPL license prevents anyone from stuffing your code 
into a proprietary box and selling it without your consent... they have to 
share just as much as you did. MIT doesn't prevent this hiding, so people 
working for companies are less likely to have trouble getting approval to use 
your code... but you may not have any access to their fixes either. Just 
different definitions of "freedom" playing out their implications.

[1] 
https://en.m.wikipedia.org/wiki/MIT_License#:~:text=The%20GNU%20GPL%20is%20explicit,license%20does%20not%20discuss%20patents.

On September 21, 2023 11:45:34 AM PDT, Michael L Friendly  
wrote:
>Yes, if usethis is the most useful place for this to be, I suppose I should 
>first flag this as an issue, and then issue a PR for my code.
>
>I don't understand the fine distinctions between GPL-2 and MIT licensed code.
>
>Perhaps some other developers can chime in here.
>
>-Michael
>
>-Original Message-
>From: Ivan Krylov  
>Sent: Thursday, September 21, 2023 1:37 PM
>To: Michael L Friendly 
>Cc: r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] roxygen style documentation for data sets
>
>В Thu, 21 Sep 2023 16:33:35 +
>Michael L Friendly  пишет:
>
>> I called this function `use_data_doc()`, because I thought it would be 
>> a welcome addition to the usethis package.
>> 
>> I hope that someone on this list can advise how to make such a 
>> function available to all R package developers.
>
>Perhaps a pull request to https://github.com/r-lib/usethis/pulls ?
>
>Should this function be considered a work derived from R? If yes, then (in my 
>non-lawyer opinion) it retains its ownership by R Core and being licensed 
>under GPL-2, which may be a problem for MIT-licensed usethis.
>
>--
>Best regards,
>Ivan
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] is this expected behavior

[Jeff Newmiller via R-package-devel]

Yes.

Demo/test files need to use the library function to attach the package like any 
other user.

On September 13, 2023 5:24:52 PM PDT, "Richard M. Heiberger"  
wrote:
>I have a demo file that uses a function defined in the package.
>when I force the demo to be run with
>R CMD check --test-dir=demo findme_1.0.tar.gz
>then the function defined in the package is not recognized.
>
>Here is the demo/findme.r file:
>
>findme::findme()
>findme()
>
>
>Here is the result of:
>
>R CMD check --test-dir=demo findme_1.0.tar.gz
>
>* checking tests in ‘demo’ ...
>  Running ‘findme.r’
> ERROR
>Running the tests in ‘demo/findme.r’ failed.
>Complete output:
>  > findme::findme()
>  [1] "You found me"
>  > findme()
>  Error in findme() : could not find function "findme"
>  Execution halted
>
>
>The first line with the "::" executed.
>The second line, which assumed the function in the current package
>would be exported, was not found.
>
>Is this the expected behavior?
>
>Thanks
>Rich
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Fw: [CRAN-pretest-archived] CRAN Submission moodlequizR 1.0.1

[Jeff Newmiller]

I don't know how you can negotiate with CRAN regarding attach, but one approach 
is to return the data frame and instruct your students to write

  moodledata <- paste.data()

instead of

  paste.data()

since either is just as obscure as the other in the mind of a beginner and the 
former promotes better understanding of R and good practice.

On September 6, 2023 11:01:45 AM PDT, Wolfgang Rolke via R-package-devel 
 wrote:
>Hi,
>
>I am trying to upload a package to CRAN but keep getting the error message 
>below. The issue seems to be the use of attach in one of my routines. As I 
>explain in the cran-comments.md this use of assign is intentional.
>
>The routine paste.data is used by undergraduate student with very little R 
>knowledge to transfer data from moodle quizzes into R. They can simply copy
>  the data in moodle, switch to R and run paste.data(). The data is assigned 
> to the global   environment under the name moodledata and can be used to find 
> the solution to the moodle quiz. I have been using this routine with my 
> students for several years without any problems.
>
>What do I need to do to get passed this automatic check?
>
>Thanks,
>Wolfgang
>
>
>From: lig...@statistik.tu-dortmund.de 
>Sent: Wednesday, September 6, 2023 1:10 PM
>To: Wolfgang Rolke 
>Cc: cran-submissi...@r-project.org 
>Subject: [CRAN-pretest-archived] CRAN Submission moodlequizR 1.0.1
>
>Dear maintainer,
>
>package moodlequizR_1.0.1.tar.gz does not pass the incoming checks 
>automatically, please see the following pre-tests:
>Windows: 
>>
>Status: 2 NOTEs
>Debian: 
>>
>Status: 2 NOTEs
>
>
>
>Please fix all problems and resubmit a fixed version via the webform.
>If you are not sure how to fix the problems shown, please ask for help on the 
>R-package-devel mailing list:
>>
>If you are fairly certain the rejection is a false positive, please reply-all 
>to this message and explain.
>
>More details are given in the directory:
>>
>The files will be removed after roughly 7 days.
>
>No strong reverse dependencies to be checked.
>
>Best regards,
>CRAN teams' auto-check service

-- 
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] R Package Development -- PDF Manual without Index

[Jeff Newmiller]

CRAN doesn't care about whether devtools is happy. R CMD check --as-cran needs 
to work, e.g. as in [1].

Devtools is a convenience tool to help put all of the necessary bits in the 
right places in your source code according to [2]. But if there is any 
disagreement about what works, devtools is never the definitive answer.

If you put your current package source code online, as in on GitHub and share 
that here, then someone may be able to help you bridge the gap to satisfy both 
devtools and CRAN.

[1] https://kbroman.org/pkg_primer/pages/check.html
[2] https://cran.r-project.org/doc/manuals/R-exts.html

On September 2, 2023 11:50:57 AM PDT, John Carter Hall  
wrote:
>Hello R-Package-Devel Mailing List,
>
>I am new to R package development, and am having to limp a project across the 
>line after my organization has gone through significant changes in recent 
>weeks.
>As such, I am emailing to understand what I can do to solve an error I am 
>having:
>
>The Error
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: PDF version of manual without index, Result: ERROR
>
>The Issue
>
>For whatever reason, the R CMD check​ desires different fields in the 
>DESCRIPTION file than does the devtools::check() function (particularly w.r.t. 
>the 'Author' field), and so I have to use devtools to build/check the package. 
>The devtools::build_manual function, however, does not work, and so I am 
>forced to utilize Rd2pdf to create my PDF manual.
>
>I have to make the manual via Windows due to issues with an Ubuntu 
>installation of my package. However, the package is intended for Linux/Debian 
>audiences.
>
>What I Need Help With
>
>I believe I have the manual created. I do not know if this manual needs to be 
>created when CRAN does their checks, but I have the document (I am comparing 
>its appearance to the manual of ggplot2​, and the structure is similar). I do 
>not know where it needs to be located. I have tried the root directory of the 
>package, the doc​ folder, etc... but nothing works.
>
>What can I do?
>
>Best,
>Carter
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

[Jeff Newmiller]

You have a really bizarre way of twisting what others are saying, Dirk. I have 
seen no-one here saying 'limit R to 2 threads' except for you, as a way to 
paint opposing views to be absurd.

What _is_ being said is that users need to be in control_, but _the default 
needs to do least harm_ until those users take responsibility for that control. 
Do not turn the throttle up until the user is prepared for the consequences. 
Trying to subvert that responsibility into packages by default is going to make 
more trouble than giving the people using those packages simple examples of how 
to take that control.

A similar problem happens when users discover .Rprofile and insert all those 
pesky library statements into it, making their scripts irreproducible. If 
data.table made a warp10() function that activated this current default 
performance setting then the user would be clearly at fault for using it in an 
inappropriate environment like a shared HPC or the CRAN servers. Don't put a 
brick on the accelerator of a teenager's car before they even figure out where 
the brakes are.

On August 25, 2023 6:17:04 PM PDT, Dirk Eddelbuettel  wrote:
>
>On 26 August 2023 at 12:05, Simon Urbanek wrote:
>| In reality it's more people running R on their laptops vs the rest of the 
>world.
>
>My point was that we also have 'single user on really Yuge workstation'. 
>
>Plus we all know that those users are often not sysadmins, and do not have
>our levels of accumulated systems knowledge.
>
>So we should give _more_ power by default, not less.
>
>| [...] they will always be saying blatantly false things like "R is not for 
>large data"
>
>By limiting R (and/or packages) to two threads we will only get more of
>these.  Our collective call.
>
>This whole thread is pretty sad, actually.
>
>Dirk
>

-- 
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] Trouble with long-running tests on CRAN debian server

[Jeff Newmiller]

I think one should be very cautious about overriding "standard" mechanisms for 
controlling software infrastructure like OpenMP.  You risk making the task of 
navigating the already-complex task of configuring the software environment 
even more complex by increasing the number of places you have to look in to 
find out why the mechanism documented by OpenMP is having no effect.

It may be that R Core agrees with you and creates an R-specific setting to 
control this... but IMO it should be accompanied by warning messages to help 
people figure out why their real work is underperforming if they link with 
compiled code that is supposed to make use of threads.

On August 23, 2023 7:24:46 AM PDT, Uwe Ligges  
wrote:
>
>
>On 23.08.2023 15:58, Jeff Newmiller wrote:
>> To whom are you addressing this question? The OpenMP developers who define 
>> the missing-OMP_THREAD_LIMIT behaviour and-or supply default config files? 
>> The CRAN server administrators who set the variable in their site-wide 
>> configuration intentionally or unintentionally? Or the package authors 
>> expected to kludge in settings to override those defaults for CRAN testing 
>> while not overriding them in normal use?
>
>Of course , the CRAN teams controls the env vars on the CRAN servers, but not 
>on a server a user might use. And a user is typically unaware that a package 
>uses multithreading.
>R users are typically not developers with a lot of insight in computer 
>science. Most R users I know would not even know how to set an env var.
>
>So why do you ecxpect your users to set an appropriate OMP_THREAD_LIMIT? 
>Particularly when they aim at parallelization, they have to set it to 1.
>I advocate not only to limit the number of cores for CRAN but also (and 
>inparticular)  the default! Something we cannot check easily.
>
>
>An alternative would be to teach R to set OMP_THREAD_LIMIT=1 locally by 
>default and a mechanism to change that for users.
>
>Best,
>Uwe Ligges
>
>
>> 
>> I would vote for explicitly addressing this (rhetorical?) question to the 
>> CRAN server administrators...
>> 
>> On August 23, 2023 6:31:01 AM PDT, Uwe Ligges 
>>  wrote:
>>> I (any many collegues here) have been caught several times by the following 
>>> example:
>>> 
>>> 1. did something in parallel on a cluster, set up via 
>>> parallel::makeCluster().
>>> 2. e.g. allocated 20 cores and got them on one single machine
>>> 3. ran some code in parallel via parLapply()
>>> 
>>> Bang! 400 threads;
>>> So I have started 20 parallel processes, each of which is using the 
>>> automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted by 
>>> the cluster to 20 (rather than 1).
>>> 
>>> Hence, I really believe a default should always be small, not only in 
>>> examples and tests, but generally. And people who aim for more should be 
>>> able to increase the defaults.
>>> 
>>> Do you believe a software that auto-occupies a 96 core machines with 96 
>>> threads by default is sensible?
>>> 
>>> Best,
>>> Uwe Ligges
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 21.08.2023 21:59, Berry Boessenkool wrote:
>>>> 
>>>> If you add that to each exported function, isn't that a lot of code to 
>>>> read + maintain?
>>>> Also, it seems like unnecessary computational overhead.
>>>>   From a software design point of view, it might be nicer to set that in 
>>>> the examples + tests.
>>>> 
>>>> Regards,
>>>> Berry
>>>> 
>>>> 
>>>> From: R-package-devel  on behalf of 
>>>> Scott Ritchie 
>>>> Sent: Monday, August 21, 2023 19:23
>>>> To: Dirk Eddelbuettel 
>>>> Cc: r-package-devel@r-project.org 
>>>> Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian 
>>>> server
>>>> 
>>>> Thanks Dirk and Ivan,
>>>> 
>>>> I took a slightly different work-around of forcing the number of threads to
>>>> 1 when running functions of the test dataset in the package, by adding the
>>>> following to each user facing function:
>>>> 
>>>> ```
>>>> # Check if running on package test_data, and if so, force data.table to
>>>> be
>>>> # single threaded so that we can avoid a NOTE on CRAN submission
>>>> if (isTRUE(all.equal(x, ukbnmr::test_data))) {
>>>>   registered

Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server

[Jeff Newmiller]

To whom are you addressing this question? The OpenMP developers who define the 
missing-OMP_THREAD_LIMIT behaviour and-or supply default config files? The CRAN 
server administrators who set the variable in their site-wide configuration 
intentionally or unintentionally? Or the package authors expected to kludge in 
settings to override those defaults for CRAN testing while not overriding them 
in normal use?

I would vote for explicitly addressing this (rhetorical?) question to the CRAN 
server administrators...

On August 23, 2023 6:31:01 AM PDT, Uwe Ligges  
wrote:
>I (any many collegues here) have been caught several times by the following 
>example:
>
>1. did something in parallel on a cluster, set up via parallel::makeCluster().
>2. e.g. allocated 20 cores and got them on one single machine
>3. ran some code in parallel via parLapply()
>
>Bang! 400 threads;
>So I have started 20 parallel processes, each of which is using the 
>automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted by the 
>cluster to 20 (rather than 1).
>
>Hence, I really believe a default should always be small, not only in examples 
>and tests, but generally. And people who aim for more should be able to 
>increase the defaults.
>
>Do you believe a software that auto-occupies a 96 core machines with 96 
>threads by default is sensible?
>
>Best,
>Uwe Ligges
>
>
>
>
>
>
>On 21.08.2023 21:59, Berry Boessenkool wrote:
>> 
>> If you add that to each exported function, isn't that a lot of code to read 
>> + maintain?
>> Also, it seems like unnecessary computational overhead.
>>  From a software design point of view, it might be nicer to set that in the 
>> examples + tests.
>> 
>> Regards,
>> Berry
>> 
>> 
>> From: R-package-devel  on behalf of 
>> Scott Ritchie 
>> Sent: Monday, August 21, 2023 19:23
>> To: Dirk Eddelbuettel 
>> Cc: r-package-devel@r-project.org 
>> Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian 
>> server
>> 
>> Thanks Dirk and Ivan,
>> 
>> I took a slightly different work-around of forcing the number of threads to
>> 1 when running functions of the test dataset in the package, by adding the
>> following to each user facing function:
>> 
>> ```
>># Check if running on package test_data, and if so, force data.table to
>> be
>># single threaded so that we can avoid a NOTE on CRAN submission
>>if (isTRUE(all.equal(x, ukbnmr::test_data))) {
>>  registered_threads <- getDTthreads()
>>  setDTthreads(1)
>>  on.exit({ setDTthreads(registered_threads) }) # re-register so no
>> unintended side effects for users
>>}
>> ```
>> (i.e. here x is the input argument to the function)
>> 
>> It took some trial and error to get to pass the CRAN tests; the number of
>> columns in the input data was also contributing to the problem.
>> 
>> Best,
>> 
>> Scott
>> 
>> 
>> On Mon, 21 Aug 2023 at 14:38, Dirk Eddelbuettel  wrote:
>> 
>>> 
>>> On 21 August 2023 at 16:05, Ivan Krylov wrote:
>>> | Dirk is probably right that it's a good idea to have OMP_THREAD_LIMIT=2
>>> | set on the CRAN check machine. Either that, or place the responsibility
>>> | on data.table for setting the right number of threads by default. But
>>> | that's a policy question: should a CRAN package start no more than two
>>> | threads/child processes even if it doesn't know it's running in an
>>> | environment where the CPU time / elapsed time limit is two?
>>> 
>>> Methinks that given this language in the CRAN Repository Policy
>>> 
>>>If running a package uses multiple threads/cores it must never use more
>>>than two simultaneously: the check farm is a shared resource and will
>>>typically be running many checks simultaneously.
>>> 
>>> it would indeed be nice if this variable, and/or equivalent ones, were set.
>>> 
>>> As I mentioned before, I had long added a similar throttle (not for
>>> data.table) in a package I look after (for work, even). So a similar
>>> throttler with optionality is below. I'll add this to my `dang` package
>>> collecting various functions.
>>> 
>>> A usage example follows. It does nothing by default, ensuring 'full power'
>>> but reflects the minimum of two possible options, or an explicit count:
>>> 
>>>  > dang::limitDataTableCores(verbose=TRUE)
>>>  Limiting data.table to '12'.
>>>  > Sys.setenv("OMP_THREAD_LIMIT"=3);
>>> dang::limitDataTableCores(verbose=TRUE)
>>>  Limiting data.table to '3'.
>>>  > options(Ncpus=2); dang::limitDataTableCores(verbose=TRUE)
>>>  Limiting data.table to '2'.
>>>  > dang::limitDataTableCores(1, verbose=TRUE)
>>>  Limiting data.table to '1'.
>>>  >
>>> 
>>> That makes it, in my eyes, preferable to any unconditional 'always pick 1
>>> thread'.
>>> 
>>> Dirk
>>> 
>>> 
>>> ##' Set threads for data.table respecting possible local settings
>>> ##'
>>> ##' This function set the number of threads \pkg{data.table} will use
>>> ##' while reflecting two possible 

Re: [R-pkg-devel] Package Load fails to find 3rd Party DLL

[Jeff Newmiller]

Use of precompiled code is not allowed in CRAN. This looks like your package 
needs to be distributed elsewhere... e.g. via GitHub.

On July 12, 2023 6:41:11 AM PDT, Russell Almond  
wrote:
>I have an R package (RNetica available at 
>https://ralmond.r-universe.dev/RNetica and 
>https://github.com/ralmond/RNetica) which links to a 3rd party library 
>Netica.dll, so RNetica.dll (built from my C code) calls the 3rd party code.
>
>The config.win script downloads Netica.dll and moves it into the 
>libs/x64 directory, where it should get loaded when RNetica.dll is 
>loaded.  However this is not happening:
>
>Here is the relevant portion of the build log (build is on R-universe, 
>but I think it is the same script as CRAN):
>
>```
>
>cp 
>"/d/a/ralmond/ralmond/RNETIC~1.RCH/00_PKG~1/RNetica/src/Netica/Netica_API_5
>10/lib64/Netica.dll" 
>"D:/a/ralmond/ralmond/RNetica.Rcheck/00LOCK-RNetica/00new/R
>Netica/libs/x64"
>   cp 
>"/d/a/ralmond/ralmond/RNETIC~1.RCH/00_PKG~1/RNetica/src/Netica/Netica_API_5
>10/lib64/Netica.lib" 
>"D:/a/ralmond/ralmond/RNetica.Rcheck/00LOCK-RNetica/00new/R
>Netica/libs/x64"
>   C:\rtools43\x86_64-w64-mingw32.static.posix\bin\nm.exe: 'NeticaDLL': 
>No such f
>ile
>   gcc -shared -s -static-libgcc -o RNetica.dll tmp.def Cases.o 
>Continuous.o Edge
>s.o Experience.o Inference.o Networks.o Node.o Random.o Registration.o 
>Session.o
>  -L. 
>-LD:/a/ralmond/ralmond/RNetica.Rcheck/00LOCK-RNetica/00new/RNetica/libs/x64
>  -lNetica -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 
>-LC:/rtools43/x8
>6_64-w64-mingw32.static.posix/lib -LC:/R/bin/x64 -lR
>   C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: internal 
>error: aborti
>ng at ../../binutils-2.40/ld/ldlang.c:527 in compare_section
>   C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: please report 
>this bug
>   collect2.exe: error: ld returned 1 exit status
>```
>
>A little bit of searching on the internet, indicates that Windows 
>sometimes reports Dll A not found when Dll A needs Dll B and it can't 
>find B.
>
>This used to work under older versions of R and the tool chain and I 
>don't think I've changed anything related to the C side of the code.
>
>1) Have the paths changed, so I no longer should be moving the (64 bit 
>version of the) 3rd party DLL to `libs/x64`?
>
>2) Is there something that has changed with the mingw tools (nm.exe and 
>ld.exe) which are changing things?
>
>3) Is there a change on how win32 and win64 variants are handled (I have 
>both 32 and 64 bit copies of the 3rd party DLL, I just need to move them 
>to the right places).
>
>Thanks for any enlightenment you can offer,
>
>     --Russell Almond
>
>
>
>

-- 
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] Public URLs for help for versions of base packages

[Jeff Newmiller]

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  
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  wrote:
>
>> On Thu, 29 Jun 2023 20:22:47 +0100
>> David Hugh-Jones  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
>>
>> ...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 broke with R 4.3.0

[Jeff Newmiller]

if (any(c( "alaska", "hawaii") %in% zoom)){}

On June 27, 2023 9:11:09 AM PDT, "Göran Broström"  wrote:
>
>
>Den 2023-06-27 kl. 17:17, skrev Göran Broström:
>> If(zoom %in% c(“alaska”,  “hawaii”)…
>
>Wrong, maybe
>
>if (("alaska" %in% zoom) || ("hawaii" %in% zoom)){}
>
>
>> 
>> Göran
>> 
>>> 27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:
>>> 
>>> It appears that my R package choroplethr broke due to this change in R
>>> 4.3.0:
>>> 
>>> CHANGES IN R 4.3.0:
>>> 
>>> SIGNIFICANT USER-VISIBLE CHANGES:
>>> 
>>> Calling && or || with LHS or (if evaluated) RHS of length greater than one
>>> is now always an error, with a report of the form
>>> 
>>> 'length = 4' in coercion to 'logical(1)'
>>> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
>>> 
>>> The specific line which broke is this:
>>> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
>>> 
>>> The bug can be reproduced like this:
>>> 
>>> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
>>>   "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
>>>   "tennessee", "virginia", "california", "delaware", "west virginia",
>>>   "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
>>>   "kansas", "maryland", "colorado", "new jersey", "north carolina",
>>>   "south carolina", "washington", "vermont", "utah", "iowa",
>>> "kentucky",
>>>   "maine", "massachusetts", "connecticut", "michigan", "missouri",
>>>   "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
>>>   "rhode island", "south dakota", "district of columbia", "texas",
>>>   "georgia", "hawaii", "illinois", "indiana")
>>> 
>>> if (zoom == "alaska" || zoom == "hawaii") {}
>>> Error in zoom == "alaska" || zoom == "hawaii" :
>>>   'length = 51' in coercion to 'logical(1)'
>>> 
>>> I have two questions:
>>> 
>>> 1. Can someone explain why this change was introduced to the language?
>>> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
>>> code?
>>> 
>>> I came up with two solutions that work. The first checks whether zoom is of
>>> length 1:
>>> 
>>> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }
>>> 
>>> The second keeps the vector recycling, but then uses all to coerce the
>>> vector to be a single value. In retrospect, I think I likely assumed that
>>> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
>>> code many years ago, so I can't be sure!):
>>> 
>>> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
>>> 
>>> Thanks in advance.
>>> 
>>> Ari
>>> 
>>> [[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

-- 
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] Problems with devtools::build() in R

[Jeff Newmiller]

Your mistake is confusing a tool designed for _iterative development_ for a 
tool designed for _delivery_.

Use R CMD build the way WRE says you should.

On May 16, 2023 9:07:05 AM PDT, Jarrett Phillips  
wrote:
>Hi All,
>
>I'm trying to generate a `tar.gz` file on a Mac for R package submission to
>CRAN but am having issues.
>
>I'm using `devtools`, specifically `build()` and `install()`.
>
>My package relies on compiled code via `Rcpp/RcppArmadillo`.
>
>build("HACSim_OO")
>── R CMD build
>─
>✔  checking for file ‘/Users/jarrettphillips/Desktop/HAC
>simulation/HACSim_OO/DESCRIPTION’ ...
>─  preparing ‘HACSim’:
>✔  checking DESCRIPTION meta-information ...
>─  cleaning src
>─  installing the package to process help pages
> ---
>─  installing *source* package ‘HACSim’ ...
>   ** using staged installation
>   ** libs
>   clang++ -arch arm64 -std=gnu++11 -
>I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
>-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
>-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2  -Wall
>-pedantic -fdiagnostics-color=always -c RcppExports.cpp -o RcppExports.o
>   clang++ -arch arm64 -std=gnu++11
>-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
>-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
>-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2  -Wall
>-pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
>   clang++ -arch arm64 -std=gnu++11 -dynamiclib
>-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
>-multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib
>-L/opt/R/arm64/lib -o HACSim.so RcppExports.o accumulate.o
>-L/Library/Frameworks/R.framework/Resources/lib -lRlapack
>-L/Library/Frameworks/R.framework/Resources/lib -lRblas
>-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
>-L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath
>-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
>-Wl,CoreFoundation
>   ld: warning: directory not found for option
>'-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
>   ld: warning: directory not found for option
>'-L/opt/R/arm64/gfortran/lib'
>   ld: library not found for -lgfortran
>   clang: error: linker command failed with exit code 1 (use -v to see
>invocation)
>   make: *** [HACSim.so] Error 1
>   ERROR: compilation failed for package ‘HACSim’
>─  removing
>‘/private/var/folders/r4/xm5blbcd2tn06tjv00lm1c78gn/T/RtmpN4uaYR/Rinstdf4219594de/HACSim’
> ---
>ERROR: package installation failed
>Error in `(function (command = NULL, args = character(),
>error_on_status = TRUE, …`:
>! System command 'R' failed
> ---
> Exit status: 1
> stdout & stderr: 
> ---
>Type .Last.error to see the more details.
>
>`clang` is installed (since I am able to run the code within my package)
>and I've verified by typing `gcc` in the Mac Terminal. I've also installed
>`Homebrew` and `gfortran`, verifying via typing in the Terminal.
>
>Any idea on what's going on how to fix the issue(s)?
>
>Thanks!
>
>Cheers,
>
>Jarrett
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

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

[Jeff Newmiller]

Long build time for vignettes?

On January 22, 2023 10:51:30 AM PST, 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
>
>

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

[Jeff Newmiller]

Isn't the whole purpose of creating a new package to introduce new algorithms? 
That there is a history related to the modelsummary package is fine, but I 
think the request is for references to published discussion of why modelsummary 
needed to be augmented with new algorithms. It seems to me that other than 
mentioning that this package augments modelsummary that issue is moot... rather 
you need to expand on why this package is relevant.

On December 16, 2022 10:06:44 AM PST, Michael Topper  
wrote:
>Hello all,
>
>I just received feedback from my first CRAN submission. Currently, I am a
>little confused as to one point of the feedback which reads:
>
>
>
>
>
>
>
>
>
>*If there are references describing the methods in your package, pleaseadd
>these in the description field of your DESCRIPTION file in the formauthors
>(year) authors (year) authors (year, ISBN:...)or if
>those are not available: with no space after 'doi:', 'arXiv:',
>'https:' and angle brackets forauto-linking. (If you want to add a title as
>well please put it inquotes: "Title")*
>
>For some background:
>
>   - My package is named panelsummary. The link to the github can be found
>   here: https://github.com/michaeltopper1/panelsummary
>   - My package inherits some documentation of some of the parameters from
>   the package modelsummary
>   . In particular, two
>   of my functions (panelsummary::panelsummary and
>   panelsummary::panelsummary_raw) share a couple of the same arguments as
>   modelsummary::modelsummary. I used roxygen2 (@inherits) to generate
>   documentation for the shared arguments.
>   - Because of this inherited documentation, I have also included the
>   author/creator of modelsummary as a copyright holder in the DESCRIPTION
>   file with a comment.
>
>
>My confusion:
>
>   - I understand the Description portion of the DESCRIPTION file needs to
>   be edited, but I'm a little confused as to what I am supposed to add and
>   how. Do I need to include a citation to the published paper of
>   modelsummary and describe where I use the documentation? Modelsummary was
>   published in the journal of statistical software and the following was
>   included on the modelsummary release information:
>  - Arel-Bundock, Vincent (2022). “modelsummary: Data and Model
>  Summaries in R.” Journal of Statistical Software, 103(1), 1-23.
>  doi:10.18637/jss.v103.i01 https://doi.org/10.18637/jss.v103.i01.’
>
>What would be most helpful:
>
>   - If there is any other Description file from another package that
>   contains an example of what to do in such a situation, this would be
>   greatly appreciated!
>
>Please let me know if any additional details are needed, and thank you so
>much for your help/time!
>
>Michael
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

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

[Jeff Newmiller]

Educating package authors about the semantics of URLs is not really something 
the CRAN maintainers should have to do. A slash at the end of a URL implies 
different URL construction for relative URLs based on the original one. [1]

I am not sure why you think https is no more secure than http... that is 
exactly why it exists. Again, not the job of CRAN maintainers to explain this 
to you.

It is not appropriate to rely on URL redirection (from deepbionics to github) 
in a package... redirections are extra work and hide the true url from the user 
anyway.

As for having the same URL accepted in one package but rejected in another... 
well, CRAN moderators are not perfect. They try to automate identification of 
issues that have previously caused problems, but maybe they don't catch 
everything every time.

Yes, making software that doesn't break in odd situations is hard. Thank you 
for making an effort, and thank CRAN for remembering all of these mysterious 
problems and warning you to fix things that might only break in situations you 
haven't directly encountered before they puzzle new R users.

[1] 
https://stackoverflow.com/questions/5948659/when-should-i-use-a-trailing-slash-in-my-url

On November 28, 2022 11:19:40 PM PST, "Dr. habil. Michael Thrun" 
 wrote:
>Dear All,
>I got from Uwe the following message after uploading an update of my package 
>“DatabionicSwarm”.  "Found the  following (possibly) invalid URLs: URL:  
>https://www.deepbionics.org (moved to  https://mthrun.github.io/index) From: 
>DESCRIPTION Status: 301 Message: Moved Permanently
>Please change http --> https, add trailing slashes, or follow moved content as 
>appropriate.
>"
> I asked then
>"
>Dear Uwe,
>your request states to either
>Please  change http --> https, add trailing slashes or to  follow moved 
>content as appropriate.
>As it is not  appropriate to follow content, I select the first   choice. the 
>URL is 
>"https://www.deepbionics.org/; 
> which mets both conditions of beeing "https" and 
> having at the end one "/".
>What is the problem?  Please elaborate.
>You already accepted another  package GeneralizedUmatrix today with exactly 
>same 
> url. I really dont understand it. Please be so kind 
> to elabore.”
>
> As an answer I got
>"You are abusig the system! Again: ”
>
>Hence, I have several questions.
>First, do we not communicate with CRAN anymore through the submission 
>procedure of the package? If not, which is the correct line of communication 
>in such a case?
>
>Second, are the answers that we get now fully automatically generated? It 
>would be strange for me to believe that Uwe would provide such an answer to my 
>polite request.
>
>Third, why can I have a CRAN package "DataVisualizations" with this URL 
>online, another one named "GeneralizedUmatrix" uploaded the same day with the 
>same URL, which both are OK, but the URL in "DatabionicSwarm" is not?
>
>Forth, can't we have more clear feedback messages?
>I mean, having in the description the URL "https://www.deepbionics.org/; and 
>getting the feedback "http --> https, add trailing slashes or ... "does not 
>make any sense. Also, could someone please explain why is a "/" at the end of 
>an URL necessary? What is the technical background to this?
>
>Fifth, why do we need https/TLS/SSL? I have to pay a monthly fee for a 
>certificate to apply this to my website so that CRAN accepts my URL - and as 
>far as I can tell, it makes things only more complex but not more secure 
>(e.g., https://www.elektronik-kompendium.de/sites/net/1906041.htm). Or in 
>other words, it seems to me that we are expected to pay to follow the 
>guideline of having a certificate instead of making better code with fewer 
>bugs. I am no security expert, but my baseline in computer science is always 
>if a tool is more complex, then the chances are lower that it works as 
>intended, and the possibilities are higher that it has unintended and 
>potentially risky side effects.
>
>Best Regards
>
>Michael
> 
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Cannot submit package due to false-positive rejection

[Jeff Newmiller]

This is definitely not a false positive. Find a way to not run long calcs 
during the CRAN build. There is no alternative.

One way this can be done is by only running your examples when an environment 
variable of your choosing exists. Since CRAN machines won't configure that 
variable, you can get around this hard requirement.

On October 28, 2022 12:48:44 PM PDT, Ying Li via R-package-devel 
 wrote:
>Hello all,
>
>Our package did not pass the automagical checks when submitted to CRAN. We 
>think the rejection is a false positive, so we �reply-all to that message and 
>explain� as following the official instruction. We provided explanation for 
>all notes in that email (replied to 
>cran-submissi...@r-project.org) but did 
>not receive any message after 9 days.
>
>I am looking for suggestions on what to do in this case: should we continue 
>waiting for CRAN team�s reply? Or is it necessary to eliminate those notes and 
>then submit the package again?
>
>Below are the notes from CRAN teams' auto-check service and our explanation 
>send to CRAN team:
>
>>Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
>>Check: CRAN incoming feasibility, Result: NOTE
>> Maintainer: 'Arindam RoyChoudhury 
>> mailto:arr2...@med.cornell.edu>>'
>
>>  New submission
>
>>  Possibly misspelled words in DESCRIPTION:
>>Peng (17:5)
>>Phylogenetics (17:32)
>>   al (17:13)
>>et (17:10)
>
>> Size of tarball: 14208488 bytes
>
>Explain:  This is a new submission. These words are not misspelled.
>
>>Flavor: r-devel-windows-x86_64
>>Check: examples, Result: NOTE
>>  Examples with CPU (user + system) or elapsed time > 10s
>>   user system elapsed
>>  RDM 40.05   0.89   40.94
>
>Explain:  This is because a large dataset is used in the example. An example 
>with large dataset is necessary, as this package is meant for analyzing large 
>datasets.
>
>
>>Flavor: r-devel-linux-x86_64-debian-gcc
>>Check: examples, Result: NOTE
>> Examples with CPU (user + system) or elapsed time > 5s
>>  user system elapsed
>>  RDM 24.399  0.888  25.289
>
>Explain:  This is because a large dataset is used in the example. An example 
>with large dataset is necessary, as this package is meant for analyzing large 
>datasets.
>
>Any suggestions or comments would be appreciated. Thank you in advance!
>
>Best,
>Ying
>
>
>
>   [[alternative HTML version deleted]]
>

-- 
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] Issue handling datetimes: possible differences between computers

[Jeff Newmiller]

I have no idea how to get readxl::read_excel to import a timestamp column in a 
timezone. It is true that Excel has no concept of timezones, but the data one 
finds there usually came from a text file at some point. Importing as character 
is a feasible strategy, but trying to convince an intermediate user to go to 
that much trouble is a headache when the issue is ignored in the help file.

It is evidently possible to specify a locale input to readr::read_csv, but the 
default behaviour guesses timestamp columns and assumes "UTC", and a file may 
contain data from different timezones (UTC and local civil are a common 
combination). Again, character import and manual conversion are needed.

On October 10, 2022 9:40:42 AM PDT, Hadley Wickham  wrote:
>On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller  wrote:
>>
>> ... which is why tidyverse functions and Python datetime handling irk me so 
>> much.
>>
>> Is tidyverse time handling intrinsically broken? They have a standard 
>> practice of reading time as UTC and then using force_tz to fix the 
>> "mistake". Same as Python.
>
>Can you point to any docs that lead you to this conclusion so we can
>get them fixed? I strongly encourage people to parse date-times in the
>correct time zone; this is why lubridate::ymd_hms() and friends have a
>tz argument.
>
>Hadley
>

-- 
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] Issue handling datetimes: possible differences between computers

[Jeff Newmiller]

... which is why tidyverse functions and Python datetime handling irk me so 
much.

Is tidyverse time handling intrinsically broken? They have a standard practice 
of reading time as UTC and then using force_tz to fix the "mistake". Same as 
Python.

On October 9, 2022 6:57:06 PM PDT, Simon Urbanek  
wrote:
>Alexandre,
>
>it's better to parse the timestamp in correct timezone:
>
>> foo = as.POSIXlt("2021-10-01", "UTC")
>> as.POSIXct(as.character(foo), "Europe/Berlin")
>[1] "2021-10-01 CEST"
>
>The issue stems from the fact that you are pretending like your timestamp is 
>UTC (which it is not) while you want to interpret the same values in a 
>different time zone. The DST flags varies depending on the day (due to DST 
>being 0 or 1 depending on the date) and POSIXlt does not have that information 
>since you only attached the time zone without updating it:
>
>> str(unclass(as.POSIXlt(foo, "Europe/Berlin")))
>List of 9
> $ sec  : num 0
> $ min  : int 0
> $ hour : int 0
> $ mday : int 1
> $ mon  : int 9
> $ year : int 121
> $ wday : int 5
> $ yday : int 273
> $ isdst: int 0
> - attr(*, "tzone")= chr "Europe/Berlin"
>
>note that isdst is 0 from the UTC entry (which doesn't have DST) even though 
>that date is actually DST in CEST. Compare that to the correctly parsed 
>POSIXlt:
>
>> str(unclass(as.POSIXlt(as.character(foo), "Europe/Berlin")))
>List of 11
> $ sec   : num 0
> $ min   : int 0
> $ hour  : int 0
> $ mday  : int 1
> $ mon   : int 9
> $ year  : int 121
> $ wday  : int 5
> $ yday  : int 273
> $ isdst : int 1
> $ zone  : chr "CEST"
> $ gmtoff: int NA
> - attr(*, "tzone")= chr "Europe/Berlin"
>
>where isdst is 1 since it is indeed the DST. The OS difference seems to be 
>that Linux respects the isdst information from POSIXlt while Windows and macOS 
>ignores it. This behavior is documented: 
>
> At all other times ‘isdst’ can be deduced from the
> first six values, but the behaviour if it is set incorrectly is
> platform-dependent.
>
>You can re-set isdst to -1 to make sure R will try to determine it:
>
>> foo$isdst = -1L
>> as.POSIXct(foo, "Europe/Berlin")
>[1] "2021-10-01 CEST"
>
>So, generally, you cannot simply change the time zone in POSIXlt - don't 
>pretend the time is in UTC if it's not, you have to re-parse or re-compute the 
>timestamps for it to be reliable or else the DST flag will be wrong.
>
>Cheers,
>Simon
>
>
>> On 10/10/2022, at 1:14 AM, Alexandre Courtiol  
>> wrote:
>> 
>> Hi R pkg developers,
>> 
>> We are facing a datetime handling issue which manifests itself in a
>> package we are working on.
>> 
>> In context, we noticed that reading datetime info from an excel file
>> resulted in different data depending on the computer we used.
>> 
>> We are aware that timezone and regional settings are general sources
>> of troubles, but the code we are using was trying to circumvent this.
>> We went only as far as figuring out that the issue happens when
>> converting a POSIXlt into a POSIXct.
>> 
>> Please find below, a minimal reproducible example where `foo` is
>> converted to `bar` on two different computers.
>> `foo` is a POSIXlt with a defined time zone and upon conversion to a
>> POSIXct, despite using a set time zone, we end up with `bar` being
>> different on Linux and on a Windows machine.
>> 
>> We noticed that the difference emerges from the system call
>> `.Internal(as.POSIXct())` within `as.POSIXct.POSIXlt()`.
>> We also noticed that the internal function in R actually calls
>> getenv("TZ") within C, which is probably what explains where the
>> difference comes from.
>> 
>> Such a behaviour is probably expected and not a bug, but what would be
>> the strategy to convert a POSIXlt into a POSIXct that would not be
>> machine dependent?
>> 
>> We finally noticed that depending on the datetime used as a starting
>> point and on the time zone used when calling `as.POSIXct()`, we
>> sometimes have a difference between computers and sometimes not...
>> which adds to our puzzlement.
>> 
>> Many thanks.
>> Alex & Liam
>> 
>> 
>> ``` r
>> ## On Linux
>> foo <- structure(list(sec = 0, min = 0L, hour = 0L, mday = 1L, mon =
>> 9L, year = 121L, wday = 5L, yday = 273L, isdst = 0L),
>> class = c("POSIXlt", "POSIXt"), tzone = "UTC")
>> 
>> bar <- as.POSIXct(foo, tz = "Europe/Berlin")
>> 
>> bar
>> #> [1] "2021-10-01 01:00:00 CEST"
>> 
>> dput(bar)
>> #> structure(1633042800, class = c("POSIXct", "POSIXt"), tzone =
>> "Europe/Berlin")
>> ```
>> 
>> ``` r
>> ## On Windows
>> foo <- structure(list(sec = 0, min = 0L, hour = 0L, mday = 1L, mon =
>> 9L, year = 121L, wday = 5L, yday = 273L, isdst = 0L),
>> class = c("POSIXlt", "POSIXt"), tzone = "UTC")
>> 
>> bar <- as.POSIXct(foo, tz = "Europe/Berlin")
>> 
>> bar
>> #> [1] "2021-10-01 CEST"
>> 
>> dput(bar)
>> structure(1633046400, class = c("POSIXct", "POSIXt"), tzone = 
>> "Europe/Berlin")
>> ```
>> 
>> -- 
>> Alexandre Courtiol, www.datazoogang.de
>> 
>> __
>> 

Re: [R-pkg-devel] How to decrease time to import files in xlsx format?

[Jeff Newmiller]

It looks like you are reading directly from URLs? How do you know the delay is 
not network I/O delay?

Parallel computation is not a panacea. It allows tasks _that are CPU-bound_ to 
get through the CPU-intensive work faster. You need to be certain that your 
tasks actually can benefit from parallelism before using it... there is a 
significant overhead and added complexity to using parallel processing that 
will lead to SLOWER processing if mis-used.

On October 4, 2022 11:29:54 AM PDT, Igor L  wrote:
>Hello all,
>
>I'm developing an R package that basically downloads, imports, cleans and
>merges nine files in xlsx format updated monthly from a public institution.
>
>The problem is that importing files in xlsx format is time consuming.
>
>My initial idea was to parallelize the execution of the read_xlsx function
>according to the number of cores in the user's processor, but apparently it
>didn't make much difference, since when trying to parallelize it the
>execution time went from 185.89 to 184.12 seconds:
>
># not parallelized code
>y <- purrr::map_dfr(paste0(dir.temp, '/', lista.arquivos.locais),
>   readxl::read_excel, sheet = 1, skip = 4, col_types =
>c(rep('text', 30)))
>
># parallelized code
>plan(strategy = future::multicore(workers = 4))
>y <- furrr::future_map_dfr(paste0(dir.temp, '/', lista.arquivos.locais),
> readxl::read_excel, sheet = 1, skip = 4,
>col_types = c(rep('text', 30)))
>
> Any suggestions to reduce the import processing time?
>
>Thanks in advance!
>

-- 
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] Inquiry

[Jeff Newmiller]

If you haven't settled on exactly which approach you want to use in 
accomplishing the main goals of your exported package functions, then hiding 
the gory details can make it easier to tell people later to sod off when you 
decide those gory details functions should act different or use different 
function signatures.

Anyone regularly using ::: earns the lack of reproducibility they get.

On September 27, 2022 6:37:28 PM PDT, Rolf Turner  
wrote:
>
>On Tue, 27 Sep 2022 07:43:03 +
>Georgi Boshnakov  wrote:
>
>> >...functions, that are not meant to be called directly by users,
>> >should be documented in a file named -internal.Rd.  
>> 
>> This is one option, convenient in the use-case of the question. But
>> why export a function that you actively don't want the users to know
>> about?
>
>
>
>Why would you not want users to know about functions?  This strikes me
>as being overly authoritarian. Of course, to export or not to export
>is the choice of the package author.  It is also sensible to try to
>protect users from shooting themselves in the foot.  However if they
>really want to shoot themselves in the foot, that's their call.
>
>Anyway, users can always get at non-exported functions using ":::".
>
>cheers,
>
>Rolf Turner
>

-- 
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] Rlang and Code Evalutation Within Aesthetics

[Jeff Newmiller]

Things like sensible legends are also impeded by using complex expressions in 
aesthetics mappings, so call it a workaround if you like but creating the data 
frame the way it should be _before_ giving it to ggplot has always been 
recommended.

On April 30, 2022 5:09:51 AM PDT, Duncan Murdoch  
wrote:
>On 30/04/2022 8:00 a.m., Dario Strbenac wrote:
>> Good day,
>> 
>> I am troubled understanding why the following example doesn't work:
>> 
>>> characteristicsList
>> $x
>> `Classifier Name`
>>> ggplot2::aes(fill = if(TRUE) NULL else 
>>> !!rlang::sym(characteristicsList[["fillColour"]]))
>> Error in `rlang::sym()`:
>> ! Can't convert NULL to a symbol.
>>> rlang::last_error()
>> 10. rlang::sym(characteristicsList[["fillColour"]])
>> 
>> but the following does work without error:
>> 
>>> if(TRUE) NULL else !!rlang::sym(characteristicsList[["fillColour"]])
>> NULL # It is desirably avoiding the else part.
>> 
>> The first example seems to be evaluating the else part, even though the if 
>> condition is true.
>> 
>> The overall aim is to allow the end-user to specify a named list of 
>> appearance-modifying parameters, and for the function to create a ggplot 
>> with them, without being bamboozled if the end-user's list doesn't contain 
>> the specification for fill colour variable name or line colour variable name 
>> (like the list in the example above does not have). Thanks in advance for 
>> any suggested reading.
>
>I'm pretty sure this isn't the right place to ask about ggplot2, but that 
>looks like a bug to me.
>
>Duncan Murdoch
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] handling of byte-order-mark on r-devel-linux-x86_64-debian-clang machine

[Jeff Newmiller]

Thanks to the ubiquity of Excel and its misguided inclusion of BOM codes in its 
UTF-8 CSV format, this optimism about encoding being a corner case seems 
premature. There are actually multiple options in Excel for writing CSV files, 
and only one of them (not the first one fortunately) has this "feature", but I 
(and various beginners I end up helping) seem to encounter these silly files 
far more frequently than seems reasonable.

On April 5, 2022 11:20:37 AM PDT, Tomas Kalibera  
wrote:
>
>On 3/28/22 13:16, Ivan Krylov wrote:
>> On Mon, 28 Mar 2022 09:54:57 +0200
>> Tomas Kalibera  wrote:
>>
>>> Could you please clarify which part you found somewhat confusing,
>>> could that be improved?
>> Perhaps "somewhat confusing" is an overstatement, sorry about that. All
>> the information is already there in both ?file and ?readLines, it just
>> requires a bit of thought to understand it.
>>
 When reading from a text connection, the connections code, after
 re-encoding based on the ‘encoding’ argument, returns text that is
 assumed to be in native encoding; an encoding mark is only added by
 functions that read from the connection, so e.g.  ‘readLines’ can
 be instructed to mark the text as ‘"UTF-8"’ or ‘"latin1"’, but
 ‘readLines’ does no further conversion.  To allow reading text in
 ‘"UTF-8"’ on a system that cannot represent all such characters in
 native encoding (currently only Windows), a connection can be
 internally configured to return the read text in UTF-8 even though
 it is not the native encoding; currently ‘readLines’ and ‘scan’ use
 this feature when given a connection that is not yet open and, when
 using the feature, they unconditionally mark the text as ‘"UTF-8"’.
>> The paragraph starts by telling the user that the text is decoded into
>> the native encoding, then tells about marking the encoding (which is
>> counter-productive when decoding arbitrarily-encoded text into native
>> encoding) and only then presents the exception to the native encoding
>> output rule (decoding into UTF-8). If I'm trying to read a
>> CP1252-encoded file on a Windows 7 machine with CP1251 as the session
>> encoding, I might get confused by the mention of encoding mark between
>> the parts that are important to me.
>>
>> It could be an improvement to mention that exception closer to the
>> first point of the paragraph and, perhaps, to split the "encoding mark"
>> part from the "text connection decoding" part:
>>
 Functions that read from the connection can add an encoding mark
 to the returned text. For example, ‘readLines’ can be instructed
 to mark the text as ‘"UTF-8"’ or ‘"latin1"’, but does no further
 conversion.

 When given a connection that is not yet open and has a non-default
 ‘encoding’ argument, ‘readLines’ and ‘scan’ internally configure the
 connection to read text in UTF-8. Otherwise, the text after decoding
 is assumed to be in native encoding.
>> (Maybe this is omitting too much and should be expanded.)
>>
>> It could also be helpful to mention the fact that the encoding argument
>> to readLines() can be ignored right in the description of that
>> argument, inviting the user to read the Details section for more
>> information.
>
>Thanks for the suggestions, I've rewritten the paragraphs, biasing 
>towards users who have UTF-8 as the native encoding as this is going to 
>be the majority. These users should not have to worry much about the 
>encoding marks anymore, nor about the internal UTF-8 mode of the 
>connections code. But the level of detail I think needs to remain as 
>long as these features are supported - the level of detail is based on 
>numerous questions and bug reports.
>
>Best
>Tomas
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Is using global assignment in package tests allowed?

[Jeff Newmiller]

I don't know the answer to your question, but "beyond my ken" doesn't sound 
like a very convincing reason. Mucking with any environment that isn't yours is 
asking for trouble... the behavior you depend on today may come into conflict 
with the code you are coordinating with when you least expect it.

Is your code in a public version control repo?

On January 27, 2022 6:55:49 AM PST, James Pustejovsky  wrote:
>Hello,
>
>I'm writing unit tests using testthat for a package that we want to submit
>to CRAN. Because of some aspect of how testthat works (which is beyond my
>ken), I have only been able to get my tests to work by using global
>assignment (<<-) to create some objects on which the tests are then run.
>However, per CRAN policy: "Packages should not modify the global
>environment (user’s workspace)."
>
>Does anyone know whether this policy applies to all code within the
>package, including unit tests? Or does it apply just to the code and
>functions in /R?
>Or to all code that is executed as part of checking the package (i.e., code
>that is never run can use <<-)?
>
>James
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] socketConnection, delay when reading from

[Jeff Newmiller]

Google?

https://developer.r-project.org/Blog/public/2020/03/17/socket-connections-update/

https://www.digitalocean.com/community/tutorials/understanding-sockets

https://developer.ibm.com/tutorials/l-sockpit/

On November 27, 2021 2:36:48 PM PST, Ben Engbers  wrote:
>Hi,
>
>Looks promising! Where can I find more information or tutorials about 
>psock or parallel computing?
>
>Best,
>Ben
>
>Op 27-11-2021 om 20:19 schreef Tomas Kalibera:
>> On 11/27/21 8:05 PM, Tomas Kalibera wrote:
>> 
>> This is an extended demo with socketSelect() used to wait on the client 
>> for some data to be available, to avoid consuming too much CPU by 
>> polling. To be pasted into two R sessions running on the same computer.
>> You would have to replace the function done() with something figuring 
>> out from the data whether it is complete or not, based on the protocol.
>> 
>> Best
>> Tomas
>> 
>> 
>> # the client
>> 
>> con2 <- socketConnection("localhost", port = 6011, open = "rb")
>> cat("Connected...\n")
>> total <- 0
>> 
>> done <- function(n) {
>>    n >= 2e8
>> }
>> 
>> while(!done(total)) {
>>     cat("Waiting for data to become ready...\n")
>>     socketSelect(list(con2))
>>     cat("Reading data...\n")
>>     r <- readBin(con2, "raw", 1024)
>>     total <- total + length(r)
>>     cat("Read", length(r), "bytes (total ", total, ").\n")
>> }
>> close(con2)
>> 
>> # the server
>> 
>> n <- 1e8
>> w <- as.raw(runif(n, 0, 255))
>> con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
>> open="a+b")
>> cat("Connected...\n")
>> writeBin(w, con1)
>> cat("Sent data the first time, sleeping...\n")
>> Sys.sleep(10)
>> cat("Sending data the second time...\n")
>> writeBin(w, con1)
>> cat("Data sent to client...\n")
>> close(con1)
>> 
>>>
>>> Best
>>> Tomas
>>>
>>> # the client
>>>
>>> con2 <- socketConnection("localhost", port = 6011, open = "rb")
>>> cat("Connected...\n")
>>> total <- 0
>>>
>>> done <- function(n) {
>>>   n >= 1e8
>>> }
>>>
>>> while(!done(total)) {
>>>    r <- readBin(con2, "raw", 1024)
>>>    total <- total + length(r)
>>>    cat("Read", length(r), "bytes (total ", total, ").\n")
>>> }
>>> close(con2)
>>>
>>> # the server
>>>
>>> n <- 1e8
>>> w <- as.raw(runif(n, 0, 255))
>>> con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
>>> open="a+b")
>>> cat("Connected...\n")
>>> writeBin(w, con1)
>>> cat("Data sent to client...\n")
>>> close(con1)
>>>

 Ben

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

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] socketConnection, delay when reading from

[Jeff Newmiller]

Maybe time to learn it. At least to assemble complete messages.

That said, the design of this protocol is intrinsically inefficient. Maybe they 
will upgrade if the software gets popular.

On November 27, 2021 8:24:36 AM PST, Ben Engbers  
wrote:
>Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
>> This is a null-terminated message protocol [1]. It has to be processed one 
>> byte at a time.
>> 
>> [1] https://docs.basex.org/wiki/Server_Protocol
>> 
>The message may contain embedded 0x00's. To distinguish these embedded 
>0x00's (and 0xFF's) from a terminating 0x00, embedded 0x00's and 0xFFare 
>prefixed with a 0xFF byte. This means that when you process one byte at 
>a time you have to perform a check on every byte. This results in 
>totally unacceptable response times (My first version of this client was 
>based on this approach)
>
>The only alternative solution I can think off is to use C++ to create a 
>socket and a function that reads from the socket. But since I have 
>hardly any experience with C++ programming nor using the rcpp package
>
>Ben

-- 
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] socketConnection, delay when reading from

[Jeff Newmiller]

This is a null-terminated message protocol [1]. It has to be processed one byte 
at a time.

[1] https://docs.basex.org/wiki/Server_Protocol

On November 27, 2021 7:45:31 AM PST, Gabor Grothendieck 
 wrote:
>Whether the length is variable or not isn't relevant. The point is
>whether the message is prefaced by a length or command from which the
>length can be derived.  Maybe it is not and you will have to rely on
>inefficient methods but in many cases protocols are designed to avoid
>such problems.
>
>On Sat, Nov 27, 2021 at 9:40 AM Ben Engbers  wrote:
>>
>> No, according to the specification the minimal number of bytes that is
>> returned is 2. There is no maximum. (When querying a database you never
>> know on forehand how many records match the query so by definition you
>> can't calculate the size of the message).
>>
>> In some C, C++ or Java-code I found on internet, it was possible to
>> change the timeout settings so that there would be no delay. Of course
>> this would have as consequence that in your code you have to deal with
>> the possibility that the message has not been completely returned.
>>
>> In R you can set the timeout to 0 but that results in errors (at least
>> on Windows)
>>
>> Op 27-11-2021 om 14:57 schreef Gabor Grothendieck:
>> > Does the message start with a length or a command whose argument length is 
>> > known
>> > depending on the particular command?
>> > If so first read the length or command and from that the length of the
>> > remainder of
>> > the message can be determined.
>> >
>> > On Sat, Nov 27, 2021 at 4:09 AM Ben Engbers  
>> > wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> I have been working on a R-client for the BaseX XML-database and version
>> >> 0.9.2 is nearly finished (submitting version 0.9.0 was rejected by CRAN).
>> >> Version 0.3 of RBaseX can be found here
>> >> (https://cran.microsoft.com/web/packages/RBaseX/index.html).
>> >>
>> >> The client-server protocol specifies that the communication between the
>> >> client and the database is based on a socket. The code (below) shows how
>> >> I create that socket.
>> >>
>> >> Writing to the socket works perfect. Reading from the sockets (see
>> >> second codeblock) also produces correct results. The problem however is
>> >> that the timeout, as specified when initializing the socket, causes a 1
>> >> second delay for every read-operation.
>> >> I have experimented a lot with different settings and have been
>> >> searching a lot on internet, but I can't find any method to get rid of
>> >> that delay. (In C or C++ that should be easier but I have never before
>> >> had any need to use those languages).
>> >> The very first version of my client used a block-size of 1 when reading.
>> >> That gave acceptable response times for small query-results but reading
>> >> large responses from the database took very long time.
>> >>
>> >> Do you have any suggestions on how to cope with this problem?
>> >>
>> >> Ben Engbers
>> >>
>> >> -
>> >>   CreateSocket = function(host, port = 1984L, username, password) {
>> >> tryCatch(
>> >>   {conn <- private$conn <- socketConnection(
>> >> host = "localhost", port,
>> >> open = "w+b", server = FALSE, blocking = TRUE, encoding =
>> >> "UTF-8", timeout = 1)
>> >>   }, error = function(e) {
>> >> stop("Cannot open the connection")
>> >>   }
>> >> )
>> >>
>> >> -
>> >>
>> >> readBin_ <- function(conn) {
>> >> chars_read <- raw(0)
>> >> rd <- readBin(conn, what = "raw", 1024)
>> >> while(length(rd) == 1024) {
>> >>   chars_read <- c(chars_read, rd)
>> >>   rd <- readBin(conn, "raw", 1024)
>> >>   }
>> >> if (length(rd) > 0) chars_read <- c(chars_read, rd)
>> >> return(chars_read)
>> >> }
>> >>
>> >> __
>> >> R-package-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>> >
>> >
>>
>
>

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Inconsistent available package dependencies

[Jeff Newmiller]

You should ALWAYS build with the latest stable AND the latest development 
versions of R before submitting.

On November 15, 2021 6:33:12 PM PST, Michael Hellstern  wrote:
>Hi all,
>
>I maintain a package (netgsa) that has been on CRAN since september 2021
>and recently got an email about CRAN check failures. There are 2 errors and
>1 warning. The failures are listed here:
>https://cran.r-project.org/web/checks/check_results_netgsa.html.
>
>The failures are a result of Bioconductor packages. Both errors are about
>package dependencies not being available (org.Hs.eg.db and/or ndexr) while
>the warning comes from the vignette building failing which is caused by an
>error in the graphite package. I checked and these packages were and still
>are available on Bioconductor. The errors occurred on macOS 10.13.6. While
>not exactly the same OS, I ran R CMD check --as-cran on my macOS 10.15.7
>and did not get any errors or warnings. It seems odd that I would get a
>package dependency availability error for only 2 flavors and that I would
>not be able to reproduce this on a similar OS.
>
>I searched online but have not found anything useful. I built the package
>under R 4.0.2 which is now a little dated so am wondering if it is related
>to this? Do I need to rebuild using the most recent version of R? Any
>advice on how to resolve this would be greatly appreciated!
>
>Best,
>
>Mike
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

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

[Jeff Newmiller]

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.

On October 9, 2021 7:34:55 AM PDT, Vladimir Dergachev  
wrote:
>
>
>On Sat, 9 Oct 2021, Ivan Krylov wrote:
>
>> В Thu, 7 Oct 2021 21:58:08 -0400 (EDT)
>> Vladimir Dergachev  пишет:
>>
>>>* My understanding from reading documentation and source code is
>>> that there is no dedicated support in R yet, but there are packages
>>> that use multithreading. Are there any plans for multithreading
>>> support in future R versions ?
>>
>> Shared memory multithreading is hard to get right in a memory-safe
>> language (e.g. R), but there's the parallel package, which is a part of
>> base R, which offers process-based parallelism and may run your code on
>> multiple machines at the same time. There's no communication _between_
>> these machines, though. (But I think there's an MPI package on CRAN.)
>
>Well, the way I planned to use multitheading is to speedup processing of 
>very large vectors, so one does not have to wait seconds for the command 
>to return. Same could be done for many built-in R primitives.
>
>>
>>>* pthread or openmp ? I am particularly concerned about
>>> interaction with other packages. I have seen that using pthread and
>>> openmp libraries simultaneously can result in incorrectly pinned
>>> threads.
>>
>> pthreads-based code could be harder to run on Windows (which is a
>> first-class platform for R, expected to be supported by most packages).
>
>Gábor Csárdi pointed out that R is compiled with mingw on Windows and 
>has pthread support - something I did not know either.
>
>> OpenMP should be cross-platform, but Apple compilers are sometimes
>> lacking; the latest Apple likely has been solved since I've heard about
>> it. If your problem can be made embarrassingly parallel, you're welcome
>> to use the parallel package.
>
>I used parallel before, it is very nice, but R-level only. I am looking 
>for something to speedup response of individual package functions so they 
>themselves can be used of part of more complicated code.
>
>>
>>>* control of maximum number of threads. One can default to openmp
>>> environment variable, but these might vary between openmp
>>> implementations.
>>
>> Moreover, CRAN-facing tests aren't allowed to consume more than 200%
>> CPU, so it's a good idea to leave the number of workers in control of
>> the user. According to a reference guide I got from openmp.org, OpenMP
>> implementations are expected to understand omp_set_num_threads() and
>> the OMP_NUM_THREADS environment variable.
>
>Oh, this would never be run through CRAN tests, it is meant for data that 
>is too big for CRAN.
>
>I seem to remember that the Intel compiler used a different environmental 
>variable, but it could be this was fixed since the last time I used it.
>
>best
>
>Vladimir Dergachev
>
>>
>> -- 
>> Best regards,
>> Ivan
>>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Lists vs Attributes

[Jeff Newmiller]

Duncan has used the phrase "do regular operations on the object" to divide the 
use cases and emphasized that needing the attributes might be important, but he 
did not come out and remind you that if you _do_ perform regular operations on 
it then the outputs of those operations are likely to lose the attributes, 
which is why you might want to avoid relying on them if that is an issue for 
your class use cases.

On October 1, 2021 5:30:56 PM PDT, Duncan Murdoch  
wrote:
>On 01/10/2021 6:14 p.m., Reed A. Cartwright wrote:
>> I'm rethinking the interface of a package, specifically how external binary
>> data is formatted for use in R. I can't decide if it is better to use
>> attributes to store metadata or use a list to hold the main data and
>> metadata as separate elements.
>
>Is the object like some other common R object?  You say it's a 16x16x16 
>array of integers.  Is there an advantage to treating it *exactly* like 
>that, so x[1,2,3] gives an integer?  Then put the other stuff in attributes.
>
>Is it weird enough that x[1,2,3] *needs* to look at the other attributes 
>to know what to return?  Does it never make sense to do regular 
>operations on the object, as though it really was 16x16x16 array of 
>integers?  Then make it a list of different components, and spend the 
>time to define methods to handle any operations that do make sense.
>
>Both approaches are possible; you want to choose the one that is 
>easiest, and most maintainable.
>
>Duncan Murdoch
>
>> 
>> Here's is what one datatype currently looks like:
>> 
>> List of 2
>>   $ : int [1:16, 1:16, 1:16] 9 9 9 9 10 10 1 1 14 14 ...
>>..- attr(*, "palette")=List of 16
>>   [snip]
>>   $ : int [1:16, 1:16, 1:16] 1 1 1 1 1 1 1 1 1 1 ...
>>..- attr(*, "palette")=List of 2
>>   [snip]
>>- attr(*, "offset")= int 3
>> 
>> It's a list of two 16x16x16 arrays of integers. Each array has its own
>> "palette" attribute. Each value in the array refers to a specific element
>> of the palette. In addition the entire list has an offset attribute.
>> 
>> I am considering alternative strategies for representing this data, and I
>> would like any opinions on which style is recommended and why?
>> 
>> List of 3
>>   $ index  :List of 2
>>..$ : int [1:16, 1:16, 1:16] 9 9 9 9 10 10 1 1 14 14 ...
>>..$ : int [1:16, 1:16, 1:16] 1 1 1 1 1 1 1 1 1 1 ...
>>   $ palette:List of 2
>>..$ :List of 16
>>..$ :LIST of 2
>>   $ offset : int 3
>> 
>> or
>> 
>> List of 2
>>   $ :List of 2
>>..$ index: int [1:16, 1:16, 1:16] 9 9 9 9 10 10 1 1 14 14 ...
>>..$ palette:List of 16
>>   $ : List of 2
>>   ..$ index : int [1:16, 1:16, 1:16] 1 1 1 1 1 1 1 1 1 1 ...
>>   ..$ palette : List of 2
>>   - attr(*, "offset")= int 3
>> 
>> Thanks.
>> 
>>  [[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

-- 
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] if statements in NAMESPACE file

[Jeff Newmiller]

Expecting a window handle relevant to the script to exist for the purpose of 
identifying a path seem to be orthogonal problems to me. But Andrew has 
indicated offlist that he has alternate code for other cases only uses this 
technique when appropriate.

I still feel this is too convoluted as a way to identify a path, but if he 
covers all cases then my opinion is just an opinion.

On September 30, 2021 2:34:48 PM PDT, Duncan Murdoch  
wrote:
>On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:
>> What if you are on Windows but running R at the command prompt, or via 
>> cygwin, or in the console window of RStudio?
>> 
>> This seems unstable to me.
>
>Sorry, too much context missing.  What's unstable?
>
>Duncan Murdoch
>
>> 
>> On September 30, 2021 11:52:16 AM PDT, Andrew Simmons  
>> wrote:
>>> Hello,
>>>
>>>
>>> I'm updating my package 'this.path' which is supposed to retrieve the
>>> absolute path of the executing script when called. It's similar to 'here',
>>> except that 'here' constructs paths relative to a project directory,
>>> whereas 'this.path' constructs paths relative to script directories. I was
>>> updating the section where I retrieve the executing script's path while
>>> running from a script open in Rgui for Windows, and I needed
>>> utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles
>>> is a Windows only function, I
>>> would imagine that 'utils' contains a similar line of code as above:
>>>
>>>
>>> if (.Platform$OS.type == "windows")
>>> getWindowsHandles <- function() ...
>>>
>>>
>>> and then in the NAMESPACE:
>>>
>>>
>>> if (.Platform$OS.type == "windows")
>>> export(getWindowsHandles)
>>>
>>>
>>> so I'd like to change my code to getWindowsHandles and import
>>> getWindowsHandles from utils, but I can only do that on Windows, and so the
>>> conditional importing should work for me. At no point does my function
>>> mis-behave because of a attempting to use a function that isn't exported on
>>> that platform, because within the function it only uses getWindowsHandles
>>> if the OS is Windows.
>>>
>>>
>>> On Thu, Sep 30, 2021 at 11:01 AM Mark Miller 
>>> wrote:
>>>
>>>> Returning to the original question, if it's helpful: I'd like to know what
>>>> constraints led to considering an export only available on Windows, and see
>>>> if we can suggest some other designs. It'd be good to keep the user's
>>>> mental model abstracted from the platform they're working on. There are
>>>> often unavoidable differences due to platform, but usually they're handled
>>>> with warnings and errors rather than selective exports.
>>>>
>>>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool <
>>>> berryboessenk...@hotmail.com> wrote:
>>>>
>>>>>
>>>>> One of the very best fortunes nominations!
>>>>>
>>>>> [...]
>>>>>
>>>>>I suspect something like
>>>>>
>>>>> if (stats::runif(1) > 0.5) export(someFunction)
>>>>>
>>>>> would work too, for a particularly frustrating experience for your
>>>>> users.  It would mean half the installs export the function, and half
>>>>> don't.
>>>>>
>>>>> 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
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] if statements in NAMESPACE file

[Jeff Newmiller]

What if you are on Windows but running R at the command prompt, or via cygwin, 
or in the console window of RStudio?

This seems unstable to me.

On September 30, 2021 11:52:16 AM PDT, Andrew Simmons  
wrote:
>Hello,
>
>
>I'm updating my package 'this.path' which is supposed to retrieve the
>absolute path of the executing script when called. It's similar to 'here',
>except that 'here' constructs paths relative to a project directory,
>whereas 'this.path' constructs paths relative to script directories. I was
>updating the section where I retrieve the executing script's path while
>running from a script open in Rgui for Windows, and I needed
>utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles
>is a Windows only function, I
>would imagine that 'utils' contains a similar line of code as above:
>
>
>if (.Platform$OS.type == "windows")
>getWindowsHandles <- function() ...
>
>
>and then in the NAMESPACE:
>
>
>if (.Platform$OS.type == "windows")
>export(getWindowsHandles)
>
>
>so I'd like to change my code to getWindowsHandles and import
>getWindowsHandles from utils, but I can only do that on Windows, and so the
>conditional importing should work for me. At no point does my function
>mis-behave because of a attempting to use a function that isn't exported on
>that platform, because within the function it only uses getWindowsHandles
>if the OS is Windows.
>
>
>On Thu, Sep 30, 2021 at 11:01 AM Mark Miller 
>wrote:
>
>> Returning to the original question, if it's helpful: I'd like to know what
>> constraints led to considering an export only available on Windows, and see
>> if we can suggest some other designs. It'd be good to keep the user's
>> mental model abstracted from the platform they're working on. There are
>> often unavoidable differences due to platform, but usually they're handled
>> with warnings and errors rather than selective exports.
>>
>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool <
>> berryboessenk...@hotmail.com> wrote:
>>
>> >
>> > One of the very best fortunes nominations!
>> >
>> > [...]
>> >
>> >   I suspect something like
>> >
>> >if (stats::runif(1) > 0.5) export(someFunction)
>> >
>> > would work too, for a particularly frustrating experience for your
>> > users.  It would mean half the installs export the function, and half
>> > don't.
>> >
>> > 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
>>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

__
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

[Jeff Newmiller]

Grace is in the eyes of the beholder.

Using stop in your functions can be perfectly valid. But within the context of 
examples or tests you need to catch those errors because one key definition of 
success in normal building of a package is that no uncaught errors occur. So 
either don't call those functions during package check, or catch the errors and 
move on. The former is probably best (no point in wasting time if you are going 
to ignore the failure anyway)... only run them interactively or when running 
full tests during development.


On September 24, 2021 8:27:32 AM PDT, Roy Mendelssohn - NOAA Federal via 
R-package-devel  wrote:
>Just so I am clear,  I should not call stop(),  but instead call a return() 
>and return something or other  (there is nothing to skip to - it is doing a 
>data download and either it works or it failed).  Is there a preferred 
>something to return?  And it is okay to write a message to the screen?  
>
>I should add that when I first ran into this awhile back I asked what "failed 
>gracefully" means,  and never received a response.  To me,  writing out a 
>message to the user and stopping is graceful exit, but obviously it is not.  
>What would help then, since this problem has been cited by others, is more 
>explicit guidelines as to what constitutes a graceful exit with examples.  My 
>$0.02
>
>-Roy
>
>
>
>> On Sep 24, 2021, at 8:03 AM, Ben Bolker  wrote:
>> 
>>  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
>
>**
>"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 

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Jeff Newmiller]

I agree... but trouble is in the eyes of the beholder. If OP's approval process 
requires use of actively-maintained software, then use of code depending on one 
of these "retired"/"superceded" packages could indeed be a problem... for the 
OP. OP cannot expect to be able to impose those requirements on others though.

On September 21, 2021 9:48:28 AM PDT, Hadley Wickham  
wrote:
>> But for the broader question, Jeff is saying that there really are 700 
>> packages that are in potential trouble!
>
>I think that's rather an overstatement of the problem — there's
>nothing wrong with plyr; it's just no longer under active development.
>If anything, plyr is one of the safest packages to depend upon because
>you can know it will never change :)
>
>Hadley
>

-- 
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] [External] Re: What is a "retired"package?

[Jeff Newmiller]

As you previously quoted:

> plyr is retired: this means only changes necessary to keep it on CRAN will be 
> made.

That excludes bugfixes related to any specific use cases it is not currently 
capable of handling. In other words, if it doesn't handle the data you pass 
along to it from your users, or there turns out to be a security problem (I 
agree, not likely, but remember these agencies don't shade things by "likely") 
then the plyr maintainers aren't promising to fix it. Take it "as-is". This is 
exactly what this "agency" you are being hassled by is concerned about... not 
the label applied to that status.

On September 21, 2021 8:50:32 AM PDT, "Lenth, Russell V" 
 wrote:
>... "I am not fixing this hot mess"??? To the contrary, the README contains a 
>clearly expressed intention to maintain plyr to keep in on CRAN.
>
>RL
>
>-Original Message-
>From: Jeff Newmiller  
>Sent: Tuesday, September 21, 2021 10:36 AM
>To: r-package-devel@r-project.org; Lenth, Russell V ; 
>r-package-devel@r-project.org
>Subject: [External] Re: [R-pkg-devel] What is a "retired"package?
>
>There is nothing official about that term. However, the meaning as intended by 
>the package authors seems pretty clear to me, and if some organization decides 
>not to allow software that is not being maintained to be relied upon then that 
>is their decision. I don't think slapping a different label on "I am not 
>fixing this hot mess" is going to change that organization's stance, and 
>expecting the author to play that game is unreasonable.
>
>Welcome to the downside of package interdependencies. I highly recommend that 
>you migrate away from plyr, either by absorbing the key functions you need 
>from it or by relying on different packages.
>

-- 
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] What is a "retired"package?

[Jeff Newmiller]

There is nothing official about that term. However, the meaning as intended by 
the package authors seems pretty clear to me, and if some organization decides 
not to allow software that is not being maintained to be relied upon then that 
is their decision. I don't think slapping a different label on "I am not fixing 
this hot mess" is going to change that organization's stance, and expecting the 
author to play that game is unreasonable.

Welcome to the downside of package interdependencies. I highly recommend that 
you migrate away from plyr, either by absorbing the key functions you need from 
it or by relying on different packages.

On September 21, 2021 8:15:28 AM PDT, "Lenth, Russell V" 
 wrote:
>I received a request that I remove the 'plyr' package from the Imports for my 
>package, because plyr is retired. Indeed, the README file for plyr states:
>
>> plyr is retired: this means only changes necessary to keep it on CRAN 
> will be made. 
>> We recommend using dplyr (for data frames) or purrr (for lists) instead.
>
>This says "retired" but it also suggests that plyr will continue to be 
>maintained. And that is a good thing because plyr has over 700 direct 
>reverse-dependents, and almost 2000 if we include indirect reverse 
>dependencies. 
>
>So it seems to me that it isn't a problem at all to have my package import 
>plyr. I use its 'aaply' and 'alply' functions, which are like 'apply' but work 
>for any dimensional array. There are no obvious replacements in purrr or 
>dplyr, and if there were and I used them instead, it would increase my 
>indirect dependencies to several packages that are not actually needed.
>
>The user requesting that I drop plyr states that this is needed to satisfy 
>regulatory needs, that it is problematic to qualify my package since it 
>imports a retired package. 
>
>So my question is: Is there a specific meaning in CRAN for "retired," or is 
>that just loose language from the plyr developers? I did not find the term in 
>"CRAN Repository Policy" or "Writing R Extensions." It appears that my user or 
>their regulatory agency thinks it means that it could be deprecated in the 
>near future. (If that is indeed what it means, there are 700+ packages in 
>trouble!) Otherwise, perhaps the appropriate request may be to the plyr 
>maintainers to modify how they describe its status, so as to avoid confusion.
>
>Russ Lenth
>University of Iowa
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] NOTE related to Miniconda installation

[Jeff Newmiller]

I can't really see why it should be "recommended" to handle installing system 
requirements inside an R package. There are many ways to satisfy such 
requirements that would not involve miniconda. If you were determined to 
provide such support, doing so in a normal function documented in a vignette 
seems more appropriate.

On September 17, 2021 11:55:07 AM PDT, "Walter, Vonn" 
 wrote:
>Hi Everyone,
>
>I am developing a package (called mypackage in the text below) that uses 
>reticulate to call a Python script for computational efficiency.  At some 
>point during the development of the package I read that it would be good to 
>verify installation of Miniconda.  Thus mypackage includes an onLoad.R file 
>that asks users to either confirm that Miniconda is installed or to proceed 
>with installation on Miniconda.  When I run devtools::check() I get a NOTE 
>related to my onLoad.R file, and this seems to be causing problems when I 
>submit the package to CRAN.  There are no WARNINGs or ERRORs.  Any thoughts 
>would be greatly appreciated.
>
>Thanks,
>
>Vonn
>
>* checking R code for possible problems ... [19s] NOTE
>File 'mypackage/R/onLoad.R':
>  .onLoad calls:
>packageStartupMessage("You should install miniconda before using this 
> package")
>
>See section 'Good practice' in '?.onAttach'.
>
>Here's the code/text from my onLoad.R file:
>
>#' Perform necessary tasks when the mypackage package is loaded
>#'
>#'
>miniconda_installation <- NULL
>miniconda_permission <- NULL
>numpy_import <- NULL
>
>.onLoad <- function(libname, pkgname)
>{
>miniconda_installation <- utils::askYesNo("Is miniconda 
> installed?")
>
>if (isFALSE(miniconda_installation))
>{
>miniconda_permission <- 
> utils::askYesNo("Install miniconda?  Downloads 50MB and takes time.")
>
>if (isTRUE(miniconda_permission))
>{
>reticulate::install_miniconda()
>} else{
>
> packageStartupMessage("You should install miniconda before using this 
> package")
>}
>
>numpy_import <- reticulate::import("numpy", 
> delay_load = TRUE)
>}
>}
>
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Packages required but not available

[Jeff Newmiller]

This advice would apply if the errors were being generated on a computer under 
the package developer's control... but this looks like it is from a repo 
submission.

That said, if the developer has installed packages not currently in BioC for 
R4.1.1 they may need to wait for those packages to propagate in the official 
BioC repo and then to the submission test computers.

On September 11, 2021 3:47:32 PM PDT, dbosa...@gmail.com wrote:
>Reminder that you have to re-install any packages that your oncoPredict 
>package depends on for the new R version 4.1.1.  Packages are 
>downloaded/installed to a specific R version.  If you switch to another 
>version, everything needs to be reinstalled.  I always get this error after 
>upgrading or switching R versions.
>
> �
>
>If you’ve already reinstalled and are still getting the error, then maybe it 
>is something with your NAMESPACE or DESCRIPTION file.  Like if you are using a 
>package inside a function, but forget to add it to the DESCRIPTION.  Or you 
>put it in the DESCRIPTION, but forget to add the @import roxygen directive 
>above your function so that it gets into the NAMESPACE.  
>
> �
>
>Those are the situations that most commonly generate this error, from what I 
>have seen.  
>
> �
>
>From: Danielle Maeser  
>Sent: Saturday, September 11, 2021 6:28 PM
>To: dbosa...@gmail.com; R Package Devel 
>Subject: Re: [R-pkg-devel] Packages required but not available
>
> �
>
>Hi David,
>
> �
>
>Yes. I did recently upgrade R. �
>
> �
>
>On Sat, Sep 11, 2021 at 4:28 PM  > wrote:
>
>Danielle:
>
>Did you recently upgrade to R 4.1.1?
>
>David
>
>
>-Original Message-
>From: R-package-devel  > On Behalf Of Danielle Maeser 
>via R-package-devel
>Sent: Saturday, September 11, 2021 5:10 PM
>To: R Package Devel  >
>Subject: [R-pkg-devel] Packages required but not available
>
>Hello,
>
>I received the following output from my package, oncoPredict.
>
>However, I don't understand how to correct this error. I've tested the advice 
>here:
>https://stackoverflow.com/questions/14358814/error-in-r-cmd-check-packages-required-but-not-available
>without success.
>
>Any thoughts as to how this error can be fixed?
>
>Danielle Maeser
>
>
>
>
>
>
>*Version: 0.1Check: package dependenciesResult: ERROR �  � Packages required
>but not available: �  �  �'org.Hs.eg.db', 'TxDb.Hsapiens.UCSC.hg19.knownGene',
>'maftools', �  �  �'TCGAbiolinks'*
> � * � See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’*
>
>* �  � manual.Flavor: r-release-macos-x86_64
>*
>--
>Ph.D. Student
>Bioinformatics and Computational Biology University of Minnesota
>
> �  �  �  � [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org   mailing 
>list https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
>
> �
>

-- 
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] Additional CRAN Checks

[Jeff Newmiller]

Exactly what errors do you think you found? It is not an error for a package to 
be compatible with a range of versions of R.

On September 6, 2021 4:02:08 AM PDT, Colin Gillespie  
wrote:
>Dear All,
>
>Sorry if this is the wrong mailing address.
>
>I was doing a little investigation of R versions in packages and
>discovered a number of errors:
>
>https://cran.r-project.org/web/packages/bartCause/index.html  - R (≥ 3.1-0)
>https://cran.r-project.org/web/packages/activityGCMM/index.html  - R (3.00)
>https://cran.r-project.org/web/packages/deTestSet/index.html - R (≥ 2.01)
>
>and also
>
>https://cran.r-project.org/web/packages/NGSSEML/ - R (≥ 1.9.0), R (≥
>3.5.0), R (≥ 3.5.0), R (≥ 3.5.0), R (≥ 3.5.0), R (≥ 3.5.0), R (≥
>3.5.0)
>
>Overall I detected ~40 packages with issues:
>
>c("activityGCMM", "behavr", "bioassays", "bvpSolve", "celestial",
>"chest", "CRTSize", "csppData", "damr", "deTestSet", "diagram",
>"directPA", "DiscreteFDR", "ecolMod", "ecp", "epibasix", "europepmc",
>"fabisearch", "FDX", "ggetho", "hyper.fit", "MedSurvey", "NBPSeq",
>"NetIndices", "NFWdist", "OmegaG", "primer", "RATest", "refund",
>"RmarineHeatWaves", "rmcfs", "rootSolve", "RPPASPACE", "scopr",
>"scoringRules", "seqDesign", "shape", "sleepr", "SMPracticals",
>"text", "tggd", "zeitgebr")
>
>It seems like this would be a useful check to implement on the R CMD check.
>
>Thanks
>
>Colin
>
>
>Dr Colin Gillespie
>https://twitter.com/csgillespie
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Spelling and manual CRAN inspection

[Jeff Newmiller]

Spelling has different importance to different people. You are expressing a 
value judgement that differs from the values of R Core, but are presenting your 
opinion as if they are facts. My point is that your challenging attitude IMO 
makes having a conversation about those concerns difficult. (I am not 
associated with R Core in any way, and do in fact empathize with your 
frustration with the process.)

I think it is worth pointing out that spelling errors in the DESCRIPTION file 
are of greater significance than other areas of a package as they can affect 
assignment of responsibility and permissions, as well as reflecting poorly on 
the CRAN summary web pages. I suspect that problems with DESCRIPTION files in 
the past lead to this requirement.

I would encourage you to pause for a day or two before sending off messages 
like this in the future... a lesson I have learned the hard way myself.

On July 16, 2021 9:08:27 AM PDT, "Kevin R. Coombes"  
wrote:
>Hi,
>
>  I have been updating a couple of R packages this morning. One of them
>triggered a manual inspection for "possibly mis-spelled words in
>DESCRIPTION" for my last name (Coombes) --- even though none of the
>other 20 packages that I maintain has ever triggered that particular
>NOTE. A second package also triggered a manual inspection for
>mis-spelled words including "Proteomics". (These flags only arose on
>the
>debian CRAN machine, not the Windows CRAN machine, and not on my home
>machines. And let's ignore how many spelling corrections I had to make
>while typing this email)
>
>*My question, however, is: why should this NOTE ever trigger a manual
>inspection?* That makes more work for the CRAN maintainers, who I am
>sure have better things to do than evaluate spelling. Anything that
>would actually stop the package from working (mis-spelling a keyword,
>or
>mis-spelling the name of package that is imported) is going to cause an
>automatic ERROR and a rejection of the submission without making more
>work for the CRAN maintainers. The other mis-spellings may reflect
>poorly on the package author, but since they are NOTEs, it is easy
>enough to get them fixed for the next round without making human
>eyeballs look at them.
>
>Best,
>    Kevin
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Assignments to the global environment and use of on.exit

[Jeff Newmiller]

Just don't. E.g. 
https://stackoverflow.com/questions/12598242/global-variables-in-packages-in-r

On June 22, 2021 1:47:56 AM PDT, Siddhanta Phuyal 
 wrote:
> Hello,
>
>A few weeks ago, I submitted a package to CRAN. The automated system
>rejected the package showing the following note:
>
>Found the following assignments to the global environment:
>  File 'EuclideanSD/R/EuclideanSD.R':
>assign("nums", x, envir = globalenv())
>
>Context of the problem:
>
>The package has a function that takes a vector from the user. The
>vector is
>used by the shiny app to produce the desired output. The sever and UI
>functions are located inside the 'inst' folder. Since they are located
>at a
>different location, the server function cannot directly access the
>vector
>received by the function from the user. Hence, the package creates a
>global
>variable to store the data which can also be used by the server
>function.
>
>The solution I offered:
>
>However, before assigning the variable to a global environment, the
>function checks whether there is a variable with the same name in the
>global environment. If there is such a variable, then the function
>restores
>that variable back to its original state by using on.exit(num<-oldnum)
>prior to exiting the function. On the contrary, if such a variable does
>not
>exist, then the variable assigned to the global environment is removed
>on
>exit. I have included the code to clarify my argument. Please see below
>for
>the code:
>
>if (exists("nums",where = 1)){
>oldnums <- nums
>nums <- x
>shiny::runApp(system.file(package="EuclideanSD","app"))
>on.exit(nums<-oldnums)
>
>  }else{
>assign("nums",x,envir = globalenv())
>shiny::runApp(system.file(package="EuclideanSD","app"))
>on.exit(remove("nums",pos=1))
>  }
>
>I tried to explain the same to the maintainers of CRAN by replying to
>the
>message that I got from the CRAN. However, there was no response.
>
>I have two questions that I hope to get help from this community:
>
>1) Is my solution reasonably okay with the requirements of the CRAN?
>2) If the solution is not okay, what could be the better solution?
>However,
>the features of the package cannot be changed. For example, the data
>has to
>be fed through the function and not through the website.
>
>Thank you for your help.
>
>Looking forward to hearing from you.
>
>Best Regards,
>Siddhanta Phuyal
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

__
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

[Jeff Newmiller]

This is a job for a detective, not a package developer mailing list participant.

If this condition persists, CRAN will archive the package, as maintaining a 
valid email address is required.

On June 18, 2021 5:29:20 PM PDT, 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

-- 
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] Question about preventing CRAN package archival

[Jeff Newmiller]

... but you went ahead and did it anyway.

MIT software can be absorbed by GPL2 software, but not vice versa since MIT 
allows the code to be further incorporated into and distributed as non-free 
software, a permission not granted by GPL2.

I am opposed to people snarfing GPL2 code up for their non-free software 
tarpits, and transferring GPL2 code to MIT without the GPL2 author explicitly 
re-releasing as MIT would allow that.

On June 2, 2021 11:51:01 PM PDT, Berwin A Turlach  
wrote:
>G'day Jeff,
>
>On Wed, 02 Jun 2021 11:34:21 -0700
>Jeff Newmiller  wrote:
>
>Not that I want to get involved in old discussions :), but...
>
>> MIT is more permissive than GPL2,
>
>... this statement depends on how one defines "permissive".
>
>MIT requires that you fulfil: "The above copyright notice and this
>permission notice shall be included in all copies or substantial
>portions of the Software." (https://opensource.org/licenses/MIT)
>
>Whereas GPL 2 merely requires that you "[...] conspicuously and
>appropriately publish on each copy an appropriate copyright notice and
>disclaimer of warranty [...]".
>
>Thus, arguably, GPL 2 is more permissive.
>
>>  so there is a collision there. 
>
>Well, luckily the FSF does not think that the MIT license is
>incompatible with the GPL license, though it finds the term "MIT
>license" misleading and discourages its use, see
>https://www.gnu.org/licenses/license-list.html
>
>Cheers,
>
>   Berwin

-- 
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] Question about preventing CRAN package archival

[Jeff Newmiller]

MIT is more permissive than GPL2, so there is a collision there. But you may be 
able to work it out with the author?

On June 2, 2021 10:36:00 AM PDT, 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=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
>> > ,
>> > is.symmetric.matrix
>> > , and
>> > is.positive.definite
>> > ) 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 

Re: [R-pkg-devel] \donttest{} and writing outputs to tempdir()

[Jeff Newmiller]

Make examples shorter so they can run faster. Wrapping everything in donttest 
means that running examples() does nothing, which is counterproductive.

Techinically, vignettes are not tests or examples... but they do have the 
advantage that they don't have to run quickly. But that doesn't make a vignette 
a substitute for either examples or tests.

As for writing to the wrong place, you should probably just double check. 

On June 1, 2021 9:39:43 PM PDT, Danielle Maeser  wrote:
>Hello,
>
>I received the following comments from a CRAN maintainer, and I don't
>understand why they were an issue. I'd appreciate any insight you can
>provide.
>
>Danielle
>
>
>
>
>
>
>
>*All your examples are wrapped in \donttest{} and therefore do not
>gettested.Please unwrap the examples if that is feasible and if they
>can
>beexecuted in < 5 sec for each Rd file or create additionally small
>toyexamples to allow automatic testing.*
>
>I don't think I can unwrap the examples in \donttest{} because they
>cannot
>be executed in <5 seconds for each Rd file, and the automatic testing
>of
>toy data is satisfied in the vignettes I provide for each function.
>Therefore, I am not sure what change to make here.
>
>
>
>
>*Please ensure that your functions do not write by default or in
>yourexamples/vignettes/tests in the user's home filespace (including
>thepackage directory and getwd()). This is not allowed by CRAN
>policies.In
>your examples/vignettes/tests you can write to tempdir().*
>
>Additionally, all of my vignettes write the output of each function to
>tempdir(). Therefore, I am not sure why this is a problem.

-- 
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] Installed image not found in Debian

[Jeff Newmiller]

Why aren't you using system.file()?

On May 11, 2021 1:45:37 PM PDT, Tiago Olivoto  wrote:
>Dear all,
>I just submitted a new package 'pliman' (
>https://github.com/TiagoOlivoto/pliman) and it does not pass the
>incoming
>checks automatically.
>I have some images that are under '/inst/tmp_images' to be installed
>with
>the package. In some examples and Vignettes, I use the helper function
>image_pliman() <
>https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L125>
>to get the patch of a given image
>
>Then, I use image_import() <
>https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L69>
>to
>import the image into R.
>
>All tests passed in Windows <
>https://win-builder.r-project.org/incoming_pretest/pliman_0.1.0_20210511_212904/Windows/00check.log>
>but an error was got in Debian <
>https://win-builder.r-project.org/incoming_pretest/pliman_0.1.0_20210511_212904/Debian/00check.log
>>
>The error occurs when image_import () has been called, for example
>
>image_import(image_pliman("soybean_touch.jpg"))
>Error:  'soybean_touch' not found in
>.//srv/hornik/tmp/CRAN/pliman.Rcheck/pliman/tmp_images
>
>It seems that this error comes from this check <
>https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L92-L97>
>that checks if the image name is available in the directory. Please,
>see a
>toy example with my data.
>
># Get the patch of the image
>image <- image_pliman("soybean_touch.jpg")
>image
>[1]
>"E:/Documents/R/win-library/4.0/pliman/tmp_images/soybean_touch.jpg"
>
># Get the directory of the image
>img_dir <- file_dir(image)
>> img_dir
>[1] "E:/Documents/R/win-library/4.0/pliman/tmp_images"
>
># Get all files in the directory
>> all_files <- sapply(list.files(img_dir), file_name)
>> all_files
>background.jpgla_back.jpgla_leaf.jpg  la_leaves.JPG
>  "background"  "la_back"  "la_leaf""la_leaves"
>la_pattern.JPGla_temp.jpg objects_300dpi.jpg   sev_back.jpg
>  "la_pattern"  "la_temp"   "objects_300dpi" "sev_back"
>sev_healthy.jpg   sev_leaf.jpgsev_leaf_nb.jpg 
>sev_sympt.jpg
> "sev_healthy" "sev_leaf"  "sev_leaf_nb""sev_sympt"
> soy_green.jpg  soybean_grain.jpg  soybean_touch.jpg
>   "soy_green""soybean_grain""soybean_touch"
>
># Get the name of the image and check if it is in the directory
>> img_name <- file_name(image)
>> img_name
>[1] "soybean_touch"
>
>if(!grepl("http", img_dir, fixed = TRUE) & !img_name %in% all_files){
>  stop(" '", img_name, "' not found in ", img_dir,  call. = FALSE)
>}
>
>In this case, there is no error since  "soybean_touch" is in
>'all_files'
>
>I have no idea how to fix this issue and why this error occurs only on
>Debian and not on Windows. Any suggestion to fix the error and/or
>improve
>the code will be welcome!
>Thanks in advance,
>Tiago
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Package Vignette depends on Ensembl, server certificate issue?

[Jeff Newmiller]

Maybe use r.rsp?

https://blog.r-hub.io/2020/06/03/vignettes/
How to include my pre-print / cheatsheet as a PDF vignette?



On April 8, 2021 12:39:20 PM PDT, "Dr. Connie Brett" 
 wrote:
>Hello,
>I have a package (DGEobj) that depends on the Ensembl service to look
>up information used to build the vignette.  My builds work fine on
>Travis, locally and on R-hub.  Occasionally I have seen blips with
>regard to internet-based resources not being available, and my vignette
>depends on a number of internet resources to get example datasets. 
>However when I submitted my package to CRAN today the failures Windows
>and Debian were that the server certificate verification failed ( SSL
>certificate problem: unable to get local issuer certificate).
>I’m not sure if there is something I can do about this or if this is
>considered a "false positive" per the email - it seems like a "wait and
>retry" issue.  I don’t want to be rude uploading the package again
>without a change or erroneously emailing in response to the rejection. 
>How should this be handled properly now and into the future?  It isn’t
>feasible to not use Ensembl for this vignette.
>Thanks for your insight and feedback!
>
>Flavor: r-devel-windows-ix86+x86_64
>Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> --- re-building 'DGEobj_Overview.Rmd' using rmarkdown
>
> Ensembl site unresponsive, trying asia mirror
> Quitting from lines 259-280 (DGEobj_Overview.Rmd) 
>Error: processing vignette 'DGEobj_Overview.Rmd' failed with
>diagnostics:
> SSL certificate problem: unable to get local issuer certificate
> --- failed re-building 'DGEobj_Overview.Rmd'
>
> SUMMARY: processing the following file failed:
>   'DGEobj_Overview.Rmd'
>
> Error: Vignette re-building failed.
> Execution halted
>
>
>Flavor: r-devel-linux-x86_64-debian-gcc
>Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> --- re-building 'DGEobj_Overview.Rmd' using rmarkdown
>
> Ensembl site unresponsive, trying asia mirror
> Quitting from lines 235-256 (DGEobj_Overview.Rmd) 
>Error: processing vignette 'DGEobj_Overview.Rmd' failed with
>diagnostics:
> server certificate verification failed. CAfile: none CRLfile: none
> --- failed re-building 'DGEobj_Overview.Rmd'
>
> SUMMARY: processing the following file failed:
>   'DGEobj_Overview.Rmd'
>
> Error: Vignette re-building failed.
> Execution halted
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Lazy data compression for packages without data folder

[Jeff Newmiller]

I don't think those settings apply to that file. Search for "sysdata.rda" in 
[1].

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

On April 1, 2021 3:11:17 AM PDT, Peter Ruckdeschel  
wrote:
>Hi,  
>
>I just noticed that, last week-end, R CMD build was changed to remove
>‘LazyData’ and
>‘LazyDataCompression’ fields from the ‘DESCRIPTION’ file of packages
>without a ‘data’
>directory.
>
>Now, in our package "RobAStRDA" published on CRAN in version 1.2.0
>2019-03-11, we 
>deliberately do have a ‘LazyData´ field in the ‘DESCRIPTION’ file of
>the package
>without a ‘data’ folder.
>
>This package just contains a sysdata.rda file with a large amount of
>interpolation grids
>and functions not to be analyzed as statistical data but rather to be
>used for speed-ups
>in our package "RobExtremes" (also on CRAN).
>
>What is the recommended way to achieve this, i.e., use the sysdata.rda
>file in compressed
>form and in lazy data format without placing it into a ‘data’ folder?
>
>Any suggestions welcome,
>best regards, Peter (Ruckdeschel)
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Why .Rbuildignore doesn't ignore?

[Jeff Newmiller]

Don't run check against your development directory. Run it against the tar.gz 
file.

On March 4, 2021 5:09:07 AM PST, Jose Barrera  wrote:
>Dear all,
>
>devtools::check() gives me the following NOTE:
>
>* Non-standard files/directories found at top level:
> ‘README.Rmd’ ‘miclust.Rproj’
>
>I get the same result with R CMD check --as-cran and R CMD check in a
>terminal.
>
>My .Rbuildignore includes both ^.*\.Rproj$ and ^README\.Rmd$.
>
>I haven't had this issue when checking another package I recently and
>successfully sent to CRAN, so I have no idea why I get that NOTE now.
>
>I would appreciate any help to know why .Rbuildignore seems not to
>ignore
>those files.
>
>Thanks,
>
>Jose Barrera
>Statistician, Associate Lecturer
>
>*IS**Global*
>Barcelona Institute for Global Health - Campus MAR
>Barcelona Biomedical Research Park (PRBB) (Room Hypatia)
>
>Doctor Aiguader, 88
>08003 Barcelona, Spain
>Tel. +34 93 2147383
>jose.barr...@isglobal.org
>
>Personal website: sites.google.com/view/josebarrera
>www.isglobal.org
>
>This message is intended exclusively for its addressee and may contain
>information that is CONFIDENTIAL and protected by professional
>privilege.
>If you are not the intended recipient you are hereby notified that any
>dissemination, copy or disclosure of this communication is strictly
>prohibited by law. If this message has been received in error, please
>immediately notify us via e-mail and delete it.
>
>DATA PROTECTION. We inform you that your personal data, including your
>e-mail address and data included in your email correspondence, are
>included
>in the ISGlobal Foundation filing system. Your personal data will be
>used
>for the purpose of contacting you and sending information on the
>activities
>of the above foundations. You can exercise your rights to  access to
>personal data, rectification, erasure, restriction of processing, data
>portability and object by contacting the following address:
>*l...@isglobal.org
>*. ISGlobal Privacy Policy at *www.isglobal.org
>*.
>
>
>-
>
>CONFIDENCIALIDAD. Este mensaje y sus anexos se dirigen exclusivamente a
>su
>destinatario y puede contener información confidencial, por lo que la
>utilización, divulgación y/o copia sin autorización está prohibida por
>la
>legislación vigente. Si ha recibido este mensaje por error, le rogamos
>lo
>comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
>PROTECCIÓN DE DATOS. Sus datos de carácter personal utilizados en este
>envío, incluida su dirección de e-mail, forman parte de ficheros de
>titularidad de la Fundación ISGlobal  para cualquier finalidades de
>contacto, relación institucional y/o envío de información sobre sus
>actividades. Los datos que usted nos pueda facilitar contestando este
>correo quedarán incorporados en los correspondientes ficheros,
>autorizando
>el uso de su dirección de e-mail para las finalidades citadas. Puede
>ejercer los derechos de acceso, rectificación, supresión, limitación
>del
>tratamiento, portabilidad y oposición dirigiéndose a *l...@isglobal.org
>* . Política de privacidad en *www.isglobal.org
>*.

-- 
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] Advice on R-forge to Github migration

[Jeff Newmiller]

Technically, git does not record file history... it records commit history, and 
reconstructs file history as needed. The contents of a file identify it 
uniquely among all commits ever made regardless of which directory it was ever 
in. IMO this is the main reason why git is superior and I put up wth the 
inconsistent command line interface because of it.

git mv is very simple [1].

[1] https://stackoverflow.com/questions/1094269/whats-the-purpose-of-git-mv

On January 31, 2021 10:21:09 AM PST, Joshua Ulrich  
wrote:
>On Sun, Jan 31, 2021 at 12:10 PM Duncan Murdoch
> wrote:
>>
>> rgl has been on R-forge for a long time, but I am now planning on
>> migrating it to Github.  I really dislike git, but Github offers
>enough
>> benefits, and nowadays I'm familiar enough with them, that I think
>I'd
>> be better off there.
>>
>> The easiest way to do this would be to do almost nothing:  just
>declare
>> the the dmurdoch/rgl fork of r-forge/rgl is now where all new changes
>> will be committed.
>>
>> Can anyone else who has done this migration tell me if there there
>any
>> disadvantages to this that I don't know about?  What I know:
>>
>>   - I'll lose the bug reports and forum discussions that were sent to
>> R-forge.
>>   - I'll need to do a bit of work to change dmurdoch/rgl to a more
>> standard R package layout, but this should be quite easy:  basically
>> just moving the files in pkg/rgl to the top level.  I assume "git mv"
>> will keep their history if I do this.
>>
>I've moved history and issues from R-Forge to GitHub for half a dozen
>R packages. I might be able to do this rgl. At minimum, I could help
>you do it.
>
>Yes, git mv will retain the file history.
>
>> Duncan Murdoch
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Package used unconditionally only in testing

[Jeff Newmiller]

This is normally where the Suggests field is used.

On January 8, 2021 6:17:58 AM PST, Greg Freedman Ellis  
wrote:
>Hi all,
>
>I'm trying to update a package to conform to pass tests given
>`_R_CHECK_DEPENDS_ONLY_=TRUE`.
>
>In this package, we only use the package `httptest` during testing, but
>the
>tests are (almost) meaningless if it is not installed, so I would like
>to
>indicate that it is a required package rather than skipping tests if it
>is
>not installed.
>
>If I move `httptest` to Depends, then I get the error CRAN check note:
>> Namespace in Imports field not imported from: ‘httptest’
>>   All declared Imports should be used.
>
>I think this would best be solved by a DESCRIPTION field that indicates
>a
>package is required, but only for tests, but I do not see such a field.
>The
>only solution I can think of is to have a trivial import of `httptest`
>in
>the main package to silence the NOTE. Is there a better solution?
>
>Greg Freedman Ellis
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Sweave vignette and bibtex

[Jeff Newmiller]

Sheepish grins may be good for character building, but MREs are good for 
solving problems. You can choose which you want first!  ;-)

On January 6, 2021 9:50:13 AM PST, Jarrod Hadfield  wrote:
>Dear Duncan and Michael,
>
>Thank you for the quick replies. When trying to generate a reproducible
>
>example I realised I'd done something embarassingly stupid and the 
>problem is now resolved.
>
>Kind Regards,
>
>Jarrod
>
>
>
>On 06/01/2021 17:06, Michael Dewey wrote:
>> This email was sent to you by someone outside the University.
>> You should only click on links or attachments if you are certain that
>
>> the email is genuine and the content is safe.
>>
>> Dear Jarrod
>>
>> It works for me with Sweave so perhaps we need some more details.
>>
>> Michael
>>
>> On 06/01/2021 11:20, Jarrod Hadfield wrote:
>>> Hi,
>>>
>>> I have a Sweave vignette in a package I have written. When building,
>the
>>> citations are not put into the pdf - perhaps because two passes of
>the
>>> tex file are required but only one is executed. Is there a way to
>force
>>> two passes of the tex file?
>>>
>>> Kind Regards,
>>>
>>> Jarrod
>>>
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>> -- 
>> Michael
>> http://www.dewey.myzen.co.uk/home.html
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Accessing features in R4.0.

[Jeff Newmiller]

For "obvious" reasons? I don't see this kind of avoidance as "obviously" 
correct at all. You have a dependency... it should be declared. There are 
various ways to proceed, with Imports or Depends or Suggests or pulling the 
code into your package... but trying to subvert the dependency management is 
counterproductive.

On December 16, 2020 8:28:15 AM PST, Colin Gillespie  
wrote:
>Hi,
>
>I'm planning on using the tools::R_user_dir function in a package. But
>for obvious reasons, I don't want to set the dependency on R 4.
>
>My code is basically
>
>if (as.numeric(R.version$major) < 4) # do something
>else tools::R_user_dir("oysteR", which = "cache")
>
>When checking on win-builder R3.6 I get the note
>
>* checking dependencies in R code ... NOTE
>Missing or unexported object: 'tools::R_user_dir'
>
>## Question
>
>Is my code correct and can I ignore this note?
>
>Thanks
>
>Colin
>
>
>Dr Colin Gillespie
>http://www.mas.ncl.ac.uk/~ncsg3/
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally

[Jeff Newmiller]

Examples should use dontrun to avoid calling functions that call stop.

On December 12, 2020 8:24:50 AM PST, Michael L Friendly  
wrote:
>I got the email below concerning 3 of my packages but wonder if they
>are false alarms or
>if not, how to locate & fix the problem.
>
>This concerns packages: ...
>
>Suggested packages should be used conditionally: see �1.1.3.1 of
>'Writing R Extensions'.  Some of these are hard to install on a
>platform without X11 such as M1 Macs: see the logs at
>https://www.stats.ox.ac.uk/pub/bdr/M1mac/.
>
>You can check all of the suggested packages by setting environment
>variable _R_CHECK_DEPENDS_ONLY_=true  -- see
>https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Tools .
>
>Is this a false alarm?
>
>In each case, the outfile contains:
>
>* checking package namespace information ... OK
>* checking package dependencies ... NOTE
>Package suggested but not available for checking: 'rgl'
>
>indicating that rgl is not avaiable on the testing machine.  Then, when
>checking examples an error is triggered
>when an example calls something that requires rgl.
>
>>
>> heplot3d(Adopted.mod, hypotheses=list("Reg"=c("AMED", "BMIQ")),
>+ col = c("red", "blue", "black", "gray"), wire=FALSE)
>Loading required namespace: rgl
>Failed with error:  'there is no package called 'rgl''
>Error in heplot3d.mlm(Adopted.mod, hypotheses = list(Reg = c("AMED",
>"BMIQ")),  :
>  rgl package is required.
>Calls: heplot3d -> heplot3d.mlm
>Execution halted
>
>Yet, heplot3d seems to contain the required way to refer to the
>suggested rgl package:
>
> if (!requireNamespace("rgl")) stop("rgl package is required.")
>
>So, I'm mystified.  Can anyone help?
>
>
>
>Michael Friendly Email: friendly AT yorku DOT ca
>Professor, Psychology Dept. & Former Chair, ASA Statistical Graphics
>Section
>York University  Voice: 416 736-2100 x66249
>4700 Keele StreetWeb: http://www.datavis.ca | @datavisFriendly
>Toronto, ONT  M3J 1P3 CANADA
>
>
>   [[alternative HTML version deleted]]

-- 
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] Conditional timeout for httr request when running R CMD check

[Jeff Newmiller]

Don't test against a live website for most of your testing... use recorded or 
simulated input. If your package functional interface doesn't allow for that, 
then re-factor it so it does.

For those tests that actually have to interact with the live website, only run 
them if you know you are not on CRAN. The testthat package has support for this 
if you don't want to roll your own.

On November 30, 2020 10:45:01 AM PST, "Ayala Hernandez, Rafael" 
 wrote:
>Dear all,
>
>My package openSkies includes a set of functions to retrieve
>information from the OpenSky API.
>
>The examples for these functions can, on rare occassions, take
>anomously longer times to complete than usually because of issues on
>the API side.
>
>I have already included a timeout parameter to prevent endless attempts
>to retrieve the result when, for example, the API is down for
>maintenance.
>
>I have recently been asked by CRAN to reduce the execution time of each
>example to below 5 s. In order to do this, I can set the timeout
>parameter to something below 5s, and return NULL and a message
>indicating the resource is not currently available. However, I think
>this might not be the best option for examples that demonstrate
>important functionalities to users.
>
>Therefore, I was wondering if there is anyway to set up the timeout
>parameter to a different value than usual based on the condition that
>examples are being run as part of R CMD check?
>
>Thanks a lot in advance
>
>Best wishes,
>
>Rafa
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] URLencode at DESCRIPTION file and citation()

[Jeff Newmiller]

Section 2.1 of the Writing R Extensions manual points out that percent symbols 
must (practically) always be escaped in Rd files. This includes within URLs.

On November 3, 2020 2:08:05 AM PST, "Maëlle SALMON via R-package-devel" 
 wrote:
>Hello,
>
>1) I found (via GitHub search for DOIs in DESCRIPTION
>files 
>https://github.com/search?q=org%3Acran+%3Cdoi+user%3Acran+filename%3ADESCRIPTION=Code=advsearch==)
>a package with an URL-encoded DOI see
>https://github.com/cran/clust.bin.pair/blob/e464ac7e5d094bffd25b7c4cbba67820b60f1cc1/DESCRIPTION
>and the resulting CRAN page
>https://cran.r-project.org/web/packages/clust.bin.pair/index.html So I
>think you are right to use URL encoding.
>
>I can reproduce the problem you get with the roxygen2-generated
>package-level manual page. The problem is that when going from Rd to
>HTML, the parts after "%" are ignored indeed. I'm not sure at what
>level this should be fixed. I opened an issue in roxygen2
>https://github.com/r-lib/roxygen2/issues/1164 I hope others will have
>more useful answers. :-)
>
>2) For that aspect I looked into a CITATION file I knew
>https://github.com/ropensci/bomrang/blob/master/inst/CITATION
>
>For finding the version it uses meta$Version. So your CITATION could
>e.g. become
>
>citHeader("To cite raytracing in publications use at least the first,
>if not both:")
>
>year <- sub("-.*", "", meta$Date)
>note <- sprintf("R package version %s", meta$Version)
>
>citEntry(entry = "manual",
>   title  = "raytracing: An R package for identification and
>tracking the atmospheric Rossby waves",
>   author = personList(c(person("Amanda", "Rehbein"),
>    person("Tercio", "Ambrizzi"),
>    person("Sergio", "Ibarra-Espinosa"),
>    person("Livia M. M.", "Dutra"))),
>   year   = year,
>   url    = "https://github.com/salvatirehbein/raytracing;,
>   note  = note,
>   textVersion  =
>   paste0("Rehbein, A., Ambrizzi, T., Ibarra-Espinosa, S., Dutra, L. M.
>M.: Rossby Wave Ray Tracing v", meta$Version, ".
>https://github.com/salvatirehbein/raytracing, ", year,".")
>)
>
>citation(auto = meta)
>
>citFooter("Thanks")
>
>Maëlle.
>
>
>Den söndag 1 november 2020 21:29:54 CET, Amanda Rehbein
> skrev: 
>
>
>
>
>
>Dear R-Devs,
>
>I was wondering if someone could please help me to with two errors when
>submitting a package to CRAN.
>
>1) At the DESCRIPTION file I added some DOI's with curled brackets "<>"
>inside the "<>" (e.g.
>2.0.CO;2>).
>I tried URLencode() the string in R and copy/paste the output into
>the DESCRIPTION file, like this:
>. But when I
>load,
>build, check, etc, and ?raytracing the DOI does not appear correctly.
>Everything after the first "%" disappeared and obviously, the DOI
>doesn't
>work anymore.
>
>
>2) I have a CITATION file at the sub-directory ins. Its content is like
>this:
>
>citHeader("To cite raytracing in publications use one of below:")
>
>citEntry(entry = "manual",
>  title          = "Atmospheric Rossby waves identification and
>tracking
>with a raytracing numerical model",
>  author        = personList(c(person("Amanda", "Rehbein"),
>                    person("Tercio", "Ambrizzi"),
>                    person("Sergio", "Ibarra-Espinosa"),
>                    person("Livia M. M.", "Dutra"))),
>  year          = "2020",
>  url            = "https://github.com/salvatirehbein/raytracing;,
>
>  textVersion  =
>  paste0("Rehbein, A., Ambrizzi, T., Ibarra-Espinosa, S., Dutra, L. M.
>M.:
>Atmospheric Rossby waves identification and tracking with a raytracing
>numerical model ", packageVersion("raytracing"), ".
>https://github.com/salvatirehbein/raytracing, 2020.")
>)
>
>It passes all checks and gives a-okay citation when I type
>citation("raytracing"). However, it fails in the CRAN tests with the
>following error message.
>
>Reading CITATION file fails with
>    there is no package called 'raytracing'
>  when package is not installed.
>
>I will be very thankful for any help with this! Best,
>Amanda
>
>    [[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

-- 
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] best practices for handling a mixed-licensed package

[Jeff Newmiller]

You are addressing interpretation of "a license", while my concern is not with 
the licenses themselves but with the identification of which code goes with 
which license. Assuming that you will need to retain lawyers to decide how to 
handle a license in a particular use case may be reasonable, but assuming you 
will also use them to parse the files in the package  seems rather less 
reasonable IMO when you have such a clear alternative (packaging).

On October 3, 2020 9:02:02 AM PDT, Dirk Eddelbuettel  wrote:
>
>On 3 October 2020 at 09:54, Hadley Wickham wrote:
>| I think this is a bit of an oversimplification, especially given that
>| "compatibility" is not symmetric. For example, you can include MIT
>license
>| code in a GPL licensed package; you can not include GPL licensed code
>| inside an MIT licensed package. There are some rough guidelines at
>| https://r-pkgs.org/license.html#license-compatibility.
>
>One approach for issues such as legal matters is to consult
>subject-matter
>experts which is why I pointed (in a prior private message spawned by
>this
>same thread) to sites such as
>
>  https://tldrlegal.com/ 
>  https://choosealicense.com/
>
>Dirk

-- 
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] best practices for handling a mixed-licensed package

[Jeff Newmiller]

Hadley offers what you _can_ do, but if you want clarity in the minds of 
_users_ I would beg you to split the code into two packages. People will likely 
either be afraid of the GPL bogey man and refrain from utilizing your MIT code 
as permitted or fail to honor the GPL terms correctly if both are in the same 
package.

On October 2, 2020 1:16:36 PM PDT, Hadley Wickham  wrote:
>On Fri, Oct 2, 2020 at 1:51 PM Ben Bolker  wrote:
>
>>
>>A collaborator is arguing that it's a good idea to license one
>small
>> component of a package under the MIT license, while the rest of it
>> remains GPL >=2.
>>
>>Suppose this is feasible.  How do I specify the license?  As far
>as I
>> can tell from
>>
>https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing
>> the DESCRIPTION file should have
>>
>> License: file LICENSE
>> License_is_FOSS: yes
>> License_restricts_use: no
>>
>>But I can't figure out what should go in the LICENSE file. The one
>> file that contains the MIT-licensed components contains the relevant
>> license text in its body.
>>
>> License: GPL (>=2) | MIT + file LICENSE
>>
>> doesn't seem right, because these are not *alternative* licenses. 
>Would
>> "GPL (>=2) + file LICENSE" be OK? We could explain the situation in
>> LICENSE.note (WRE says "To include comments about the licensing
>rather
>> than the body of a license, use a file named something like
>> LICENSE.note. ")
>>
>>Could file LICENSE contain
>>
>> The code in this package is licensed under GPL >=2 (see
>> https://www.r-project.org/Licenses/GPL-2,
>> https://www.r-project.org/Licenses/GPL-3, except for ,
>which
>> is under the MIT license (see ).
>> ?
>>
>
>I have some recommendations at
>https://r-pkgs.org/license.html#code-you-bundle, but in brief use
>License:
>GPL (>= 2) and then explain in LICENSE.note which components have more
>liberal licenses.
>
>Hadley

-- 
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] Use of `:::` in a package for code run in a parallel cluster

[Jeff Newmiller]

As Duncan said, if you are calling FROM a function in your package, and the 
function you are CALLING is in the same package, then you do NOT need any 
colons at all, whether exported or not.

On September 14, 2020 7:30:12 AM PDT, "Wang, Zhu"  wrote:
>In mypkg, I want to call a function foo from pkg,  and foo is not
>exported. I thought I should use pkg:: or pkg:::, but R CMD check
>provided a warning.
>
>Thanks,
>Zhu
>
>> You don't need either pkg:: or pkg::: if you are calling the function
>from within the package.  You may need one of those if the call is
>coming from a user script.
>
>-Original Message-
>From: Duncan Murdoch  
>Sent: Monday, September 14, 2020 7:17 AM
>To: Wang, Zhu ; David Kepplinger
>; R Package Devel
>
>Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a
>parallel cluster
>
>On 13/09/2020 8:47 p.m., Wang, Zhu wrote:
>> Apologize if I hijack this thread, but the use of ::: is something I
>was puzzled.
>> 
>> I tried Duncan's solution in my R package mypkg, something like:
>> 
>> pkg::callInternal("foo", args)
>> 
>> R CMD check mypkg
>> 
>> * checking dependencies in R code ... WARNING '::' or ':::' import
>not 
>> declared from: ‘pkg'
>> 
>> I probably missed something here.
>
>You don't need either pkg:: or pkg::: if you are calling the function
>from within the package.  You may need one of those if the call is
>coming from a user script.
>
>If you use pkg:: from mypkg, you need to declare that mypkg Imports
>pkg. 
>(This is a line in its DESCRIPTION file.)  I think that's what the
>WARNING is telling you.
>
>Duncan Murdoch
>
>> 
>> Thanks,
>> Zhu
>> 
>> -Original Message-
>> From: R-package-devel  On 
>> Behalf Of Duncan Murdoch
>> Sent: Sunday, September 13, 2020 3:20 PM
>> To: David Kepplinger ; R Package Devel 
>> 
>> Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in
>a 
>> parallel cluster
>> 
>> On 13/09/2020 3:51 p.m., David Kepplinger wrote:
>>> Dear list members,
>>>
>>> I submitted an update for my package and got automatically rejected 
>>> by the incoming checks (as expected from my own checks) for using 
>>> `:::` calls to access the package's namespace.
>>> "There are ::: calls to the package's namespace in its code. A 
>>> package
>>> *almost* never needs to use ::: for its own objects:…" (emphasis 
>>> mine)
>>>
>>> This was a conscious decision on my part as the package runs code on
>
>>> a user-supplied parallel cluster and I consider cluster-exporting
>the 
>>> required functions a no-go as it would potentially overwrite objects
>
>>> in the clusters R sessions. The package code does not own the
>cluster 
>>> and hence the R sessions. Therefore overwriting objects could 
>>> potentially lead to unintended behaviour which is opaque to the user
>and difficult to debug.
>>>
>>> Another solution to circumvent the R CMD check note is to export the
>
>>> functions to the public namespace but mark them as internal. This
>was 
>>> also suggested in another thread on this mailing list (c.f. 
>>> "Etiquette for package submissions that do not automatically pass 
>>> checks?"). I do not agree with this work-around as the methods are 
>>> indeed internal and should never be used by users. Exporting truly 
>>> internal functions for the sake of satisfying R CMD check is a bad 
>>> argument, in particular if there is a clean, well-documented, 
>>> solution by using `:::`
>> 
>> Who is calling this function:  package code or user code?  I assume 
>> it's a bit of a mix:  your package writes a script that calls the 
>> function when it runs in user space.  (It would help if you gave an 
>> explicit example of when you need to use this technique.)
>> 
>> If my assumption is correct, there are other simple workarounds 
>> besides exporting the functions.  Instead of putting
>> 
>>  pkg:::foo(args)
>> 
>> into your script, put
>> 
>>  pkg::callInternal("foo", args)
>> 
>> where pkg::callInternal is an exported function that can look up
>unexported functions in the namespace.
>> 
>> You may argue that you prefer pkg:::foo for some reason:  to which
>I'd respond that you are being rude to the CRAN volunteers.  I've
>offered two options (one in the previous thread, a different one here),
>and there was a third one in that thread offered by Ivan Krylov. 
>Surely one of these is good enough for your needs, and you shouldn't
>force CRAN to handle you specially.
>> 
>> Duncan
>> 
>>>
>>> I argue `:::` is the only clean solution to this problem and no
>dirty 
>>> work-arounds are necessary. This is a prime example of where `:::`
>is 
>>> actually useful and needed inside a package. If the R community 
>>> disagrees, I think R CMD check should at least emit a WARNING
>instead 
>>> of a NOTE and elaborate on the problem and accepted work-arounds in 
>>> "Writing R extensions". Or keep emitting a NOTE but listing those 
>>> nebulous reasons where `:::` would be tolerated inside a package.
>>> Having more transparent criteria for 

Re: [R-pkg-devel] failing on win and debian -- because of new submission?

[Jeff Newmiller]

I would not read anything into this. Does [1] help?

[1] https://jef.works/blog/2018/06/18/get-your-package-on-cran-in-10-steps/

On September 12, 2020 1:58:15 PM PDT, Simit Patel  wrote:
>hello,
>
> 
>i am submitting my first package for CRAN, but am failing pre-check on
>windows and debian. below is an excerpt from the failure message:
>
> 
>
>package wordpressr_0.1.0.tar.gz does not pass the incoming checks
>automatically, please see the following pre-tests:
>Windows:
>
>Status: 1 NOTE
>Debian:
>
>Status: 1 NOTE
>
> 
>as the logs confirm, the only note is related to this being a new
>submission. should i email CRAN staff noting that this is a
>false-positive that should be reviewed? 
>
> 
>any and all help is most appreciated!
>
> 
>thanks
>
>simit 
>
> 
>-- 
>
>URL: https://sixjupiter.com
>
>Email: si...@sixjupiter.com
>
>Phone/SMS/whatsapp: +1 646 327 3895
>
>Skype: simitp_1
>
>Telegram: @SimitPatel
>
> 
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] DOI for archived package?

[Jeff Newmiller]

If your article is published with a DOI and read by anyone actually interested 
in it then it will be likely be accessed, so "never" seems rather pessimistic 
of you. You could simply not argue with your editor and acquiesce.



On September 10, 2020 9:14:12 AM PDT, "Kevin R. Coombes" 
 wrote:
>Hi,
>
>I am in the process of submitting a "workflow" article about an R 
>package (which is onCRAN) to F1000Research. The associate editor that I
>
>am dealing with wants a "DOI" for the source code of the package being 
>described in the manuscript.  I have already explained that CRAN 
>archives all versions of packages, and I sent him the URL to the
>archive 
>page for the package, However, he still seems to believe that a DOI 
>needs to be assigned by some site like Zenodo.
>
>I haven't yet responded by pointing out that CRAN has been archiving
>all 
>versions of packages since at least the year 2000, it has mirrors all 
>over the world, and the URL/URI used here is likely to be far more 
>permanent than the DOI from Zenodo. Nor have I pointed out that there 
>are more than 15,000 packages at CRAN, nor that not a single R user 
>would ever think to go look on Zenodo for an R package.
>
>Does anyone have other suggestions for how to respond? (I know;  I
>could 
>just put the [expletive] thing into Zenodo and move on, but creating a 
>permanent identifier for something that will *never *be accessed just 
>seems stupid.)
>
>Thanks,
>   Kevin
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

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

[Jeff Newmiller]

The whole point of the Suggests package relationship is that you don't actually 
have to have it installed to use the package. It does have to be installed to 
check the package, which allows the link to be tested at least once before 
being released.

On August 7, 2020 8:02:47 AM PDT, "Brian G. Peterson"  
wrote:
>
>On Fri, 2020-08-07 at 15:46 +0100, Gábor Csárdi wrote:
>> If you want to link to a package in the documentation, you'll have to
>> add it to Suggests.
>
>This doesn't make any sense.  If you don't use the code from that
>package anywhere, then a cross-reference to that package should not
>require the extra dependency in Suggests.  
>
>Cross references should be able to point to other functionality that
>might be useful to the user, or might add extra depth of understanding
>to a concept.  If the user doesn't have the package installed, no
>worries, it is just a cross reference.
>
>The requirement you are suggesting is also not discussed in Writing R
>Extensions:
>
>https://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Cross_002dreferences
>
>In fact, it explicitly allows links to potentially uninstalled
>packages.
>
>Regards,
>
>Brian
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Error in CHECK caused by dev.off()

[Jeff Newmiller]

I suspect your foo and bar variables are not logical anymore... insufficient 
info. However, why aren't you using short-circuit && and || operators?

On July 22, 2020 5:36:06 AM PDT, "Helmut Schütz"  
wrote:
>Dear all,
>
>I have two variables, foo and bar. The first is TRUE if a png should be
>
>created and the second is TRUE if an already existing one should be 
>overwritten.
>At the end of the plot I had
>if (foo | (foo & bar)) dev.off()
>This worked as expected in all versions of my package built in R up to 
>v3.6.3. However, when I CHECK the package in v4.0.2 I get:
> > grDevices::dev.off()
>Error in grDevices::dev.off() :
>   cannot shut down device 1 (the null device)
>Execution halted
>
>I tried:
>if (foo | (foo & bar)) {
>   dev <- dev.list()
>   if (!is.null(dev)) {
>     if (dev == 2) invisible(dev.off())
>   }
>}
>without success (same error).
>
>Even the more general
>if (foo | (foo & bar)) {
>   graphics.off()
>}
>did not work.
>
>The plot is called only in an example of one man-page -- though
>embedded 
>in \donttest{}.
>Even if I set both foo and bar to FALSE (i.e., the respective part of 
>the code should not be executed at all), I get the same error.
>
>Any ideas/suggestions?
>
>Regards,
>Helmut

-- 
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] [External] Re: Interpret feedback: not write testthat-tests in examples

[Jeff Newmiller]

Looks like 187 opportunities to improve clarity.

On July 16, 2020 11:30:37 AM PDT, Ben Bolker  wrote:
>FWIW/in defense of the OP, this is a *very* common idiom in the base R 
>code base.  There may be some false positives, but
>
> find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc |
>wc
>
>lists 187 files, e.g. from src/library/utils/man/object.size.Rd
>
>stopifnot(identical( ## assert that all three are the same :
>  unique(substr(as.vector(fsl), 1,5)),
>  format(round(as.vector(sl)/1024, 1
>
>
>On 7/16/20 2:02 PM, luke-tier...@uiowa.edu wrote:
>> On Thu, 16 Jul 2020, Henrik Bengtsson wrote:
>>
>>> If the point of having, say,
>>>
>>> stopifnot(add(1, 2) == sum(c(1, 2))
>>>
>>> is to make it explicit to the reader that your add() function gives
>>> the same results as sum(), then I argue that is valid to use in an
>>> example.  I'm pretty sure I've used that in some of my examples. 
>For
>>> the purpose, there should be no reason why you can't use other
>>> "assert" functions for this purpose, e.g.
>>>
>>> testthat::expect_equal(add(1, 2), sum(c(1, 2))
>>
>> If the point is to communicate this to users I would write something
>like
>>
>> ## The following evaluates to TRUE:
>> add(1, 2) == sum(c(1, 2)
>>
>> Using stopifnot just adds clutter that obscures the message for a
>> human reader; testthat::expect_equal even more so.
>>
>> Best,
>>
>> luke
>>
>>>
>>> Now, if the point of your "assert" statement is only to validate
>your
>>> package/code, then I agree it should not be in the example code
>>> because it adds clutter.  Such validation should be in a package
>test.
>>>
>>> So, if the former, I suggest you reply to the CRAN Team and explain 
>>> this.
>>>
>>> /Henrik
>>>
>>> On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
>>>  wrote:

 Dear R package developers,

 I would enjoy some help regarding some feedback I got on my package
>
 from a CRAN volunteer, as I am unsure how to interpret this
>correctly.

 This is the feedback I got (I added '[do]'):

> Please [do] not write testthat-tests in your examples.

 I wonder if this is about using `testthat` or using tests in
>general.

 To simplify the context, say I wrote a package with a function 
 called `add`, that adds two numbers. My example code would then be 
 something like this:

 ```
 library(testthat)

 expect_equal(add(1, 2), 3)
 ```

 The first interpretation is about using `testthat`: maybe I should 
 use base R (`stopifnot`) or another testing library (`testit`) or 
 hand-craft it myself?

 The second interpretation is about using tests in example code. I 
 like to actively demonstrate that my code works as expected. I 
 checked the policies regarding examples, and I could not find a
>rule 
 that I should refrain from doing so.

 What is the correct response to this feedback?

 Thanks for your guidance, Richel Bilderbeek

 __
 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

-- 
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] Interpret feedback: not write testthat-tests in examples

[Jeff Newmiller]

The point of an example is to provide an illustration of how the function 
should be used for people who are not software developers. IMO any use of any 
other functions should be absolutely minimized to reduce the cognitive overload 
("you need to understand 13 other concepts before you can understand what this 
function does"). Even stopifnot is in my view best avoided, and if you choose 
to use it then the use of that function should come _after_ the use of the 
function so it can be ignored by the reader without disrupting their reading of 
the example.

Complex interactions between functions should be described in vignettes, and 
tests should be stored in test code. R package help already has a reputation 
for being obtuse to beginners and mixing tests into examples exacerbates that 
perception.

On July 16, 2020 10:39:45 AM PDT, Henrik Bengtsson  
wrote:
>If the point of having, say,
>
>stopifnot(add(1, 2) == sum(c(1, 2))
>
>is to make it explicit to the reader that your add() function gives
>the same results as sum(), then I argue that is valid to use in an
>example.  I'm pretty sure I've used that in some of my examples.  For
>the purpose, there should be no reason why you can't use other
>"assert" functions for this purpose, e.g.
>
>testthat::expect_equal(add(1, 2), sum(c(1, 2))
>
>Now, if the point of your "assert" statement is only to validate your
>package/code, then I agree it should not be in the example code
>because it adds clutter.  Such validation should be in a package test.
>
>So, if the former, I suggest you reply to the CRAN Team and explain
>this.
>
>/Henrik
>
>On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
> wrote:
>>
>> Dear R package developers,
>>
>> I would enjoy some help regarding some feedback I got on my package
>from a CRAN volunteer, as I am unsure how to interpret this correctly.
>>
>> This is the feedback I got (I added '[do]'):
>>
>> > Please [do] not write testthat-tests in your examples.
>>
>> I wonder if this is about using `testthat` or using tests in general.
>>
>> To simplify the context, say I wrote a package with a function called
>`add`, that adds two numbers. My example code would then be something
>like this:
>>
>> ```
>> library(testthat)
>>
>> expect_equal(add(1, 2), 3)
>> ```
>>
>> The first interpretation is about using `testthat`: maybe I should
>use base R (`stopifnot`) or another testing library (`testit`) or
>hand-craft it myself?
>>
>> The second interpretation is about using tests in example code. I
>like to actively demonstrate that my code works as expected. I checked
>the policies regarding examples, and I could not find a rule that I
>should refrain from doing so.
>>
>> What is the correct response to this feedback?
>>
>> Thanks for your guidance, Richel Bilderbeek
>>
>> __
>> 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

-- 
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] Getting two independent packages with identical S3 generics to dispatch each other's methods

[Jeff Newmiller]

Perhaps:

https://cran.r-project.org/web/packages/generics/index.html


On July 10, 2020 4:51:52 PM PDT, "Pavel N. Krivitsky"  
wrote:
>Dear All,
>
>I would like to have two packages that do not depend on each other that
>have an identical generic to be able to dispatch to each other's (non-
>conflicting) methods. If it is of interest, the background for why this
>is needed is given at the end of this e-mail.
>
>As it is, it looks like two packages that do not depend on each other
>both define a generic, they do not see each other's S3 methods. 
>
>For example, in the two attached minimal packages, which define and
>export generic foo() (identical in both packages) and methods
>foo.character() and foo.numeric() that are exported via S3method(), we
>get,
>
>> library(test.character)
>> foo("a")
>foo.character() called.
>> library(test.numeric)
>Attaching package: ‘test.numeric’
>The following object is masked from ‘package:test.character’:
>foo
>> foo(1)
>foo.numeric() called.
>> foo("a")
>Error in UseMethod("foo") : 
>no applicable method for 'foo' applied to an object of class
>"character"
>
>That is, test.numeric::foo() doesn't "see"
>test.character:::foo.character() and vice versa. Is there a way to make
>them see each other?
>
>This issue has arisen before, e.g. at
>https://stackoverflow.com/questions/25251136/how-to-conditionally-define-a-generic-function-in-r-namespace
>.
>
>The "clean" solution is, of course, to create a third package to define
>the generic that the two packages could import (and, if necessary,
>reexport). However, that involves creating an almost-empty package that
>then has to be submitted to CRAN, maintained, and add some amount of
>storage and computational overhead. Is there another way to do this
>that is transparent to the end user?
>
>
># Background
>
>This arose as a result of two packages (lme4 and ergm) both wanting to
>implement a simulate.formula() method, causing conflicts when the user
>wanted to use both at the same time.
>
>ergm has a mechanism for dispatching based on the class of the LHS of
>the formula. It does so by defining a generic, simulate_formula() which
>evaluates the formula's LHS and dispatches a method (e.g.,
>simulate_formula.()) based on that.
>
>Since lme4 and ergm generally use different LHSs, we are thinking of
>resolving the conflict by copying the LHS dispatching mechanism from
>ergm to lme4, and then defining our own summary_formula methods as
>needed.
>
>   Thank you in advance,
>   Pavel

-- 
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] data and load version 3

[Jeff Newmiller]

Your choice. Do you want to support people using older versions of R, or not?

On June 29, 2020 1:55:02 PM PDT, "Göran Broström"  wrote:
>I added two data sets (.rda) to my package eha, but when I build the
>new 
>version I get:
>
> WARNING: Added dependency on R >= 3.5.0 because serialized objects in 
>serialize/load version 3 cannot be read in older versions of R. 
>File(s) 
>containing such objects: ‘eha/data/swedeaths.rda’ 
>‘eha/data/swepop.rda’
>
>In DESCRIPTION I have 'Depends: R (>= 3.0.0)'
>
>After googling for a while (found nothing relevant in 'WRE'), I 
>understand that I have two options: (i) Change 'Depends' in DESCRIPTION
>
>as suggested, and (ii) using save with 'version = 2' for the new files.
>
>And, if I am recommended to choose (i), should I recreate the old data 
>files with 'version = 3'?
>
>My guess is go for (i) and version = 3 for all data files, but I feel 
>that I need advise.
>
>Thanks, Göran
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] package CatDataAnalysis

[Jeff Newmiller]

Data are not copyrightable. As long as you do not use the exact phrases from 
the book you should be okay. But if you don't agree, then you should not 
proceed, and complaining here is not going to fix this.

On June 28, 2020 11:22:41 AM PDT, Charles Geyer  wrote:
>That's where the copyright violation comes in.  Copying descriptions
>from
>the book is clear copyright violation unless it is so minimal as to be
>"fair use" and I have no idea where that line is.  Even Alan may not be
>free to add such descriptions.  I have no idea what his contract with
>Wiley
>says.
>
>So like I said in my original posting, good idea in an alternative
>universe
>where copyright law does not exist.
>
>On Sun, Jun 28, 2020 at 1:13 PM Jeff Newmiller
>
>wrote:
>
>> Just describe the nature of the data sets literally as though the
>book was
>> inaccessible. They are not asking you to describe how one should
>analyze
>> the the data, so there really shouldn't be any conflict with the book
>> content that your agreement with the author has not already resolved.
>>
>> If you feel you are being held to a higher standard than others have
>> been... that is life. As a user of packages I agree with the CRAN
>that
>> package documention should be usable on its own.
>>
>> On June 28, 2020 10:58:15 AM PDT, Charles Geyer
>
>> wrote:
>> >CRAN did not just ask for an expanded Description field.  They
>> >instructed
>> >"Tell the users what the datasets are about and what they contain so
>> >they
>> >can use them even when they haven't read your book".  AFAIK no CRAN
>> >package
>> >that goes with a book satisfies that.
>> >
>> >On Sun, Jun 28, 2020 at 12:52 PM Max Turgeon
>
>> >wrote:
>> >
>> >> Fair enough. But CRAN is clearly asking for a more detailed
>> >Description
>> >> field. I simply offered one suggestion for expanding it. Keep in
>mind
>> >> that users will typically see the DESCRIPTION file first, and not
>the
>> >help
>> >> pages.
>> >>
>> >>
>> >> Max Turgeon
>> >> Assistant Professor
>> >> Department of Statistics
>> >> Department of Computer Science
>> >> University of Manitoba
>> >> maxturgeon.ca
>> >>
>> >>
>> >> --
>> >> *From:* Charles Geyer 
>> >> *Sent:* June 28, 2020 12:48:06 PM
>> >> *To:* Max Turgeon
>> >> *Cc:* R Package Development
>> >> *Subject:* Re: [R-pkg-devel] package CatDataAnalysis
>> >>
>> >> *Caution:* This message was sent from outside the University of
>> >Manitoba.
>> >> The link to Alan's web site is on every help page (in the source
>> >> section).  That's where the source is supposed to be.
>> >>
>> >> I have no problem with adding the source to the DESCRIPTION file,
>but
>> >that
>> >> is not what CRAN asked me to do.
>> >>
>> >> On Sun, Jun 28, 2020 at 12:16 PM Max Turgeon
>> >
>> >> wrote:
>> >>
>> >>> For what it's worth, I'd be inclined to interpreting CRAN's
>response
>> >>> *very* literally, i.e. your Description field is not descriptive
>> >enough.
>> >>> According to what I can see in the Github repo, you only have
>> >>>
>> >>>
>> >>> "Datasets used in the book Categorical Data Analysis by Agresti
>but
>> >not
>> >>> printed in the book."
>> >>>
>> >>>
>> >>> Which is not much more than what the Title field says. One
>glaring
>> >>> omission (IMO) from the Description field is any mention of
>> >Agresti's
>> >>> website, where the data comes from.
>> >>>
>> >>>
>> >>> In contrast, looking at the "woolridge" package, I can see from
>the
>> >>> Description field that it contains 111 datasets (well, that's in
>the
>> >Title
>> >>> field), it's about econometrics, and the purpose of the package
>is
>> >to make
>> >>> it easier for students to work with these datasets.
>> >>>
>> >>>
>> >>> Max Turgeon
>> >>> Assistant Professor
>> >>> Department of Statistics
>> >>> Department of Computer Science
>> >>> University of Manitoba
>> >>> maxturgeo

Re: [R-pkg-devel] package CatDataAnalysis

[Jeff Newmiller]

Just describe the nature of the data sets literally as though the book was 
inaccessible. They are not asking you to describe how one should analyze the 
the data, so there really shouldn't be any conflict with the book content that 
your agreement with the author has not already resolved.

If you feel you are being held to a higher standard than others have been... 
that is life. As a user of packages I agree with the CRAN that package 
documention should be usable on its own.

On June 28, 2020 10:58:15 AM PDT, Charles Geyer  wrote:
>CRAN did not just ask for an expanded Description field.  They
>instructed
>"Tell the users what the datasets are about and what they contain so
>they
>can use them even when they haven't read your book".  AFAIK no CRAN
>package
>that goes with a book satisfies that.
>
>On Sun, Jun 28, 2020 at 12:52 PM Max Turgeon 
>wrote:
>
>> Fair enough. But CRAN is clearly asking for a more detailed
>Description
>> field. I simply offered one suggestion for expanding it. Keep in mind
>> that users will typically see the DESCRIPTION file first, and not the
>help
>> pages.
>>
>>
>> Max Turgeon
>> Assistant Professor
>> Department of Statistics
>> Department of Computer Science
>> University of Manitoba
>> maxturgeon.ca
>>
>>
>> --
>> *From:* Charles Geyer 
>> *Sent:* June 28, 2020 12:48:06 PM
>> *To:* Max Turgeon
>> *Cc:* R Package Development
>> *Subject:* Re: [R-pkg-devel] package CatDataAnalysis
>>
>> *Caution:* This message was sent from outside the University of
>Manitoba.
>> The link to Alan's web site is on every help page (in the source
>> section).  That's where the source is supposed to be.
>>
>> I have no problem with adding the source to the DESCRIPTION file, but
>that
>> is not what CRAN asked me to do.
>>
>> On Sun, Jun 28, 2020 at 12:16 PM Max Turgeon
>
>> wrote:
>>
>>> For what it's worth, I'd be inclined to interpreting CRAN's response
>>> *very* literally, i.e. your Description field is not descriptive
>enough.
>>> According to what I can see in the Github repo, you only have
>>>
>>>
>>> "Datasets used in the book Categorical Data Analysis by Agresti but
>not
>>> printed in the book."
>>>
>>>
>>> Which is not much more than what the Title field says. One glaring
>>> omission (IMO) from the Description field is any mention of
>Agresti's
>>> website, where the data comes from.
>>>
>>>
>>> In contrast, looking at the "woolridge" package, I can see from the
>>> Description field that it contains 111 datasets (well, that's in the
>Title
>>> field), it's about econometrics, and the purpose of the package is
>to make
>>> it easier for students to work with these datasets.
>>>
>>>
>>> Max Turgeon
>>> Assistant Professor
>>> Department of Statistics
>>> Department of Computer Science
>>> University of Manitoba
>>> maxturgeon.ca
>>>
>>>
>>>
>>>
>>> --
>>> *From:* R-package-devel  on
>>> behalf of Charles Geyer 
>>> *Sent:* June 28, 2020 11:38 AM
>>> *To:* Neal Fultz
>>> *Cc:* R Package Development
>>> *Subject:* Re: [R-pkg-devel] package CatDataAnalysis
>>>
>>> 
>>> Caution: This message was sent from outside the University of
>Manitoba.
>>> 
>>>
>>> Actually the wooldridge package does not seem to satisfy any of the
>>> specific requests CRAN asked me for.  I have checked several other
>CRAN
>>> packages for textbooks and they don't seem to satisfy those
>requirements
>>> either.  So this seems to be a new idea from CRAN.
>>>
>>> On Sun, Jun 28, 2020 at 11:32 AM Neal Fultz 
>wrote:
>>>
>>> > I'm not sure exactly what cran is asking for, but the wooldridge
>>> > package is a good example of a text book data set package, so
>maybe
>>> > you can use the same format they did.
>>> >
>>> > https://cran.r-project.org/web/packages/wooldridge/index.html
>>> >
>>> > Best,
>>> >
>>> > Neal
>>> >
>>> > On Sun, Jun 28, 2020 at 9:08 AM Charles Geyer
>
>>> > wrote:
>>> > >
>>> > > I have a package that has the datasets for Categorical Data
>Analysis
>>> by
>>> > > Agresti that do not appear in the book.  The whole package is a
>github
>>> > repo
>>> > > https://github.com/cjgeyer/CatDataAnalysis.  All of the data
>were
>>> > > translated mechanically using the R script foo.R included in the
>repo
>>> > (but
>>> > > not in the package) from Agresti's web site
>>> > > http://www.stat.ufl.edu/~aa/cda/data.html.
>>> > >
>>> > > This package seems to be a useful service to students and
>teachers.
>>> The
>>> > > data
>>> > > are much simpler to use with this package than trying to get the
>data
>>> > from
>>> > > Agresti's web page (foo.R has 277 lines of code).
>>> > >
>>> > > When I submitted the package to CRAN, I got the following
>response.
>>> > >
>>> > > > The Description field of the DESCRIPTION file is intended to
>be a
>>> (one
>>> > > > paragraph) description of what the package does and why it may
>be
>>> > > > useful. 

Re: [R-pkg-devel] Problem with test data folder. R package develpoment

[Jeff Newmiller]

Use a different name than "data" such as "rawdata" within "inst" to put files 
that your code refers to using the system.name() function. The directory name 
"data" is used for a specific purpose as described in the Writing R Extensions 
manual [1], and if you want to put files in that directory following those 
special requirements then they must be in the top level "data" directory.

[1] 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Data-in-packages

On June 14, 2020 1:55:50 AM PDT, Subhadip Datta  
wrote:
>I attached my test data in inst/data but why this warning is showing.
>"Found the following non-empty subdirectories of 'inst' also used by R:
>inst/data
> It is recommended not to interfere with package subdirectories used by
>  R."
>This is not a problem from my side.  It used the data from that
>directory but showed an error for the folder.

-- 
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] [R] a question of etiquette

[Jeff Newmiller]

The obvious answer is simply to refer to GPL. It isn't necessary to propagate a 
derogatory point of view by finding another word for an incorrect idea.  Try 
re-reading my previous words without trying to hold on to a flawed 
interpretation.

On June 2, 2020 5:33:56 PM PDT, Avraham Adler  wrote:
>Apologies; my intent was not to disparage, but that is the term is used
>in
>the industry and in venues which discuss FLOSS because it reflects that
>the
>addition of one component with that kind of copyleft license causes the
>entire project to need that particular copyleft license. If there is a
>term
>which reflects that mechanism from a discipline other than biology,
>please let me know.
>
>Thanks,
>
>Avi
>
>On Tue, Jun 2, 2020 at 8:25 PM Jeff Newmiller
>
>wrote:
>
>> "Viral" is has connotations that reflect the biases of the person
>using
>> the term. A less loaded perspective is that some people don't want
>you to
>> take their contributions out of circulation by using it as the
>foundation
>> of your proprietary work. If you want to close it up, build from
>scratch or
>> find some other code that isn't GPL.
>>
>> Describing it as "viral" makes it sound as if they were trying to
>steal
>> something you did instead of protecting their code from being stolen.
>> Please refrain from being inflammatory.
>>
>> On June 2, 2020 4:49:25 PM PDT, Avraham Adler
>
>> wrote:
>> >IANAL, but the GPL family of licenses is VIRAL copy left so it
>infects
>> >anything it touched, which is why many shy away and prefer something
>> >like
>> >the Mozilla Public License 2 (MPL) as a compromise between viral
>> >copyleft
>> >and the permissive MIT/ISC/BSD2.
>> >
>> >Avi
>> >
>> >On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:
>> >
>> >> Spencer,
>> >>
>> >> I apologize for my obvious (in hindsight) error in bringing up the
>> >topic.
>> >> I will bring up one example, because of your request. Google has
>> >listed
>> >> GPL-1, 2, and 3 as one of several licenses that are restricted and
>> >cannot
>> >> be used by a Google product delivered to outside customers. This
>> >include
>> >> downloadable client software and software such as insdie the
>Google
>> >Search
>> >> Appliance. This includes having scripts that load packages
>> >dynamically as
>> >> with “library()” and “require()”. Please see
>> >> https://opensource.google/docs/thirdparty/licenses/#restricted for
>> >their
>> >> wording.
>> >>
>> >> I am not defending their position and disagree with it. However,
>it
>> >is
>> >> their position based on what I think is a conservative or overly
>> >cautious
>> >> legal interpretation. I am not a lawyer, however, so my opinions
>are
>> >of no
>> >> import.
>> >>
>> >> Mark
>> >> R. Mark Sharp, Ph.D.
>> >> Data Scientist and Biomedical Statistical Consu
>>
><https://www.google.com/maps/search/a+Scientist+and+Biomedical+Statistical+Consu?entry=gmail=g>
>> ltant
>> >> 7526 Meadow Green St.
>> >> San Antonio, TX 78251
>> >> mobile: 210-218-2868
>> >> rmsh...@me.com
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
>> >> spencer.gra...@effectivedefense.org> wrote:
>> >> >
>> >> >   Can Dr. Sharp kindly provide a credible reference,
>discussing
>> >the
>> >> alleged ambiguities in GPL-2 and GPL-3 that convince some
>companies
>> >to
>> >> avoid them?
>> >> >
>> >> >
>> >> >   I like Wikimedia Foundation projects like Wikipedia, where
>> >almost
>> >> anyone can change almost anything, and what stays tends to be
>written
>> >from
>> >> a neutral point of view, citing credible sources.  I get several
>> >emails a
>> >> day notifying me of changes in articles I'm "watching".  FUD,
>> >vandalism,
>> >> etc., are generally reverted fairly quickly or moved to the "Talk"
>> >page
>> >> associated with each article, where the world is invited to
>provide
>> >> credible so

Re: [R-pkg-devel] [R] a question of etiquette

[Jeff Newmiller]

"Viral" is has connotations that reflect the biases of the person using the 
term. A less loaded perspective is that some people don't want you to take 
their contributions out of circulation by using it as the foundation of your 
proprietary work. If you want to close it up, build from scratch or find some 
other code that isn't GPL.

Describing it as "viral" makes it sound as if they were trying to steal 
something you did instead of protecting their code from being stolen. Please 
refrain from being inflammatory.

On June 2, 2020 4:49:25 PM PDT, Avraham Adler  wrote:
>IANAL, but the GPL family of licenses is VIRAL copy left so it infects
>anything it touched, which is why many shy away and prefer something
>like
>the Mozilla Public License 2 (MPL) as a compromise between viral
>copyleft
>and the permissive MIT/ISC/BSD2.
>
>Avi
>
>On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:
>
>> Spencer,
>>
>> I apologize for my obvious (in hindsight) error in bringing up the
>topic.
>> I will bring up one example, because of your request. Google has
>listed
>> GPL-1, 2, and 3 as one of several licenses that are restricted and
>cannot
>> be used by a Google product delivered to outside customers. This
>include
>> downloadable client software and software such as insdie the Google
>Search
>> Appliance. This includes having scripts that load packages
>dynamically as
>> with “library()” and “require()”. Please see
>> https://opensource.google/docs/thirdparty/licenses/#restricted for
>their
>> wording.
>>
>> I am not defending their position and disagree with it. However, it
>is
>> their position based on what I think is a conservative or overly
>cautious
>> legal interpretation. I am not a lawyer, however, so my opinions are
>of no
>> import.
>>
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
>> spencer.gra...@effectivedefense.org> wrote:
>> >
>> >   Can Dr. Sharp kindly provide a credible reference, discussing
>the
>> alleged ambiguities in GPL-2 and GPL-3 that convince some companies
>to
>> avoid them?
>> >
>> >
>> >   I like Wikimedia Foundation projects like Wikipedia, where
>almost
>> anyone can change almost anything, and what stays tends to be written
>from
>> a neutral point of view, citing credible sources.  I get several
>emails a
>> day notifying me of changes in articles I'm "watching".  FUD,
>vandalism,
>> etc., are generally reverted fairly quickly or moved to the "Talk"
>page
>> associated with each article, where the world is invited to provide
>> credible source(s).
>> >
>> >
>> >   Spencer Graves
>> >
>> >
>> > On 2020-06-02 10:12, Dirk Eddelbuettel wrote:
>> >> On 2 June 2020 at 10:06, R. Mark Sharp wrote:
>> >> | The GPL-2 and GPL-3 licenses are apparently sufficiently
>ambiguous in
>> the legal community that some companies avoid them.
>> >>
>> >> Wittgenstein:  'That whereof we cannot speak, thereof we must
>remain
>> silent'
>> >>
>> >> This is a mailing list of the R project. R is a GNU Project. R is
>> licensed
>> >> under the GPL, version two or later. That has not stopped large
>> corporations
>> >> from using R, adopting R, or starting or acquiring R related
>businesses.
>> >>
>> >> If you have a strong urge to spread FUD about the GPL and R, could
>you
>> have the
>> >> modicum of etiquette to not do it on a mailing list of the R
>Project?
>> >>
>> >> Dirk
>> >>
>> >
>> > __
>> > 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>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?

[Jeff Newmiller]

Each call to system is independent, so it definitely is a problem.

Use Sys.setenv to make changes in environment variables that can be used within 
system calls.

Bash is not involved with the system call on Windows... so your syntax for 
setting an environment variable is not portable.

On June 1, 2020 11:10:41 AM PDT, Jan Gorecki  wrote:
>Thank you Jeff for your comments.
>Yet they does not seem to be related.
>a) Environment variable is created inside `system` command, so env var
>stays valid for the command. Which is confirmed in the first call that
>properly shows CFLAGS.
>b) Syntax passed checkbashisms so I expect no problems due to that.
>
>On Mon, Jun 1, 2020 at 4:03 PM Jeff Newmiller
> wrote:
>>
>> I don't know anything about the function of that environment
>variable, but
>>
>> a) system() invokes a child process so environment variable changes
>made using it will only affect the child process created by that system
>call.
>>
>> b) The syntax you have used is shell-specific, so does not look
>portable.
>>
>> On June 1, 2020 4:58:19 AM PDT, Jan Gorecki 
>wrote:
>> >Hi package devel support,
>> >
>> >I am trying to use R_MAKEVARS_USER to customize build, rather than
>> >.R/Makevars. It is properly displayed from config CFLAGS but during
>> >package install it doesn't seem to work.
>> >
>> >In R-admin in "6.3.3 Customizing package compilation" there is:
>> >
>> >> Note that these mechanisms do not work with packages which fail to
>> >pass settings down to sub-makes, perhaps reading etc/Makeconf in
>> >makefiles in subdirectories.
>> >
>> >It seems that it applies to me. How should I debug that? to make
>this
>> >env var respected? Note that my pkg has src/Makevars to handle
>openmp
>> >switch nicely
>> >Thank you
>> >
>> >system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config
>CFLAGS")
>> >-O3
>> >
>> >system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
>> >--library=library/gcc/O3 mypkg_1.0.0.tar.gz")
>> >* installing *source* package 'mypkg' ...
>> >** using staged installation
>> >** libs
>> >gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic 
>-g
>> >-O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
>> >-fstack-protector-strong -Wformat -Werror=format-security
>-Wdate-time
>> >-D_FORTIFY_SOURCE=2 -g  -c assign.c -o assign.o
>> >
>> >__
>> >R-package-devel@r-project.org mailing list
>> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> --
>> Sent from my phone. Please excuse my brevity.

-- 
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] R_MAKEVARS_USER fail to pass down to sub-makes?

[Jeff Newmiller]

I don't know anything about the function of that environment variable, but 

a) system() invokes a child process so environment variable changes made using 
it will only affect the child process created by that system call.

b) The syntax you have used is shell-specific, so does not look portable.

On June 1, 2020 4:58:19 AM PDT, Jan Gorecki  wrote:
>Hi package devel support,
>
>I am trying to use R_MAKEVARS_USER to customize build, rather than
>.R/Makevars. It is properly displayed from config CFLAGS but during
>package install it doesn't seem to work.
>
>In R-admin in "6.3.3 Customizing package compilation" there is:
>
>> Note that these mechanisms do not work with packages which fail to
>pass settings down to sub-makes, perhaps reading etc/Makeconf in
>makefiles in subdirectories.
>
>It seems that it applies to me. How should I debug that? to make this
>env var respected? Note that my pkg has src/Makevars to handle openmp
>switch nicely
>Thank you
>
>system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config CFLAGS")
>-O3
>
>system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
>--library=library/gcc/O3 mypkg_1.0.0.tar.gz")
>* installing *source* package 'mypkg' ...
>** using staged installation
>** libs
>gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic  -g
>-O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
>-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>-D_FORTIFY_SOURCE=2 -g  -c assign.c -o assign.o
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] References in DESCRIPTION file

[Jeff Newmiller]

Sorry, ESP not working today. Note that this list may or may not include the 
reviewer who last checked your submission.

Perhaps re-read [1] and if you are still puzzled then consider pointing us to 
(or pasting into the body of the email) the DESCRIPTION file you are having 
difficulty with so we don't have to engage psychic powers.

Oh, and DON'T post HTML-formatted email on the R mailing lists.

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

On May 25, 2020 7:38:51 AM PDT, "Cantin, Alan (NRCan/RNCan)" 
 wrote:
>Hi folks,
>
>Upon manual inspection of my package by CRAN maintainers I have been
>asked to put my references in the description field of the DESCRIPTION
>file. I have formatted all of my references as requested and put them
>there but get a note when checking the package (Malformed Description
>field: should contain one or more complete sentences.).  Does anyone
>have advice on how to place these here so I can clear this final hurdle
>to get the package back up on CRAN?
>
>Thanks,
>
>Alan Cantin
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Problems importing packages with SystemRequirements

[Jeff Newmiller]

Maybe your use of those packages represent use cases that are not tested by 
those packages. If you pare down your code that triggers these problems to 
small reproducible examples then you can contribute them to those packages?

On April 27, 2020 11:05:49 PM PDT, fvaf...@mailbox.org wrote:
>Dear All,
>I maintain a package that has issues 
>`sh: whoami: not found` and `sh: git: not found`
>(see
>https://cran.r-project.org/web/checks/check_results_packager.html),
>albeit not having any (declared or undeclared) external
>dependencies -- no calls to system() or system2().
>
>It does import functions from CRAN packages `whoami` and `git2r`,
>though. 
>Mysteriously to me, neither
>https://cran.r-project.org/web/checks/check_results_git2r.html
>nor 
>https://cran.r-project.org/web/checks/check_results_whoami.html
>show any issues.
>
>Has anybody any clue why this is so? 
>
>Thanks anyway,
>Dominik Cullmann
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] /usr/bin/ld: cannot find -ludev

[Jeff Newmiller]

This is a highly OS-specific dependency. Are you sure you need this? Is it 
listed in your SystemRequirements entry in your DESCRIPTION file?

On April 26, 2020 6:41:27 AM PDT, "Sameh M. Abdulah" 
 wrote:
>I am getting this error when trying to install my package on CRAN. Do I
>need to contact
>CRAN to include it on the CRAN system? or there is another solution.
>
>
>/usr/bin/ld: cannot find -ludev
>collect2: error: ld returned 1 exit status
>
>
>
>--Sameh
>
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Detritus in temp directory - Note from submission of R package in CRAN

[Jeff Newmiller]

I agree that my example was not optimal, but I was trying to duplicate the 
existing behaviour with the exception of use of global variables.

On April 18, 2020 3:02:17 PM PDT, Duncan Murdoch  
wrote:
>On 18/04/2020 5:55 p.m., Jeff Newmiller wrote:
>> See below:
>> 
>> On Sat, 18 Apr 2020, David Andres Zamora Avila wrote:
>> 
>>> Thanks for your answers.
>>> This a part of my script where it creates files and saves it in
>anything
>>> path. I am not pretty secure how use file.path() or tempdir(). Can
>you give
>>> me more details about it, please?
>>>
>>> if (!exists("path_pet")){
>>> path_pet <- getwd()
>>>   } else if (!exists("path_p")){
>>> path_p <- getwd()
>>>   } else if (!exists("path_p") | !exists("path_pet")){
>>> path_pet <- getwd()
>>> path_p <- getwd()
>>>   }
>> 
>> The above code should not exist. You are making a package, so you are
>> putting it into a function and either looking for the existence of
>global
>> variables (side effects! requiring user to use special variable
>names!
>> this is not good!), or the "path_pet" and "path_p" variables were
>created
>> in your function and you should already know that they exist.
>> 
>> If we assume that "path_pet" and "path_p" are parameters to this
>package
>> function you are writing, like so:
>> 
>> myfunc <- function( x, y, ..., path_pet = getwd(), path_p = getwd() )
>{
>> ...
>> }
>> 
>> then the user can let the default be the current working directory,
>or can
>> specify which directories the function should work in. Specifically,
>when
>> you are writing your examples or test code and pretending to be a
>user,
>> you can create a temporary directory and use it like so:
>
>I think your advice would probably pass the checks, but it's bad
>advice, 
>because it leaves the user vulnerable to having files wiped out by 
>myfunc().
>
>Functions shouldn't write to the current directory unless the user 
>explicitly asks for it.
>
>A better header would be
>
>myfunc <- function( x, y, ..., path_pet = temp.dir(), path_p = 
>temp.dir() ) {
>
>Then the user has to explicitly code "path_pet = getwd()" to wipe out 
>their own files.
>
>Duncan Murdoch
>
>> 
>> workingdir <- tempdir(TRUE)
>> result <- myfunc( A, B, path_pet = workingdir, path_p = workingdir )
>> 
>> which means you can then clean up after yourself with
>> 
>> unlink( workingdir, recursive = TRUE )
>> 
>> I don't think this question is really about R packages anymore... if
>you
>> still cannot read the help files to figure out your questions about
>how to
>> do manage temporary files then you should probably make a small
>> reproducible example(!!) and post a question on R-help.
>> 
>> (end of comments)
>> 
>>>   if (file_type == "raster"){
>>> #  identify raster format and loading
>>> if (format == "GTiff"){
>>>
>>>   if( length(list.files(path_pet, pattern = ".tif")) == 0 |
>length(
>>> list.files(path_p, pattern = ".tif")) == 0){
>>> stop("Not avaliable data of precipitation or
>evapotranspiration")
>>>   }
>>>   pet_files <- list.files(path_pet)
>>>   pet <- raster::stack(paste(path_pet, pet_files, sep = ""))
>>>   p_files <- list.files(path_p)
>>> Kind regards,
>>>
>>> David Zamora
>>>
>>> El jue., 16 abr. 2020 a las 17:12, Uwe Ligges (<
>>> lig...@statistik.tu-dortmund.de>) escribi?:
>>>
>>>>
>>>>
>>>> On 16.04.2020 20:09, Duncan Murdoch wrote:
>>>>> On 16/04/2020 1:11 p.m., David Andres Zamora Avila wrote:
>>>>>>Hi,
>>>>>>
>>>>>> I submitted my package in CRAN and always appearance the next
>NOTE.
>>>>>>
>>>>>> Flavor: r-devel-linux-x86_64-debian-gcc
>>>>>> Check: for detritus in the temp directory, Result: NOTE
>>>>>> Found the following files/directories:
>>>>>>   'RtmpcDoRWjr.nc'
>>>>>>
>>>>>> I have tried to solve it in several ways (like if(interactive()),
>but
>>>>>> I not
>>>>>> sure how can I solve it

Re: [R-pkg-devel] Detritus in temp directory - Note from submission of R package in CRAN

[Jeff Newmiller]

See below:

On Sat, 18 Apr 2020, David Andres Zamora Avila wrote:


Thanks for your answers.
This a part of my script where it creates files and saves it in anything
path. I am not pretty secure how use file.path() or tempdir(). Can you give
me more details about it, please?

if (!exists("path_pet")){
   path_pet <- getwd()
 } else if (!exists("path_p")){
   path_p <- getwd()
 } else if (!exists("path_p") | !exists("path_pet")){
   path_pet <- getwd()
   path_p <- getwd()
 }


The above code should not exist. You are making a package, so you are 
putting it into a function and either looking for the existence of global 
variables (side effects! requiring user to use special variable names! 
this is not good!), or the "path_pet" and "path_p" variables were created 
in your function and you should already know that they exist.


If we assume that "path_pet" and "path_p" are parameters to this package 
function you are writing, like so:


myfunc <- function( x, y, ..., path_pet = getwd(), path_p = getwd() ) {
  ...
}

then the user can let the default be the current working directory, or can 
specify which directories the function should work in. Specifically, when 
you are writing your examples or test code and pretending to be a user, 
you can create a temporary directory and use it like so:


workingdir <- tempdir(TRUE)
result <- myfunc( A, B, path_pet = workingdir, path_p = workingdir )

which means you can then clean up after yourself with

unlink( workingdir, recursive = TRUE )

I don't think this question is really about R packages anymore... if you 
still cannot read the help files to figure out your questions about how to 
do manage temporary files then you should probably make a small 
reproducible example(!!) and post a question on R-help.


(end of comments)


 if (file_type == "raster"){
   #  identify raster format and loading
   if (format == "GTiff"){

 if( length(list.files(path_pet, pattern = ".tif")) == 0 | length(
list.files(path_p, pattern = ".tif")) == 0){
   stop("Not avaliable data of precipitation or evapotranspiration")
 }
 pet_files <- list.files(path_pet)
 pet <- raster::stack(paste(path_pet, pet_files, sep = ""))
 p_files <- list.files(path_p)
Kind regards,

David Zamora

El jue., 16 abr. 2020 a las 17:12, Uwe Ligges (<
lig...@statistik.tu-dortmund.de>) escribi?:




On 16.04.2020 20:09, Duncan Murdoch wrote:

On 16/04/2020 1:11 p.m., David Andres Zamora Avila wrote:

  Hi,

I submitted my package in CRAN and always appearance the next NOTE.

Flavor: r-devel-linux-x86_64-debian-gcc
Check: for detritus in the temp directory, Result: NOTE
   Found the following files/directories:
 'RtmpcDoRWjr.nc'

I have tried to solve it in several ways (like if(interactive()), but
I not
sure how can I solve it.


How was the file created?  What the check wants is that you delete it
when you are finished with it.  You can use the unlink() function to do
that.


Or better create it in tempdir(): I guess you used paste(tempdir(), ...)
instead of file.path() and got afilename one level above tempdir()?

Best,
Uwe Ligges




Duncan Murdoch

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





--

David Zamora <https://sites.google.com/a/unal.edu.co/dazamoraa/>
PhD Student, Universidad Nacional de Colombia, Bogot?
phone: +571 3165000 ext 13406
address: Av. NQS (Carrera 30) # 45-03, Hydraulics Lab (408-213)
email: dazamo...@unal.edu.co

[[alternative HTML version deleted]]

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



---
Jeff NewmillerThe .   .  Go Live...
DCN:Basics: ##.#.   ##.#.  Live Go...
  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...1k

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

Re: [R-pkg-devel] Appropriate keyword in help file.

[Jeff Newmiller]

You can get away with a lot if you are not distributing your package. But I 
usually try to satisfy R CMD check at least.

On April 16, 2020 5:50:04 PM PDT, Rolf Turner  wrote:
>
>On 17/04/20 12:14 pm, Duncan Murdoch wrote:
>
>> On 16/04/2020 8:12 p.m., Rolf Turner wrote:
>>>
>>> I'm writing a package (just for my own use, for the time being at
>least)
>>> that contains a function for estimating the parameters of a
>>> distribution.  The function is essentially a wrapper for fitdistr()
>from
>>> the MASS package.
>>>
>>> When I looked at RShowDoc("KEYWORDS"), I could not find an
>appropriate
>>> keyword to use in the help file for this function.  There's "htest &
>>> Statistical Inference", but that's not right, since this function is
>>> about estimation, not hypothesis testing.  I'd hoped that there'd be
>a
>>> keyword "estimation" (or "point estimation") or something like that,
>but
>>> there isn't.
>>>
>>> I guess I can use "utilities" (???) or "misc", but these seem a bit
>>> unsatisfactory.
>>>
>>> Can anyone suggest a better idea?
>> 
>> Don't use any keyword. When was the last time you searched on one?
>
>
>I have *never* in my life searched on a keyword! :-)
>
>I just thought that it was an Immutable Law of the Universe that a help
>
>file had to have at least one keyword, and that the R Gods would rain 
>fire and brimstone down upon one's head if no keyword was supplied.
>
>In a similar vein:  would the R Gods allow me to make up my own keyword
>
>rather than choosing from those listed by RShowDoc("KEYWORDS")?
>
>Thanks.
>
>cheers,
>
>Rolf

-- 
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] Add SystemRequirements of imported package in description file?

[Jeff Newmiller]

AFAIK, no, though if the upstream package cannot (or won't) be implemented 
without that system requirement and it really is a requirement for this package 
then you might want to indicate "libzzz via Package X" just to be clear for 
users. If it isn't a requirement for most of your functionality then you may 
want to use Suggests to alleviate the problem.

On April 9, 2020 12:51:56 AM PDT, Dominik Leutnant  
wrote:
>Hi all,
>
>should “SystemRequirements” of an imported package be listed in the
>description file of a package?
>
>General scenario:
>- Package X imports Package Y.
>- Package Y lists “libzzz” as SystemRequirements.
>
>Should Package X list the SystemRequirements “libzzz” as well?
>(question occurred @ https://github.com/dleutnant/influxdbr/issues/47)
>
>Thank you and happy easter!
>Dominik
>
>
>
>Dr. Dominik Leutnant
>Department of Civil Engineering
>Institute for Infrastucture·Water·Resources·Environment (IWARU)
>WG Urban Hydrology and Water Management
>
>Muenster University of Applied Sciences
>Corrensstr. 25
>FRG-48149 Münster
>Germany
>
>Tel.:  +49 (0) 251/83-65274
>Mail:  leutn...@fh-muenster.de
>Web: https://www.fh-muenster.de/
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Jeff Newmiller]

I did not say "interfere"... I said "problems with consistency". I don't think 
your wholesale import of functions without corresponding help pages is 
consistent with the normal use of R, which will make reading R code written 
with this mechanism in place a painful source of trouble for help forums.

On the other hand, if the code is prefaced with an environment name then there 
will be no expectation that a help page should exist on the part of someone 
reading that code for the first time. (It will be no less obscure, but at least 
it won't be misleading.)

On April 7, 2020 9:40:02 AM PDT, Stefan Lenz IMBI  
wrote:
>Thank you very much for your comment. 
>Could you elaborate how you think that it could interfere with the help
>system?
>I haven't yet connected the Julia help with the R help, as the R help
>system is quite complex and RStudio handles it again differently. So
>it's simply like the functions were declared on the command line. They
>have no help.
>A simply way to print the help for a Julia function, e.g. the function
>"first", is to call
> juliaEval("@doc first")
>This then simply prints the output on the command line.
>
> 
>ursprüngliche Nachricht-
>Von: Jeff Newmiller [jdnew...@dcn.davis.ca.us]
>An: r-package-devel@r-project.org, Duncan Murdoch
>[murdoch.dun...@gmail.com], Stefan Lenz IMBI
>[l...@imbi.uni-freiburg.de]
>Datum: Mon, 06 Apr 2020 10:51:53 -0700
>-
> 
> 
>> One could take the position that the library and require functions
>were a mistake 
>> to begin with and that all contributed packages should be accessed
>using ::... or 
>> one could recognize that these functions are an expected feature of R
>at this 
>> point and then it is not defensible to ban the proposed approach of
>importing 
>> names as Stefan wants to. I don't think it is fair to require this
>higher level of 
>> specificity just because it involves use of attach.
>> 
>> That said, another feature of R packages is the integrated help
>system... 
>> importing Julia functions wholesale may lead to problems with
>consistency in 
>> navigating the help files. IMO it may be justifiable to ban this
>particular 
>> syntactic convenience to maintain some separation in the minds of
>users looking 
>> for help on these new functions, since the syntactic and semantic
>structure of 
>> functions from another language may not align well with normal R
>functions. But I 
>> am not familiar with Julia or Stefan's package or the support it
>brings in this 
>> area... I just disagree with banning a "library" lookalike function
>"just 
>> because" it happens to involve attach.
>> 
>> On April 6, 2020 8:40:12 AM PDT, Duncan Murdoch
> 
>> wrote:
>>>On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:
>>>> Yes, as I wrote earlier, I would like to imitate the behaviour of
>>>loading an R package
>>>> 
>>>> juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
>>>> myJuliaFunction()
>>>> 
>>>> like R:
>>>> 
>>>> library("MyRPackage") # exports myRFunction
>>>> myRFunction()
>>>> 
>>>> I could return an environment, such that the call becomes
>>>> 
>>>> attach(juliaUsing("SomeJuliaPackage"))
>>>> myJuliaFunction()
>>>
>>>I wouldn't use it that way. I'd write it as
>>>
>>> sjp <- juliaUsing("SomeJuliaPackage")
>>> sjp$myJuliaFunction()
>>>
>>>This is similar to the advice to use pkg::foo() rather than
>>>library(pkg) 
>>>followed by plain foo() in the code.
>>>
>>>Duncan Murdoch
>>>
>>>> 
>>>> But calling juliaUsing(), as it is now, takes care that if a
>package
>>>is imported a second time,
>>>> the first data base is removed via detach().
>>>> This way, users do not have to worry about calling juliaUsing()
>>>mutliple times in a script, same
>>>> as R users don't have to worry about calling library() multiple
>>>times.
>>>> If you call the code with attach() multiple times and do not
>detach,
>>>you get your screen cluttered with
>>>> warnings "xxx is masked by xxx".
>>>> So I would say it would decrease user-friendliness to return an
>>>environment.
>>>> I also want to make explicit, that the call to attach
>>>> occurs only once in my code, after creating the environmen

Re: [R-pkg-devel] About dataset in my own package

[Jeff Newmiller]

Either use the data() function to retrieve it or use the

LazyData: true

line in your DESCRIPTION file.

On April 6, 2020 11:25:21 PM PDT, jared_wood  wrote:
>Dear all，
>
>I have three datasets (drugbank.rda edgar.rda mala.rda) in my package
>and I put them in the document folder which called “data”.
>
> 
>
>And I just use the dataset in the function. However, here comes a note:
>
> 
>
>drugbank_disease_gene: no visible binding for global variable
>
>'drugbank'
>
>  edgar_disease_gene: no visible binding for global variable 'edgar'
>
>  malacards_disease_gene: no visible binding for global variable 'mala'
>
>  Undefined global functions or variables:
>
>drugbank edgar mala
>
> 
>
>It shows that I need to do something else. I am confused and I don’
>know what need to do next.
>
> 
>
>Thanks for your attention. 
>
>| |
>jared_wood
>|
>|
>jared_w...@163.com
>|
>签名由网易邮箱大师定制
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Jeff Newmiller]

One could take the position that the library and require functions were a 
mistake to begin with and that all contributed packages should be accessed 
using ::...  or one could recognize that these functions are an expected 
feature of R at this point and then it is not defensible to ban the proposed 
approach of importing names as Stefan wants to. I don't think it is fair to 
require this higher level of specificity just because it involves use of attach.

That said, another feature of R packages is the integrated help system... 
importing Julia functions wholesale may lead to problems with consistency in 
navigating the help files. IMO it may be justifiable to ban this particular 
syntactic convenience to maintain some separation in the minds of users looking 
for help on these new functions, since the syntactic and semantic structure of 
functions from another language may not align well with normal R functions. But 
I am not familiar with Julia or Stefan's package or the support it brings in 
this area... I just disagree with banning a "library" lookalike function "just 
because" it happens to involve attach.

On April 6, 2020 8:40:12 AM PDT, Duncan Murdoch  
wrote:
>On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:
>> Yes, as I wrote earlier, I would like to imitate the behaviour of
>loading an R package
>> 
>>   juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
>>   myJuliaFunction()
>> 
>> like R:
>> 
>>   library("MyRPackage") # exports myRFunction
>>   myRFunction()
>> 
>> I could return an environment, such that the call becomes
>> 
>>   attach(juliaUsing("SomeJuliaPackage"))
>>   myJuliaFunction()
>
>I wouldn't use it that way.  I'd write it as
>
> sjp <- juliaUsing("SomeJuliaPackage")
> sjp$myJuliaFunction()
>
>This is similar to the advice to use pkg::foo() rather than
>library(pkg) 
>followed by plain foo() in the code.
>
>Duncan Murdoch
>
>> 
>> But calling juliaUsing(), as it is now, takes care that if a package
>is imported a second time,
>> the first data base is removed via detach().
>> This way, users do not have to worry about calling juliaUsing()
>mutliple times in a script, same
>> as R users don't have to worry about calling library() multiple
>times.
>> If you call the code with attach() multiple times and do not detach,
>you get your screen cluttered with
>> warnings "xxx is masked by xxx".
>> So I would say it would decrease user-friendliness to return an
>environment.
>> I also want to make explicit, that the call to attach
>> occurs only once in my code, after creating the environment:
>> 
>>   envName <- paste0("JuliaConnectoR:", absoluteModulePath)
>>   if (envName %in% search()) {
>>   detach(envName, character.only = TRUE)
>>   }
>>   attach(funenv, name = envName)
>> 
>> This code is only called by juliaImport() and juliaUsing(), which
>aren't called by any other function of
>> the package
>> and are supposed to be called directly by the user.
>> 
>> Stefan
>>   
>> ursprüngliche Nachricht-
>> Von: Duncan Murdoch [murdoch.dun...@gmail.com]
>> An: Dirk Eddelbuettel [e...@debian.org], Ben Bolker
>[bbol...@gmail.com]
>> Kopie: List r-package-devel [r-package-devel@r-project.org]
>> Datum: Mon, 6 Apr 2020 11:00:09 -0400
>> -
>>   
>>   
>>> On 06/04/2020 10:49 a.m., Dirk Eddelbuettel wrote:

 On 6 April 2020 at 08:38, Ben Bolker wrote:
 | Just reply to the CRAN maintainers and explain this situation.
>It¨s
 | slightly buried, but the e-mail you received does say:
 |
 | > If you are fairly certain the rejection is a false positive,
>please reply-all to this
 | > message and explain.

 True, but this misses the "Letter of the law" versus the "Spirit of
>the law".

 It might be worth mentioning that use of attach() is seen, to find
>one poor
 analogy, pretty much like use of global variables these days. "Just
>because
 you could does not mean you should".

 See e.g. one of the first google hits for 'r do not use attach'
>here:

>https://stackoverflow.com/questions/10067680/why-is-it-not-advisable-to-use-attach-in-r-and-what-should-i-use-instead
>>>
>>> I don't have a strong opinion on this: the proposed use seems to be
>no
>>> worse than library() or require(). Those are fine for users to use,
>but
>>> are discouraged in a package. If the attach() never happens without
>an
>>> explicit request from the user (and that's what it sounds like), I'd
>say
>>> it's probably okay.
>>>
>>> However, there is an easy workaround: just return the environment
>>> without attaching it. Then the user has the choice of attaching it,
>or
>>> using it as a prefix when they call the functions in it. So it's not
>as
>>> though this will destroy the utility of the package if Stefan isn't
>>> allowed to call attach().
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> 

Re: [R-pkg-devel] packaging biosig for R

[Jeff Newmiller]

I am just a lurker (not representing CRAN) but I am having a hard time 
understanding your question.

Binary packages are a convenience for users, not a method for submitting 
packages. When you have an R package accepted it is accepted in source format.
If it doesn't exclude support for Windows or MacOSX then it will (in time) be 
compiled into a binary form for distribution in addition to being distributed 
is source form.

As the maintainer, your responsibility is merely to confirm that your source 
package is properly configured to be built in binary form before you submit it 
to CRAN. This is normally accomplished by successfully building it as binary in 
a testing environment. There are various guides out there that can be helpful 
in accomplishing this, e.g. [1].

[1] https://kbroman.org/pkg_primer/pages/cran.html


On March 15, 2020 1:07:41 AM PDT, "Alois Schlögl"  
wrote:
>
>Dear R packagers,
>
>
>the Biosig project [1] supports reading of about 50 different data
>format [2]. Recently, a language binding to R was added, because a user
>of Biosig asked for it. 
>
>
>I've read the policy [3], and it seems the biosig would qualify as
>binary package. The underlying library (libbiosig) can be installed
>
>- on linux from source, or through debian/ubuntu package
>
>- on MacOSX through Homebrew.
>
>- for Windows I'm using MXE mingw-cross-compiler environment to build
>libbiosig.dll 
>
>
>Would it be feasible to provide a package of biosig on cran ? What need
>to be considered ?
>
>
>Kind regards
>
>   Alois
>
>
>
>[1] http://biosig.sourceforge.net/download.html
>
>[2] http://pub.ist.ac.at/~schloegl/biosig/TESTED
>
>[3] https://cran.r-project.org/web/packages/policies.html
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

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