Re: [R-pkg-devel] LaTeX errors under MacOS on CRAN

[Simon Urbanek]

Ben,

if I recall there were a couple regressions in knitr that broke things, but 
since this is only a WARNING it means the check has not been automatically 
repeated after knitr update (ERRORs are re-tried nightly). I can kick off 
things manually which is likely to remove the WARNING.

Cheers,
Simon


> On 2/08/2024, at 2:53 AM, Ben Bolker  wrote:
> 
>  I note that on r-release-macos-x86_64, glmmTMB is getting warnings like this:
> 
> Error: processing vignette 'glmmTMB.Rnw' failed with diagnostics:
>  Running 'texi2dvi' on 'glmmTMB.tex' failed.
>  LaTeX errors:
>  ! Undefined control sequence.
>  l.176 \hlkwd{library}\hldef
> {(}\hlsng{"glmmTMB"}\hldef{)}
>  ?
>  ! Emergency stop.
>  ! Emergency stop.
>  l.176
> 
> 
> 
>  (I see similar but not identical problems with 
> , 
> although on different platforms.
> 
>  Has anyone seen this/does anyone have ideas for troubleshooting? (Haven't 
> checked on the r-hub platforms yet ...)
> 
>  cheers
>   Ben Bolker
> 
> __
> 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] A function in one of my package is now a method in base R

[Georgi Boshnakov]

Since the main problem is that in base-R's function your 'object' is called  
'x',  you could consider issuing an intermediate version of the package, where 
you strongly advise users not to name the first argument and to always name the 
remaining arguments. Also, make sure that your examples follow this advice.

If the function is used by package authors, you could send them emails, telling 
them exactly what to change.

After a year or so you could make the method following Duncan's advice.

Since sort_by is in package 'base', packages that use your package will no 
longer need to import sort_by from your package. There are some further 
subtleties here that could be discussed if packages that import explicitly 
sort_by from your package exist.


Georgi Boshnakov



Sent from Outlook for Android


From: R-package-devel  on behalf of 
Duncan Murdoch 
Sent: Friday, August 2, 2024 7:43:46 pm
To: Shu Fai Cheung ; r-package-devel@r-project.org 

Subject: Re: [R-pkg-devel]  A function in one of my package is now a method in 
base R

On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:
> Hi All,
>
> I have a function (not a method), sort_by(), in one of my packages. A
> new method with the same name was introduced in the recent versions of
> R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
> conflict in users' code.
>
> Certainly, users can simply use pkg_name::function_name() to solve the
> conflict. However, I would like to be consistent with base R and so I
> am thinking about converting my function to a method for the class for
> which my function is intended to work on (e.g, est_table).
>
> However, my function has arguments different from those in the base R 
> sort_by():
>
> Base R:
>
> sort_by(x, y, ...)
>
> My function:
>
> sort_by(
>object,
>by = c("op", "lhs", "rhs"),
>op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
>number_rows = TRUE
> )
>
> If I write the function sort_by.est_table(), I would need to match the
> argument names of the base R sort_by(). However, I think it is a bad
> idea to rename the arguments in my function and it will break existing
> code.
>
> Any suggestions on how I should proceed? Is keeping my function as-is
> a better option? Name conflict is not unusual across packages and so
> users need to learn how to solve this problem anyway. Nevertheless, if
> possible, I would like to solve the conflict internally such that
> users do not need to do anything.

I think it's impossible to avoid some inconvenience to your users.

Here's what I'd suggest:

