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

[Iris Simmons]

You put a space between "https:" and "//", you should definitely remove
that. Also, you need to indent your description. Right now, your
DESCRIPTION is being interpreted in this manner:

```
Package






   "neotoma2"






Title





 "Working with the
Neotoma Paleoecology Database"






 Date






 "2023-04-17"






  Version






  "1.0.0"






Authors@R
"\nc(person(given = \"Dominguez Vidana\",\n family =
\"Socorro\",\n role = c(\"aut\"),\n email = \"
s.doming...@ht-data.com\",\n comment =
structure(\"-0002-7926-4935\", .Names = \"ORCID\")),\n
 person(given = \"Simon\",\n family = \"Goring\",\n
role = c(\"aut\", \"cre\"),\n email = \"gor...@wisc.edu\",\n
  comment = structure(\"-0002-2700-4605\", .Names =
\"ORCID\")))"






  URL





  "
https://github.com/NeotomaDB/neotoma2";






   BugReports





   "
https://github.com/NeotomaDB/neotoma2/issues";






  Description





   "Access and manipulation of data using the
Neotoma Paleoecology Database."






   ."






  License
```

You can see that it is interpreting "." as the contents of the field. I added 8
spaces before "
wrote:

> Thank you for all the help.
>
> Here is the GitHub link:
> https://github.com/NeotomaDB/neotoma2
>
> Best,
>
> Socorro
>
> On Mon, Apr 17, 2023 at 8:32 PM Merlise Clyde, Ph.D. 
> wrote:
>
> > Make sure you have a period after the < > tag if that is the end of the
> > paragraph/sentences - its is not clear it is there from the snippet that
> > you sent.
> > (let us know if the package is on github as then we can see the entire
> > file)
> >
> > best,
> > Merlise
> > --
> > *From:* R-package-devel  on
> behalf
> > of Socorro Dominguez 
> > *Sent:* Monday, April 17, 2023 8:41 PM
> > *To:* Sarah Goslee 
> > *Cc:* r-package-devel@r-project.org 
> > *Subject:* Re: [R-pkg-devel] (no subject)
> >
> > Thank you!
> >
> > So, based on this link:
> >
> >
> https://urldefense.com/v3/__https://r-pkgs.org/description.html*:*:text=to*20be*20indented*3A-,Description,-*3A*20The*20description__;I34lJSUlJSU!!OToaGQ!rL12FfD_Ox2OGl4JbHsG06nsukCSrpt3piRZQ1B5cllO12AOU7ZP2OcwA5dorRJWaIda0dk74FnqQ0xeXNINIw$
> > <
> >
> https://urldefense.com/v3/__https://r-pkgs.org/description.html*:*:text=to*20be*20indented*3A-,Description,-*3A*20The*20descriptio__;I34lJSUlJSU!!OToaGQ!rL12FfD_Ox2OGl4JbHsG06nsukCSrpt3piRZQ1B5cllO12AOU7ZP2OcwA5dorRJWaIda0dk74FnqQ0wC5cqebw$
> > >
> > I thought I had to add indentations...
> >
> > So, I originally sent:
> > ```
> > Description: Access and manipulate data from the Neotoma Paleoecology
> > Database. <
> >
> https://urldefense.com/v3/__https://api.neotomadb.org/api-docs/__;!!OToaGQ!rL12FfD_Ox2OGl4JbHsG06nsukCSrpt3piRZQ1B5cllO12AOU7ZP2OcwA5dorRJWaIda0dk74FnqQ0zYR76mxw$
> > >
> > ```
> >
> > I was requested to add  referencing the "Neotoma
> Paleoecology
> > Database".
> >
> > With the Description above, I do not get any local errors when running
> the
> > R CMD but can rejects it and gives me this error:
> >
> >
> > If I do this:
> > ```
> > Description: Access and manipulate data from the Neotoma Paleoecology
> > Database.
> > <
> >
> https://urldefense.com/v3/__https://api.neotomadb.org/api-docs/__;!!OToaGQ!rL12FfD_Ox2OGl4JbHsG06nsukCSrpt3piRZQ1B5cllO12AOU7ZP2OcwA5dorRJWaIda0dk74FnqQ0zYR76mxw$
> > >
> > ```
> >
> > and run the R CMD, I get the following message:
> > ```
> > Unknown, possibly mis-spelled, fields in DESCRIPTION:
> >   ‘ > ```
> > (however, it is not an error)
> >
> >
> > I see that I have to write complete sentences, so I have done the
> > following:
> > ```
> > Description: Access and manipulation of data using the Neotoma
> Paleoecology
> > Database.
> > <
> >
> https://urldefense.com/v3/__https://api.neotomadb.org/api-docs/__;!!OToaGQ!rL12FfD_Ox2OGl4JbHsG06nsukCSrpt3piRZQ1B5cllO12AOU7ZP2OcwA5dorRJWaIda0dk74FnqQ0zYR76mxw$
> > >
> > ```
> >
> > I would llike to know if this is correct prior to submitting again. Or
> know
> > how should I place that  tag
> >
> > Thank you for all your help.
> >
> > Socorro
> >
> > On Mon, Apr 17, 2023 at 7:19 PM Sarah Goslee 
> > wrote:
> >
> > > Hi,
> > >
> > > The Writing R Packages manual is the main documentation, specifically:
> > >
> >
> https://urldefense.com/v3/__https://cran.r-project.org/doc/manuals/R-exts.html*The-DESCRIPTION-file__;Iw!!OToaGQ!rL12FfD_Ox2OGl4JbHsG06nsukCSrpt3piRZQ1B5cllO12AOU7ZP2OcwA5dorRJWaIda0dk74FnqQ0ypxASA8Q$
> > >
> > > As for indentation, don't. Just use a newline.
> > >
> > > I don't know of any templates, but the source code for many/mo

Re: [R-pkg-devel] Unfortunate function name generic.something

[Iris Simmons]

You can add

\keyword{internal}

to the Rd file. Your documentation won't show up the in the pdf manual, it
won't show up in the package index, but you'll still be able to access the
doc page with ?levels.no or help("levels.no").

This is usually used in a package's deprecated and defunct doc pages, but
you can use it anywhere.

