Re: [R-pkg-devel] No email with confirmation link on resubmission of package

[Jeff Newmiller via R-package-devel]

Did you increment the version number?

On June 5, 2024 1:19:27 AM PDT, Paul Kabaila  wrote:
>(1) Today, I submitted my R package to CRAN using
>devtools::submit_cran()
>which  resulted in an  email from
>CRAN Package Submission Form 
>cransub...@xmbombadil.wu.ac.at
>with a confirmation link,  which I clicked on.
>
>(2) I was then sent an email from
>lig...@statistik.tu-dortmund.de
>which notified that my package "does not pass the incoming checks 
>automatically",
>with 0 errors, 0 warnings and 2 notes.
>
>
>(3) I then fixed the problem for one of the notes and explained the reason for 
>the
>other note and put this information into the file
>cran-comments.md
>Then I resubmitted my R package to CRAN using
>devtools::submit_cran()
>
>However, this time I did not receive an email with a confirmation link.
>
>Has my package been resubmitted or do I need to resubmit it in some different 
>way?
>
>Paul Kabaila
>
>
>La Trobe University | TEQSA PRV12132 - Australian University | CRICOS Provider 
>00115M
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

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