- Create a method for base::sort_by(), as you suggested you could.  Use
the generic's variable names for compatibility, but also add your extra
variable names as additional arguments, e.g.

  sort_by.est_table <- function(x, y, object,
by = c("op", "lhs", "rhs"),
op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
number_rows = TRUE, ...) {

   # This test seems unlikely:  how would we have dispatch here if we
specified object explicitly?

   if (!missing(object) {
 if (!missing(x))
   stop("both x and object specified!")
 x <- object
   }

   # This one is more likely to do something:

   if (!missing(by)) {
 if (!missing(y))
   stop("both y and by specified!")
 y <- by
   }

   # Now proceed using x and y

   ...
}

- Create a separate function, e.g. sort_by_old() which is exactly
compatible with your old sort_by().  For users where the above doesn't
just work, they can switch to sort_by_old().

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!DMhcKnV6t06-gQP_syUMUckB9X-q2dwf-t0gwHnslUVystLyIK742SL2XYMJ-ugEvVxGfGLffUOBLR_lXvVhbltAha5tPmWPr6cdoQ$
 [stat[.]ethz[.]ch]


[[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] A function in one of my package is now a method in base R

[Duncan Murdoch]

The problem with that is a call like

  sort_by( object = foo, by = bar )

wouldn't be dispatched to the est_table method when foo is an est_table 
object, it would give a "argument 'x' is missing" kind of error.  It 
would be fine for


 sort_by( foo, bar )

but would also mess up on

 sort_by( foo, bar, priority )

Duncan Murdoch

On 2024-08-03 7:13 a.m., Deepayan Sarkar wrote:

I haven't thought about this carefully, but shouldn't this mostly work?

   sort_by.est_table <- function(x, y = c("op", "lhs", "rhs"),
     object = x,
     by = y,
     op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
     number_rows = TRUE, ...) 




}

-Deepayan

On Sat, 3 Aug 2024 at 00:13, Duncan Murdoch > wrote:


On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:
 > Hi All,
 >
 > I have a function (not a method), sort_by(), in one of my packages. A
 > new method with the same name was introduced in the recent
versions of
 > R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
 > conflict in users' code.
 >
 > Certainly, users can simply use pkg_name::function_name() to
solve the
 > conflict. However, I would like to be consistent with base R and so I
 > am thinking about converting my function to a method for the
class for
 > which my function is intended to work on (e.g, est_table).
 >
 > However, my function has arguments different from those in the
base R sort_by():
 >
 > Base R:
 >
 > sort_by(x, y, ...)
 >
 > My function:
 >
 > sort_by(
 >    object,
 >    by = c("op", "lhs", "rhs"),
 >    op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
 >    number_rows = TRUE
 > )
 >
 > If I write the function sort_by.est_table(), I would need to
match the
 > argument names of the base R sort_by(). However, I think it is a bad
 > idea to rename the arguments in my function and it will break
existing
 > code.
 >
 > Any suggestions on how I should proceed? Is keeping my function as-is
 > a better option? Name conflict is not unusual across packages and so
 > users need to learn how to solve this problem anyway.
Nevertheless, if
 > possible, I would like to solve the conflict internally such that
 > users do not need to do anything.

I think it's impossible to avoid some inconvenience to your users.

Here's what I'd suggest:

- Create a method for base::sort_by(), as you suggested you could.  Use
the generic's variable names for compatibility, but also add your extra
variable names as additional arguments, e.g.

   sort_by.est_table <- function(x, y, object,
     by = c("op", "lhs", "rhs"),
     op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
     number_rows = TRUE, ...) {

    # This test seems unlikely:  how would we have dispatch here if we
specified object explicitly?

    if (!missing(object) {
      if (!missing(x))
        stop("both x and object specified!")
      x <- object
    }

    # This one is more likely to do something:

    if (!missing(by)) {
      if (!missing(y))
        stop("both y and by specified!")
      y <- by
    }

    # Now proceed using x and y

    ...
}

- Create a separate function, e.g. sort_by_old() which is exactly
compatible with your old sort_by().  For users where the above doesn't
just work, they can switch to sort_by_old().

Duncan Murdoch

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




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

[R-pkg-devel] rhub (old and new) balks at building ncdf4 package

[Daniel Kelley]

I have a package, named 'oce' (developed at www.github.com/dankelley/oce and 
available through CRAN for over a decade) that uses 'ncdf4' to read some file 
types.  When I do test builds on the win and mac builders, all is fine.  When I 
do it with rhub, though, I get an error that ncdf4 cannot be built from source.

I think it's been this way for quite a while, perhaps months  Should I be doing 
something when I invoke rhub (locally or on github) to tell it to use a 
prebuild ncdf4 package?

Thanks in advance for any advice.

Dan E. Kelley
Professor, Department of Oceanography
Dalhousie University

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

Re: [R-pkg-devel] A function in one of my package is now a method in base R

[Shu Fai Cheung]

Thanks a lot for both suggestions! I haven't thought about these
approaches, They may solve my problem without breaking existing code.
I may just keep the original arguments for backward compatibility.
Coincidentally, "object" and "by" have the same meanings as "x" and
"y" in base::sort_by() and so the matching makes sense.

Regards,
Shu Fai Cheung

On Sat, Aug 3, 2024 at 7:13 PM Deepayan Sarkar
 wrote:
>
> I haven't thought about this carefully, but shouldn't this mostly work?
>
>   sort_by.est_table <- function(x, y = c("op", "lhs", "rhs"),
> object = x,
> by = y,
> op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
> number_rows = TRUE, ...) {
>
> 
>
> }
>
> -Deepayan
>
> On Sat, 3 Aug 2024 at 00:13, Duncan Murdoch  wrote:
>>
>> On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:
>> > Hi All,
>> >
>> > I have a function (not a method), sort_by(), in one of my packages. A
>> > new method with the same name was introduced in the recent versions of
>> > R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
>> > conflict in users' code.
>> >
>> > Certainly, users can simply use pkg_name::function_name() to solve the
>> > conflict. However, I would like to be consistent with base R and so I
>> > am thinking about converting my function to a method for the class for
>> > which my function is intended to work on (e.g, est_table).
>> >
>> > However, my function has arguments different from those in the base R 
>> > sort_by():
>> >
>> > Base R:
>> >
>> > sort_by(x, y, ...)
>> >
>> > My function:
>> >
>> > sort_by(
>> >object,
>> >by = c("op", "lhs", "rhs"),
>> >op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
>> >number_rows = TRUE
>> > )
>> >
>> > If I write the function sort_by.est_table(), I would need to match the
>> > argument names of the base R sort_by(). However, I think it is a bad
>> > idea to rename the arguments in my function and it will break existing
>> > code.
>> >
>> > Any suggestions on how I should proceed? Is keeping my function as-is
>> > a better option? Name conflict is not unusual across packages and so
>> > users need to learn how to solve this problem anyway. Nevertheless, if
>> > possible, I would like to solve the conflict internally such that
>> > users do not need to do anything.
>>
>> I think it's impossible to avoid some inconvenience to your users.
>>
>> Here's what I'd suggest:
>>
>> - Create a method for base::sort_by(), as you suggested you could.  Use
>> the generic's variable names for compatibility, but also add your extra
>> variable names as additional arguments, e.g.
>>
>>   sort_by.est_table <- function(x, y, object,
>> by = c("op", "lhs", "rhs"),
>> op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
>> number_rows = TRUE, ...) {
>>
>># This test seems unlikely:  how would we have dispatch here if we
>> specified object explicitly?
>>
>>if (!missing(object) {
>>  if (!missing(x))
>>stop("both x and object specified!")
>>  x <- object
>>}
>>
>># This one is more likely to do something:
>>
>>if (!missing(by)) {
>>  if (!missing(y))
>>stop("both y and by specified!")
>>  y <- by
>>}
>>
>># Now proceed using x and y
>>
>>...
>> }
>>
>> - Create a separate function, e.g. sort_by_old() which is exactly
>> compatible with your old sort_by().  For users where the above doesn't
>> just work, they can switch to sort_by_old().
>>
>> Duncan Murdoch
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] A function in one of my package is now a method in base R

[Deepayan Sarkar]

I haven't thought about this carefully, but shouldn't this mostly work?

  sort_by.est_table <- function(x, y = c("op", "lhs", "rhs"),
object = x,
by = y,
op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
number_rows = TRUE, ...) {



}

-Deepayan

On Sat, 3 Aug 2024 at 00:13, Duncan Murdoch 
wrote:

> On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:
> > Hi All,
> >
> > I have a function (not a method), sort_by(), in one of my packages. A
> > new method with the same name was introduced in the recent versions of
> > R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
> > conflict in users' code.
> >
> > Certainly, users can simply use pkg_name::function_name() to solve the
> > conflict. However, I would like to be consistent with base R and so I
> > am thinking about converting my function to a method for the class for
> > which my function is intended to work on (e.g, est_table).
> >
> > However, my function has arguments different from those in the base R
> sort_by():
> >
> > Base R:
> >
> > sort_by(x, y, ...)
> >
> > My function:
> >
> > sort_by(
> >object,
> >by = c("op", "lhs", "rhs"),
> >op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
> >number_rows = TRUE
> > )
> >
> > If I write the function sort_by.est_table(), I would need to match the
> > argument names of the base R sort_by(). However, I think it is a bad
> > idea to rename the arguments in my function and it will break existing
> > code.
> >
> > Any suggestions on how I should proceed? Is keeping my function as-is
> > a better option? Name conflict is not unusual across packages and so
> > users need to learn how to solve this problem anyway. Nevertheless, if
> > possible, I would like to solve the conflict internally such that
> > users do not need to do anything.
>
> I think it's impossible to avoid some inconvenience to your users.
>
> Here's what I'd suggest:
>
> - Create a method for base::sort_by(), as you suggested you could.  Use
> the generic's variable names for compatibility, but also add your extra
> variable names as additional arguments, e.g.
>
>   sort_by.est_table <- function(x, y, object,
> by = c("op", "lhs", "rhs"),
> op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
> number_rows = TRUE, ...) {
>
># This test seems unlikely:  how would we have dispatch here if we
> specified object explicitly?
>
>if (!missing(object) {
>  if (!missing(x))
>stop("both x and object specified!")
>  x <- object
>}
>
># This one is more likely to do something:
>
>if (!missing(by)) {
>  if (!missing(y))
>stop("both y and by specified!")
>  y <- by
>}
>
># Now proceed using x and y
>
>...
> }
>
> - Create a separate function, e.g. sort_by_old() which is exactly
> compatible with your old sort_by().  For users where the above doesn't
> just work, they can switch to sort_by_old().
>
> Duncan Murdoch
>
> __
> 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] rhub (version 2) baulking at building a vignette.

[Rolf Turner]

Thanks to Ivan Krylov and Dirk Eddelbuettel who came to my rescue.

At first I thought that Dirk's suggestion ("the zero-dependency
approach" due to Mark van der Loo) was exactly what I needed.  But this
turned out not to work; rhub_check() still failed with a complaint
about needing pdflatex.

Ivan's suggestion (the "asis" vignette from the R.rsp package) does
work.  This turns out to be easy enough to implement, but it has taken
me all day to get everything to run properly.  The difficulties were not
due to any characteristics of the "asis" approach, but rather to the
(to me) fussy, delicate, awkward, and counter-intuitive nature of rhub.
It kept finding new and innovative ways to frustrate me. ☹️ However I
finally won out.

I won't try to describe what I eventually did/had to do.  It is too
tortuous a tale of trial and error, with too many rhub "Gotchas!"
which I have difficulty reconstructing and to which I often cannot
remember the solutions.  I've got the solutions in place, and am just
crossing my fingers that I won't have to do it all over again.

Ivan Krylov  wrote:



> Since your package doesn't seem to contain any native code, wouldn't
> the Windows users be satisfied with a source package? Unless running R
> CMD build --no-build-vignettes, it will include the PDF file.

Since I don't (ever) use Windoze myself, I have no feeling for what it
(and its users) will or will not tolerate.  Nor have I any way to test
out ideas.  So I prefer to go with building Windoze binaries, via rhub
or winbuilder.  (Using each as a back-up for the other.)  Now that I
know how (???) to do this, it's not too bad.

Thanks again to Ivan and Dirk.

cheers,

Rolf

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

Re: [R-pkg-devel] A function in one of my package is now a method in base R

[Duncan Murdoch]

On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:

Hi All,

I have a function (not a method), sort_by(), in one of my packages. A
new method with the same name was introduced in the recent versions of
R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
conflict in users' code.

Certainly, users can simply use pkg_name::function_name() to solve the
conflict. However, I would like to be consistent with base R and so I
am thinking about converting my function to a method for the class for
which my function is intended to work on (e.g, est_table).

However, my function has arguments different from those in the base R sort_by():

Base R:

sort_by(x, y, ...)

My function:

sort_by(
   object,
   by = c("op", "lhs", "rhs"),
   op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
   number_rows = TRUE
)

If I write the function sort_by.est_table(), I would need to match the
argument names of the base R sort_by(). However, I think it is a bad
idea to rename the arguments in my function and it will break existing
code.

Any suggestions on how I should proceed? Is keeping my function as-is
a better option? Name conflict is not unusual across packages and so
users need to learn how to solve this problem anyway. Nevertheless, if
possible, I would like to solve the conflict internally such that
users do not need to do anything.


I think it's impossible to avoid some inconvenience to your users.

Here's what I'd suggest:

- Create a method for base::sort_by(), as you suggested you could.  Use 
the generic's variable names for compatibility, but also add your extra 
variable names as additional arguments, e.g.


 sort_by.est_table <- function(x, y, object,
   by = c("op", "lhs", "rhs"),
   op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
   number_rows = TRUE, ...) {

  # This test seems unlikely:  how would we have dispatch here if we 
specified object explicitly?


  if (!missing(object) {
if (!missing(x))
  stop("both x and object specified!")
x <- object
  }

  # This one is more likely to do something:

  if (!missing(by)) {
if (!missing(y))
  stop("both y and by specified!")
y <- by
  }

  # Now proceed using x and y

  ...
}

- Create a separate function, e.g. sort_by_old() which is exactly 
compatible with your old sort_by().  For users where the above doesn't 
just work, they can switch to sort_by_old().


Duncan Murdoch

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

Re: [R-pkg-devel] rhub (version 2) baulking at building a vignette.

[Dirk Eddelbuettel]

On 2 August 2024 at 16:12, Ivan Krylov via R-package-devel wrote:
| В Fri,  2 Aug 2024 11:10:59 +
| Rolf Turner  пишет:
| 
| > The advice was to the effect that if the vignette was actually just a
| > *.tex file, one could (after putting in some preparatory code, in the
| > form of comments, before the documentclass command) pre-process the
| > file (with pdflatex) and the build would use the *.pdf file that was
| > created, without any processing being required.
| 
| I think that you are looking for the "asis" vignette engine from the

Or the zero-dependency approach by Mark van der Loo of embedding a whole
(pre-made pdf) in a five-line Rnw sweave file described in 
  https://www.r-bloggers.com/2019/01/add-a-static-pdf-vignette-to-an-r-package/

So no real pdf processing requirement (besides the minimal include), so no
random failing over a .sty or font one uses suddenly missing on another machine.

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

[R-pkg-devel] A function in one of my package is now a method in base R

[Shu Fai Cheung]

Hi All,

I have a function (not a method), sort_by(), in one of my packages. A
new method with the same name was introduced in the recent versions of
R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
conflict in users' code.

Certainly, users can simply use pkg_name::function_name() to solve the
conflict. However, I would like to be consistent with base R and so I
am thinking about converting my function to a method for the class for
which my function is intended to work on (e.g, est_table).

However, my function has arguments different from those in the base R sort_by():

Base R:

sort_by(x, y, ...)

My function:

sort_by(
  object,
  by = c("op", "lhs", "rhs"),
  op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
  number_rows = TRUE
)

If I write the function sort_by.est_table(), I would need to match the
argument names of the base R sort_by(). However, I think it is a bad
idea to rename the arguments in my function and it will break existing
code.

Any suggestions on how I should proceed? Is keeping my function as-is
a better option? Name conflict is not unusual across packages and so
users need to learn how to solve this problem anyway. Nevertheless, if
possible, I would like to solve the conflict internally such that
users do not need to do anything.

Regards,
Shu Fai Cheung

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

Re: [R-pkg-devel] rhub (version 2) baulking at building a vignette.

[Ivan Krylov via R-package-devel]

В Fri,  2 Aug 2024 11:10:59 +
Rolf Turner  пишет:

> The advice was to the effect that if the vignette was actually just a
> *.tex file, one could (after putting in some preparatory code, in the
> form of comments, before the documentclass command) pre-process the
> file (with pdflatex) and the build would use the *.pdf file that was
> created, without any processing being required.

I think that you are looking for the "asis" vignette engine from the
R.rsp package:
https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf

> Now I want to build a Windoze binary of the package.

If the vignette uses LaTeX packages unavailable on the computer (rhub2
virtual machine) running R CMD build or R CMD check, that would indeed
not work. Not sure about CRAN.

Since your package doesn't seem to contain any native code, wouldn't
the Windows users be satisfied with a source package? Unless running R
CMD build --no-build-vignettes, it will include the PDF file.

-- 
Best regards,
Ivan

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

[R-pkg-devel] rhub (version 2) baulking at building a vignette.

[Rolf Turner]

Some time back, in the mists of memory, I got advice (on this list, I'm
pretty sure) about building vignettes.  The advice was to the effect
that if the vignette was actually just a *.tex file, one could (after
putting in some preparatory code, in the form of comments, before the
documentclass command) pre-process the file (with pdflatex)
and the build would use the *.pdf file that was created, without any
processing being required.

Being a Bear of Very Little Brain (and understanding almost nothing of
the underlying intricacies) I simply followed instructions. It seemed
to work, I was able to build and install the package containing the
vignette in question.

Now I want to build a Windoze binary of the package.  Trying to do this
with rhub led to a failure.  The build process seemed to ignore the
pre-processed *.pdf file, tried to create it, and complained that
pdflatex was not available.

I raised an "issue" about this on rhub:

   https://github.com/r-hub/rhub/issues/629

I got a response from the redoubtable Gábor Csárdi saying that
when he tried a local build of my package, the build command threw
effectively the same error as did rhub.  So there's "something about my
system" that is different.  What could it be?

I have attached my session info in a *.txt file, to avoid cluttering the
email window too much.

If anyone should wish to experiment, they can clone the package in
question (I think!) by executing: 

git clone https://github.com/rolfTurner/kanova.git

Can anyone give me some avuncular advice as to how:

(a) to get rhub_check() to use the pre-compiled file testStat.pdf, or
(b) to make pdflatex available to rhub_check()
(c) to do something else that will permit me to build a Windoze binary
 using rhub?

Grateful for any tips.

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
> sessionInfo()
R version 4.4.1 (2024-06-14)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 22.04.4 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 
LAPACK: /usr/lib/x86_64-linux-gnu/atlas/liblapack.so.3.10.3;  LAPACK version 
3.10.0

locale:
 [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C  
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_GB.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_GB.UTF-8   
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C 
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C   

time zone: Pacific/Auckland
tzcode source: system (glibc)

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

other attached packages:
[1] brev_0.0-8

loaded via a namespace (and not attached):
 [1] vctrs_0.6.5   cli_3.6.3 rlang_1.1.4   stringi_1.8.4
 [5] purrr_1.0.2   pkgload_1.4.0 promises_1.3.0shiny_1.8.1.1
 [9] xtable_1.8-4  glue_1.7.0htmltools_0.5.8.1 httpuv_1.6.15
[13] pkgbuild_1.4.4ellipsis_0.3.2fastmap_1.2.0 lifecycle_1.0.4  
[17] memoise_2.0.1 stringr_1.5.1 compiler_4.4.1miniUI_0.1.1.1   
[21] sessioninfo_1.2.2 fs_1.6.4  htmlwidgets_1.6.4 Rcpp_1.0.13  
[25] urlchecker_1.0.1  later_1.3.2   digest_0.6.36 R6_2.5.1 
[29] usethis_2.2.3 magrittr_2.0.3tools_4.4.1   mime_0.12
[33] devtools_2.4.5bspm_0.5.7profvis_0.3.8 remotes_2.5.0
[37] cachem_1.1.0 

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

Re: [R-pkg-devel] LaTeX errors under MacOS on CRAN

[Uwe Ligges]

A vague recollections tells me this happened when the set of packages 
was not fully updated.


Best,
Uwe LIgges




On 02.08.2024 09:39, Ivan Krylov via R-package-devel wrote:

В Thu, 1 Aug 2024 10:53:56 -0400
Ben Bolker  пишет:


! Undefined control sequence.
l.176 \hlkwd{library}\hldef
   {(}\hlsng{"glmmTMB"}\hldef{)}


Very strange.

This may be related to https://github.com/yihui/knitr/issues/2345
(no diagnosis) and possibly https://github.com/yihui/knitr/pull/2341
(where some of the highlight commands have been renamed).

It would be interesting to see the resulting *.tex file: somehow,
\hlkwd is defined, but \hldef isn't.

Looking at the code, knitr should be generating all these definitions
in styler_assistant_latex, called from theme_to_header_latex. This one
is either called from theme_to_header (thus from knit_theme$get(name)),
or at installation time, converting inst/themes/default.css (which
should have both hlkwd and hldef set).

Since you aren't setting any knitr highlighting themes or
opts_knit$set('header'), you should be getting both \hlkwd and \hldef
defined from themes/default.css via knitr::render_latex. Is there a way
to inadvertently set the 'header' knitr option?

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

Re: [R-pkg-devel] LaTeX errors under MacOS on CRAN

[Ivan Krylov via R-package-devel]

В Thu, 1 Aug 2024 10:53:56 -0400
Ben Bolker  пишет:

>! Undefined control sequence.
>l.176 \hlkwd{library}\hldef
>   {(}\hlsng{"glmmTMB"}\hldef{)}

Very strange.

This may be related to https://github.com/yihui/knitr/issues/2345
(no diagnosis) and possibly https://github.com/yihui/knitr/pull/2341
(where some of the highlight commands have been renamed).

It would be interesting to see the resulting *.tex file: somehow,
\hlkwd is defined, but \hldef isn't.

Looking at the code, knitr should be generating all these definitions
in styler_assistant_latex, called from theme_to_header_latex. This one
is either called from theme_to_header (thus from knit_theme$get(name)),
or at installation time, converting inst/themes/default.css (which
should have both hlkwd and hldef set).

Since you aren't setting any knitr highlighting themes or
opts_knit$set('header'), you should be getting both \hlkwd and \hldef
defined from themes/default.css via knitr::render_latex. Is there a way
to inadvertently set the 'header' knitr option?

-- 
Best regards,
Ivan

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

[R-pkg-devel] LaTeX errors under MacOS on CRAN

[Ben Bolker]

  I note that on r-release-macos-x86_64, glmmTMB is getting warnings 
like this:


 Error: processing vignette 'glmmTMB.Rnw' failed with diagnostics:
  Running 'texi2dvi' on 'glmmTMB.tex' failed.
  LaTeX errors:
  ! Undefined control sequence.
  l.176 \hlkwd{library}\hldef
 {(}\hlsng{"glmmTMB"}\hldef{)}
  ?
  ! Emergency stop.
  ! Emergency stop.
  l.176



  (I see similar but not identical problems with 
, 
although on different platforms.


  Has anyone seen this/does anyone have ideas for troubleshooting? 
(Haven't checked on the r-hub platforms yet ...)


  cheers
   Ben Bolker

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Dirk Eddelbuettel]

On 29 July 2024 at 13:02, Ivan Krylov wrote:
| On Sun, 28 Jul 2024 15:27:33 -0500
| Dirk Eddelbuettel  wrote:
| 
| > If we cannot (or do not want to) modify the given main.R, I would
| > suggest something along the lines of
| > 
| >   Rscript -e 'pdf(myfilenamevar); source("main.R"); dev.off()' | tee
| > 2024-07-28.log
| 
| Perhaps even options(device = \(file = myfilenamevar, ...) pdf(file =
| file, ...)) so that every plot would get the same treatment, though
| that requires re-implementing the dev.new() logic to guess an available
| file name. You can even misuse R_PROFILE_USER to inject the code into
| the R CMD BATCH session:
| 
| # myplots.R:
| local({
|   cmdline <- commandArgs(FALSE)
|   srcfile <- cmdline[[which(cmdline == '-f')[[1]] + 1]]
|   plotfile <- sub('(\\.R)?$', '', srcfile)
|   options(device = \(file, ...) {
|   i <- 1
|   if (missing(file)) repeat {
|   file <- sprintf('%s_%03d.pdf', plotfile, i)
|   if (!file.exists(file)) break
|   i <- i+1
|   }
|   pdf(file = file, ...)
|   })
| })
| 
| # example.R:
| plot(1:100 / 10, sin(1:100 / 10))
| dev.off()
| plot(1:100 / 10, cos(1:100 / 10))
| 
| R_PROFILE_USER=myplots.R R CMD BATCH example.R
| # produces example.Rout, example_001.pdf, example_002.pdf

Impressive. A very creative way to inject a modification into the (to my
taste overly restrictive) setup provided by R CMD BATCH.

Personally I would much rather script something cleaner with r or Rscript but
we all have our preferences.

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Ivan Krylov via R-package-devel]

On Sun, 28 Jul 2024 15:27:33 -0500
Dirk Eddelbuettel  wrote:

> If we cannot (or do not want to) modify the given main.R, I would
> suggest something along the lines of
> 
>   Rscript -e 'pdf(myfilenamevar); source("main.R"); dev.off()' | tee
> 2024-07-28.log

Perhaps even options(device = \(file = myfilenamevar, ...) pdf(file =
file, ...)) so that every plot would get the same treatment, though
that requires re-implementing the dev.new() logic to guess an available
file name. You can even misuse R_PROFILE_USER to inject the code into
the R CMD BATCH session:

# myplots.R:
local({
cmdline <- commandArgs(FALSE)
srcfile <- cmdline[[which(cmdline == '-f')[[1]] + 1]]
plotfile <- sub('(\\.R)?$', '', srcfile)
options(device = \(file, ...) {
i <- 1
if (missing(file)) repeat {
file <- sprintf('%s_%03d.pdf', plotfile, i)
if (!file.exists(file)) break
i <- i+1
}
pdf(file = file, ...)
})
})

# example.R:
plot(1:100 / 10, sin(1:100 / 10))
dev.off()
plot(1:100 / 10, cos(1:100 / 10))

R_PROFILE_USER=myplots.R R CMD BATCH example.R
# produces example.Rout, example_001.pdf, example_002.pdf

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Dirk Eddelbuettel]

On 28 July 2024 at 15:44, Duncan Murdoch wrote:
| On 2024-07-28 1:48 p.m., Josiah Parry wrote:
| > However, if plots are generated in the process, the plots are stored in
| > Rplots.pdf.
| > 
| > Is there a way via command line arguments to change the name of the pdf
| > output.
| > 
| > There might be multiple runs of this script and it would be ideal to store
| > the plot output independently.
| 
| That's the default filename if you open a PDF device.  Open it

It's the default (and fallback) device and filename you fail to specify
something else. Ie 'Rscript -e "plot(1:10)"' will create it too.

My preferred alternative is to wrap call to plot() with actual device create
(something like 'if (!interactive()) pdf(my_filename, 8. 6)' with a
corresponding 'if (!interactive()) dev.off()' to ensure the file finalised
and close.

If we cannot (or do not want to) modify the given main.R, I would suggest
something along the lines of

  Rscript -e 'pdf(myfilenamevar); source("main.R"); dev.off()' | tee 
2024-07-28.log

and Bob's your uncle now in terms of how you spec the filename.

In short, I would let go of `R CMD BATCH` if it does not do what you want.

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Duncan Murdoch]

On 2024-07-28 4:05 p.m., Josiah Parry wrote:

Thanks, Duncan!

Is there a way to override this using the command line arguments?


I assume you could do that using commandArgs() in the dev.new() call, 
but I don't use BATCH.


I'd like to be able to have a generalizable way to address this without 
having to modify R source code.


Take a look at the source to dev.new().  It tries various things, maybe 
one of those will suit you.


My understanding is that when there is a plot output, R CMD BATCH uses 
the PDF device which is a fair default.


However, there is not any use of `dev.new()` or `pdf()` called anywhere 
in the code.


Not explicitly, but if you try to call a plot function with no device 
active, the graphics system will call dev.new().


Duncan Murdoch



On Sun, Jul 28, 2024 at 3:44 PM Duncan Murdoch > wrote:


On 2024-07-28 1:48 p.m., Josiah Parry wrote:
 > Hey folks! I am working with R CMD BATCH and providing a providing a
 > logfile output e.g.
 >
 > R CMD BATCH main.R 2024-07-28.log
 >
 > This creates the desired log file with the contents of stdout and
stderr.
 >
 > However, if plots are generated in the process, the plots are
stored in
 > Rplots.pdf.
 >
 > Is there a way via command line arguments to change the name of
the pdf
 > output.
 >
 > There might be multiple runs of this script and it would be ideal
to store
 > the plot output independently.

That's the default filename if you open a PDF device.  Open it
explicitly and you can specify any file you like.

That is,

    plot(rnorm(100))

will call dev.new() which in a non-interactive session calls pdf().  If
you specify

    dev.new(file = "something.pdf")
    plot(rnorm(100))

the "file" argument will be ignored in an interactive session, but will
be used in a non-interactive one.

Duncan Murdoch




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

Re: [R-pkg-devel] R CMD BATCH plot output

[Ben Bolker]

Dirk Eddelbuettel would tell you to use his 'little r' script instead,
though not sure if it has this particular flexibility. You could wrap R CMD
BATCH in your own script that moved Rplots.pdf where you wanted it ...

On Sun, Jul 28, 2024, 4:05 PM Josiah Parry  wrote:

> Thanks, Duncan!
>
> Is there a way to override this using the command line arguments?
>
> I'd like to be able to have a generalizable way to address this without
> having to modify R source code.
>
> My understanding is that when there is a plot output, R CMD BATCH uses the
> PDF device which is a fair default.
>
> However, there is not any use of `dev.new()` or `pdf()` called anywhere in
> the code.
>
> On Sun, Jul 28, 2024 at 3:44 PM Duncan Murdoch 
> wrote:
>
> > On 2024-07-28 1:48 p.m., Josiah Parry wrote:
> > > Hey folks! I am working with R CMD BATCH and providing a providing a
> > > logfile output e.g.
> > >
> > > R CMD BATCH main.R 2024-07-28.log
> > >
> > > This creates the desired log file with the contents of stdout and
> stderr.
> > >
> > > However, if plots are generated in the process, the plots are stored in
> > > Rplots.pdf.
> > >
> > > Is there a way via command line arguments to change the name of the pdf
> > > output.
> > >
> > > There might be multiple runs of this script and it would be ideal to
> > store
> > > the plot output independently.
> >
> > That's the default filename if you open a PDF device.  Open it
> > explicitly and you can specify any file you like.
> >
> > That is,
> >
> >plot(rnorm(100))
> >
> > will call dev.new() which in a non-interactive session calls pdf().  If
> > you specify
> >
> >dev.new(file = "something.pdf")
> >plot(rnorm(100))
> >
> > the "file" argument will be ignored in an interactive session, but will
> > be used in a non-interactive one.
> >
> > Duncan Murdoch
> >
> >
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Josiah Parry]

Thanks, Duncan!

Is there a way to override this using the command line arguments?

I'd like to be able to have a generalizable way to address this without
having to modify R source code.

My understanding is that when there is a plot output, R CMD BATCH uses the
PDF device which is a fair default.

However, there is not any use of `dev.new()` or `pdf()` called anywhere in
the code.

On Sun, Jul 28, 2024 at 3:44 PM Duncan Murdoch 
wrote:

> On 2024-07-28 1:48 p.m., Josiah Parry wrote:
> > Hey folks! I am working with R CMD BATCH and providing a providing a
> > logfile output e.g.
> >
> > R CMD BATCH main.R 2024-07-28.log
> >
> > This creates the desired log file with the contents of stdout and stderr.
> >
> > However, if plots are generated in the process, the plots are stored in
> > Rplots.pdf.
> >
> > Is there a way via command line arguments to change the name of the pdf
> > output.
> >
> > There might be multiple runs of this script and it would be ideal to
> store
> > the plot output independently.
>
> That's the default filename if you open a PDF device.  Open it
> explicitly and you can specify any file you like.
>
> That is,
>
>plot(rnorm(100))
>
> will call dev.new() which in a non-interactive session calls pdf().  If
> you specify
>
>dev.new(file = "something.pdf")
>plot(rnorm(100))
>
> the "file" argument will be ignored in an interactive session, but will
> be used in a non-interactive one.
>
> Duncan Murdoch
>
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD BATCH plot output

[Duncan Murdoch]

On 2024-07-28 1:48 p.m., Josiah Parry wrote:

Hey folks! I am working with R CMD BATCH and providing a providing a
logfile output e.g.

R CMD BATCH main.R 2024-07-28.log

This creates the desired log file with the contents of stdout and stderr.

However, if plots are generated in the process, the plots are stored in
Rplots.pdf.

Is there a way via command line arguments to change the name of the pdf
output.

There might be multiple runs of this script and it would be ideal to store
the plot output independently.


That's the default filename if you open a PDF device.  Open it 
explicitly and you can specify any file you like.


That is,

  plot(rnorm(100))

will call dev.new() which in a non-interactive session calls pdf().  If 
you specify


  dev.new(file = "something.pdf")
  plot(rnorm(100))

the "file" argument will be ignored in an interactive session, but will 
be used in a non-interactive one.


Duncan Murdoch

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

[R-pkg-devel] R CMD BATCH plot output

[Josiah Parry]

Hey folks! I am working with R CMD BATCH and providing a providing a
logfile output e.g.

R CMD BATCH main.R 2024-07-28.log

This creates the desired log file with the contents of stdout and stderr.

However, if plots are generated in the process, the plots are stored in
Rplots.pdf.

Is there a way via command line arguments to change the name of the pdf
output.

There might be multiple runs of this script and it would be ideal to store
the plot output independently.

[[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] MSRV on Fedora

[Hiroaki Yutani]

> As such, I cannot manage the MSRV of the package's dependencies.

It seems the reason for geographiclib-rs's MSRV is just that it uses
std::sync::OnceLock. Maybe a possible workaround is to fork the repo and
replace it with the once_cell crate? You should be able to override the
dependency by [patch.crates-io] section.

Best,
Yutani

2024年7月24日(水) 1:20 Josiah Parry :

> Hi all!
>
> I have 2 errors related to minimum supported rust version (MSRV) on fedora
>
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rsgeo-00install.html
> that I do not know how to resolve.
>
> The package {rsgeo} has a dependency on the rust crate geo which itself has
> a dependency on geographiclib-rs which has an MSRV of 1.70 whereas the CRAN
> fedora machines are 1.69.
>
> As such, I cannot manage the MSRV of the package's dependencies.
>
> As an alternative, can I indicate in my DESCRIPTION that the package is not
> supported on Fedora so that CRAN machines do not attempt to build it? I
> would be a-okay saying if you're using fedora you have to build from
> source.
>
> [[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] MSRV on Fedora

[Duncan Murdoch]

I think saying that Fedora is not supported is the wrong solution, 
unless you know that Rust version 1.70 will never be supported on 
Fedora.  Isn't the appropriate solution to document the MSRV in the 
SystemRequirements field of your DESCRIPTION file?


When you submit, point out that you have done this in your submission 
comments.  I don't think a Fedora failure will cause a submission to be 
automatically rejected, but the CRAN reviewers may want to know if you 
have dealt with the error, and you should explain that this is what 
you've done.


Duncan Murdoch



On 2024-07-23 12:19 p.m., Josiah Parry wrote:

Hi all!

I have 2 errors related to minimum supported rust version (MSRV) on fedora
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rsgeo-00install.html
that I do not know how to resolve.

The package {rsgeo} has a dependency on the rust crate geo which itself has
a dependency on geographiclib-rs which has an MSRV of 1.70 whereas the CRAN
fedora machines are 1.69.

As such, I cannot manage the MSRV of the package's dependencies.

As an alternative, can I indicate in my DESCRIPTION that the package is not
supported on Fedora so that CRAN machines do not attempt to build it? I
would be a-okay saying if you're using fedora you have to build from
source.

[[alternative HTML version deleted]]

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


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

[R-pkg-devel] MSRV on Fedora

[Josiah Parry]

Hi all!

I have 2 errors related to minimum supported rust version (MSRV) on fedora
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rsgeo-00install.html
that I do not know how to resolve.

The package {rsgeo} has a dependency on the rust crate geo which itself has
a dependency on geographiclib-rs which has an MSRV of 1.70 whereas the CRAN
fedora machines are 1.69.

As such, I cannot manage the MSRV of the package's dependencies.

As an alternative, can I indicate in my DESCRIPTION that the package is not
supported on Fedora so that CRAN machines do not attempt to build it? I
would be a-okay saying if you're using fedora you have to build from
source.

[[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] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

Thank you Duncan for providing detailed information on parsing in R. I will
check it out and utilize the string inputs for my functions.

Best regards,
Khue Tran

On Sat, Jul 20, 2024 at 4:40 AM Duncan Murdoch 
wrote:

> Just for your info:
>
>  > exp(mpfr("0.1", 152))
> 1 'mpfr' number of precision  152   bits
> [1] 1.1051709180756476248117078264902466682245471948
>
> So it looks like your approach of parsing the numbers yourself makes sense.
>
> You can find the R parser here:
>
> https://github.com/wch/r-source/blob/b64422334a8269535718efd9a1f969c94b103056/src/main/gram.y#L2577-L2705
>
> I don't know how much of that you want to replicate, but I suppose
> handling the weird cases (e.g. 0x1p1) the way R does will make it easier
> for your users.
>
> Duncan Murdoch
>
> On 2024-07-18 4:29 p.m., Khue Tran wrote:
> > Hi,
> >
> > I am trying to create an Rcpp package that involves arbitrary precise
> > calculations. The function to calculate e^x below with 100 digits
> precision
> > works well with integers, but for decimals, since the input is a double,
> > the result differs a lot from the arbitrary precise result I got on
> > Wolfram.
> >
> > I understand the results are different since 0.1 cannot be represented
> > precisely in binary with limited bits. It is possible to enter 1 then 10
> > and get the multiprecision division of these two integers to attain a
> more
> > precise 0.1 in C++, but this method won't work on a large scale. Thus, I
> am
> > looking for a general solution to get more precise inputs?
> >
> > The dummy example is as follows:
> >
> > library(Rcpp)
> >
> > sourceCpp(code = '
> > #include 
> > #include 
> >
> > // [[Rcpp::depends(BH)]]
> > // [[Rcpp::export]]
> > std::string calculateExp100(double x) {
> >boost::multiprecision::cpp_dec_float_100 bx = x;
> >boost::multiprecision::cpp_dec_float_100 expx = exp(bx);
> >return expx.str(50);
> > }
> > ')
> >
> > [1] represents the R output and [W] for Wolfram results
> >
> > calculateExp100(1) # Agrees with Wolfram answer all the way to the last
> > digit
> > [1] "2.7182818284590452353602874713526624977572470937"
> > [W] 2.7182818284590452353602874713526624977572470936999595749669676277...
> >
> > calculateExp100(0.1) # Differs pretty significantly from Wolfram's answer
> > [1] "1.1051709180756476309466388234587796577416634163742"
> > [W] 1.1051709180756476248117078264902466682245471947375187187928632894...
> >
> > I am currently trying to get precise inputs by taking strings instead of
> > numbers then writing a function to decompose the string into a rational
> > with the denominator in the form of 10^(-n) where n is the number of
> > decimal places. I am not sure if this is the only way or if there is a
> > better method out there that I do not know of, so if you can think of a
> > general way to get precise inputs from users, it will be greatly
> > appreciated!
> >
> > Thank you!
> > Best,
> > Khue Tran
> >
>
>

[[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] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

Thank you Prof. Maechler! Indeed 0.1 is not the same as 1/10 and there are
many ways to get more precise versions of it. I will look into how to take
inputs as strings. Thank you!

Best,
Khue Tran

On Sat, Jul 20, 2024 at 4:40 AM Duncan Murdoch 
wrote:

> Just for your info:
>
>  > exp(mpfr("0.1", 152))
> 1 'mpfr' number of precision  152   bits
> [1] 1.1051709180756476248117078264902466682245471948
>
> So it looks like your approach of parsing the numbers yourself makes sense.
>
> You can find the R parser here:
>
> https://github.com/wch/r-source/blob/b64422334a8269535718efd9a1f969c94b103056/src/main/gram.y#L2577-L2705
>
> I don't know how much of that you want to replicate, but I suppose
> handling the weird cases (e.g. 0x1p1) the way R does will make it easier
> for your users.
>
> Duncan Murdoch
>
> On 2024-07-18 4:29 p.m., Khue Tran wrote:
> > Hi,
> >
> > I am trying to create an Rcpp package that involves arbitrary precise
> > calculations. The function to calculate e^x below with 100 digits
> precision
> > works well with integers, but for decimals, since the input is a double,
> > the result differs a lot from the arbitrary precise result I got on
> > Wolfram.
> >
> > I understand the results are different since 0.1 cannot be represented
> > precisely in binary with limited bits. It is possible to enter 1 then 10
> > and get the multiprecision division of these two integers to attain a
> more
> > precise 0.1 in C++, but this method won't work on a large scale. Thus, I
> am
> > looking for a general solution to get more precise inputs?
> >
> > The dummy example is as follows:
> >
> > library(Rcpp)
> >
> > sourceCpp(code = '
> > #include 
> > #include 
> >
> > // [[Rcpp::depends(BH)]]
> > // [[Rcpp::export]]
> > std::string calculateExp100(double x) {
> >boost::multiprecision::cpp_dec_float_100 bx = x;
> >boost::multiprecision::cpp_dec_float_100 expx = exp(bx);
> >return expx.str(50);
> > }
> > ')
> >
> > [1] represents the R output and [W] for Wolfram results
> >
> > calculateExp100(1) # Agrees with Wolfram answer all the way to the last
> > digit
> > [1] "2.7182818284590452353602874713526624977572470937"
> > [W] 2.7182818284590452353602874713526624977572470936999595749669676277...
> >
> > calculateExp100(0.1) # Differs pretty significantly from Wolfram's answer
> > [1] "1.1051709180756476309466388234587796577416634163742"
> > [W] 1.1051709180756476248117078264902466682245471947375187187928632894...
> >
> > I am currently trying to get precise inputs by taking strings instead of
> > numbers then writing a function to decompose the string into a rational
> > with the denominator in the form of 10^(-n) where n is the number of
> > decimal places. I am not sure if this is the only way or if there is a
> > better method out there that I do not know of, so if you can think of a
> > general way to get precise inputs from users, it will be greatly
> > appreciated!
> >
> > Thank you!
> > Best,
> > Khue Tran
> >
>
>

[[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] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

Dear Leonard,

Thank you so much for the detailed response! Indeed, it would be nice to
have it included in the BH header. Thank you for sharing your codes with
me, I will definitely take a look at them to see if I can apply them to my
case. I was steering away from mpfr type for a while since they were
creating issues for linkage between C++ and R, but if I can get them to
work in R to avoid complications, I might try that!

Thank you again!

Best,
Khue Tran

On Sun, Jul 21, 2024 at 8:06 AM Leo Mada  wrote:

> Dear Khue,
>
> As mentioned before, you can use Rmpfr to read in strings or compute
> higher precision values, like
>
> x = mpfr(1, 192) /10;
> # 0.1 with 192 bits precision
> # or x = mpfr("0.1", 192);
>
> mpfr(1, 192) /10 - mpfr("0.1", 192)
> # 1 'mpfr' number of precision  192   bits
> # [1] 0
>
> However, I do not know how easy it is to convert from the mpfr format to
> the other format. Maybe the BH-team can add an mpfr constructor to the
> library.
>
> On a somewhat related topic, I did implement a very basic solver in native
> R (and based on Rmpfr). You can have a look on GitHub; it is not a package,
> but the script should be self-contained:
>
> https://github.com/discoleo/R/blob/master/Math/Polynomials.Helper.Matrix.mpfr.R
>
> It is very basic - more like a proof of concept. It does not include any
> advanced tricks and there is quit some drop of precision in some examples,
> see:
>
> https://github.com/discoleo/R/blob/master/Math/Polynomials.Helper.mpfr.Tests.R
>
> I was primarily interested in solving systems of polynomial equations
> (including complex roots); but did not have time to finish the remaining
> work. Extending the algorithm to solve for eigenvalues may be feasible
> (although I was less interested in eigenvalues). A native implementation in
> C++ would be faster; but I try to avoid any more complicated programming if
> it is not absolutely essential!
>
> Sincerely,
>
> Leonard
>
>

[[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] Is winbuilder "offline"?

[Rolf Turner]

On Sat, 20 Jul 2024 06:20:00 +0200
Uwe Ligges  wrote:

> 
> Strange. Your package has been processed. Have you tried again?
> Are you sure the maintainer address is specified correctly and that
> the auto generated message did not make it onto your spam box?
> 
> If it still does not work, please send me the tarball and I'll take a
> look.

Thanks Uwe.  The messages (I tried three times!) were indeed in my
spam box.  This mystifies me; i.e. I have no idea how the messages got
there.  I have many "filters" defined for my email client that move
messages satisfying various patterns into my spam box.  But I cannot see
how the autogenerated messages would match any of the specified
patterns.

Be that as it may, I have made a few adjustments (in accordance with
the NOTEs that I saw) and have resubmitted the package to winbuilder.
At least I now know to check my spam box!

Thanks again.

cheers,

Rolf

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Leo Mada via R-package-devel]

Dear Khue,

As mentioned before, you can use Rmpfr to read in strings or compute higher 
precision values, like

x = mpfr(1, 192) /10;
# 0.1 with 192 bits precision
# or x = mpfr("0.1", 192);

mpfr(1, 192) /10 - mpfr("0.1", 192)
# 1 'mpfr' number of precision  192   bits
# [1] 0

However, I do not know how easy it is to convert from the mpfr format to the 
other format. Maybe the BH-team can add an mpfr constructor to the library.

On a somewhat related topic, I did implement a very basic solver in native R 
(and based on Rmpfr). You can have a look on GitHub; it is not a package, but 
the script should be self-contained:
https://github.com/discoleo/R/blob/master/Math/Polynomials.Helper.Matrix.mpfr.R

It is very basic - more like a proof of concept. It does not include any 
advanced tricks and there is quit some drop of precision in some examples, see:
https://github.com/discoleo/R/blob/master/Math/Polynomials.Helper.mpfr.Tests.R

I was primarily interested in solving systems of polynomial equations 
(including complex roots); but did not have time to finish the remaining work. 
Extending the algorithm to solve for eigenvalues may be feasible (although I 
was less interested in eigenvalues). A native implementation in C++ would be 
faster; but I try to avoid any more complicated programming if it is not 
absolutely essential!

Sincerely,

Leonard


[[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] Is winbuilder "offline"?

[Uwe Ligges]

On 20.07.2024 01:52, Rolf Turner wrote:


On Fri, 19 Jul 2024 10:18:27 +0200
Uwe Ligges  wrote:


Not that I know, which queue do you mean?


Apologies for my ignorance but I don't understand the question.  I did
not choose a "queue".  I simply (as I have always done in the past)
pointed my browser at https://win-builder.r-project.org/ .

I then clicked on "upload page" which took me
to https://win-builder.r-project.org/upload.aspx .  I then clicked on
"Browse" under "R-release", chose the file to upload
(kanova_0.1-4.tar.gz) and clicked on "Upload File".   There were no
indications of any problems.  I waited for an email from winbuilder,
but this never came.


Strange. Your package has been processed. Have you tried again?
Are you sure the maintainer address is specified correctly and that the 
auto generated message did not make it onto your spam box?


If it still does not work, please send me the tarball and I'll take a look.

Best,
Uwe




What am I missing?

cheers,

Rolf

P.S. Is "R-release" the queue in question?

R.

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

Re: [R-pkg-devel] Is winbuilder "offline"?

[Rolf Turner]

On Fri, 19 Jul 2024 10:18:27 +0200
Uwe Ligges  wrote:

> Not that I know, which queue do you mean?

Apologies for my ignorance but I don't understand the question.  I did
not choose a "queue".  I simply (as I have always done in the past)
pointed my browser at https://win-builder.r-project.org/ .

I then clicked on "upload page" which took me
to https://win-builder.r-project.org/upload.aspx .  I then clicked on
"Browse" under "R-release", chose the file to upload
(kanova_0.1-4.tar.gz) and clicked on "Upload File".   There were no
indications of any problems.  I waited for an email from winbuilder,
but this never came.

What am I missing?

cheers,

Rolf

P.S. Is "R-release" the queue in question?

R.

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Duncan Murdoch]

Just for your info:

> exp(mpfr("0.1", 152))
1 'mpfr' number of precision  152   bits
[1] 1.1051709180756476248117078264902466682245471948

So it looks like your approach of parsing the numbers yourself makes sense.

You can find the R parser here: 
https://github.com/wch/r-source/blob/b64422334a8269535718efd9a1f969c94b103056/src/main/gram.y#L2577-L2705


I don't know how much of that you want to replicate, but I suppose 
handling the weird cases (e.g. 0x1p1) the way R does will make it easier 
for your users.


Duncan Murdoch

On 2024-07-18 4:29 p.m., Khue Tran wrote:

Hi,

I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits precision
works well with integers, but for decimals, since the input is a double,
the result differs a lot from the arbitrary precise result I got on
Wolfram.

I understand the results are different since 0.1 cannot be represented
precisely in binary with limited bits. It is possible to enter 1 then 10
and get the multiprecision division of these two integers to attain a more
precise 0.1 in C++, but this method won't work on a large scale. Thus, I am
looking for a general solution to get more precise inputs?

The dummy example is as follows:

library(Rcpp)

sourceCpp(code = '
#include 
#include 

// [[Rcpp::depends(BH)]]
// [[Rcpp::export]]
std::string calculateExp100(double x) {
   boost::multiprecision::cpp_dec_float_100 bx = x;
   boost::multiprecision::cpp_dec_float_100 expx = exp(bx);
   return expx.str(50);
}
')

[1] represents the R output and [W] for Wolfram results

calculateExp100(1) # Agrees with Wolfram answer all the way to the last
digit
[1] "2.7182818284590452353602874713526624977572470937"
[W] 2.7182818284590452353602874713526624977572470936999595749669676277...

calculateExp100(0.1) # Differs pretty significantly from Wolfram's answer
[1] "1.1051709180756476309466388234587796577416634163742"
[W] 1.1051709180756476248117078264902466682245471947375187187928632894...

I am currently trying to get precise inputs by taking strings instead of
numbers then writing a function to decompose the string into a rational
with the denominator in the form of 10^(-n) where n is the number of
decimal places. I am not sure if this is the only way or if there is a
better method out there that I do not know of, so if you can think of a
general way to get precise inputs from users, it will be greatly
appreciated!

Thank you!
Best,
Khue Tran



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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Duncan Murdoch]

On 2024-07-19 12:37 p.m., Martin Maechler wrote:

Khue Tran
 on Fri, 19 Jul 2024 09:32:14 +1000 writes:


 > Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
 > looked into Rmpfr and while the package can interface GNU MPFR with R
 > smoothly, as of right now, it doesn't have all the functions I need (ie.
 > eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
 > precision is still limited by R's default double precision.

Well, it depends *how* you input 0.1:
the double precision representation of 0.1 is *NOT* the same as
mathematically 1/10 and it cannot be.

What you really want is either

mpfr(0.1, 100) # 100 as an example ... to get a more precise
   # version of the '0.1' (double prec).

## *or*, e.g.,

1 / mpfr(10, 100) # which is a more accurate approximation to
   # the mathematical fraction 1/10


It seems like mpfr("0.1", 100) works pretty well.  I'd assume it does 
the parsing, rather than parse 0.1 to the closest double, and convert that.


Duncan Murdoch




## if you really want that, I'd also recommend truly exact fractions

require(gmp)
as.bigq(1, 10) # or equivalently

1 / as.bigz(10) # which automatically makes an exact fraction

 > Thank you for the note, Dirk. I will keep in mind to send any future
 > questions regarding Rcpp to the Rcpp-devel mailing list. I understand 
that
 > the type used in the Boost library for precision is not one of the types
 > supported by SEXP, so it will be more complicated to map between the cpp
 > codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
 > (and embarking on interfacing Eigen with Rmpfr is not a small task), does
 > taking input as strings seem like the best option for me to get precise
 > inputs?

almost surely (that's also what you can do in Rmpfr)..

Martin


 > Sincerely,
 > Khue

 > On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel  
wrote:

 >>
 >> Hi Khue,
 >>
 >> On 19 July 2024 at 06:29, Khue Tran wrote:
 >> | I am currently trying to get precise inputs by taking strings instead 
of
 >> | numbers then writing a function to decompose the string into a 
rational
 >> | with the denominator in the form of 10^(-n) where n is the number of
 >> | decimal places. I am not sure if this is the only way or if there is a
 >> | better method out there that I do not know of, so if you can think of 
a
 >> | general way to get precise inputs from users, it will be greatly
 >> | appreciated!
 >>
 >> That is one possible way. The constraint really is that the .Call()
 >> interface
 >> we use for all [1] extensions to R only knowns SEXP types which map to a
 >> small set of known types: double, int, string, bool, ...  The type used 
by
 >> the Boost library you are using is not among them, so you have to add 
code
 >> to
 >> map back and forth. Rcpp makes that easier; it is still far from 
automatic.
 >>
 >> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe 
that
 >> is
 >> good enough?  Also note that Rcpp has a dedicated (low volume and 
friendly)
 >> mailing list where questions such as this one may be better suited.
 >>
 >> Cheers, Dirk
 >>
 >> [1] A slight generalisation. There are others but they are less common /
 >> not
 >> recommended.
 >>
 >> --
 >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
 >>

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Martin Maechler]

> Khue Tran 
> on Fri, 19 Jul 2024 09:32:14 +1000 writes:

> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> looked into Rmpfr and while the package can interface GNU MPFR with R
> smoothly, as of right now, it doesn't have all the functions I need (ie.
> eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
> precision is still limited by R's default double precision.

Well, it depends *how* you input 0.1:
the double precision representation of 0.1 is *NOT* the same as
mathematically 1/10 and it cannot be.

What you really want is either

mpfr(0.1, 100) # 100 as an example ... to get a more precise
   # version of the '0.1' (double prec).

## *or*, e.g.,

1 / mpfr(10, 100) # which is a more accurate approximation to
  # the mathematical fraction 1/10

## if you really want that, I'd also recommend truly exact fractions

require(gmp)
as.bigq(1, 10) # or equivalently

1 / as.bigz(10) # which automatically makes an exact fraction

> Thank you for the note, Dirk. I will keep in mind to send any future
> questions regarding Rcpp to the Rcpp-devel mailing list. I understand that
> the type used in the Boost library for precision is not one of the types
> supported by SEXP, so it will be more complicated to map between the cpp
> codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
> (and embarking on interfacing Eigen with Rmpfr is not a small task), does
> taking input as strings seem like the best option for me to get precise
> inputs?

almost surely (that's also what you can do in Rmpfr)..

Martin


> Sincerely,
> Khue

> On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel  wrote:

>> 
>> Hi Khue,
>> 
>> On 19 July 2024 at 06:29, Khue Tran wrote:
>> | I am currently trying to get precise inputs by taking strings instead 
of
>> | numbers then writing a function to decompose the string into a rational
>> | with the denominator in the form of 10^(-n) where n is the number of
>> | decimal places. I am not sure if this is the only way or if there is a
>> | better method out there that I do not know of, so if you can think of a
>> | general way to get precise inputs from users, it will be greatly
>> | appreciated!
>> 
>> That is one possible way. The constraint really is that the .Call()
>> interface
>> we use for all [1] extensions to R only knowns SEXP types which map to a
>> small set of known types: double, int, string, bool, ...  The type used 
by
>> the Boost library you are using is not among them, so you have to add 
code
>> to
>> map back and forth. Rcpp makes that easier; it is still far from 
automatic.
>> 
>> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe 
that
>> is
>> good enough?  Also note that Rcpp has a dedicated (low volume and 
friendly)
>> mailing list where questions such as this one may be better suited.
>> 
>> Cheers, Dirk
>> 
>> [1] A slight generalisation. There are others but they are less common /
>> not
>> recommended.
>> 
>> --
>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>> 

> [[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] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package

[Marc Schwartz]

Hi Ivan,

Thanks kindly for your expedient reply and pointer to the LF/CRLF issue. Not 
sure that I would have found that issue so quickly, so was hoping for some 
intuition here, as you have provided.

Thanks!

Regards,

Marc


-Original Message-
From: Ivan Krylov mailto:ikry...@disroot.org>>
Date: Friday, July 19, 2024 at 11:18 AM
To: Marc Schwartz mailto:marc_schwa...@me.com>>
Cc: mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN 
Package


Dear Marc Schwartz,


В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz mailto:marc_schwa...@me.com>> пишет:


> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv


This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with perl
-d, I can confirm this:


main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:135):
135: my @FileNames = "";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:136):
136: open (DFHANDLE, $Encode, "$CSVPath/FileNames.txt") || die
"ERROR: cannot open $CSVPath/FileNames.txt. $!\n";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:137):
137: @FileNames = ;
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:138):
138: close DFHANDLE;
DB<3> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM\cJ"
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:141):
141: chomp(@FileNames);
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:302):
302: foreach my $FileName (@FileNames) {
DB<4> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM"


Since the R code always uses a text-mode connection with WriteLines,
it always results in CR-LF line endings on Windows. The difference must
be in the default PerlIO layers applied by Strawberry Perl by default.
MSYS is based on Cygwin, which does its best to pretend to be an
Unix-like environment, so it's reasonable for an MSYS build of Perl to
default to LF line endings. But that means special-casing the MSYS
build of Perl:


DB<5> x $Encode
0 '<:encoding(utf8)'
DB<6> x $^O
0 'msys'


...and adding $Encode .= ":crlf" if $^O eq 'msys'; somewhere.


-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package

[Ivan Krylov via R-package-devel]

Dear Marc Schwartz,

В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz  пишет:

> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv

This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with perl
-d, I can confirm this:

main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:135):
135:my @FileNames = "";
  DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:136):
136:open (DFHANDLE, $Encode, "$CSVPath/FileNames.txt") || die
"ERROR: cannot open $CSVPath/FileNames.txt. $!\n";
  DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:137):
137:@FileNames = ;
  DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:138):
138:close DFHANDLE;
  DB<3> x \@FileNames
0  ARRAY(0xa005e3c08)
   0  "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM\cJ"
  DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:141):
141:chomp(@FileNames);
  DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:302):