On Fri, May 5, 2023, 06:49 Ulrike Groemping 
wrote:

> Dear package developeRs,
>
> I am working on fixing some notes regarding package DoE.base.
> One note refers to the function levels.no and complains that the
> function is not documented as a method for the generic function levels.
> Actually, it is not a method for the generic levels, but a standalone
> internal function that I like to have documented.
>
> Is there a way to document the function without renaming it and without
> triggering a note about method documentation?
>
> Best, Ulrike
>
> --
> ##
> ## Prof. Ulrike Groemping
> ## FB II
> ## Berliner Hochschule für Technik (BHT)
> ##
> ## prof.bht-berlin.de/groemping
> ## Phone: +49(0)30 4504 5127
> ## Fax:   +49(0)30 4504 66 5127
> ## Home office: +49(0)30 394 04 863
> ##
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Error: [writeRaster] cannot write file

[Iris Simmons]

You wrote

# create the plots directory if it does not exist

but then created a directory named outdir/plots/typ_Sys.time.tif

You need to rewrite the code like:

plotsdir <- file.path(outdir, "plots")
fp <- file.path(plotsdir,  paste(typ, "_",
stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]", ""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
  if (!dir.exists(plotsdir)) {
dir.create(plotsdir, recursive = TRUE)
  }

On Mon, Oct 9, 2023, 15:49 Keshav, Krishna  wrote:

> Hi,
>
> I am developing an R package where I need to save Raster file with .tif
> extension to the tempdir(). I am using terra::writeRaster for the same.
> While it works through R CMD check in mac, it is failing in R hub builder.
> Snippet ¡V
> .saverast <- function(typ, rast, outdir) {
>
>   if (is.null(outdir) || length(outdir) == 0) {
> outdir <- tempdir()
>   }
>
>   # Save the plot as a raster file
>   fp <- file.path(outdir, paste("plots", "/",
> typ, "_",
> stringr::str_replace_all(Sys.time(),
> "[^a-zA-Z0-9]", ""),
> ".tif", sep = ""))
> # Create the "plots" directory if it doesn't exist
>   if (!dir.exists(fp)) {
> dir.create(fp, recursive = TRUE)
>   }
>
>   terra::writeRaster(rast, overwrite = TRUE,
>  filename = fp,
>  gdal = c("COMPRESS=NONE"))
>   message(paste("raster created", fp, sep = ": "), "\n")
> }
>
> Error ¡V
>
>   Error: [writeRaster] cannot write file
>12. ¢|¢wgeohabnet:::.saverast(typ, rast, outdir)
>13.   ¢u¢wterra::writeRaster(rast, overwrite = TRUE, filename =
> fp, gdal = c("COMPRESS=NONE"))
>14.   ¢|¢wterra::writeRaster(rast, overwrite = TRUE, filename =
> fp, gdal = c("COMPRESS=NONE"))
>15. ¢|¢wterra (local) .local(x, filename, ...)
>16.   ¢|¢wterra:::messages(x, "writeRaster")
>17. ¢|¢wterra:::error(f, x@pnt$getError())
>
>
>
> 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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Problem with "additional repository".

[Iris Simmons]

The packages in additional repositories are not installed on the CRAN
checking machines. The NOTE is expected, but it's not a warning, so your
package should still be allowed to upload to CRAN. You should not remove
ionChannelData from Suggests because then the reference to that package in
your documentation will become a WARNING and your package will not be
uploaded to CRAN.

On Sun, Oct 15, 2023, 21:35 Rolf Turner  wrote:

>
> I have submitted a new package to CRAN, and this package has been
> knocked back on the basis of a NOTE:
>
> > * checking package dependencies ... NOTE
> > Package suggested but not available for checking: 'ionChannelData'
>
> This suggested package consists of data sets, the size of which is too
> large to satisfy CRAN's constraints. I put this package in a repository
> on github, from which it can be accessed by users.
>
> My DESCRIPTION file contains the line:
>
> > Additional_repositories: https://rolfturner.r-universe.dev
>
> The given URL seems to work, in that users can indeed load the
> ionChannelData package via the command
>
> > install.packages("ionChannelData",repos="
> https://rolfturner.r-universe.dev";)
>
> I was under the impression that this was all that I needed to do.  The
> CRAN checking process acknowledges the existence of the repository in
> question:
>
> > Suggests or Enhances not in mainstream repositories:
> >   ionChannelData
> > Availability using Additional_repositories specification:
> >   ionChannelData   yes   https://rolfturner.r-universe.dev
>
> So CRAN knows about this repository.  Why can it not make use of it?
>
> What can/should I do to resolve this problem?
>
> I guess I could simply *not* Suggest ionChannelData.  But what then, is
> the point of the option of including an Additional_repositories field in
> the DESCRIPTION file?
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Stats. Dep't. (secretaries) phone:
>  +64-9-373-7599 ext. 89622
> Home phone: +64-9-480-4619
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CartogRaflow submission

[Iris Simmons]

The packages that you imported are no longer available. As far as I
understand, rgeos, maptools, and a few other spatial related packages have
been archived and have been replaced with better alternatives.

On Tue, Oct 17, 2023, 03:13 cartograf...@gmail.com 
wrote:

> Hi, I've put an update version of the package cartogRaflow 1.0.4 in CRAN
> today.
> There are 2 errors
> Last released version's CRAN status: OK: 11, ERROR: 2
> See: <
> https://cran-archive.r-project.org/web/checks/2023/2023-10-16_check_results_cartograflow.html
> >
>
> The version 1.0.3 was archived today.
> I would like to know if these errors are due to the version 1.0.3 was
> archived. If yes, is it possible to fix these errors? Thanks in
> advance Sylvain
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Check warning around sprintf: Compiled code should not call entry points which might terminate R nor write to stdout/stderr instead of to the console, nor use Fortran I/O nor system

[Iris Simmons]

Yes, the reason for the error is the use of sprintf. You can instead use
snprintf where n is the maximum number of bytes to write, including the
terminating nul character. For example:

char msg[8191];
snprintf(msg, 8191, "criteria: error (%d) -> %s\n", inErr, errStr);
Rf_error(msg);

or however large you made the error string.


On Sat, Nov 18, 2023, 20:01 Iago Giné-Vázquez 
wrote:

> Dear all,
>
> I am updating a CRAN-archived R package, so it can get back to CRAN. But
> there is a warning produced in Linux OS that I am not sure to understand
> and I do not know how to solve, even after looking at ‘Writing portable
> packages’ in the ‘Writing R Extensions’ manual and after searching in the
> web. The warning is
>
> > * checking compiled code ... WARNING
> > File ‘ccckc/libs/ccckc.so’:
> > Found ‘sprintf’, possibly from ‘sprintf’ (C)
> > Object: ‘criteria.o’
> >
> > Compiled code should not call entry points which might terminate R nor
> > write to stdout/stderr instead of to the console, nor use Fortran I/O
> > nor system RNGs nor [v]sprintf.
> > See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
>
> The package contains both C and Fortran code and in the criteria.c there
> is only a sprintf use, as follows:
>
> sprintf(msg,"criteria: error (%d) -> %s\n", inErr, errStr);
> Rf_error(msg);
> May be the reason of the warning the next line the ‘Writing R Extensions’
> manual?
>
> > Use ofsprintfandvsprintfis regarded as a potential security risk and
> warned about on some platforms.[82](
> https://cran.r-project.org/doc/manuals/R-exts.html#FOOT82)R CMD
> checkreports if any calls are found.
>
> If that is the reason, is there any alternative to the use of sprintf?
> Anyway, what can I do?
>
> Thanks you in advance for your time.
>
> Kind regards,
> Iago
>
> Sent with [Proton Mail](https://proton.me/) secure email.
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Check warning around sprintf: Compiled code should not call entry points which might terminate R nor write to stdout/stderr instead of to the console, nor use Fortran I/O nor system

[Iris Simmons]

The n in snprintf includes the room for the terminating nul. It should be
8191. If gcc is throwing a warning, it can be ignored.

On Mon, Nov 20, 2023, 04:04 Serguei Sokol  wrote:

> Le 19/11/2023 à 02:07, Iris Simmons a écrit :
> > Yes, the reason for the error is the use of sprintf. You can instead use
> > snprintf where n is the maximum number of bytes to write, including the
> > terminating nul character. For example:
> >
> > char msg[8191];
> > snprintf(msg, 8191, "criteria: error (%d) -> %s\n", inErr, errStr);
> This line should be
>
> snprintf(msg, 8190, "criteria: error (%d) -> %s\n", inErr, errStr);
>
> i.e. 1-less than 'msg' size, leaving a room for the terminal 0-byte.
> Otherwise, a recent version of gcc emits a warning caught by CRAN.
>
> Best,
> Serguei.
>
>
> > Rf_error(msg);
> >
> > or however large you made the error string.
> >
> >
> > On Sat, Nov 18, 2023, 20:01 Iago Giné-Vázquez <
> iago.gin-...@protonmail.com>
> > wrote:
> >
> >> Dear all,
> >>
> >> I am updating a CRAN-archived R package, so it can get back to CRAN. But
> >> there is a warning produced in Linux OS that I am not sure to understand
> >> and I do not know how to solve, even after looking at ‘Writing portable
> >> packages’ in the ‘Writing R Extensions’ manual and after searching in
> the
> >> web. The warning is
> >>
> >>> * checking compiled code ... WARNING
> >>> File ‘ccckc/libs/ccckc.so’:
> >>> Found ‘sprintf’, possibly from ‘sprintf’ (C)
> >>> Object: ‘criteria.o’
> >>>
> >>> Compiled code should not call entry points which might terminate R nor
> >>> write to stdout/stderr instead of to the console, nor use Fortran I/O
> >>> nor system RNGs nor [v]sprintf.
> >>> See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
> >>
> >> The package contains both C and Fortran code and in the criteria.c there
> >> is only a sprintf use, as follows:
> >>
> >> sprintf(msg,"criteria: error (%d) -> %s\n", inErr, errStr);
> >> Rf_error(msg);
> >> May be the reason of the warning the next line the ‘Writing R
> Extensions’
> >> manual?
> >>
> >>> Use ofsprintfandvsprintfis regarded as a potential security risk and
> >> warned about on some platforms.[82](
> >> https://cran.r-project.org/doc/manuals/R-exts.html#FOOT82)R CMD
> >> checkreports if any calls are found.
> >>
> >> If that is the reason, is there any alternative to the use of sprintf?
> >> Anyway, what can I do?
> >>
> >> Thanks you in advance for your time.
> >>
> >> Kind regards,
> >> Iago
> >>
> >> Sent with [Proton Mail](https://proton.me/) secure email.
> >>  [[alternative HTML version deleted]]
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Question regarding finding the source file location without R-packages outside of R-Studio

[Iris Simmons]

I think 'package:renv' does a lot of the stuff you mentioned here. I
think they accomplished your issue by making an .Rprofile file for
each project. The working directory would be set to the root directory
of the project, the R profile runs and sets .libPaths() as
appropriate, then the scripts can run.

If you don't like that idea, then I don't think you can accomplish
what you want in base R. There are packages that can determine the
path of the current script. I made a package called 'this.path' that
does that, and it works with GUIs RGui for Windows, RStudio, VSCode,
Jupyter, Emacs (indev version, soon to be on CRAN), and from a shell
(Rscript). The core functions of the package are stable, not so much
for others. There are plenty of other packages that offer the same:
'here', 'rprojroot', 'whereami', 'funr', 'scriptName', 'envDocument'.
There may be others. I can't confirm their stability but it would seem
they are stable.

On Thu, Nov 23, 2023 at 2:39 PM Tony Wilkes  wrote:
>
> Hi everyone,
>
> I have a question. I hope it's not a stupid question.
>
> Suppose you'd want to perform version control and project isolation. You'd 
> create a project folder (let's call it "MyProject"), and place all the R 
> packages you need for that project inside a subfolder (let's say 
> "MyProject/MyLibrary"). Now you create and run an R-script in "MyProject".
> install.packages(), library(), etc. all have a lib.loc argument to specify 
> the library path. So one can manually specify the path of your project, and 
> then you'd have your project isolation and version control fully set-up.
>
> But if I want to set-up the library path automatically, to make it portable, 
> I would need to determine the script location. In RStudio I can use the 
> 'rstudioapi' package, which is very stable, and so does not really require 
> version control. But for outside R-Studio, I have not found a very stable 
> package that also works.
> I prefer not using external R packages that requires version control (i.e. a 
> package that changes often-ish): you'd need the package to access the project 
> library, but the project library to access the package.
>
> This brings me to my actual question: is it possible to determine the source 
> file location of an R script outside of R-Studio, without resorting to R 
> packages ? Or else use an R package that is VERY stable (i.e. doesn't change 
> every (half) a year, like tidyverse packages tend to do)? commandArgs() used 
> to contain the script path (apparently), but it doesn't work for me.
>
> By the way: I wish to get the script path in an interactive session.
>
> Thank you in advance.
>
> Kind regards,
>
> Tony
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

[Iris Simmons]

You cannot and should not ignore this.

An R package should never ever be assigning variables into environments for
which they haven't been granted permission to do so. You should ask the
user whether they want the object assigned in the global environment before
doing so, and the default should be no so that it will not be assigned in
non interactive sessions.

On Thu, Jan 4, 2024, 15:54 Tiago Olivoto  wrote:

> Hi everyone!
> I which a happy new year!
>
>
> I'm coding a shiny app and I would like to include an option so that the
> users can assign the results to the global environment for further
> analysis.
>
> I have written the following code, which checks if 'globalvarname' (the
> name of object to be created in the global environment) already exists,
> returning an error if so, and asking to the user change the name.
>
> code
> ---
> observeEvent(input$savetoglobalenv, {
>  ### more code here
>
>   if (exists(input$globalvarname, envir = globalenv())) {
> sendSweetAlert(
>   session = session,
>   title = "Error",
>   text = paste0("The object'", input$globalvarname, "' already exists
> in the global environment. Please, change the name."),
>   type = "success"
> )
>   } else {
> assign(input$globalvarname, report, envir = globalenv())
> ask_confirmation(
>   inputId = "myconfirmation",
>   type = "warning",
>   title = "Close the App?",
>   text = paste0("The object'", input$globalvarname, "' has been created
> in the Global environment. To access the created object, you need first to
> stop the App. Do you really want to close the app now?"),
>   btn_labels = c("Nope", "Yep"),
>   btn_colors = c("#FE642E", "#04B404")
> )
>   }
> })
> -
>
> Thus, the object is only created when the user decides to assign such an
> object to the global environment. As the object's name is checked, there is
> no way of replacing some object already available in the global
> environment.
>
> Of course, when running devtools::check(), a NOTE is returned
>
> Found the following assignments to the global environment:
>   Arquivo 'plimanshiny/R/mod_analyze.R':
>
> Can I ignore this safely?
> Is there any suggestion to handly this without using 'assign()'
>
> Thanks in advance,
> Olivoto
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Including "Rmath.h" in C code for an R package

[Iris Simmons]

To avoid the remapping of beta to Rf_beta, you should
define R_NO_REMAP_RMATH before you include Rmath:

#define R_NO_REMAP_RMATH
#include 

On Sun, Jun 2, 2024, 19:33 Gregory Raskind  wrote:

> Hi,
>
> I'm extending an R package that uses the R C API directly. I'd like to use
> some distribution functions, so I included the "Rmath.h" header. The issue
> is that this introduces macros that have unintended consequences for the
> code. For example, I have a local variable named "beta", which is expanded
> to "Rf_beta".
>
> Is there a way of including the "Rmath.h" header without applying the
> macros to my code? E.g. if I want to use the beta function, I would use it
> with "Rf_beta(a,b)", but "beta" would remain my local variable.
>
> Thanks for your time!
>
> Best,
> Greg
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] warning: explicit assigning values of variable of type ....

[Iris Simmons]

Unless I'm misunderstanding, you're trying to pass a value by name to a
function. That is not a thing in C nor C++. However if you want to name the
arguments, you can do so with comments:

/* print = */ print

On Thu, Jun 6, 2024, 19:16 Søren Højsgaard via R-package-devel <
r-package-devel@r-project.org> wrote:

> Dear all,
>
> From CRAN maintainers I recieve:
>
>
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: whether package can be installed, Result: WARNING
>   Found the following significant warnings:
> grips_fit_ips.cpp:149:45: warning: explicitly assigning value of
> variable of type 'int' to itself [-Wself-assign]
> grips_fit_ips.cpp:213:16: warning: explicitly assigning value of
> variable of type 'int' to itself [-Wself-assign]
> grips_fit_ips.cpp:254:10: warning: explicitly assigning value of
> variable of type 'int' to itself [-Wself-assign]
> grips_fit_ips.cpp:254:21: warning: explicitly assigning value of
> variable of type 'double' to itself [-Wself-assign]
>
>
>
> The first warning pertains to the line:
>
> conips_inner_(S, K, elst0, clist0, print=print);
>
> print on lhs of "=" is the formal name and print on rhs of "=" the name of
> a variable. Does the compiler think I assign an integer
> to itself? Like if I write
>
> int a=7;
> a=a;
>
> Can anyone help me throw light on this?
>
> Thanks in advance
> Søren
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] accessing data folder Warning/Error

[Iris Simmons]

Unless I'm misunderstanding, it sounds like you're storing data that your
package requires in an external location. You need to put your data into
your R package and then access that data with system.file(package =
"", )

Sometimes people will make a folder inst/extdata inside their R package
directory and then dump the data that the package requires in there. You
can see this link for more information:
https://cran.r-project.org/doc/FAQ/R-exts.html#Data-in-packages

So, if you move your files into your R package, you should have a directory
inst/extdata/data-raw, and files inst/extdata/metadata,
inst/extdata/textgrid, and inst/extdata/README.md

When your package is installed, the contents of inst are unpacked into the
install directory. So, to refer to files after the package has been
installed and loaded, use:

system.file(package = "", "extdata", "data-raw", )
system.file(package = "", "extdata", "metadata")
...

On Tue, Jun 11, 2024, 19:13 Yana Outkin  wrote:

> I am currently in the process of submitting a package to CRAN. I am having
> difficulties with the example section in Summary.Rd
>
> I placed the data in a folder called data-raw, which contains a metadata
> file, textgrid file, and a README.md description of the data. This package
> builds on existing software that generate these metadata and textgrids
> files. The current package processes and plots this data.
>
> When I run the R CMD check, the working directory is set to a folder
> (.Rcheck) within the package, so I reset working directory with
> setwd(".."), to be able to access the data-raw folder. This gives a
> warning.
>
> Is there a different way I can access my example dataset?
>
> Thank you!
> Yana Outkin
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

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

[Iris Simmons]

This is actually an issue that was just fixed.

package:vctrs has an error when installing under r86723 because it creates
delayed bindings at package install time that cannot be restored at package
load time.

It may be a small while before the newest R devel version is in use by the
CRAN farm, but after that point package:vctrs will install successfully
again and you can submit your R package.

On Wed, Jun 12, 2024, 14:04 Leonardo Cefalo 
wrote:

> Dear all
>
> I have just submitted a new version of the package SchoolDataIT
> 
>
> On r-devel-linux-x86_64-debian-gcc I got this error
> <
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/SchoolDataIT-00check.html>
>
> :
>
> Result: ERROR
>Packages required but not available:
>  'dplyr', 'ggplot2', 'readr', 'readxl', 'rvest', 'stringr', 'tidyr'
>
>Packages suggested but not available for checking: 'testthat',
> 'tidyverse'
>
>See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’
>manual.
>
> If I don't get it wrong, this should be a version problem but I cannot
> figure out how to modify the DESCRIPTION in order to avoid this result.
> Also I never noticed such problems with the old package version, though
> no version specification was included either (except for testthat) and
> the DESCRIPTION file had the same Imports and Suggestions fields
>
> I have found this discussion on the posit community
> <
> https://forum.posit.co/t/package-required-but-not-available-error-on-cran/180047>
>
> but I am not sure if it is exactly the same case - also because the same
> platforms did not give any problem with tidyverse packages before.
>
> Could somebody please help me understanding how to fix this?
> Thank you very much in advance
>
> With kindest regards
> LC
>
> 
> Sostieni la formazione e la ricerca universitaria con il tuo 5 per mille
> all'Università di Bari.
> Firma la casella "Finanziamento della ricerca scientifica e della
> Università"
> indicando il codice fiscale 80002170720.
>
> Il tuo contributo può fare la differenza: oggi più che mai!
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Incomprehensible warning while checking

[Iris Simmons]

Hi,


I've got an update for my R package ready to go. It checks successfully on
my own machine for r-oldrel and r-release, but when I submit it to R Win
Builder for r-devel to be checked, it gives me a warning not seen before
with an uninformative message:

* checking whether the namespace can be unloaded cleanly ... WARNING
 unloading

 Here are the results:

https://win-builder.r-project.org/gCD9sLW91fW6

How am I supposed to interpret this?


Regards,
Iris

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Incomprehensible warning while checking

[Iris Simmons]

Thank you Jeff! I'm not worried about the NOTE about the URLs, I've
submitted many previous versions of this package that all had that note and
they've all been accepted.

I'm worried about the WARNING when the namespace is unloaded. The message
is just " unloading" with no further elaboration. I can't fix this
issue because I don't actually know what's wrong.


On Fri, Jun 28, 2024, 18:43 Jeff Newmiller  wrote:

> Google for "http 403 error"... likely win-builder has multiple packages
> with links to Posit, and the Posit web server is throttling automated hits.
>
> Theoretically this is just a warning and you can try submitting to CRAN,
> but CRAN may have even less luck accessing Posit than win-builder.
> Submitting anyway is recommended here [1].
>
> [1]
> https://stackoverflow.com/questions/66078248/invalid_url_in_cran_checks
>
> On June 28, 2024 2:57:13 PM PDT, Iris Simmons  wrote:
> >Hi,
> >
> >
> >I've got an update for my R package ready to go. It checks successfully on
> >my own machine for r-oldrel and r-release, but when I submit it to R Win
> >Builder for r-devel to be checked, it gives me a warning not seen before
> >with an uninformative message:
> >
> >* checking whether the namespace can be unloaded cleanly ... WARNING
> > unloading
> >
> > Here are the results:
> >
> >https://win-builder.r-project.org/gCD9sLW91fW6
> >
> >How am I supposed to interpret this?
> >
> >
> >Regards,
> >Iris
> >
> >   [[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.
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] NOTE about lack of prebuilt manual

[Iris Simmons]

This is something I'd run into recently as well.

The R devs changed the default from building the manual to not building the
manual. Now if you want (or need) to build the manual, you should add

BuildManual: TRUE

to your DESCRIPTION.

On Mon, Jul 8, 2024, 10:05 Michael Dewey  wrote:

> Short version
>
> I have recently tried to update two of my CRAN packages and I am getting
> the NOTE from R CMD check --as-cran
>
> Package has help file(s) containing install/render-stage \Sexpr{}
> expressions but no prebuilt PDF manual.
>
> (It comes on one line in the check.log)
>
> What am I doing wrong?
>
> ===
>
> More details
>
> Both packages have lived successfuly on CRAN for some time but my recent
> attempts to update lead to the NOTE shown above. I notice that the
> version currently on CRAN do have in the tarball a directory called
> build which amongst other thing does contain the package manual. However
> when I build the updated versions the tarball still contains a build
> directory but without the manual.
>
> I am using 4.4.1 under Windows 10. I open a command line and do
> everything from there with R CMD, I do not use any helper package. The
> help files do not explicitly contain any instance of \Sexpr{} but they
> do contain macros. Both of them use mathjaxr and Rdpack and one also has
> some macros written by me. They have been like that for some while. The
> Rd files are hand-written, I do not use any package to generate
> documentation.
>
> I notice that R CMD build has an option to turn off the manual but I do
> not set that and there does not seem to be a turn on option. I have
> looked at the NEWS for R4.4.0 and 4.4.1 but withou enlightenment. The
> versions on CRAN were probably generated with R 4.3.3 judgin by the date
> when I made them.
>
> I know it is only a NOTE but I would like to know why it is happening.
>
> I hope that is enough detail to be helpful but I can expand on any
> unclear areas.
>
> --
> Michael
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] new version jumps in minor?

[Iris Simmons]

The auto checker will publish an R package that has Status: OK and no
Note_to_CRAN_maintainers.

The auto checker will reject an R package that has WARNINGs and/or ERRORS.

The auto checker will flag an R package for manual inspection otherwise. A
CRAN team member will see your NOTE and know it's nothing to worry about
and publish it anyway. I've had similar before, and I've waited at most 5
hours for someone to check and approve it.

On Tue, Nov 5, 2024, 14:29 Toby Hocking  wrote:

> I thought that the auto-check robot only accepts submissions which
> have Status: OK? (no NOTEs at all)
> Is it documented somewhere which NOTEs are allowed by the auto-check
> service?
>
> On Tue, Nov 5, 2024 at 4:10 AM Uwe Ligges
>  wrote:
> >
> > CRAN does not object to these versioning, the notes are not the reason
> > for rejection. Who told they are?
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >
> > On 05.11.2024 01:02, Josiah Parry wrote:
> > > Rolf,
> > >
> > > The versioning method they’re using is referred to as CalVer
> > > https://calver.org/ (not as catchy as SemVer) and it is actually quite
> > > useful! With one look at the version you can get a good sense of it’s
> > > general release date.
> > >
> > > Posit, for example, moved their professional products to use this
> > > versioning method a number of years ago.
> > >
> > > I wouldn’t poopoo it so quickly!
> > >
> > > On Mon, Nov 4, 2024 at 15:32 Rolf Turner 
> wrote:
> > >
> > >>
> > >> On Mon, 4 Nov 2024 16:33:40 -0500
> > >> Toby Hocking  wrote:
> > >>
> > >> 
> > >>
> > >>> Version jumps in minor (submitted: 2024.11.2, existing: 2024.1.24)
> > >>
> > >> It looks to me that you are setting your version numbers in an
> > >> unorthodox manner, which could/will confuse the living Drambuie out of
> > >> people.
> > >>
> > >> I conjecture that you are setting your version number to represent the
> > >> relevant date.  E.g. 2024.11.2  means 2 November, 2024 and 2024.1.24
> > >> means 24 January 2024.
> > >>
> > >> In my understanding, the usual convention is for the version number to
> > >> be of the form l.m.n (or l.m-n) --- major.minor.patch (or
> > >> major.minor-patch).  The date should be specified in the *Date* field
> of
> > >> the DESCRIPTION file.
> > >>
> > >> It probably does not matter a hell of a lot.  "Writing R Extensions"
> > >> just says that the version number should be "a sequence of at least
> two
> > >> (and usually three) non-negative integers separated by single ‘.’ or
> > >> ‘-’ characters".
> > >>
> > >> However you might save yourself some "NOTEs" by adhering to the
> > >> "l.m.n" convention and incrementing the components sequentially.
> > >>
> > >> cheers,
> > >>
> > >> Rolf Turner
> > >>
> > >> --
> > >> Honorary Research Fellow
> > >> Department of Statistics
> > >> University of Auckland
> > >> Stats. Dep't. (secretaries) phone:
> > >>   +64-9-373-7599 ext. 89622
> > >> Home phone: +64-9-480-4619
> > >>
> > >> __
> > >> R-package-devel@r-project.org mailing list
> > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > >>
> > >
> > >   [[alternative HTML version deleted]]
> > >
> > > __
> > > R-package-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] truncating strings on purpose

[Iris Simmons]

You could use memcpy instead. That gets rids of the type checking though.

You could also define something like char * my_strncpy ( char *
destination, const char * source, size_t num ) { return (char *)
memcpy(destination, source, num) } to keep the type checking.

On Wed, Dec 11, 2024, 07:12 Brad Eck  wrote:

> Dear List
>
> The latest update to my epanet2toolkit package bounced from CRAN due to
> some warnings about string truncation in C code from gcc.
>
> Found the following significant warnings:
> input2.c:863:5: warning: ‘__builtin_strncpy’ output may be truncated
> copying 225 bytes from a string of length 255 [-Wstringop-truncation]
> input2.c:302:15: warning: ‘__builtin_strncpy’ output may be truncated
> copying 78 bytes from a string of length 1024 [-Wstringop-truncation]
> report.c:795:9: warning: ‘__builtin_strncpy’ output may be truncated
> copying 967 bytes from a string of length 1024 [-Wstringop-truncation]
>
> The package wraps a simulation engine that parses inputs from and
> writes results to text files. Where the truncation warnings appear, I
> am truncating on purpose using `strncpy` to avoid overflows later.  I
> believe this works fine from an application point of view but the
> warnings remain.
>
> Any suggestions on how to carry out a truncation so that gcc won't
> complain?
>
> Thanks in advance,
>
> Brad
>
> PS - CRAN check info is here
>
> https://win-builder.r-project.org/incoming_pretest/epanet2toolkit_1.0.6_20241209_221743/specialChecks/
>
> PPS the latest CRAN submission is from this branch
> https://github.com/bradleyjeck/epanet2toolkit/tree/lto-crash
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Establishing how a package violated CRAN policies

[Iris Simmons]

You can find those results here:

https://cran.r-project.org/src/contrib/PACKAGES.in

Your package says "Archived on 2024-12-16 from policy violation. On
Internet Access."

There are additional details from the check result that failed here:

https://www.stats.ox.ac.uk/pub/bdr/donttest/CopernicusMarine.out


On Sat, Dec 21, 2024, 17:34 Pepijn de Vries 
wrote:

> Hi fellow developers,
>
> By accident I discovered that one of my packages has been archived by CRAN
> (https://cran.r-project.org/package=CopernicusMarine) because it violates
> CRAN policies. Can this happen unannounced? If so, how can I discover the
> specific violation, such that I can fix this, or at least avoid it in my
> other packages? If not, how could I get a copy of the announcement?
>
> Any suggestions are welcome.
>
> Kind regards,
>
> Pepijn
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Replacement for SETLENGTH

[Iris Simmons]

Hi Merlise!


Referring to here:

https://github.com/wch/r-source/blob/8ca367db0c94194f07ee7bcf4b883e9c5dc11e02/src/main/builtin.c#L832

It seems as though the object is only re-used if the new length is
equal to the old length.

If you use Rf_lengthgets, you will need to protect the return value.
The code you wrote that uses protect indexes looks correct, and the
reprotect is good because you no longer need the old object.

2 is the correct amount to unprotect. PROTECT and PROTECT_WITH_INDEX
(as far as I know) are the only functions that increase the size of
the protect stack, and so the only calls that need to be unprotected.
Typically, people define `int nprotect = 0;` at the start of their
functions, add `nprotect++;` after each PROTECT and PROTECT_WITH_INDEX
call, and add `UNPROTECT(nprotect);` immediately before each return or
function end. That makes it easier to keep track.

I typically use R_PreserveObject and R_ReleaseObject to protect
objects without a need to bind them somewhere in my package's
namespace. This would be that .onLoad() uses R_PreserveObject to
protect some objects, and .onUnload uses R_ReleaseObject to release
the protected objects. I probably would not use that for what you're
describing.


Regards,
Iris

On Tue, Jan 14, 2025 at 11:26 PM Merlise Clyde, Ph.D.  wrote:
>
> I am trying to determine the best way to eliminate the use of SETLENGTH to 
> truncate over allocated vectors in my package BAS to eliminate the NOTES 
> about non-API calls in anticipation of R 4.5.0.
>
> From WRE:  "At times it can be useful to allocate a larger initial result 
> vector and resize it to a shorter length if that is sufficient. The functions 
> Rf_lengthgets and Rf_xlengthgets accomplish this; they are analogous to using 
> length(x) <- n in R. Typically these functions return a freshly allocated 
> object, but in some cases they may re-use the supplied object."
>
> it looks like using
>
> x = Rf_lengthgets(x, newsize);
> SET_VECTOR_ELT(result, 0, x);
>
> before returning works to resize without a performance hit that incurs with a 
> copy.  (will this always re-use the supplied object if newsize < old size?)
>
> There is no mention in section 5.9.2 about the need for re-protection of the 
> object,  but it seems to be mentioned in some packages as well as a really 
> old thread about SET_LENGTH that looks like a  non-API MACRO to lengthgets,
>
> indeed if I call gc() and then rerun my test I have had some non-reproducible 
> aborts in R Studio on my M3 Mac (caught once in R -d lldb)
>
> Do I need to do something more like
>
> PROTECT_INDEX ipx0;.
> PROTECT_WITH_INDEX(x0 = allocVector(REALSXP, old_size), &ipx0);
>
> PROTECT_INDEX ipx1;.
> PROTECT_WITH_INDEX(x1 = allocVector(REALSXP, old_size), &ipx1);
>
> # fill in values in x0 and  x1up to new_size (random) < old_size
> ...
> REPROTECT(x0 = Rf_lengthgets(x0, new_size), ipx0);
> REPROTECT(x1 = Rf_lengthgets(x1, new_size), ipx1);
>
> SET_VECTOR_ELT(result, 0, x0);
> SET_VECTOR_ELT(result, 1, x1);
> ...
> UNPROTECT(2);   # or is this 4?
> return(result);
>
>
> There is also a mention in WRE of R_PreserveObject and R_ReleaseObject -
>
> looking for advice if this is needed, or which approach is better/more stable 
> to replace SETLENGTH?   (I have many many instances that need to be updated, 
> so trying to get some clarity here before updating and running code through 
> valgrind or other sanitizers to catch any memory issues before submitting an 
> update to CRAN.
>
> best,
> Merlise
>
>
>
>
>
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Replacement for SETLENGTH

[Iris Simmons]

I don't think memcpy works well for VECSXP. The elements being overwritten
need to have their reference counts decreased and the new elements need to
have theirs increased.

Also, I don't entirely know how accurate everything I'm about to say is,
but I think you need to be using SET_TRUELENGTH and SET_GROWABLE_BIT along
with SETLENGTH. There's an example here:

https://github.com/wch/r-source/blob/744b5d34e1b8eb839e5d49d91ab21c1fe6800856/src/main/subassign.c#L257


The example uses SET_STDVEC_LENGTH which shouldn't be used, just replace it
with SETLENGTH.

So in your code, I'd replace:

SETLENGTH(modelspace, nUnique);

with

SET_GROWABLE_BIT(modelspace);
SET_TRUELENGTH(modelspace, nModels);
SETLENGTH(modelspace, nUnique);

On Wed, Jan 15, 2025, 10:30 Merlise Clyde, Ph.D.  wrote:

> Thanks for the added explanation Iris and Tomas!
>
> So looking at the code for xlengthgets, it does appear that I may take a
> memory hit for multiple large objects due to the second allocation before
> the old objects are possibly garbage collected. There are about 12 such
> instances per function that are returned (I do use a counter for keeping
> track of the number of PROTECTED and to UNPROTECT for bookkeeping :-).
>  For memory limited machines, the alloc/copy was a problem for memory usage
> - and if I recall was one of the reasons in 2008 I switched to SETLENGTH,
> which doesn't seem to do an allocation ???  If there is going to be an
> absolute ban on SETLENGTH  in packages I'll probably need to address memory
> management differently for those cases.
>
> I did see a note before the function def'n of xlengthgets:
>
> /* (if it is vectorizable). We could probably be fairly */
> /* clever with memory here if we wanted to. */
>
> It would seem that memcpy would be more efficient for at least some of the
> types  (REALSPX, INTSPX) unless I am missing something - but any way to be
> more clever with VECSPX ?
>
> best,
> Merlise
>
>
>
> Merlise Clyde (she/her/hers)
> Professor of Statistical Science and Director of Graduate Studies
> Duke University
>
> 
> From: Iris Simmons 
> Sent: Wednesday, January 15, 2025 1:00 AM
> To: Merlise Clyde, Ph.D. 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] Replacement for SETLENGTH
>
> Hi Merlise!
>
>
> Referring to here:
>
>
> https://github.com/wch/r-source/blob/bb5a829466f77a3e1d03541747d149d65e900f2b/src/main/builtin.c#L834
>
> It seems as though the object is only re-used if the new length is
> equal to the old length.
>
> If you use Rf_lengthgets, you will need to protect the return value.
> The code you wrote that uses protect indexes looks correct, and the
> reprotect is good because you no longer need the old object.
>
> 2 is the correct amount to unprotect. PROTECT and PROTECT_WITH_INDEX
> (as far as I know) are the only functions that increase the size of
> the protect stack, and so the only calls that need to be unprotected.
> Typically, people define `int nprotect = 0;` at the start of their
> functions, add `nprotect++;` after each PROTECT and PROTECT_WITH_INDEX
> call, and add `UNPROTECT(nprotect);` immediately before each return or
> function end. That makes it easier to keep track.
>
> I typically use R_PreserveObject and R_ReleaseObject to protect
> objects without a need to bind them somewhere in my package's
> namespace. This would be that .onLoad() uses R_PreserveObject to
> protect some objects, and .onUnload uses R_ReleaseObject to release
> the protected objects. I probably would not use that for what you're
> describing.
>
>
> Regards,
> Iris
>
> On Tue, Jan 14, 2025 at 11:26 PM Merlise Clyde, Ph.D. 
> wrote:
> >
> > I am trying to determine the best way to eliminate the use of SETLENGTH
> to truncate over allocated vectors in my package BAS to eliminate the NOTES
> about non-API calls in anticipation of R 4.5.0.
> >
> > From WRE:  "At times it can be useful to allocate a larger initial
> result vector and resize it to a shorter length if that is sufficient. The
> functions Rf_lengthgets and Rf_xlengthgets accomplish this; they are
> analogous to using length(x) <- n in R. Typically these functions return a
> freshly allocated object, but in some cases they may re-use the supplied
> object."
> >
> > it looks like using
> >
> > x = Rf_lengthgets(x, newsize);
> > SET_VECTOR_ELT(result, 0, x);
> >
> > before returning works to resize without a performance hit that incurs
> with a copy.  (will this always re-use the supplied object if newsize < old
> size?)
> >
> > There is no mention in sec

Re: [R-pkg-devel] How to resolve help files with \Sexpr{} warning?

[Iris Simmons]

I believe R CMD build changed the default from --manual to --no-manual, I'm
not sure why. You could add --manual when you build the tarball or you
could add

BuildManual: TRUE

to your DESCRIPTION.

On Mon, Apr 14, 2025, 09:41  wrote:

>
>
> Dear R Devs,
>
>
> I am unsure how to resolve this NOTE in my package build (I am
> comfortable with the possibly misspelled words part):
>
>  Package has help file(s) containing install/render-stage \Sexpr{}
>  expressions but no prebuilt PDF manual.
>
>
> I've dozens of files and no idea which one(s) offend, or if I am missing
> some other detail. (Aside: I am using mathjaxr... not sure if that is
> the issue.)
>
>
> Links for winbuilder logs are here for the time being:
>
>  https://win-builder.r-project.org/qG7LHs2Yf18p
>  https://win-builder.r-project.org/BBXdLV7kDOuI
>  https://win-builder.r-project.org/63RmX21pnrAw ←This check passes
>
>
> Thank you very much,
>
> Alexis Dinno
>
>
> PS Am including the log from the R-release winbuilder check in case my
> links expire:
>
>
> * using log directory
> 'd:/RCompile/CRANguest/R-oldrelease/tost.suite.Rcheck'
> * using R version 4.4.3 (2025-02-28 ucrt)
> * using platform: x86_64-w64-mingw32
> * R was compiled by
> gcc.exe (GCC) 13.3.0
> GNU Fortran (GCC) 13.3.0
> * running under: Windows Server 2022 x64 (build 20348)
> * using session charset: UTF-8
> * checking for file 'tost.suite/DESCRIPTION' ... OK
> * this is package 'tost.suite' version '3.15'
> * package encoding: UTF-8
> * checking CRAN incoming feasibility ... [8s] NOTE
> Maintainer: 'Alexis Dinno '
>
> New submission
>
> Possibly misspelled words in DESCRIPTION:
>   Kolmogorov (9:402)
>   McNemar's (9:198)
>   OLS (9:289)
>   Smirnov (9:413)
>   Stata (9:47)
>   Wilcoxon (9:312, 9:340)
>   nonparametric (9:546)
>   rrp (9:842)
>   rrpi (9:855)
>   tost (9:18, 9:65, 9:837, 9:850)
>
> Package has help file(s) containing install/render-stage \Sexpr{}
> expressions but no prebuilt PDF manual.
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking whether package 'tost.suite' can be installed ... OK
> * checking installed package size ... OK
> * checking package directory ... OK
> * checking for future file timestamps ... OK
> * checking DESCRIPTION meta-information ... OK
> * checking top-level files ... OK
> * checking for left-over files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking code files for non-ASCII characters ... OK
> * checking R files for syntax errors ... OK
> * checking whether the package can be loaded ... [1s] OK
> * checking whether the package can be loaded with stated dependencies
> ... [1s] OK
> * checking whether the package can be unloaded cleanly ... [1s] OK
> * checking whether the namespace can be loaded with stated dependencies
> ... [1s] OK
> * checking whether the namespace can be unloaded cleanly ... [1s] OK
> * checking loading without being on the library search path ... [1s] OK
> * checking use of S3 registration ... OK
> * checking dependencies in R code ... OK
> * checking S3 generic/method consistency ... OK
> * checking replacement functions ... OK
> * checking foreign function calls ... OK
> * checking R code for possible problems ... [16s] OK
> * checking Rd files ... [1s] OK
> * checking Rd metadata ... OK
> * checking Rd line widths ... OK
> * checking Rd cross-references ... OK
> * checking for missing documentation entries ... OK
> * checking for code/documentation mismatches ... OK
> * checking Rd \usage sections ... OK
> * checking Rd contents ... OK
> * checking for unstated dependencies in examples ... OK
> * checking contents of 'data' directory ... OK
> * checking data for non-ASCII characters ... [0s] OK
> * checking data for ASCII and uncompressed saves ... OK
> * checking examples ... [7s] OK
> * checking PDF version of manual ... [12s] OK
> * checking HTML version of manual ... [5s] OK
> * checking for detritus in the temp directory ... OK
> * DONE
> Status: 1 NOTE
> __
> 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