302:foreach my $FileName (@FileNames) {
  DB<4> x \@FileNames
0  ARRAY(0xa005e3c08)
   0  "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM"

Since the R code always uses a text-mode connection with WriteLines,
it always results in CR-LF line endings on Windows. The difference must
be in the default PerlIO layers applied by Strawberry Perl by default.
MSYS is based on Cygwin, which does its best to pretend to be an
Unix-like environment, so it's reasonable for an MSYS build of Perl to
default to LF line endings. But that means special-casing the MSYS
build of Perl:

  DB<5> x $Encode
0  '<:encoding(utf8)'
  DB<6> x $^O
0  'msys'

...and adding $Encode .= ":crlf" if $^O eq 'msys'; somewhere.

-- 
Best regards,
Ivan

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

[R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package

[Marc Schwartz]

Hi All,

I recently became aware of what appears to be some kind of incompatibility 
between the Perl distribution that is included in the RTools 4.4 distribution 
and my WriteXLS package on CRAN, running R 4.4.1. As far as I can tell, since 
the vast majority of the users of my package, which requires Perl, are running 
standard Perl installations, that is native OS, Strawberry Perl or Active State 
Perl, this appears to be something of a unique issue. 

It is not clear to me what the root cause of the problem is, and whether it is 
the RTools Perl binary itself and/or any of the other related components that 
are included in RTools, if this is specific to RTools, or may be an upstream 
issue from MSYS2. Thus, before I think about going down the rabbit hole, I am 
wondering if anyone has any intuitive guidance on this issue.

I was also a bit confused by this, as my aging memory recalled that the old 
Vanilla Perl had been removed from RTools many years ago circa R 2.x.y, so 
presume that there was motivation to reintroduce Perl in recent versions of 
RTools.

I have been able to largely replicate the problem on my MacBook Pro, running a 
Windows 11 VM under Parallels on macOS 14.5, and confirmed a workaround using a 
current Strawberry Perl installation for Windows on the same system. 

The initial report was from a user running Windows 10 on a native Intel based 
PC, with R 4.4.1 and RTools 4.4 installed, and they reported the following 
error:

> WriteXLS::WriteXLS(iris, "test.xlsx", verbose=T)
Creating Temporary Directory for CSV Files:  
C:\Users\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS 

Creating CSV File: 1.csv
Creating SheetNames.txt

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "en"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
. No such file or 
directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
Creating Excel File: C:\Users\Kleinbub\Documents\test.xlsx

Reading: C:\Users\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
The Perl script 'WriteXLSX.pl' failed to run successfully.
Cleaning Up Temporary Files and Directory


The basic workflow steps are that my R code wrapper function writes a CSV file 
containing the 'iris' dataframe into a temporary directory, my Perl script then 
reads in and parses that CSV file. and creates the Excel file using the 
relevant Perl packages included. The 'verbose = TRUE' setting outputs some 
additional diagnostic messages.

Note above that there are some warnings regarding locale settings from Perl, 
which I could not replicate on my Windows VM, albeit I can replicate the key 
error and failure of the Perl script as indicated.

If I run the same test code on my Windows 11 VM system, I get the following, 
including the initial testing function, which points to Perl in RTools:

> testPerl()
A system perl installation found in C:\rtools44\usr\bin\perl.exe

The perl modules included with WriteXLS are located in 
C:/Users/marcschwartz/AppData/Local/R/win-library/4.4/WriteXLS/Perl

All required Perl modules were found.

> WriteXLS(iris, "test.xlsx")
ERROR: cannot open 
C:\Users\MARCSC~1\AppData\Local\Temp\RtmpmKwGGX/WriteXLS/1.csv
. No such file or directory
The Perl script 'WriteXLSX.pl' failed to run successfully.


Note that I do not get the locale warnings, and this does not appear to be a 
permissions issue, but the Perl script still fails after indicating the 
inability to find the CSV file in the temporary directory.

With a Strawberry Perl installation in place, and explicitly pointing 
WriteXLS() to that Perl binary, I get a successful creation of the Excel file:

> WriteXLS(iris, "test.xlsx", perl = "C:\\Strawberry\\perl\\bin\\perl")
> 
> WriteXLS(iris, "test.xlsx", perl = "C:/Strawberry/perl/bin/perl")
>


Thus, I am confused as to the source of the incompatibility, and may be missing 
some nuances regarding the Perl binary and related components in RTools.

Any thoughts/pointers would be appreciated. 

Thank you,

Marc Schwartz

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

Re: [R-pkg-devel] Is winbuilder "offline"?

[Uwe Ligges]

Not that I know, which queue do you mean?

Best,
Uwe

On 19.07.2024 00:45, Rolf Turner wrote:


I submitted a package to winbuilder, yesterday.  Twice.  No response of
any sort.  Is the system down, for some reason?  Anyone know?  Ta.

cheers,

Rolf Turner

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Vladimir Dergachev]

On Fri, 19 Jul 2024, Khue Tran wrote:


I will need to run eigen() on a symmetric matrix, but I want to get arbitrary 
precise eigenvalues since we will need those eigenvalues for our further 
calculations. Does that make sense?


For a symmetric matrix there is a nice algorithm that is simple to 
implement and that converges fairly fast.


What you do is find the largest in absolute value off-diagonal entry.

The you construct 2x2 rotation matrix that zeros it: A --> R A R^-1, where 
R is a rotation matrix. The rotation matrix has mostly 1's on the main 
diagonal except for rows and columns of the large off-diagonal entry.


Repeat the procedure until the off-diagonal entries are as small as you 
want.


Because you are picking the largest value every time the algorithm is 
fairly stable.


The only disadvantage is that this algorithm plays havoc with sparse 
matrices by creating too many new non-zero entries, so for those you need 
to use a different method.


best

Vladimir Dergachev


Best,
Khue Tran

On Fri, Jul 19, 2024 at 12:14 PM Vladimir Dergachev  
wrote:

  Do you need to run eigen() on an arbitrary matrix or symmetric one ?

  best

  Vladimir Dergachev

  On Fri, 19 Jul 2024, Khue Tran wrote:

  > Thank you Simon! This is very helpful! Regarding eigen, I found in the
  > Boost library the following example for arbitrary precision matrix 
solver:
  > 
https://github.com/boostorg/multiprecision/blob/develop/example/eigen_example.cpp.
  > I am not sure if the precision is fully preserved throughout the 
process,
  > but this example motivated me to try coding with the Boost library.
  >
  > Best,
  > Khue Tran
  >
  > On Fri, Jul 19, 2024 at 9:50 AM Simon Urbanek 

  > wrote:
  >
  >> Khue,
  >>
  >>
  >>> On 19/07/2024, at 11:32 AM, Khue Tran  wrote:
  >>>
  >>> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
  >>> looked into Rmpfr and while the package can interface GNU MPFR with R
  >>> smoothly, as of right now, it doesn't have all the functions I need 
(ie.
  >>> eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), 
the
  >>> precision is still limited by R's default double precision.
  >>>
  >>
  >>
  >> Don't use doubles, use decimal fractions:
  >>
  >>> Rmpfr::mpfr(gmp::as.bigq(1,10), 512)
  >> 1 'mpfr' number of precision  512   bits
  >> [1]
  >> 
0.1002
  >>
  >> As for eigen() - I'm not aware of an arbitrary precision solver, so I
  >> think the inputs are your least problem - most tools out there use 
LAPACK
  >> which doesn't support arbitrary precision so your input precision is 
likely
  >> irrelevant in this case.
  >>
  >> Cheers,
  >> Simon
  >>
  >>
  >>
  >>> Thank you for the note, Dirk. I will keep in mind to send any future
  >>> questions regarding Rcpp to the Rcpp-devel mailing list. I understand
  >> that
  >>> the type used in the Boost library for precision is not one of the 
types
  >>> supported by SEXP, so it will be more complicated to map between the 
cpp
  >>> codes and R. Given Rmpfr doesn't provide all necessary mpfr 
calculations
  >>> (and embarking on interfacing Eigen with Rmpfr is not a small task), 
does
  >>> taking input as strings seem like the best option for me to get 
precise
  >>> inputs?
  >>>
  >>> Sincerely,
  >>> Khue
  >>>
  >>> On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel 
  >> wrote:
  >>>
  
   Hi Khue,
  
   On 19 July 2024 at 06:29, Khue Tran wrote:
   | I am currently trying to get precise inputs by taking strings 
instead
  >> of
   | numbers then writing a function to decompose the string into a
  >> rational
   | with the denominator in the form of 10^(-n) where n is the number 
of
   | decimal places. I am not sure if this is the only way or if there 
is a
   | better method out there that I do not know of, so if you can think 
of
  >> a
   | general way to get precise inputs from users, it will be greatly
   | appreciated!
  
   That is one possible way. The constraint really is that the .Call()
   interface
   we use for all [1] extensions to R only knowns SEXP types which map 
to a
   small set of known types: double, int, string, bool, ...  The type 
used
  >> by
   the Boost library you are using is not among them, so you have to add
  >> code
   to
   map back and forth. Rcpp makes that easier; it is still far from
  >> automatic.
  
   R has packages such as Rmpfr interfacing GNU MPFR based on 

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

I will need to run eigen() on a symmetric matrix, but I want to get
arbitrary precise eigenvalues since we will need those eigenvalues for our
further calculations. Does that make sense?

Best,
Khue Tran

On Fri, Jul 19, 2024 at 12:14 PM Vladimir Dergachev 
wrote:

>
> Do you need to run eigen() on an arbitrary matrix or symmetric one ?
>
> best
>
> Vladimir Dergachev
>
> On Fri, 19 Jul 2024, Khue Tran wrote:
>
> > Thank you Simon! This is very helpful! Regarding eigen, I found in the
> > Boost library the following example for arbitrary precision matrix
> solver:
> >
> https://github.com/boostorg/multiprecision/blob/develop/example/eigen_example.cpp
> .
> > I am not sure if the precision is fully preserved throughout the process,
> > but this example motivated me to try coding with the Boost library.
> >
> > Best,
> > Khue Tran
> >
> > On Fri, Jul 19, 2024 at 9:50 AM Simon Urbanek <
> simon.urba...@r-project.org>
> > wrote:
> >
> >> Khue,
> >>
> >>
> >>> On 19/07/2024, at 11:32 AM, Khue Tran  wrote:
> >>>
> >>> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> >>> looked into Rmpfr and while the package can interface GNU MPFR with R
> >>> smoothly, as of right now, it doesn't have all the functions I need
> (ie.
> >>> eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(),
> the
> >>> precision is still limited by R's default double precision.
> >>>
> >>
> >>
> >> Don't use doubles, use decimal fractions:
> >>
> >>> Rmpfr::mpfr(gmp::as.bigq(1,10), 512)
> >> 1 'mpfr' number of precision  512   bits
> >> [1]
> >>
> 0.1002
> >>
> >> As for eigen() - I'm not aware of an arbitrary precision solver, so I
> >> think the inputs are your least problem - most tools out there use
> LAPACK
> >> which doesn't support arbitrary precision so your input precision is
> likely
> >> irrelevant in this case.
> >>
> >> Cheers,
> >> Simon
> >>
> >>
> >>
> >>> Thank you for the note, Dirk. I will keep in mind to send any future
> >>> questions regarding Rcpp to the Rcpp-devel mailing list. I understand
> >> that
> >>> the type used in the Boost library for precision is not one of the
> types
> >>> supported by SEXP, so it will be more complicated to map between the
> cpp
> >>> codes and R. Given Rmpfr doesn't provide all necessary mpfr
> calculations
> >>> (and embarking on interfacing Eigen with Rmpfr is not a small task),
> does
> >>> taking input as strings seem like the best option for me to get precise
> >>> inputs?
> >>>
> >>> Sincerely,
> >>> Khue
> >>>
> >>> On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel 
> >> wrote:
> >>>
> 
>  Hi Khue,
> 
>  On 19 July 2024 at 06:29, Khue Tran wrote:
>  | I am currently trying to get precise inputs by taking strings
> instead
> >> of
>  | numbers then writing a function to decompose the string into a
> >> rational
>  | with the denominator in the form of 10^(-n) where n is the number of
>  | decimal places. I am not sure if this is the only way or if there
> is a
>  | better method out there that I do not know of, so if you can think
> of
> >> a
>  | general way to get precise inputs from users, it will be greatly
>  | appreciated!
> 
>  That is one possible way. The constraint really is that the .Call()
>  interface
>  we use for all [1] extensions to R only knowns SEXP types which map
> to a
>  small set of known types: double, int, string, bool, ...  The type
> used
> >> by
>  the Boost library you are using is not among them, so you have to add
> >> code
>  to
>  map back and forth. Rcpp makes that easier; it is still far from
> >> automatic.
> 
>  R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe
> >> that
>  is
>  good enough?  Also note that Rcpp has a dedicated (low volume and
> >> friendly)
>  mailing list where questions such as this one may be better suited.
> 
>  Cheers, Dirk
> 
>  [1] A slight generalisation. There are others but they are less
> common /
>  not
>  recommended.
> 
>  --
>  dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> >>>
> >>>   [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Vladimir Dergachev]

Do you need to run eigen() on an arbitrary matrix or symmetric one ?

best

Vladimir Dergachev

On Fri, 19 Jul 2024, Khue Tran wrote:


Thank you Simon! This is very helpful! Regarding eigen, I found in the
Boost library the following example for arbitrary precision matrix solver:
https://github.com/boostorg/multiprecision/blob/develop/example/eigen_example.cpp.
I am not sure if the precision is fully preserved throughout the process,
but this example motivated me to try coding with the Boost library.

Best,
Khue Tran

On Fri, Jul 19, 2024 at 9:50 AM Simon Urbanek 
wrote:


Khue,



On 19/07/2024, at 11:32 AM, Khue Tran  wrote:

Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
looked into Rmpfr and while the package can interface GNU MPFR with R
smoothly, as of right now, it doesn't have all the functions I need (ie.
eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
precision is still limited by R's default double precision.




Don't use doubles, use decimal fractions:


Rmpfr::mpfr(gmp::as.bigq(1,10), 512)

1 'mpfr' number of precision  512   bits
[1]
0.1002

As for eigen() - I'm not aware of an arbitrary precision solver, so I
think the inputs are your least problem - most tools out there use LAPACK
which doesn't support arbitrary precision so your input precision is likely
irrelevant in this case.

Cheers,
Simon




Thank you for the note, Dirk. I will keep in mind to send any future
questions regarding Rcpp to the Rcpp-devel mailing list. I understand

that

the type used in the Boost library for precision is not one of the types
supported by SEXP, so it will be more complicated to map between the cpp
codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
(and embarking on interfacing Eigen with Rmpfr is not a small task), does
taking input as strings seem like the best option for me to get precise
inputs?

Sincerely,
Khue

On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel 

wrote:




Hi Khue,

On 19 July 2024 at 06:29, Khue Tran wrote:
| I am currently trying to get precise inputs by taking strings instead

of

| numbers then writing a function to decompose the string into a

rational

| with the denominator in the form of 10^(-n) where n is the number of
| decimal places. I am not sure if this is the only way or if there is a
| better method out there that I do not know of, so if you can think of

a

| general way to get precise inputs from users, it will be greatly
| appreciated!

That is one possible way. The constraint really is that the .Call()
interface
we use for all [1] extensions to R only knowns SEXP types which map to a
small set of known types: double, int, string, bool, ...  The type used

by

the Boost library you are using is not among them, so you have to add

code

to
map back and forth. Rcpp makes that easier; it is still far from

automatic.


R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe

that

is
good enough?  Also note that Rcpp has a dedicated (low volume and

friendly)

mailing list where questions such as this one may be better suited.

Cheers, Dirk

[1] A slight generalisation. There are others but they are less common /
not
recommended.

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



  [[alternative HTML version deleted]]

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






[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

Thank you Simon! This is very helpful! Regarding eigen, I found in the
Boost library the following example for arbitrary precision matrix solver:
https://github.com/boostorg/multiprecision/blob/develop/example/eigen_example.cpp.
I am not sure if the precision is fully preserved throughout the process,
but this example motivated me to try coding with the Boost library.

Best,
Khue Tran

On Fri, Jul 19, 2024 at 9:50 AM Simon Urbanek 
wrote:

> Khue,
>
>
> > On 19/07/2024, at 11:32 AM, Khue Tran  wrote:
> >
> > Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> > looked into Rmpfr and while the package can interface GNU MPFR with R
> > smoothly, as of right now, it doesn't have all the functions I need (ie.
> > eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
> > precision is still limited by R's default double precision.
> >
>
>
> Don't use doubles, use decimal fractions:
>
> > Rmpfr::mpfr(gmp::as.bigq(1,10), 512)
> 1 'mpfr' number of precision  512   bits
> [1]
> 0.1002
>
> As for eigen() - I'm not aware of an arbitrary precision solver, so I
> think the inputs are your least problem - most tools out there use LAPACK
> which doesn't support arbitrary precision so your input precision is likely
> irrelevant in this case.
>
> Cheers,
> Simon
>
>
>
> > Thank you for the note, Dirk. I will keep in mind to send any future
> > questions regarding Rcpp to the Rcpp-devel mailing list. I understand
> that
> > the type used in the Boost library for precision is not one of the types
> > supported by SEXP, so it will be more complicated to map between the cpp
> > codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
> > (and embarking on interfacing Eigen with Rmpfr is not a small task), does
> > taking input as strings seem like the best option for me to get precise
> > inputs?
> >
> > Sincerely,
> > Khue
> >
> > On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel 
> wrote:
> >
> >>
> >> Hi Khue,
> >>
> >> On 19 July 2024 at 06:29, Khue Tran wrote:
> >> | I am currently trying to get precise inputs by taking strings instead
> of
> >> | numbers then writing a function to decompose the string into a
> rational
> >> | with the denominator in the form of 10^(-n) where n is the number of
> >> | decimal places. I am not sure if this is the only way or if there is a
> >> | better method out there that I do not know of, so if you can think of
> a
> >> | general way to get precise inputs from users, it will be greatly
> >> | appreciated!
> >>
> >> That is one possible way. The constraint really is that the .Call()
> >> interface
> >> we use for all [1] extensions to R only knowns SEXP types which map to a
> >> small set of known types: double, int, string, bool, ...  The type used
> by
> >> the Boost library you are using is not among them, so you have to add
> code
> >> to
> >> map back and forth. Rcpp makes that easier; it is still far from
> automatic.
> >>
> >> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe
> that
> >> is
> >> good enough?  Also note that Rcpp has a dedicated (low volume and
> friendly)
> >> mailing list where questions such as this one may be better suited.
> >>
> >> Cheers, Dirk
> >>
> >> [1] A slight generalisation. There are others but they are less common /
> >> not
> >> recommended.
> >>
> >> --
> >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >>
> >
> >   [[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] How to get arbitrary precise inputs from R for an Rcpp package?

[J C Nash]

On the other hand, Rmpfr did allow me to write an mpfr rootfinder for Martin M. 
in 2011
(he modified and streamlined it for use) since one can run R codes on mpfr 
objects
as long as one is careful which operators are applied. So one probably could do
something with a very pedestrian eigenvalue method. One or other of the codes
from my Compact Numerical Methods for Computers might be applicable, but the 1st
edition Step-And-Description codes are likely to be more useful than the Pascal
of the Second Edition. The one-sided Jacobi approach for eigen or svd has a 
pretty
tiny code. No claims for great efficiency, but in times when loading from 
floppies
was the order of the day, the short code often got the lowest start to finish 
elapsed
time.

Best, JN


On 2024-07-18 19:50, Simon Urbanek wrote:

Khue,



On 19/07/2024, at 11:32 AM, Khue Tran  wrote:

Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
looked into Rmpfr and while the package can interface GNU MPFR with R
smoothly, as of right now, it doesn't have all the functions I need (ie.
eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
precision is still limited by R's default double precision.




Don't use doubles, use decimal fractions:


Rmpfr::mpfr(gmp::as.bigq(1,10), 512)

1 'mpfr' number of precision  512   bits
[1] 
0.1002

As for eigen() - I'm not aware of an arbitrary precision solver, so I think the 
inputs are your least problem - most tools out there use LAPACK which doesn't 
support arbitrary precision so your input precision is likely irrelevant in 
this case.

Cheers,
Simon




Thank you for the note, Dirk. I will keep in mind to send any future
questions regarding Rcpp to the Rcpp-devel mailing list. I understand that
the type used in the Boost library for precision is not one of the types
supported by SEXP, so it will be more complicated to map between the cpp
codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
(and embarking on interfacing Eigen with Rmpfr is not a small task), does
taking input as strings seem like the best option for me to get precise
inputs?

Sincerely,
Khue

On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel  wrote:



Hi Khue,

On 19 July 2024 at 06:29, Khue Tran wrote:
| I am currently trying to get precise inputs by taking strings instead of
| numbers then writing a function to decompose the string into a rational
| with the denominator in the form of 10^(-n) where n is the number of
| decimal places. I am not sure if this is the only way or if there is a
| better method out there that I do not know of, so if you can think of a
| general way to get precise inputs from users, it will be greatly
| appreciated!

That is one possible way. The constraint really is that the .Call()
interface
we use for all [1] extensions to R only knowns SEXP types which map to a
small set of known types: double, int, string, bool, ...  The type used by
the Boost library you are using is not among them, so you have to add code
to
map back and forth. Rcpp makes that easier; it is still far from automatic.

R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe that
is
good enough?  Also note that Rcpp has a dedicated (low volume and friendly)
mailing list where questions such as this one may be better suited.

Cheers, Dirk

[1] A slight generalisation. There are others but they are less common /
not
recommended.

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Simon Urbanek]

Khue,


> On 19/07/2024, at 11:32 AM, Khue Tran  wrote:
> 
> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> looked into Rmpfr and while the package can interface GNU MPFR with R
> smoothly, as of right now, it doesn't have all the functions I need (ie.
> eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
> precision is still limited by R's default double precision.
> 


Don't use doubles, use decimal fractions:

> Rmpfr::mpfr(gmp::as.bigq(1,10), 512)
1 'mpfr' number of precision  512   bits 
[1] 
0.1002

As for eigen() - I'm not aware of an arbitrary precision solver, so I think the 
inputs are your least problem - most tools out there use LAPACK which doesn't 
support arbitrary precision so your input precision is likely irrelevant in 
this case.

Cheers,
Simon



> Thank you for the note, Dirk. I will keep in mind to send any future
> questions regarding Rcpp to the Rcpp-devel mailing list. I understand that
> the type used in the Boost library for precision is not one of the types
> supported by SEXP, so it will be more complicated to map between the cpp
> codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
> (and embarking on interfacing Eigen with Rmpfr is not a small task), does
> taking input as strings seem like the best option for me to get precise
> inputs?
> 
> Sincerely,
> Khue
> 
> On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel  wrote:
> 
>> 
>> Hi Khue,
>> 
>> On 19 July 2024 at 06:29, Khue Tran wrote:
>> | I am currently trying to get precise inputs by taking strings instead of
>> | numbers then writing a function to decompose the string into a rational
>> | with the denominator in the form of 10^(-n) where n is the number of
>> | decimal places. I am not sure if this is the only way or if there is a
>> | better method out there that I do not know of, so if you can think of a
>> | general way to get precise inputs from users, it will be greatly
>> | appreciated!
>> 
>> That is one possible way. The constraint really is that the .Call()
>> interface
>> we use for all [1] extensions to R only knowns SEXP types which map to a
>> small set of known types: double, int, string, bool, ...  The type used by
>> the Boost library you are using is not among them, so you have to add code
>> to
>> map back and forth. Rcpp makes that easier; it is still far from automatic.
>> 
>> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe that
>> is
>> good enough?  Also note that Rcpp has a dedicated (low volume and friendly)
>> mailing list where questions such as this one may be better suited.
>> 
>> Cheers, Dirk
>> 
>> [1] A slight generalisation. There are others but they are less common /
>> not
>> recommended.
>> 
>> --
>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
looked into Rmpfr and while the package can interface GNU MPFR with R
smoothly, as of right now, it doesn't have all the functions I need (ie.
eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
precision is still limited by R's default double precision.

Thank you for the note, Dirk. I will keep in mind to send any future
questions regarding Rcpp to the Rcpp-devel mailing list. I understand that
the type used in the Boost library for precision is not one of the types
supported by SEXP, so it will be more complicated to map between the cpp
codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
(and embarking on interfacing Eigen with Rmpfr is not a small task), does
taking input as strings seem like the best option for me to get precise
inputs?

Sincerely,
Khue

On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel  wrote:

>
> Hi Khue,
>
> On 19 July 2024 at 06:29, Khue Tran wrote:
> | I am currently trying to get precise inputs by taking strings instead of
> | numbers then writing a function to decompose the string into a rational
> | with the denominator in the form of 10^(-n) where n is the number of
> | decimal places. I am not sure if this is the only way or if there is a
> | better method out there that I do not know of, so if you can think of a
> | general way to get precise inputs from users, it will be greatly
> | appreciated!
>
> That is one possible way. The constraint really is that the .Call()
> interface
> we use for all [1] extensions to R only knowns SEXP types which map to a
> small set of known types: double, int, string, bool, ...  The type used by
> the Boost library you are using is not among them, so you have to add code
> to
> map back and forth. Rcpp makes that easier; it is still far from automatic.
>
> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe that
> is
> good enough?  Also note that Rcpp has a dedicated (low volume and friendly)
> mailing list where questions such as this one may be better suited.
>
> Cheers, Dirk
>
> [1] A slight generalisation. There are others but they are less common /
> not
> recommended.
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Is winbuilder "offline"?

[Rolf Turner]

I submitted a package to winbuilder, yesterday.  Twice.  No response of
any sort.  Is the system down, for some reason?  Anyone know?  Ta.

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Dirk Eddelbuettel]

Hi Khue,

On 19 July 2024 at 06:29, Khue Tran wrote:
| I am currently trying to get precise inputs by taking strings instead of
| numbers then writing a function to decompose the string into a rational
| with the denominator in the form of 10^(-n) where n is the number of
| decimal places. I am not sure if this is the only way or if there is a
| better method out there that I do not know of, so if you can think of a
| general way to get precise inputs from users, it will be greatly
| appreciated!

That is one possible way. The constraint really is that the .Call() interface
we use for all [1] extensions to R only knowns SEXP types which map to a
small set of known types: double, int, string, bool, ...  The type used by
the Boost library you are using is not among them, so you have to add code to
map back and forth. Rcpp makes that easier; it is still far from automatic.

R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe that is
good enough?  Also note that Rcpp has a dedicated (low volume and friendly)
mailing list where questions such as this one may be better suited.

Cheers, Dirk

[1] A slight generalisation. There are others but they are less common / not
recommended.

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Vladimir Dergachev]

I see there are existing extended precision packages: Ryacas and Rmpfr, 
you might want to take a look at them and their representation of numbers 
with higher precision than a double.


best

Vladimir Dergachev

On Fri, 19 Jul 2024, Khue Tran wrote:


Hi,

I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits precision
works well with integers, but for decimals, since the input is a double,
the result differs a lot from the arbitrary precise result I got on
Wolfram.

I understand the results are different since 0.1 cannot be represented
precisely in binary with limited bits. It is possible to enter 1 then 10
and get the multiprecision division of these two integers to attain a more
precise 0.1 in C++, but this method won't work on a large scale. Thus, I am
looking for a general solution to get more precise inputs?


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

Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Dénes Tóth]

Hi Khue,

Have you already checked the Rmpfr package?: 
https://cran.r-project.org/package=Rmpfr


Best,
Denes


On 7/18/24 22:29, Khue Tran wrote:

Hi,

I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits precision
works well with integers, but for decimals, since the input is a double,
the result differs a lot from the arbitrary precise result I got on
Wolfram.

I understand the results are different since 0.1 cannot be represented
precisely in binary with limited bits. It is possible to enter 1 then 10
and get the multiprecision division of these two integers to attain a more
precise 0.1 in C++, but this method won't work on a large scale. Thus, I am
looking for a general solution to get more precise inputs?

The dummy example is as follows:

library(Rcpp)

sourceCpp(code = '
#include 
#include 

// [[Rcpp::depends(BH)]]
// [[Rcpp::export]]
std::string calculateExp100(double x) {
   boost::multiprecision::cpp_dec_float_100 bx = x;
   boost::multiprecision::cpp_dec_float_100 expx = exp(bx);
   return expx.str(50);
}
')

[1] represents the R output and [W] for Wolfram results

calculateExp100(1) # Agrees with Wolfram answer all the way to the last
digit
[1] "2.7182818284590452353602874713526624977572470937"
[W] 2.7182818284590452353602874713526624977572470936999595749669676277...

calculateExp100(0.1) # Differs pretty significantly from Wolfram's answer
[1] "1.1051709180756476309466388234587796577416634163742"
[W] 1.1051709180756476248117078264902466682245471947375187187928632894...

I am currently trying to get precise inputs by taking strings instead of
numbers then writing a function to decompose the string into a rational
with the denominator in the form of 10^(-n) where n is the number of
decimal places. I am not sure if this is the only way or if there is a
better method out there that I do not know of, so if you can think of a
general way to get precise inputs from users, it will be greatly
appreciated!

Thank you!
Best,
Khue Tran



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

[R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?

[Khue Tran]

Hi,

I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits precision
works well with integers, but for decimals, since the input is a double,
the result differs a lot from the arbitrary precise result I got on
Wolfram.

I understand the results are different since 0.1 cannot be represented
precisely in binary with limited bits. It is possible to enter 1 then 10
and get the multiprecision division of these two integers to attain a more
precise 0.1 in C++, but this method won't work on a large scale. Thus, I am
looking for a general solution to get more precise inputs?

The dummy example is as follows:

library(Rcpp)

sourceCpp(code = '
#include 
#include 

// [[Rcpp::depends(BH)]]
// [[Rcpp::export]]
std::string calculateExp100(double x) {
  boost::multiprecision::cpp_dec_float_100 bx = x;
  boost::multiprecision::cpp_dec_float_100 expx = exp(bx);
  return expx.str(50);
}
')

[1] represents the R output and [W] for Wolfram results

calculateExp100(1) # Agrees with Wolfram answer all the way to the last
digit
[1] "2.7182818284590452353602874713526624977572470937"
[W] 2.7182818284590452353602874713526624977572470936999595749669676277...

calculateExp100(0.1) # Differs pretty significantly from Wolfram's answer
[1] "1.1051709180756476309466388234587796577416634163742"
[W] 1.1051709180756476248117078264902466682245471947375187187928632894...

I am currently trying to get precise inputs by taking strings instead of
numbers then writing a function to decompose the string into a rational
with the denominator in the form of 10^(-n) where n is the number of
decimal places. I am not sure if this is the only way or if there is a
better method out there that I do not know of, so if you can think of a
general way to get precise inputs from users, it will be greatly
appreciated!

Thank you!
Best,
Khue Tran

-- 
*Khue B. Tran (she/her/hers)*
tr...@kenyon.edu | +1 (220) - 203 - 9306 | LinkedIn

Mathematics and Music Double Major, Kenyon College '25

[[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] Fwd: CRAN Submission rkriging 1.0.1

[Ivan Krylov via R-package-devel]

Hi Chaofan and welcome to R-package-devel!

В Wed, 17 Jul 2024 11:52:53 -0700
Bill Huang <10billhuan...@gmail.com> пишет:

> The package can be installed successfully locally and passed CRAN
> auto-check. However, it cannot pass the gcc-UBSAN test with the
> following error message: a problem with the LLT function in Eigen. I
> am not sure how to fix this.

The problem is detected by special, normally disabled instrumentation
called UBSanitizer [1]. If you don't want to compile R with sanitizers
enabled yourself, ready-made Docker/Podman containers
rocker-org/r-devel-san and rocker-org/r-devel-san-clang [2] (and
others, there are sanitizer containers published by the R-hub
project as well) should help you reproduce the problem.

In this case, I suspect that you stumbled upon a problem in Eigen
itself: the Eigen::LLT constructor does not initialise an enumeration
field, ComputationInfo m_info, which results in the field being
populated by something out of range of the enumeration, which invokes
undefined behaviour.

You can reproduce the problem without building an R package at all:

#include 
#include 

struct foo : Eigen::LLT {
foo() : Eigen::LLT(42) {
// m_info is protected, hence use of inheritance
std::cout << m_info << std::endl;
}
};

int main() {
foo L;
}

g++ -fsanitize=undefined -g -Og -I $LIBRARY/RcppEigen/include/Eigen \
 -o ex ex.cpp
./ex
# ex.cpp:7:16: runtime error: load of value 32608, which is not a valid
# value for type 'ComputationInfo'
# 32608

A workaround for the problem is to move the initialization of the
Eigen::LLT Kriging::L_ field from the constructor body
into the member initializer list:

--- rkriging.orig/src/kriging.cpp   2024-07-04 06:45:57.0 +0300
+++ rkriging/src/kriging.cpp2024-07-18 14:10:54.0 +0300
@@ -20,10 +20,9 @@
 return kriging->get_nllh(log_lengthscale, nugget);
 }

-Kriging::Kriging(const Eigen::MatrixXd& X, const Eigen::VectorXd& y, Kernel& 
Ker, const bool& interpolation): n_(X.rows()), p_(X.cols()), X_(X), y_(y), 
Ker_(Ker), interpolation_(interpolation) {
+Kriging::Kriging(const Eigen::MatrixXd& X, const Eigen::VectorXd& y, Kernel& 
Ker, const bool& interpolation): n_(X.rows()), p_(X.cols()), X_(X), y_(y), 
Ker_(Ker), interpolation_(interpolation), L_(n_) {
 a_.resize(n_);
 b_.resize(n_);
-L_ = Eigen::LLT(n_);
 y_tss_ = y_.squaredNorm() - std::pow(y_.sum(),2)/n_;
 nugget_ = interpolation_ ? 1e-6 : 1e-3;
 nllh_ = std::numeric_limits::infinity();

This seems to avoid poking the bear of undefined behaviour with
potential copying of invalid enum value in L_ until something
initialises it properly.

I'm not sure whether this is worth reporting to Eigen as something to
fix. I hope that people here with more experience in C++ and Eigen will
be able to answer that question.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Using-Undefined-Behaviour-Sanitizer

[2]
https://rocker-project.org/images/base/r-devel.html

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

Re: [R-pkg-devel] Disable parallelism on installation time

[Matt Denwood]

On the subject of extendr ... the recently published JOSS paper (which also 
mentions CRAN compliance under the "Creating Rust-powered R packages section") 
provides a good entry point for those interested in using extendr for their 
R/Rust packages:  https://joss.theoj.org/papers/10.21105/joss.06394

Best,

Matt


On 17/07/2024, 22.30, "R-package-devel on behalf of Chung-hong Chan" 
mailto:r-package-devel-boun...@r-project.org> on behalf of 
chainsawti...@gmail.com > wrote:


[Du får ikke ofte mails fra chainsawti...@gmail.com 
. Få mere at vide om, hvorfor dette er vigtigt, 
på https://aka.ms/LearnAboutSenderIdentification 
 ]


To add to this, I would like to point out that extendr actually has a
guide on how to make an R package with Rust code CRAN compliance.


https://github.com/extendr/rextendr/blob/main/vignettes/articles/cran-compliance.Rmd
 





On Wed, Jul 17, 2024 at 10:21 AM Ivan Krylov via R-package-devel
mailto:r-package-devel@r-project.org>> wrote:
>
> В Tue, 16 Jul 2024 21:18:17 -0300
> Alberson Miranda  > пишет:
>
> > besides examples, tests, vignettes and readme, what parts of code
> > runs during installation of a R package
>
> Neither. This is about `cargo build` compiling in parallel, not your
> package code computing in parallel. Giving the -j 2 flag to cargo
> should solve the problem:
> https://github.com/R-ArcGIS/arcgisgeocode/blob/8fbd93c3607363a9fef2d445711de647e5127566/src/Makevars#L5
>  
> 
>
> --
> Best regards,
> Ivan
>
> __
> R-package-devel@r-project.org  mailing 
> list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel 
> 


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




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

[R-pkg-devel] Fwd: CRAN Submission rkriging 1.0.1

[Bill Huang]

Hi, Team.

I am working on a package that uses RcppEigen. The package can be installed
successfully locally and passed CRAN auto-check. However, it cannot pass
the gcc-UBSAN test with the following error message: a problem with the LLT
function in Eigen. I am not sure how to fix this. Any suggestion or help is
highly appreciated!

rkriging.Rcheck/rkriging-Ex.Rout:/data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66:49:
runtime error: load of value 20880, which is not a valid value for type
'ComputationInfo'
 #0 0x7f967645dfc6 in Eigen::LLT, 1>::operator=(Eigen::LLT, 1>&&)
/data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66
 #1 0x7f967645dfc6 in Kriging::Kriging(Eigen::Matrix const&, Eigen::Matrix const&,
Kernel&, bool const&)
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:26
 #2 0x7f96769cac53 in
UniversalKriging::UniversalKriging(Eigen::Matrix const&, Eigen::Matrix const&, Kernel&, bool
const&, unsigned long const&,
Rcpp::Function_Impl)
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:385
 #3 0x7f9676929f68 in Rcpp::Constructor_6, Eigen::Matrix, Kernel&, bool, unsigned long,
Rcpp::Function_Impl >::get_new(SEXPREC**, int)
/data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/Module_generated_Constructor.h:115
 #4 0x7f96767c091f in
Rcpp::class_::newInstance(SEXPREC**, int)
/data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/class.h:131
 #5 0x7f967c9d56a8 in class__newInstance(SEXPREC*)
/tmp/Rtmp7QBClZ/R.INSTALL19fb7f3cfc39c8/Rcpp/src/module.cpp:143

Thank you!
Best,
Chaofan

-- Forwarded message -
From: Uwe Ligges 
Date: Tue, Jul 16, 2024 at 2:19 AM
Subject: Re: CRAN Submission rkriging 1.0.1
To: Bill Huang <10billhuan...@gmail.com>


Please ask on the mailing list 

Best,
Uwe Ligges


On 16.07.2024 08:32, Bill Huang wrote:
> Hi, Uwe.
>
> Thanks for the message! I am not sure how to resolve this issue. Is
> there anyone you know that might be able to help me on this?
>
> Thank you!
> Best,
> Chaofan
>
> On Mon, Jul 15, 2024 at 11:44 AM Uwe Ligges
>  > wrote:
>
> Thanks, we still see with gcc-UBSAN
>
>
>
 
rkriging.Rcheck/rkriging-Ex.Rout:/data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66:49:
> runtime error: load of value 20880, which is not a valid value for
type
> 'ComputationInfo'
>   #0 0x7f967645dfc6 in Eigen::LLT -1, -1>, 1>::operator=(Eigen::LLT -1>, 1>&&)
>
 /data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66
>   #1 0x7f967645dfc6 in Kriging::Kriging(Eigen::Matrix -1, -1,
> 0, -1, -1> const&, Eigen::Matrix const&,
> Kernel&, bool const&)
>
 
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:26
>   #2 0x7f96769cac53 in
> UniversalKriging::UniversalKriging(Eigen::Matrix -1> const&, Eigen::Matrix const&, Kernel&,
> bool
> const&, unsigned long const&,
> Rcpp::Function_Impl)
>
 
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:385
>   #3 0x7f9676929f68 in Rcpp::Constructor_6 Eigen::Matrix, Eigen::Matrix 0, -1, 1>, Kernel&, bool, unsigned long,
> Rcpp::Function_Impl >::get_new(SEXPREC**, int)
>
 
/data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/Module_generated_Constructor.h:115
>   #4 0x7f96767c091f in
> Rcpp::class_::newInstance(SEXPREC**, int)
> /data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/class.h:131
>   #5 0x7f967c9d56a8 in class__newInstance(SEXPREC*)
> /tmp/Rtmp7QBClZ/R.INSTALL19fb7f3cfc39c8/Rcpp/src/module.cpp:143
>
>
> Please fix and resubmit.
>
> Best,
> Uwe Ligges
>
>
>
> On 13.07.2024 23:47, CRAN Package Submission Form wrote:
>  >
>  > [This was generated from CRAN.R-project.org/submit.html
> ]
>  >
>  > The following package was uploaded to CRAN:
>  > ===
>  >
>  > Package Information:
>  > Package: rkriging
>  > Version: 1.0.1
>  > Title: Kriging Modeling
>  > Author(s): Chaofan Huang [aut, cre], V. Roshan Joseph [aut]
>  > Maintainer: Chaofan Huang <10billhuan...@gmail.com
> >
>  > Depends: R (>= 3.0.2)
>  > Description: An 'Eigen'-based computationally efficient 'C++'
>  >implementation for fitting various kriging models to data.
>  >This research is supported by U.S. National Science
>  >Foundation grant DMS-2310637.
>  > License: GPL (>= 2)
>  > Imports: Rcpp, nloptr (>= 1.2.0), methods, stats
>  > LinkingTo: Rcpp, RcppEigen (>= 0.3.3.5.0), BH (>= 1.75.0.0),
> nloptr (>=
>  >1.2.0)
>  >
>  >
>  > The maintainer confirms that he or she
>  > has 

Re: [R-pkg-devel] Disable parallelism on installation time

[Chung-hong Chan]

To add to this, I would like to point out that extendr actually has a
guide on how to make an R package with Rust code CRAN compliance.

https://github.com/extendr/rextendr/blob/main/vignettes/articles/cran-compliance.Rmd


On Wed, Jul 17, 2024 at 10:21 AM Ivan Krylov via R-package-devel
 wrote:
>
> В Tue, 16 Jul 2024 21:18:17 -0300
> Alberson Miranda  пишет:
>
> > besides examples, tests, vignettes and readme, what parts of code
> > runs during installation of a R package
>
> Neither. This is about `cargo build` compiling in parallel, not your
> package code computing in parallel. Giving the -j 2 flag to cargo
> should solve the problem:
> https://github.com/R-ArcGIS/arcgisgeocode/blob/8fbd93c3607363a9fef2d445711de647e5127566/src/Makevars#L5
>
> --
> Best regards,
> Ivan
>
> __
> 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] Disable parallelism on installation time

[Ivan Krylov via R-package-devel]

В Tue, 16 Jul 2024 21:18:17 -0300
Alberson Miranda  пишет:

> besides examples, tests, vignettes and readme, what parts of code
> runs during installation of a R package

Neither. This is about `cargo build` compiling in parallel, not your
package code computing in parallel. Giving the -j 2 flag to cargo
should solve the problem:
https://github.com/R-ArcGIS/arcgisgeocode/blob/8fbd93c3607363a9fef2d445711de647e5127566/src/Makevars#L5

-- 
Best regards,
Ivan

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

[R-pkg-devel] Disable parallelism on installation time

[Alberson Miranda]

Dear listeners,

I'm having a hard time trying to figure out the following NOTE:

|* checking whether package 'fio' can be installed... [202s/46s] NOTE 
Installation took CPU time 4.4 times elapsed time |

Uwe asked if there's code running in parallel by default and, yes, there 
was: my code uses rayon (general parallelism) and faer (linear algebra, 
with rayon feature on) Rust crates. So I did a little refactor and added 
a method to allow the user to specify max threads. Then I started every 
example, tests, vignette and readme by limiting threads to 1 to avoid 
parallelism.

Nonetheless, I still get the NOTE. Finally, out of despair, I've deleted 
vignettes, tests, code on readme and enclosed all examples 
with|\dontrun{}|but that didn't work either.

So my question is, besides examples, tests, vignettes and readme,*what 
parts of code runs during installation of a R package? Is parallelism 
the only trigger for that NOTE or could it be something else?*

Source code is here  and there's 
also a SO post with my failed attempts 

 
in detail.

-- 
Best,
Alberson Miranda

[[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] Properly referencing copied code

[DRC via R-package-devel]

Thank you everyone, I think this gives me everything I need to know and I have 
no problem spreading the copyright around.

I'm not sure adding my dependencies to MXE is going to make sense here but open 
to being convinced otherwise. The package I am working on is wrapping functions 
from my own simple external C library. I wrote the C lib outside of the R 
package specifically so it would be possible to integrate the algorithm into 
multiple high level interfaces (i.e. python, matlab, in addition to R) 
otherwise the C would have been directly written into the R package. I don't 
see my lib as something anybody else is likely going to need to link against.

This C lib does depend on igraph though, which is more likely to be useful. 
However, I don't think it's actually going to be straight forward to add to MXE 
given how much effort I have had to put into getting it to compile with R and I 
honestly would rather not be the one who needs to figure out how to do it 
right. I hope that is understandable given it's pretty clear I am out of my 
skill set as a biologist and that I am in the last few months of my PhD program 
and have already exceeded the time I can afford on this side project.

There's a few problems that I think will make igraph difficult to package with 
MXE based on the challenges I have had with compiling on CRAN's build servers, 
assuming the environments are similar. 1. It was not possible for me to get 
igraph to compile correctly using cmake on CRAN builders due to other missing 
dependencies (including flex which I was previously told I have to pre-generate 
the resulting C files rather than depend on flex being available which prevents 
me from using cmake that calls flex itself). This means having to write new 
build logic instead of depending on the upstream cmake recipe, which is fragile 
and could break with an update. 2. There are some configuration options which 
are beneficial to choose based on the current project. Of particularly interest 
is that the igraph C lib has had to add a `USING_R` macro to modify the 
behavior in the lib based on whether it is used inside of `R` or not. Since MXE 
is not specific to R this requires a different build depending on where it's 
being used. 3. igraph is currently in the process of releasing 1.0.0 and the 
maintainers have noted there will be breaking changes. Given that it is not yet 
as mature as other commonly used dependencies, it is safer to use the pinned 
version shipped with my C lib than depending on a system wide installation.

Even if there is a range of versions I can check for, I would think there would 
still be a need to ship an appropriate version of igraph with the R package 
(and therefore still have all the logic needed to build it) in cases where the 
system's available igraph version is not appropriate, igraph is not compiled in 
a thread safe manner, or igraph is not compiled for R (which it definitely 
wouldn't be anywhere not using MXE, i.e. on a Linux computer where 
`install.packages` will compile the package locally). As such I don't think it 
makes much sense to try to add it to MXE, especially before determining if 
there is demand for the lib in CRAN packages.

 - DRC

On Monday, July 15th, 2024 at 4:11 AM, Ivan Krylov 'ikrylov at disroot.org' 
wrote:

> В Fri, 12 Jul 2024 20:17:22 +
> DRC via R-package-devel r-package-devel@r-project.org пишет:
>
> > > Has copyright holders of included software in a [ctb] role only
> >
> > I think I'm being asked to add the cph role to essentially every
> > author in addition to [ctb]
>
>
> That's how I'm reading it too.
>
> > but that doesn't seem to be what the CRAN policy wants
>
>
> I agree that there does seem to be a conflict, with the policy only
> asking to use 'cph' for non-'aut' or 'ctb' copyright holders.
>
> > and I still don't know how to decide who gets both.
>
>
> Technically, the conflict can be resolved by noting that the CRAN
> policy doesn't prohibit using 'cph' for 'aut' or 'ctb' co-authors.
> Since both your reviewer and help(person) ask for 'cph' for all
> copyright holders, it sounds like all co-authors who wrote any code
> should get an additional 'cph'.
>
> It would help if CRAN Policy also said that 'cph' should be used for
> all copyright holders.
>
> > Right now there are several people who have explicit copyright over
> > certain code so I would think just add cph to all those authors? Or
> > just give everyone cph who isn't a minor contributor?
>
>
> It shouldn't be too wrong to say that if someone wrote a nontrivial line
> of code you're including in your package, they are a copyright holder.
>
> This is an important cornerstone of "bazaar-style" development of free
> software: if many entities own copyright to parts of a computer
> program, no single entity has the right to re-license the whole under a
> non-free license. Contrast this with "cathedral-style" development
> where every contribution is either accompanied by a copyright 

Re: [R-pkg-devel] Properly referencing copied code

[Ivan Krylov via R-package-devel]

В Fri, 12 Jul 2024 20:17:22 +
DRC via R-package-devel  пишет:

> > Has copyright holders of included software in a [ctb] role only  
> 
> I think I'm being asked to add the cph role to essentially every
> author in addition to [ctb]

That's how I'm reading it too.

> but that doesn't seem to be what the CRAN policy wants

I agree that there does seem to be a conflict, with the policy only
asking to use 'cph' for non-'aut' or 'ctb' copyright holders.

> and I still don't know how to decide who gets both.

Technically, the conflict can be resolved by noting that the CRAN
policy doesn't _prohibit_ using 'cph' for 'aut' or 'ctb' co-authors.
Since both your reviewer and help(person) ask for 'cph' for all
copyright holders, it sounds like all co-authors who wrote any code
should get an additional 'cph'.

It would help if CRAN Policy also said that 'cph' should be used for
all copyright holders.

> Right now there are several people who have explicit copyright over
> certain code so I would think just add cph to all those authors? Or
> just give everyone cph who isn't a minor contributor?

It shouldn't be too wrong to say that if someone wrote a nontrivial line
of code you're including in your package, they are a copyright holder.

This is an important cornerstone of "bazaar-style" development of free
software: if many entities own copyright to parts of a computer
program, no single entity has the right to re-license the whole under a
non-free license. Contrast this with "cathedral-style" development
where every contribution is either accompanied by a copyright transfer
document or rewritten from scratch (e.g. SQLite): this lets the single
owner re-license the code under whatever terms they prefer.

Having said that, if you would like to follow the recommendations of
Simon and Tomas and package some of the third-party code for MXE and
macOS recipes, don't hesitate to ask.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Properly referencing copied code

[Tomas Kalibera]

On 7/13/24 12:24, Simon Urbanek wrote:



On 12 Jul 2024, at 10:07, Ivan Krylov via R-package-devel 
 wrote:

В Thu, 11 Jul 2024 20:58:53 +
DRC via R-package-devel  пишет:


1. How does linking to external libs differ from providing the source
of a library and linking against that?

I think that the author information in the DESCRIPTION is about what your package 
provides by itself, not everything that may end up in the address space once the 
package is loaded. Since CRAN prefers self-contained packages, we end up including them 
in our packages (unless the third-party library is already very common and present in 
RTools & macOS recipes & common GNU/Linux distros), which requires us to 
specify their authors.



To clarify: as far as CRAN is concerned you only need to include sources that 
are otherwise not commonly available - or if you need to modify them for the 
purpose of the package, so it should be quite rare. In fact the CRAN policy 
states that a package should always look for an available library first. If we 
just are talking about libraries then a very rough rule of thumb is that if 
your dependent library is in Debian then you don't need to ship it as sources.

That said, if you are using something that is not in the current Rtools/recipes 
then you have to tell CRAN so we can be add it to macOS and Windows toolchains 
(assuming both are supported by the library you need) - but that doesn't mean 
you should ship them yourself (in fact that tends to cause a lot more problems).


And you can indeed help with adding such library to Rtools/recipes. In 
case of Rtools, ideally first add it upstream to MXE.


Best
Tomas



Cheers,
Simon

__
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] Properly referencing copied code

[Simon Urbanek]

> On 12 Jul 2024, at 10:07, Ivan Krylov via R-package-devel 
>  wrote:
> 
> В Thu, 11 Jul 2024 20:58:53 +
> DRC via R-package-devel  пишет:
> 
>> 1. How does linking to external libs differ from providing the source
>> of a library and linking against that?
> 
> I think that the author information in the DESCRIPTION is about what your 
> package provides by itself, not everything that may end up in the address 
> space once the package is loaded. Since CRAN prefers self-contained packages, 
> we end up including them in our packages (unless the third-party library is 
> already very common and present in RTools & macOS recipes & common GNU/Linux 
> distros), which requires us to specify their authors.
> 


To clarify: as far as CRAN is concerned you only need to include sources that 
are otherwise not commonly available - or if you need to modify them for the 
purpose of the package, so it should be quite rare. In fact the CRAN policy 
states that a package should always look for an available library first. If we 
just are talking about libraries then a very rough rule of thumb is that if 
your dependent library is in Debian then you don't need to ship it as sources.

That said, if you are using something that is not in the current Rtools/recipes 
then you have to tell CRAN so we can be add it to macOS and Windows toolchains 
(assuming both are supported by the library you need) - but that doesn't mean 
you should ship them yourself (in fact that tends to cause a lot more problems).

Cheers,
Simon

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

Re: [R-pkg-devel] Properly referencing copied code

[DRC via R-package-devel]

Thanks that helps. Are there any thoughts on the feedback I was given? I'm 
still a bit confused on the note:

> Has copyright holders of included software in a [ctb] role only

I think I'm being asked to add the cph role to essentially every author in 
addition to ctp but that doesn't seem to be what the CRAN policy wants and I 
still don't know how to decide who gets both. Right now there are several 
people who have explicit copyright over certain code so I would think just add 
cph to all those authors? Or just give everyone cph who isn't a minor 
contributor?

 - DRC

On Friday, July 12th, 2024 at 3:07 AM, Ivan Krylov 'ikrylov at disroot.org' 
 wrote:

> 
> В Thu, 11 Jul 2024 20:58:53 +
> DRC via R-package-devel r-package-devel@r-project.org пишет:
> 
> > 1. How does linking to external libs differ from providing the source
> > of a library and linking against that?
> 
> 
> I think that the author information in the DESCRIPTION is about what
> your package provides by itself, not everything that may end up in the
> address space once the package is loaded. Since CRAN prefers
> self-contained packages, we end up including them in our packages
> (unless the third-party library is already very common and present in
> RTools & macOS recipes & common GNU/Linux distros), which requires us
> to specify their authors.
> 
> > Do I need to provide references to lapack and blas if they aren't
> > shipped with the package? What about math (lm)?
> 
> 
> No.
> 
> > 2. What roles to supply to authors of external software?
> 
> > Do I need to differentiate between authors with explicit copyrights
> > `c('ctb', 'cph')` vs those who are authors but are not listed as
> > copyright holders `c('ctb')` in the third party source? Or just give
> > everyone both?
> 
> 
> I would expect most authors and contributors to be copyright holders
> too, but it must be possible to contribute without providing patches
> and becoming one. E.g. a project might recognise a tester and bug
> reporter as a full author, but there is no code that they own any
> copyright on.
> 
> > 3. One of my dependencies has a lot of copyright holders throughout
> > the source. Most of these are for individual functions and cmake
> > files that are not directly used by my package. What is the best way
> > to handle this? Add as much of the unused parts of the third party
> > package to the .Rbuildignore file as possible to filter out the
> > unused parts?
> 
> 
> If it's feasible to implement, omitting unused files from the tarball
> is a good idea.
> 
> > 4. Is there a better place to put all these authors? The author list
> > has already gotten large and I still have many more to add.
> 
> 
> CRAN recognises inst/AUTHORS. Here's a recently released package with
> no obvious problems that makes use of it:
> https://CRAN.R-project.org/package=xlcharts
> 
> We should probably document it somewhere.
> 
> --
> Best regards,
> Ivan

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

[R-pkg-devel] relative vignette paths across CRAN check flavors

[Slager, Dave]

Hi,

Do the r-oldrel-macos-* CRAN check servers use a different setting that affects 
how vignette paths work? These two flavors seem less robust to relative 
vignette paths than other flavors, and I haven't been able to figure out why by 
looking at the descriptions of the flavors or the R CMD check output. For 
example, see:

https://cran.r-project.org/web/checks/check_results_PieGlyph.html
https://cran.r-project.org/web/checks/check_results_APCalign.html
https://cran.r-project.org/web/checks/check_results_agua.html
https://cran.r-project.org/web/checks/check_results_cleanepi.html
https://cran.r-project.org/web/checks/check_results_hardhat.html
https://cran.r-project.org/web/checks/check_results_IncidencePrevalence.html
https://cran.r-project.org/web/checks/check_results_metajam.html
https://cran.r-project.org/web/checks/check_results_ulrb.html

Thanks,
Dave

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

Re: [R-pkg-devel] Properly referencing copied code

[Ivan Krylov via R-package-devel]

В Thu, 11 Jul 2024 20:58:53 +
DRC via R-package-devel  пишет:

> 1. How does linking to external libs differ from providing the source
> of a library and linking against that?

I think that the author information in the DESCRIPTION is about what
your package provides by itself, not everything that may end up in the
address space once the package is loaded. Since CRAN prefers
self-contained packages, we end up including them in our packages
(unless the third-party library is already very common and present in
RTools & macOS recipes & common GNU/Linux distros), which requires us
to specify their authors.

> Do I need to provide references to lapack and blas if they aren't
> shipped with the package? What about math (lm)?

No.

> 2. What roles to supply to authors of external software?

> Do I need to differentiate between authors with explicit copyrights
> `c('ctb', 'cph')` vs those who are authors but are not listed as
> copyright holders `c('ctb')` in the third party source? Or just give
> everyone both?

I would expect most authors and contributors to be copyright holders
too, but it must be possible to contribute without providing patches
and becoming one. E.g. a project might recognise a tester and bug
reporter as a full author, but there is no code that they own any
copyright on.

> 3. One of my dependencies has a lot of copyright holders throughout
> the source. Most of these are for individual functions and cmake
> files that are not directly used by my package. What is the best way
> to handle this? Add as much of the unused parts of the third party
> package to the .Rbuildignore file as possible to filter out the
> unused parts?

If it's feasible to implement, omitting unused files from the tarball
is a good idea.

> 4. Is there a better place to put all these authors? The author list
> has already gotten large and I still have many more to add.

CRAN recognises inst/AUTHORS. Here's a recently released package with
no obvious problems that makes use of it:
https://CRAN.R-project.org/package=xlcharts

We should probably document it somewhere.

-- 
Best regards,
Ivan

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

[R-pkg-devel] Properly referencing copied code

[DRC via R-package-devel]

I'm trying to submit a package to CRAN that uses external C libs but properly 
crediting copyright holders and authors is the main issue holding up the 
submission and I've repeatedly failed to satisfy the requirements. I am having 
a lot of trouble understanding what/who I need to be listing in my DESCRIPTION 
file and how they should be listed.

1. How does linking to external libs differ from providing the source of a 
library and linking against that? Do I need to provide references to lapack and 
blas if they aren't shipped with the package? What about math (lm)?

2. What roles to supply to authors of external software? After my last 
submission, I got the note:
> Has copyright holders of included software in a [ctb] role only

>From the CRAN Repository Policy file:
>Where code is copied (or derived) from the work of others (including from R 
>itself), care must be taken that any copyright/license statements are 
>preserved and authorship is not misrepresented.
>Preferably, an ‘Authors@R’ field would be used with ‘ctb’ roles for the 
>authors of such code. Alternatively, the ‘Author’ field should list these 
>authors as contributors.
>
>Where copyrights are held by an entity other than the package authors, this 
>should preferably be indicated via ‘cph’ roles in the ‘Authors@R’ field, or 
>using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS file).

My interpretation of the CRAN policy is that the role 'cph' should be used only 
for "entities other than the package authors" and therefore authors should only 
get 'ctb'. Do I need to differentiate between authors with explicit copyrights 
`c('ctb', 'cph')` vs those who are authors but are not listed as copyright 
holders `c('ctb')` in the third party source? Or just give everyone both?

3. One of my dependencies has a lot of copyright holders throughout the source. 
Most of these are for individual functions and cmake files that are not 
directly used by my package. What is the best way to handle this? Add as much 
of the unused parts of the third party package to the .Rbuildignore file as 
possible to filter out the unused parts? (Many copyrights are from parts of the 
package that are independent on the parts I used so for example ignore an 
unused vendor package seems reasonable but what about hand picking the main 
source files that are actually compiled to avoid copyrights?) Or list all of 
the authors/copyrights in the my DESCRIPTION file?

4. Is there a better place to put all these authors? The author list has 
already gotten large and I still have many more to add. I've seen use of an 
`AUTHOR-list.md` in packages but I don't see this mentioned in official 
documentation. In the previous quotation from CRAN's policy document, it 
mentions the possible use of a `inst/COPYRIGHTS` file that is referenced in the 
DESCRIPTION. Is there an equivalent for authors? Is it preferred to just put 
everything in DESCRIPTION instead?

- DRC
[[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] Options "reset" when options(opts)

[Vladimir Dergachev]

On Thu, 11 Jul 2024, David Hugh-Jones wrote:


This surprised me, even though it shouldn’t have done. (My false internal
model of the world was that oo <- options(); … options(oo) would overwrite
the entire options list with the old values.) I wonder if it would be worth
pointing out explicitly in ?options.


Arguably, it would be nice to have a parameter like "reset", so 
that one can call


options(oo, reset=TRUE)

and any options not explicitly passed by oo are set to NULL.

This way there are two modes of operation - bulk setting of subset of 
options with reset=FALSE, and restoring full options set with reset=TRUE.


best

Vladimir Dergachev



Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Thu, 11 Jul 2024 at 08:03, Greg Jefferis  wrote:


Dear John,

You need to collect the return value when setting options. This will
include an explicit NULL value for an option that was previously NULL.

Best,

Greg Jefferis.

options(digits.secs = NULL)

noset2 = function() {
  opts <- options(digits.secs = 3)
  on.exit(options(opts))
  print(opts)
}


getOption("digits.secs")

NULL


noset2()

$digits.secs
NULL


getOption("digits.secs")

NULL

Gregory Jefferis
Division of Neurobiology
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://jefferislab.org
https://www.zoo.cam.ac.uk/research/groups/connectomics



On 11 Jul 2024, at 06:08, John Muschelli  wrote:

When setting options in a function, I have always used the following:
 opts <- options()
 on.exit(options(opts), add = TRUE)
and assumed it "reset" options to what they were prior to running the
function.  But for some options that are set to NULL, it does not seem to
reset them.  Specifically, I have found digits.secs to be set after this
simple example below.  Is this expected behavior/documented?  Overall,

this

specific example (the one I encountered in the wild) is not that harmful,
but I wanted to ask before I set a fix for this in our work

noset = function() {
 opts = options()
 print(opts$digits.secs)
 on.exit(options(opts))
 options(digits.secs = 3)
}
getOption("digits.secs")
#> NULL
noset()
#> NULL
getOption("digits.secs")
#> [1] 3


John Muschelli, PhD
Associate Research Professor
Department of Biostatistics
Johns Hopkins Bloomberg School of Public Health

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


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

Re: [R-pkg-devel] Help for understanding CRAN rejection

[Matei Teleman]

Dear Ivan,

Thank you so much for your help.

I followed your advices and I reduced the size of the example data, move one 
package from Import to Suggest.

The type of the license is unfortunately not depending on me so I’ll try one 
last time with the CC license and the new improvements.

Thank your again for your time.

Have a nice day!

Best regards,

Matei


> Le 9 juil. 2024 à 12:45, Ivan Krylov  a écrit :
> 
> (I am adding the mailing list back in Cc: because package licensing is
> a complicated topic.)
> 
> В Tue, 9 Jul 2024 09:25:14 +
> Matei Teleman  пишет:
> 
>> I’ve added “ … SuperCell uses
>> [velocyto.R](https://github.com/velocyto-team/velocyto.R) for RNA
>> velocity. ” in the Description field. Is that enough or I need also
>> to directly give the command line to install the package from GitHub ?
> 
> It looks like a link should be fine. Here are a few examples of CRAN
> packages that have a non-CRAN/Bioconductor package in Suggests: without
> setting up Additional_repositories:
> 
> https://CRAN.R-project.org/package=babelmixr2
> https://CRAN.R-project.org/package=bandsfdp
> https://cran.r-project.org/package=GCD
> 
> I'm sorry that I didn't note any of the following in my initial reply,
> but what worries me about CC BY-NC-ND specifically is that out of 117
> CRAN packages with a Creative Commons license and 18 of those that use
> the non-FOSS "NonCommercial" clause, none use the "NoDerivatives"
> clause. Your users would probably appreciate being able to install
> binary builds of your package from CRAN. Does `R CMD INSTALL --build`
> count as creating a derivative work, or is it "merely changing the
> format"? Then again, CC BY-NC-ND _is_ mentioned in the list of CRAN
> licenses, so it could work.
> 
> I found a rejected copy of your package in the archive subdirectory on
> the CRAN FTP server and a GitHub repository [*] that seems to be
> slightly outdated compared to the archived package. (It's best to link
> to up-to-date package sources when seeking help with code.) I'm getting
> an additional NOTE:
> 
>>> Imports includes 21 non-default packages.
>>> Importing from so many packages makes the package vulnerable to any
>>> of them becoming unavailable.  Move as many as possible to Suggests
>>> and use conditionally.
> 
> Is there a way to make some of the currently required dependencies into
> conditional dependencies? R CMD check --as-cran sets the limit to 20,
> so moving just one package from Imports to Suggests will silence this
> particular NOTE.
> 
> I see that most of your package size comes from the data subdirectory.
> CRAN policy says: "Packages should be of the minimum necessary size.
> <...> Neither data nor documentation should exceed 5MB. <...> Where a
> large amount of data is required (even after compression),
> consideration should be given to a separate data-only package which can
> be updated only rarely (since older versions of packages are archived
> in perpetuity)."
> Is there a way to reduce the size of the data? It's ideal if there's
> only enough data to demonstrate how an algorithm works in the
> \examples{} section of your documentation and to exercise as much of
> your code as feasible in your tests.
> 
> Finally, were there any recommendations in the rejection e-mail from
> CRAN? Sometimes NOTEs are unavoidable, but we should strive to minimise
> them anyway.
> 
> -- 
> Best regards,
> Ivan
> 
> [*] https://github.com/GfellerLab/SuperCell

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

Re: [R-pkg-devel] cpp11 and "non-API calls to R"

[Chung-hong Chan]

Not from CRAN, also not in a position to opine on cpp11 status, but I
wrote about it recently. My solution for readODS back then was to
vendor cpp11 and remove the SET_LENGTH call manually, like . But back
then CRAN might not know about this. I think it should be easier now.

https://www.chainsawriot.com/postmannheim/2024/05/26/readods230.html

On Mon, Jul 8, 2024 at 4:25 PM Mark Padgham  wrote:
>
> Dear R-pkg-dev folk,
>
> The cpp11 package, which was developed yet is no longer maintained by
> Jim Hester, now triggers warnings on some CRAN pre-submit checks for
> "non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
> relevant issue is https://github.com/r-lib/cpp11/issues/355, with a pull
> request to resolve at https://github.com/r-lib/cpp11/pull/358. Problem
> is the package is now largely inactive, with the PR hanging there for a
> month or so unattended. I presume this warning means I can not resubmit
> any package depending on cpp11 until this is resolved. But then there
> are currently 75 packages potentially affected by this which would then
> also be unable to be resubmitted. (Follow the links from the main GitHub
> issue for a glimpse of the scale of this problem.)
>
> Any suggestions? In particular, it would be helpful, in this arguably
> unusual and quite prominent case, to hear any views from CRAN folk as to
> whether everybody dependent on cpp11 will have to wait for resolution
> before they'll be able to resubmit? Alternatively, any indication from
> anybody in a position to opine on cpp11 status and future maintenance
> plans would be great!
>
> Thanks,
>
> Mark
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Options "reset" when options(opts)

[David Hugh-Jones]

This surprised me, even though it shouldn’t have done. (My false internal
model of the world was that oo <- options(); … options(oo) would overwrite
the entire options list with the old values.) I wonder if it would be worth
pointing out explicitly in ?options.

Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Thu, 11 Jul 2024 at 08:03, Greg Jefferis  wrote:

> Dear John,
>
> You need to collect the return value when setting options. This will
> include an explicit NULL value for an option that was previously NULL.
>
> Best,
>
> Greg Jefferis.
>
> options(digits.secs = NULL)
>
> noset2 = function() {
>   opts <- options(digits.secs = 3)
>   on.exit(options(opts))
>   print(opts)
> }
>
> > getOption("digits.secs")
> NULL
>
> > noset2()
> $digits.secs
> NULL
>
> > getOption("digits.secs")
> NULL
>
> Gregory Jefferis
> Division of Neurobiology
> MRC Laboratory of Molecular Biology
> Francis Crick Avenue
> Cambridge Biomedical Campus
> Cambridge, CB2 OQH, UK
>
> http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
> http://jefferislab.org
> https://www.zoo.cam.ac.uk/research/groups/connectomics
>
>
> > On 11 Jul 2024, at 06:08, John Muschelli  wrote:
> >
> > When setting options in a function, I have always used the following:
> >  opts <- options()
> >  on.exit(options(opts), add = TRUE)
> > and assumed it "reset" options to what they were prior to running the
> > function.  But for some options that are set to NULL, it does not seem to
> > reset them.  Specifically, I have found digits.secs to be set after this
> > simple example below.  Is this expected behavior/documented?  Overall,
> this
> > specific example (the one I encountered in the wild) is not that harmful,
> > but I wanted to ask before I set a fix for this in our work
> >
> > noset = function() {
> >  opts = options()
> >  print(opts$digits.secs)
> >  on.exit(options(opts))
> >  options(digits.secs = 3)
> > }
> > getOption("digits.secs")
> > #> NULL
> > noset()
> > #> NULL
> > getOption("digits.secs")
> > #> [1] 3
> >
> >
> > John Muschelli, PhD
> > Associate Research Professor
> > Department of Biostatistics
> > Johns Hopkins Bloomberg School of Public Health
> >
> > [[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] Options "reset" when options(opts)

[Greg Jefferis]

Dear John,

You need to collect the return value when setting options. This will include an 
explicit NULL value for an option that was previously NULL. 

Best,

Greg Jefferis.

options(digits.secs = NULL)

noset2 = function() {
  opts <- options(digits.secs = 3)
  on.exit(options(opts))
  print(opts)
}

> getOption("digits.secs")
NULL
 
> noset2()
$digits.secs
NULL

> getOption("digits.secs")
NULL

Gregory Jefferis
Division of Neurobiology
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
http://jefferislab.org
https://www.zoo.cam.ac.uk/research/groups/connectomics


> On 11 Jul 2024, at 06:08, John Muschelli  wrote:
> 
> When setting options in a function, I have always used the following:
>  opts <- options()
>  on.exit(options(opts), add = TRUE)
> and assumed it "reset" options to what they were prior to running the
> function.  But for some options that are set to NULL, it does not seem to
> reset them.  Specifically, I have found digits.secs to be set after this
> simple example below.  Is this expected behavior/documented?  Overall, this
> specific example (the one I encountered in the wild) is not that harmful,
> but I wanted to ask before I set a fix for this in our work
> 
> noset = function() {
>  opts = options()
>  print(opts$digits.secs)
>  on.exit(options(opts))
>  options(digits.secs = 3)
> }
> getOption("digits.secs")
> #> NULL
> noset()
> #> NULL
> getOption("digits.secs")
> #> [1] 3
> 
> 
> John Muschelli, PhD
> Associate Research Professor
> Department of Biostatistics
> Johns Hopkins Bloomberg School of Public Health
> 
> [[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] [External] Use of ‘R_InputHandlers’

[luke-tierney]

On Wed, 10 Jul 2024, Duncan Murdoch wrote:


An update to the rgl package was rejected with this note:


* checking compiled code ... NOTE
File ‘rgl/libs/rgl.so’:
  Found non-API call to R: ‘R_InputHandlers’

Compiled code should not call non-API entry points in R.

See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual,
and section ‘Moving into C API compliance’ for issues with the use of
non-API entry points.


See 
 
for more info.


`R_InputHandlers` isn't actually a function, it's a linked list of structures 
holding input handlers.  rgl links into it to handle mouse and keyboard 
interaction when it is displaying a window in X11.


Ideally the code generating the NOTE should be revised since a few of
the things checked for at that point are global variables, not entry
points.

Given the design of this interface this variable should be added to
the embedding API and dropped from the check list. I have not dropped
it from the check list in R-devel so you should no longer get this
NOTE.

Best,

luke



`R_InputHandlers` is declared in R in src/include/R_ext/eventloop.h, where 
comments state



/*
   For use by alternative front-ends and packages which need to share
   the R event loop (on Unix-alikes).

   Not part of the API and subject to change without notice.

   NB: HAVE_SYS_SELECT_H should be checked and defined before this is
   included.
 */


WRE has a discussion of the issue in 8.1.4, "meshing event loops".  It refers 
to comments in src/unix/sys-std.c, but I'm not sure which comments.


rgl references it from this code:

https://github.com/dmurdoch/rgl/blob/fbedc326e291c3ec28a9ccac7d030f04b05edfa3/src/x11lib.cpp#L53-L72

Can anyone tell me whether I can fix this?

Duncan Murdoch

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Options "reset" when options(opts)

[John Muschelli]

When setting options in a function, I have always used the following:
  opts <- options()
  on.exit(options(opts), add = TRUE)
and assumed it "reset" options to what they were prior to running the
function.  But for some options that are set to NULL, it does not seem to
reset them.  Specifically, I have found digits.secs to be set after this
simple example below.  Is this expected behavior/documented?  Overall, this
specific example (the one I encountered in the wild) is not that harmful,
but I wanted to ask before I set a fix for this in our work

noset = function() {
  opts = options()
  print(opts$digits.secs)
  on.exit(options(opts))
  options(digits.secs = 3)
}
getOption("digits.secs")
#> NULL
noset()
#> NULL
getOption("digits.secs")
#> [1] 3


John Muschelli, PhD
Associate Research Professor
Department of Biostatistics
Johns Hopkins Bloomberg School of Public Health

[[alternative HTML version deleted]]

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

[R-pkg-devel] Use of ‘R_InputHandlers’

[Duncan Murdoch]

An update to the rgl package was rejected with this note:


* checking compiled code ... NOTE
File ‘rgl/libs/rgl.so’:
  Found non-API call to R: ‘R_InputHandlers’

Compiled code should not call non-API entry points in R.

See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual,
and section ‘Moving into C API compliance’ for issues with the use of
non-API entry points.


See 
 
for more info.


`R_InputHandlers` isn't actually a function, it's a linked list of 
structures holding input handlers.  rgl links into it to handle mouse 
and keyboard interaction when it is displaying a window in X11.


`R_InputHandlers` is declared in R in src/include/R_ext/eventloop.h, 
where comments state



/*
   For use by alternative front-ends and packages which need to share
   the R event loop (on Unix-alikes).

   Not part of the API and subject to change without notice.

   NB: HAVE_SYS_SELECT_H should be checked and defined before this is
   included.
 */


WRE has a discussion of the issue in 8.1.4, "meshing event loops".  It 
refers to comments in src/unix/sys-std.c, but I'm not sure which comments.


rgl references it from this code:

https://github.com/dmurdoch/rgl/blob/fbedc326e291c3ec28a9ccac7d030f04b05edfa3/src/x11lib.cpp#L53-L72

Can anyone tell me whether I can fix this?

Duncan Murdoch

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

Re: [R-pkg-devel] Help for understanding CRAN rejection

[Ivan Krylov via R-package-devel]

(I am adding the mailing list back in Cc: because package licensing is
a complicated topic.)

В Tue, 9 Jul 2024 09:25:14 +
Matei Teleman  пишет:

> I’ve added “ … SuperCell uses
> [velocyto.R](https://github.com/velocyto-team/velocyto.R) for RNA
> velocity. ” in the Description field. Is that enough or I need also
> to directly give the command line to install the package from GitHub ?

It looks like a link should be fine. Here are a few examples of CRAN
packages that have a non-CRAN/Bioconductor package in Suggests: without
setting up Additional_repositories:

https://CRAN.R-project.org/package=babelmixr2
https://CRAN.R-project.org/package=bandsfdp
https://cran.r-project.org/package=GCD

I'm sorry that I didn't note any of the following in my initial reply,
but what worries me about CC BY-NC-ND specifically is that out of 117
CRAN packages with a Creative Commons license and 18 of those that use
the non-FOSS "NonCommercial" clause, none use the "NoDerivatives"
clause. Your users would probably appreciate being able to install
binary builds of your package from CRAN. Does `R CMD INSTALL --build`
count as creating a derivative work, or is it "merely changing the
format"? Then again, CC BY-NC-ND _is_ mentioned in the list of CRAN
licenses, so it could work.

I found a rejected copy of your package in the archive subdirectory on
the CRAN FTP server and a GitHub repository [*] that seems to be
slightly outdated compared to the archived package. (It's best to link
to up-to-date package sources when seeking help with code.) I'm getting
an additional NOTE:

>> Imports includes 21 non-default packages.
>> Importing from so many packages makes the package vulnerable to any
>> of them becoming unavailable.  Move as many as possible to Suggests
>> and use conditionally.

Is there a way to make some of the currently required dependencies into
conditional dependencies? R CMD check --as-cran sets the limit to 20,
so moving just one package from Imports to Suggests will silence this
particular NOTE.

I see that most of your package size comes from the data subdirectory.
CRAN policy says: "Packages should be of the minimum necessary size.
<...> Neither data nor documentation should exceed 5MB. <...> Where a
large amount of data is required (even after compression),
consideration should be given to a separate data-only package which can
be updated only rarely (since older versions of packages are archived
in perpetuity)."
Is there a way to reduce the size of the data? It's ideal if there's
only enough data to demonstrate how an algorithm works in the
\examples{} section of your documentation and to exercise as much of
your code as feasible in your tests.

Finally, were there any recommendations in the rejection e-mail from
CRAN? Sometimes NOTEs are unavoidable, but we should strive to minimise
them anyway.

-- 
Best regards,
Ivan

[*] https://github.com/GfellerLab/SuperCell

__
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

[Michael Dewey]

Thank you to, in alphabetical order of given names, Iris, Ivan, Uwe and 
Wolfgang for your responses. I implemented Iris' suggestion and have 
successfully uploaded one of the packages to CRAN.


Michael

On 09/07/2024 10:06, Ivan Krylov wrote:

В Tue, 9 Jul 2024 08:54:22 +
"Viechtbauer, Wolfgang (NP)"
 пишет:


This appears to be related to this change
(https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):

- tools::checkRd() (used by R CMD check) detects more problems with
⁠\Sexpr⁠-based dynamic content, including bad nesting of ⁠\Sexpr⁠s
and invalid arguments.


The exact change was:

r85348 | hornik | 2023-10-18 08:13:46 + (Wed, 18 Oct 2023) | 1 line
Build PDF refman only when explicitly asked for.

--- src/library/tools/R/build.R (revision 85347)
+++ src/library/tools/R/build.R (revision 85348)
@@ -633,7 +633,7 @@
  }

 needRefman <- manual &&
-parse_description_field(desc, "BuildManual", TRUE) &&
+parse_description_field(desc, "BuildManual", FALSE) &&
  any(btinfo[, "later"])
 if (needRefman) {
 messageLog(Log, "building the PDF package manual")

So now R CMD build only builds the manual when both BuildManual is set
to yes _and_ there are \Sexpr{}s with [stage=install or render].
(Previously BuildManual: yes was assumed by default.)

Was the motivation for this change to make R CMD build faster for
everyone, with the expectation that the relatively rare package
maintainers with non-[stage=build] \Sexpr{}s will set BuildManual: yes
to adapt?



--
Michael

__
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

[Ivan Krylov via R-package-devel]

В Tue, 9 Jul 2024 08:54:22 +
"Viechtbauer, Wolfgang (NP)"
 пишет:

> This appears to be related to this change
> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):
> 
> - tools::checkRd() (used by R CMD check) detects more problems with
> ⁠\Sexpr⁠-based dynamic content, including bad nesting of ⁠\Sexpr⁠s
> and invalid arguments.

The exact change was:

r85348 | hornik | 2023-10-18 08:13:46 + (Wed, 18 Oct 2023) | 1 line
Build PDF refman only when explicitly asked for.

--- src/library/tools/R/build.R (revision 85347)
+++ src/library/tools/R/build.R (revision 85348)
@@ -633,7 +633,7 @@
 }

needRefman <- manual &&
-parse_description_field(desc, "BuildManual", TRUE) &&
+parse_description_field(desc, "BuildManual", FALSE) &&
 any(btinfo[, "later"])
if (needRefman) {
messageLog(Log, "building the PDF package manual")

So now R CMD build only builds the manual when both BuildManual is set
to yes _and_ there are \Sexpr{}s with [stage=install or render].
(Previously BuildManual: yes was assumed by default.)

Was the motivation for this change to make R CMD build faster for
everyone, with the expectation that the relatively rare package
maintainers with non-[stage=build] \Sexpr{}s will set BuildManual: yes
to adapt?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] cpp11 and "non-API calls to R"

[Hadley Wickham]

Hi Mark,

The cpp11 package is now maintained by Davis Vaughan and we will release a
new version once the C API status is a little cleaner. This warnings
generated from cpp11 will not interfere with your ability to submit your
package; just let CRAN know that the warnings are coming from cpp11.

Hadley

On Mon, Jul 8, 2024 at 4:25 PM Mark Padgham  wrote:

> Dear R-pkg-dev folk,
>
> The cpp11 package, which was developed yet is no longer maintained by
> Jim Hester, now triggers warnings on some CRAN pre-submit checks for
> "non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
> relevant issue is https://github.com/r-lib/cpp11/issues/355, with a pull
> request to resolve at https://github.com/r-lib/cpp11/pull/358. Problem
> is the package is now largely inactive, with the PR hanging there for a
> month or so unattended. I presume this warning means I can not resubmit
> any package depending on cpp11 until this is resolved. But then there
> are currently 75 packages potentially affected by this which would then
> also be unable to be resubmitted. (Follow the links from the main GitHub
> issue for a glimpse of the scale of this problem.)
>
> Any suggestions? In particular, it would be helpful, in this arguably
> unusual and quite prominent case, to hear any views from CRAN folk as to
> whether everybody dependent on cpp11 will have to wait for resolution
> before they'll be able to resubmit? Alternatively, any indication from
> anybody in a position to opine on cpp11 status and future maintenance
> plans would be great!
>
> Thanks,
>
> Mark
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
http://hadley.nz

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

[Viechtbauer, Wolfgang (NP)]

Hi Michael,

I assume you are getting this note because you are using mathjaxr. I am also 
getting this and others have reported the same:

https://github.com/wviechtb/mathjaxr/issues/15

(my response on the forum was a bit premature, since this note eventually did 
show up for me as well).

This appears to be related to this change 
(https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):

- tools::checkRd() (used by R CMD check) detects more problems with 
⁠\Sexpr⁠-based dynamic content, including bad nesting of ⁠\Sexpr⁠s and invalid 
arguments.

which was made in R version 4.4.0. I have submitted an updated metafor version 
in the meantime despite this note and it was accepted without any problems. 
Also, while I am getting this note locally, this note does not show up on the 
CRAN check results:

https://cran.r-project.org/web/checks/check_results_metafor.html

The manual is also available on the CRAN website:

https://cran.r-project.org/package=metafor

and also in the build directory of the tarball 
(https://cran.r-project.org/src/contrib/metafor_4.6-0.tar.gz).

So, unless CRAN states otherwise, I would suggest to submit the updated 
versions, burn some incense, pray twenty vectorized hail Rs, and hope for the 
best.

Best,
Wolfgang

> -Original Message-
> From: R-package-devel  On Behalf Of Uwe
> Ligges
> Sent: Monday, July 8, 2024 16:40
> To: Iris Simmons ; Michael Dewey 
> Cc: List r-package-devel 
> Subject: Re: [R-pkg-devel] NOTE about lack of prebuilt manual
>
> On 08.07.2024 16:08, Iris Simmons wrote:
> > 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
>
> Well, not really, we still build manuals unless file(s) containing
> install/render-stage \Sexpr{}  are present (as in this case).
>
> Best,
> Uwe Ligges
>
> > 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

Re: [R-pkg-devel] Help for understanding CRAN rejection

[Ivan Krylov via R-package-devel]

В Mon, 8 Jul 2024 15:12:24 +
Matei Teleman  пишет:

> Non-FOSS package license (file LICENSE)

> The license we’re using is the standard CC BY-NC-ND 4.0 and is listed
> among the accepted licenses for CRAN

Instead of putting the license text in a file inside the package (that
would have to match byte by byte in order to be recognised
automatically, or may be subtly different from the original with
potentially drastic legal consequences), use the name of the license
listed at [1]:

License: CC BY-NC-ND 4.0

If you want to keep the full text of the license in your source code
repository, put it in a file that you exclude from the source package
using .Rbuildignore.

I'm assuming you've already seen the CC FAQ [2] that recommends against
using CC licenses for software and chose it because it offers
restrictions for commercial use and distribution of derivatives. Too
bad none of the other licenses at [1] offer the same kind of
restrictions.

>Suggests or Enhances not in mainstream repositories:
>  velocyto.R

Just making sure: have you provided the instructions for obtaining
velocyto.R in the 'Description' field of the DESCRIPTION file?

-- 
Best regards,
Ivan

[1]
https://svn.r-project.org/R/trunk/share/licenses/license.db

[2]
https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

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

Re: [R-pkg-devel] Notes while a new R package submission

[Ben Bolker]

  The first NOTE is irrelevant.  The second NOTE says that you must 
reduce the running time of your examples (so that the longest of them 
takes <10 seconds on the *slowest* CRAN testing platform). This thread 
might be useful: 
https://stat.ethz.ch/pipermail/r-package-devel/2021q4/007521.html


  cheers
   Ben Bolker


On 2024-07-08 6:09 a.m., Mahadi Hassan wrote:

Hello everyone
I need your attention. I have developed a new R package and submitted it to
CRAN. In return main i got two notes they are:

* using log directory 'd:/RCompile/CRANincoming/R-devel/drglm.Rcheck'
* using R Under development (unstable) (2024-07-05 r86875 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
 gcc.exe (GCC) 13.2.0
 GNU Fortran (GCC) 13.2.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* checking for file 'drglm/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'drglm' version '1.0.1'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'MHNayem '

New submission
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'drglm' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for future file timestamps ... OK
* checking 'build' directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking code files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking installed files from 'inst/doc' ... OK
* checking files in 'vignettes' ... OK
* checking examples ... [257s] NOTE
Examples with CPU (user + system) or elapsed time > 10s
 user system elapsed
drglm  93.50  14.34  107.82
drglm.multinom 78.65  13.28   91.89
big.drglm  26.61   1.75   28.36
make.data  25.07   1.78   26.84
* checking for unstated dependencies in 'tests' ... OK
* checking tests ... OK
   Running 'testthat.R'
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes ... OK
* checking re-building of vignette outputs ... [241s] OK
* checking PDF version of manual ... [13s] OK
* checking HTML version of manual ... OK
* DONE
Status: 2 NOTEs



And my submission got cancelled automatically.  Can you tell me how to
solve such notes and how can i resubmit it to CRAN?

[[alternative HTML version deleted]]

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


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


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

[R-pkg-devel] Help for understanding CRAN rejection

[Matei Teleman]

Hello everyone,

I hope this email finds you well.

I’m sorry to bother you, it’s the very first time I’m submitting a package to 
CRAN.

Recently my submission got rejected with the following feedback:
Non-FOSS package license (file LICENSE)

   Suggests or Enhances not in mainstream repositories:
 velocyto.R

   Found the following (possibly) invalid URLs:
 URL: https://cran.r-project.org/web/packages/Seurat/index.html
   From: inst/doc/a_SuperCell.html
   Status: 200
   Message: OK
   CRAN URL not in canonical form

   The canonical URL of the CRAN page for a package is
 
https://CRAN.R-project.org/package=pkgname


   Size of tarball: 9076436 bytes


Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: package dependencies, Result: NOTE
   Package suggested but not available for checking: ‘velocyto.R'


The license we’re using is the standard CC BY-NC-ND 4.0 and is listed among the 
accepted licenses for CRAN.

I fixed the URL issue but how can I make CRAN accept the package ?

Thank you advance for your time and your help !

Have a nice day.

Best Regards,

Matei Teleman

[[alternative HTML version deleted]]

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

[R-pkg-devel] Notes while a new R package submission

[Mahadi Hassan]

Hello everyone
I need your attention. I have developed a new R package and submitted it to
CRAN. In return main i got two notes they are:

* using log directory 'd:/RCompile/CRANincoming/R-devel/drglm.Rcheck'
* using R Under development (unstable) (2024-07-05 r86875 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 13.2.0
GNU Fortran (GCC) 13.2.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* checking for file 'drglm/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'drglm' version '1.0.1'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'MHNayem '

New submission
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'drglm' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for future file timestamps ... OK
* checking 'build' directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking code files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking installed files from 'inst/doc' ... OK
* checking files in 'vignettes' ... OK
* checking examples ... [257s] NOTE
Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
drglm  93.50  14.34  107.82
drglm.multinom 78.65  13.28   91.89
big.drglm  26.61   1.75   28.36
make.data  25.07   1.78   26.84
* checking for unstated dependencies in 'tests' ... OK
* checking tests ... OK
  Running 'testthat.R'
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes ... OK
* checking re-building of vignette outputs ... [241s] OK
* checking PDF version of manual ... [13s] OK
* checking HTML version of manual ... OK
* DONE
Status: 2 NOTEs



And my submission got cancelled automatically.  Can you tell me how to
solve such notes and how can i resubmit it to CRAN?

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Segfaults on R-devel

[Ben Bolker]

  I'm pretty sure this is from this R-devel commit:

https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250

 This turns on stricter boundary checking, specifically see 
https://github.com/lme4/lme4/issues/794#issuecomment-2154948145


  Arguably, accessing an element of a zero-length vector is at least 
undefined behaviour, so you shouldn't be doing it ...




On 2024-07-08 6:46 p.m., Claborne, Daniel via R-package-devel wrote:

Seemingly starting with the most recent builds of R-devel, I�ve been getting 
segfaults related to a piece of cpp code that indexes a zero-size 
NumericVector.  Essentially the same as this dummy example:

```
library(Rcpp)

sourceCpp(
   code = '
   #include
   using namespace Rcpp;

   // [[Rcpp::export]]
   NumericVector zeroindex() {
 NumericVector zerosize(0);

 Rcout << zerosize[0] << std::endl;

 return zerosize;
   }
   '
)

zeroindex()
```

On R-release and on previous builds, this returns something like:

```
6.92674e-310
numeric(0)
```

But on current R-devel containers:

```

  *** caught segfault ***

address 0x1, cause 'memory not mapped'



Traceback:

  1: .Call()

  2: zeroindex()



Possible actions:

1: abort (with core dump, if enabled)

2: normal R exit

3: exit R without saving workspace

4: exit R saving workspace
```

It was easy enough to write a catch for the zero-size vector, however I�m 
wondering why the discrepancy between R-devel and previous versions?

Best,
-DMC

[[alternative HTML version deleted]]


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


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


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

[R-pkg-devel] Segfaults on R-devel

[Claborne, Daniel via R-package-devel]

Seemingly starting with the most recent builds of R-devel, I�ve been getting 
segfaults related to a piece of cpp code that indexes a zero-size 
NumericVector.  Essentially the same as this dummy example:

```
library(Rcpp)

sourceCpp(
  code = '
  #include
  using namespace Rcpp;

  // [[Rcpp::export]]
  NumericVector zeroindex() {
NumericVector zerosize(0);

Rcout << zerosize[0] << std::endl;

return zerosize;
  }
  '
)

zeroindex()
```

On R-release and on previous builds, this returns something like:

```
6.92674e-310
numeric(0)
```

But on current R-devel containers:

```

 *** caught segfault ***

address 0x1, cause 'memory not mapped'



Traceback:

 1: .Call()

 2: zeroindex()



Possible actions:

1: abort (with core dump, if enabled)

2: normal R exit

3: exit R without saving workspace

4: exit R saving workspace
```

It was easy enough to write a catch for the zero-size vector, however I�m 
wondering why the discrepancy between R-devel and previous versions?

Best,
-DMC

[[alternative HTML version deleted]]

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

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

[Uwe Ligges]

On 08.07.2024 16:08, Iris Simmons wrote:

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



Well, not really, we still build manuals unless file(s) containing 
install/render-stage \Sexpr{}  are present (as in this case).


Best,
Uwe Ligges




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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] cpp11 and "non-API calls to R"

[Josiah Parry]

Hi Mark,

As someone else affected by this issue, it is actually quite tough to
resolve. This is because quite literally every other day, the list of what
is and is not non-API is changing. It is particularly challenging since
this is in R-devel and not any stable R release.

If there were a stable list of non-API and a stable release of R that this
is associated with it is my guess that the PR would’ve been merged by now.

On Mon, Jul 8, 2024 at 10:25 Mark Padgham  wrote:

> Dear R-pkg-dev folk,
>
> The cpp11 package, which was developed yet is no longer maintained by
> Jim Hester, now triggers warnings on some CRAN pre-submit checks for
> "non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
> relevant issue is https://github.com/r-lib/cpp11/issues/355, with a pull
> request to resolve at https://github.com/r-lib/cpp11/pull/358. Problem
> is the package is now largely inactive, with the PR hanging there for a
> month or so unattended. I presume this warning means I can not resubmit
> any package depending on cpp11 until this is resolved. But then there
> are currently 75 packages potentially affected by this which would then
> also be unable to be resubmitted. (Follow the links from the main GitHub
> issue for a glimpse of the scale of this problem.)
>
> Any suggestions? In particular, it would be helpful, in this arguably
> unusual and quite prominent case, to hear any views from CRAN folk as to
> whether everybody dependent on cpp11 will have to wait for resolution
> before they'll be able to resubmit? Alternatively, any indication from
> anybody in a position to opine on cpp11 status and future maintenance
> plans would be great!
>
> Thanks,
>
> Mark
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] cpp11 and "non-API calls to R"

[Ben Bolker]

  Have you contacted the maintainer directly (i.e. by e-mail)?  (Yes, 
they should be paying attention to Github, but trying another channel 
never hurts.)


  My personal experience is that I was succeeded in submitting a 
package update to CRAN even though there were NOTEs of this sort (in 
that case SET_TYPEOF) arising from an upstream package 
; I explained the issue in 
my cover letter.


  It may take a while to sort out all of the fallout from the 
tightening of the API rules; I think the CRAN maintainers are aware of this.


  cheers
   Ben Bolker


On 2024-07-08 10:24 a.m., Mark Padgham wrote:

Dear R-pkg-dev folk,

The cpp11 package, which was developed yet is no longer maintained by
Jim Hester, now triggers warnings on some CRAN pre-submit checks for
"non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
relevant issue is https://github.com/r-lib/cpp11/issues/355, with a pull
request to resolve at https://github.com/r-lib/cpp11/pull/358. Problem
is the package is now largely inactive, with the PR hanging there for a
month or so unattended. I presume this warning means I can not resubmit
any package depending on cpp11 until this is resolved. But then there
are currently 75 packages potentially affected by this which would then
also be unable to be resubmitted. (Follow the links from the main GitHub
issue for a glimpse of the scale of this problem.)

Any suggestions? In particular, it would be helpful, in this arguably
unusual and quite prominent case, to hear any views from CRAN folk as to
whether everybody dependent on cpp11 will have to wait for resolution
before they'll be able to resubmit? Alternatively, any indication from
anybody in a position to opine on cpp11 status and future maintenance
plans would be great!

Thanks,

Mark

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


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


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

[R-pkg-devel] cpp11 and "non-API calls to R"

[Mark Padgham]

Dear R-pkg-dev folk,

The cpp11 package, which was developed yet is no longer maintained by
Jim Hester, now triggers warnings on some CRAN pre-submit checks for
"non-API calls to R" via "SETLENGTH", "SET_TRUELENGTH", and others. The
relevant issue is https://github.com/r-lib/cpp11/issues/355, with a pull
request to resolve at https://github.com/r-lib/cpp11/pull/358. Problem
is the package is now largely inactive, with the PR hanging there for a
month or so unattended. I presume this warning means I can not resubmit
any package depending on cpp11 until this is resolved. But then there
are currently 75 packages potentially affected by this which would then
also be unable to be resubmitted. (Follow the links from the main GitHub
issue for a glimpse of the scale of this problem.)

Any suggestions? In particular, it would be helpful, in this arguably
unusual and quite prominent case, to hear any views from CRAN folk as to
whether everybody dependent on cpp11 will have to wait for resolution
before they'll be able to resubmit? Alternatively, any indication from
anybody in a position to opine on cpp11 status and future maintenance
plans would be great!

Thanks,

Mark

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

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

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

[Michael Dewey]

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

Re: [R-pkg-devel] Is R-Forge dead?

[Achim Zeileis]

On Tue, 2 Jul 2024, Martin Maechler wrote:


Achim Zeileis
on Tue, 2 Jul 2024 01:05:07 +0200 (CEST) writes:


   > Kevin, R-Forge is still alive but there are problems with
   > the build queue as you noticed. The problems occurred
   > after R-Forge upgraded to R 4.4.0 - just as there was a
   > switch in the maintenance team at WU Wien.

   > The problem is with the Windows build/check tools which
   > work fine when run manually but either fail (if there is
   > compiled code in the package) or stall when run in batch
   > mode.

   > Jorge, the new member in the admin team at WU, has been
   > going through all the scripts with Uwe (Ligges) but they
   > haven't spotted the problem so far. I think that the next
   > step will be to migrate the Windows build/check processes
   > to the Win-Builder machine.

   > I hope that they will succeed in doing so in the next
   > weeks. Apologies for the inconvenience.

   > Best wishes, Achim

Thanks a lot, Achim,
for the update and explanation!

I maintain quite a few packages on R-forge,
enjoying the simplicity of svn (subversion) on the way.

For automatic building and checking,  some of you may be aware
that the R-OpenSci organization has hosted and sponsored the
"R-Universe" project https://ropensci.org/r-universe/,
implemented and made quite successful I think primarily by
Jeroen Ooms.   A main goal (I think) has been to *be* as
universal as possible, and provide a "portal" for "all" publicly
hosted R packages and not only foster to private company-owned
platforms such as github, but rather work with more general
"organizations" such as CRAN and BioC (each via their 'Meta
CRAN'), then also R-forge and many many more, see
   https://r-universe.dev/organizations/

Consequently, the R-forge packages are also all mirrored and
presented there, *and* also built and checked,
  --> https://r-forge.r-universe.dev/
... sometimes (somewhat confusingly to us, in one case) checking
against non-released versions of CRAN packages (instead of the stable
CRAN version)  which of course may be useful ((and I think is
similar to how R-forge works;  if there are released and
unreleased version of packages around, it's not easily
determinable *which* version should be used for tests of other
packages)).

Anyway, I was glad in one case that R-universe provided a built
version of the development version of one of my packages other
users could easily install.

Martin

PS:  I have not been a fan of r-universe, notably originally, as
it diverts attention away from R-project and CRAN, but then did
notice how useful it can be to the R users community, and how
well it has been maintained, hence these kudos!


+1 Thanks for pointing to R-universe, Martin, indeed an excellent service!

An additional detail about the packages at:

https://R-Forge.R-universe.dev/

This are the development versions of the R-Forge packages that are already 
released on CRAN.


If anyone has R-Forge packages that are not (yet) released on CRAN and you 
want to deploy them via R-universe, then you can do so by setting up your 
own universe. I'm using that for many of my R-Forge packages, see


https://zeileis.R-universe.dev/

and

https://github.com/zeileis/zeileis.r-universe.dev

for the underlying configuration.

Best wishes,
Achim




   > On Tue, 2 Jul 2024, Kevin R. Coombes wrote:

   >> Hi,
   >>
   >> I have been maintaining packages in R-Forge for many
   >> tears. Last week I sent an email to r-fo...@r-project.org
   >> to report problems with the build process.  It appears
   >> that any changes I have pushed to R-Forge over
   >> approximately the last two months have resulted in the
   >> package remaining in the "Building" state, even though
   >> the logs suggest that the package built successfully on
   >> both LINUX and Windows. (Also, four of the six affected
   >> packages only included changes to the man pages to clean
   >> up NOTEs from the R cmd checks on old versions at CRAN,
   >> where the new versions now happily reside.) I have
   >> received no response nor acknowledgement to my email to
   >> R-Forge.
   >>
   >> Assuming that R-Forge has finally succumbed to the
   >> ravages of entropy, does anyone have advice on creating a
   >> git project that contains multiple R packages? (I really
   >> don't want to have to create 20+ new git projects, one
   >> per package).
   >>
   >> Best,    Kevin
   >>
   >> __
   >> R-package-devel@r-project.org mailing list
   >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
   >>
   > __
   > R-package-devel@r-project.org mailing list
   > https://stat.ethz.ch/mailman/listinfo/r-package-devel



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

Re: [R-pkg-devel] Is R-Forge dead?

[Martin Maechler]

> Achim Zeileis 
> on Tue, 2 Jul 2024 01:05:07 +0200 (CEST) writes:

> Kevin, R-Forge is still alive but there are problems with
> the build queue as you noticed. The problems occurred
> after R-Forge upgraded to R 4.4.0 - just as there was a
> switch in the maintenance team at WU Wien.

> The problem is with the Windows build/check tools which
> work fine when run manually but either fail (if there is
> compiled code in the package) or stall when run in batch
> mode.

> Jorge, the new member in the admin team at WU, has been
> going through all the scripts with Uwe (Ligges) but they
> haven't spotted the problem so far. I think that the next
> step will be to migrate the Windows build/check processes
> to the Win-Builder machine.

> I hope that they will succeed in doing so in the next
> weeks. Apologies for the inconvenience.

> Best wishes, Achim

Thanks a lot, Achim,
for the update and explanation!

I maintain quite a few packages on R-forge,
enjoying the simplicity of svn (subversion) on the way.

For automatic building and checking,  some of you may be aware
that the R-OpenSci organization has hosted and sponsored the
"R-Universe" project https://ropensci.org/r-universe/,
implemented and made quite successful I think primarily by
Jeroen Ooms.   A main goal (I think) has been to *be* as
universal as possible, and provide a "portal" for "all" publicly
hosted R packages and not only foster to private company-owned
platforms such as github, but rather work with more general
"organizations" such as CRAN and BioC (each via their 'Meta
CRAN'), then also R-forge and many many more, see
https://r-universe.dev/organizations/

Consequently, the R-forge packages are also all mirrored and
presented there, *and* also built and checked,
   --> https://r-forge.r-universe.dev/
... sometimes (somewhat confusingly to us, in one case) checking
against non-released versions of CRAN packages (instead of the stable
CRAN version)  which of course may be useful ((and I think is
similar to how R-forge works;  if there are released and
unreleased version of packages around, it's not easily
determinable *which* version should be used for tests of other
packages)).

Anyway, I was glad in one case that R-universe provided a built
version of the development version of one of my packages other
users could easily install.

Martin

PS:  I have not been a fan of r-universe, notably originally, as
it diverts attention away from R-project and CRAN, but then did
notice how useful it can be to the R users community, and how
well it has been maintained, hence these kudos!


> On Tue, 2 Jul 2024, Kevin R. Coombes wrote:

>> Hi,
>> 
>> I have been maintaining packages in R-Forge for many
>> tears. Last week I sent an email to r-fo...@r-project.org
>> to report problems with the build process.  It appears
>> that any changes I have pushed to R-Forge over
>> approximately the last two months have resulted in the
>> package remaining in the "Building" state, even though
>> the logs suggest that the package built successfully on
>> both LINUX and Windows. (Also, four of the six affected
>> packages only included changes to the man pages to clean
>> up NOTEs from the R cmd checks on old versions at CRAN,
>> where the new versions now happily reside.) I have
>> received no response nor acknowledgement to my email to
>> R-Forge.
>> 
>> Assuming that R-Forge has finally succumbed to the
>> ravages of entropy, does anyone have advice on creating a
>> git project that contains multiple R packages? (I really
>> don't want to have to create 20+ new git projects, one
>> per package).
>> 
>> Best,    Kevin
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Is R-Forge dead?

[Jeff Newmiller via R-package-devel]

I cannot/will not to help you do this, but there are people out there who 
disagree with me who put considerable effort into doing this... the search term 
you would need in order to find them is "monorepo". But please reconsider...  
the whole point of putting code into separate packages is to isolate their 
internals to make them less interdependent... putting all of them into a 
monorepo can lead you to forget that users experience them as distinct units.

On July 1, 2024 3:04:40 PM PDT, "Kevin R. Coombes"  
wrote:
>Hi,
>
>I have been maintaining packages in R-Forge for many tears. Last week I sent 
>an email to r-fo...@r-project.org to report problems with the build process. 
>It appears that any changes I have pushed to R-Forge over approximately the 
>last two months have resulted in the package remaining in the "Building" 
>state, even though the logs suggest that the package built successfully on 
>both LINUX and Windows. (Also, four of the six affected packages only included 
>changes to the man pages to clean up NOTEs from the R cmd checks on old 
>versions at CRAN, where the new versions now happily reside.) I have received 
>no response nor acknowledgement to my email to R-Forge.
>
>Assuming that R-Forge has finally succumbed to the ravages of entropy, does 
>anyone have advice on creating a git project that contains multiple R 
>packages? (I really don't want to have to create 20+ new git projects, one per 
>package).
>
>Best,
>   Kevin
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
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 R-Forge dead?

[Achim Zeileis]

Kevin,

R-Forge is still alive but there are problems with the build queue as you 
noticed. The problems occurred after R-Forge upgraded to R 4.4.0 - just as 
there was a switch in the maintenance team at WU Wien.


The problem is with the Windows build/check tools which work fine when run 
manually but either fail (if there is compiled code in the package) or stall 
when run in batch mode.


Jorge, the new member in the admin team at WU, has been going through all the 
scripts with Uwe (Ligges) but they haven't spotted the problem so far. I think 
that the next step will be to migrate the Windows build/check processes to the 
Win-Builder machine.


I hope that they will succeed in doing so in the next weeks. Apologies for the 
inconvenience.


Best wishes,
Achim


On Tue, 2 Jul 2024, Kevin R. Coombes wrote:


Hi,

I have been maintaining packages in R-Forge for many tears. Last week I sent 
an email to r-fo...@r-project.org to report problems with the build process. 
It appears that any changes I have pushed to R-Forge over approximately the 
last two months have resulted in the package remaining in the "Building" 
state, even though the logs suggest that the package built successfully on 
both LINUX and Windows. (Also, four of the six affected packages only 
included changes to the man pages to clean up NOTEs from the R cmd checks on 
old versions at CRAN, where the new versions now happily reside.) I have 
received no response nor acknowledgement to my email to R-Forge.


Assuming that R-Forge has finally succumbed to the ravages of entropy, does 
anyone have advice on creating a git project that contains multiple R 
packages? (I really don't want to have to create 20+ new git projects, one 
per package).


Best,
   Kevin

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


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

Re: [R-pkg-devel] Is R-Forge dead?

[Duncan Murdoch]

While you can put multiple packages in one Git repository, I'd suggest 
that you don't do that.  Most packages are in their own repository, and 
that means that users who want to contribute to your packages are 
familiar with that setup.  If they have to fork 20 packages at once to 
make a contribution to one of them, they are less likely to want to do it.


Duncan Murdoch

On 2024-07-01 6:04 p.m., Kevin R. Coombes wrote:

Hi,

I have been maintaining packages in R-Forge for many tears. Last week I
sent an email to r-fo...@r-project.org to report problems with the build
process. It appears that any changes I have pushed to R-Forge over
approximately the last two months have resulted in the package remaining
in the "Building" state, even though the logs suggest that the package
built successfully on both LINUX and Windows. (Also, four of the six
affected packages only included changes to the man pages to clean up
NOTEs from the R cmd checks on old versions at CRAN, where the new
versions now happily reside.) I have received no response nor
acknowledgement to my email to R-Forge.

Assuming that R-Forge has finally succumbed to the ravages of entropy,
does anyone have advice on creating a git project that contains multiple
R packages? (I really don't want to have to create 20+ new git projects,
one per package).

Best,
     Kevin

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


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

Re: [R-pkg-devel] Is R-Forge dead?

[Ben Bolker]

  I don't know about R-forge, but it's perfectly workable to put 
multiple packages within a single repo, with each package in its own 
subdirectory.  You'll run into some headaches occasionally with (e.g.) 
CI machinery that assumes that the head of a git repo is also the 
primary package directory (e.g. 
https://github.com/r-hub/rhub/issues/584) ...


On 2024-07-01 6:04 p.m., Kevin R. Coombes wrote:

Hi,

I have been maintaining packages in R-Forge for many tears. Last week I 
sent an email to r-fo...@r-project.org to report problems with the build 
process. It appears that any changes I have pushed to R-Forge over 
approximately the last two months have resulted in the package remaining 
in the "Building" state, even though the logs suggest that the package 
built successfully on both LINUX and Windows. (Also, four of the six 
affected packages only included changes to the man pages to clean up 
NOTEs from the R cmd checks on old versions at CRAN, where the new 
versions now happily reside.) I have received no response nor 
acknowledgement to my email to R-Forge.


Assuming that R-Forge has finally succumbed to the ravages of entropy, 
does anyone have advice on creating a git project that contains multiple 
R packages? (I really don't want to have to create 20+ new git projects, 
one per package).


Best,
    Kevin

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


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

Re: [R-pkg-devel] Is R-Forge dead?

[Brian G. Peterson]

Kevin,

I can't speak to whether R-Forge is dead, we migrated our projects to
github a long time ago.

The most straightforward answer for R packages in git repositories is
to use separate git projects.  we were even able to import the entire
SVN history and r-forge issue history to github for each of our r-forge
projects when we migrated. The only major complexity that I recall was
creating a table mapping svn contributors to github users (where
available).

If you want to do it all in one git repository, I strongly suggest that
you *still* import all the svn history, but that you do it in one
directory per project, since this is required by `R CMD build`.  We
sometimes use this 'one package per directory' approach in some of our
private repositories at work.  In this case, if you use an IDE like
RStudio, you'll still create separate *RStudio* projects in each
directory, so that you can build, install, test, etc each package from
the IDE, but you can use a single repository for all of it.

Your future self will thank you for having full version control history
of all the "Olde" (tm) versions.

Best of luck.  - Brian

see reference below about importing an svn repo to git:


Ref:
https://docs.github.com/en/migrations/importing-source-code/using-the-command-line-to-import-source-code/importing-a-subversion-repository

-- 
Brian G. Peterson
ph: +1.773.459.4973
im: bgpbraverock

On Mon, 2024-07-01 at 18:04 -0400, Kevin R. Coombes wrote:
> Hi,
> 
> I have been maintaining packages in R-Forge for many tears. Last week
> I 
> sent an email to r-fo...@r-project.org to report problems with the
> build 
> process. It appears that any changes I have pushed to R-Forge over 
> approximately the last two months have resulted in the package
> remaining 
> in the "Building" state, even though the logs suggest that the
> package 
> built successfully on both LINUX and Windows. (Also, four of the six 
> affected packages only included changes to the man pages to clean up 
> NOTEs from the R cmd checks on old versions at CRAN, where the new 
> versions now happily reside.) I have received no response nor 
> acknowledgement to my email to R-Forge.
> 
> Assuming that R-Forge has finally succumbed to the ravages of
> entropy, 
> does anyone have advice on creating a git project that contains
> multiple 
> R packages? (I really don't want to have to create 20+ new git
> projects, 
> one per package).
> 
> Best,
>     Kevin
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[R-pkg-devel] Is R-Forge dead?

[Kevin R. Coombes]

Hi,

I have been maintaining packages in R-Forge for many tears. Last week I 
sent an email to r-fo...@r-project.org to report problems with the build 
process. It appears that any changes I have pushed to R-Forge over 
approximately the last two months have resulted in the package remaining 
in the "Building" state, even though the logs suggest that the package 
built successfully on both LINUX and Windows. (Also, four of the six 
affected packages only included changes to the man pages to clean up 
NOTEs from the R cmd checks on old versions at CRAN, where the new 
versions now happily reside.) I have received no response nor 
acknowledgement to my email to R-Forge.


Assuming that R-Forge has finally succumbed to the ravages of entropy, 
does anyone have advice on creating a git project that contains multiple 
R packages? (I really don't want to have to create 20+ new git projects, 
one per package).


Best,
   Kevin

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

[R-pkg-devel] R-devel non-API & extendr v0.7.0

[Josiah Parry]

Hi folks,

A new release of extendr v0.7.0 is now available.

This release addresses the R-devel WARNings from non-API functions being
used.
This release also comes with breaking changes. We've written a brief
migration guide
which can be found at:

htttps://extendr.github.io/blog/posts/2024-06-30-extendr-release-070

We went through the packages with `rust` in the SystemRequirements field of
the DESCRIPTION
file found in the CRAN_package_db() and submitted PRs to update and migrate
the version of extendr.

If you have not received a PR from us and have a failing package check on
CRAN, please
reply here with a link to your repo and we will give it a look!

Thanks,

Josiah

[[alternative HTML version deleted]]

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