Re: [R-pkg-devel] Compiled code should not call non-API entry points in R

[Dirk Eddelbuettel]

On 3 November 2022 at 21:09, Andrew Simmons wrote:
| I had some R code for dealing with connections, and I was using
| summary.connection(). I rewrote it in C, so I was doing something more
| like:
| 
| #include 
| 
| Rconnection Rcon = R_GetConnection(file);
| Rcon->description or Rcon->class
| 
| but now, when checking my package, I get the following note:
| 
| * checking compiled code ... NOTE
| File 'this.path/libs/x64/this.path.dll':
|   Found non-API call to R: 'R_GetConnection'
| 
| Compiled code should not call non-API entry points in R.
| 
| See 'Writing portable packages' in the 'Writing R Extensions' manual.
| 
| This isn't surprising,  (seen here:
| 
https://github.com/wch/r-source/blob/50ff41b742a1ac655314be5e25897a12d3096661/src/include/R_ext/Connections.h#L21)
| says that it is not part of the R API, and later on says that it is
| subject to change without notice or backwards compatibility.
| 
| R_GetConnection was added in R 3.3.0, so I added "Depends: R (>=
| 3.3.0)" to my DESCRIPTION, then I added something like this to my
| header:
| 
| #if !defined(R_CONNECTIONS_VERSION)
| #error why is R_CONNECTIONS_VERSION not defined
| #elif R_CONNECTIONS_VERSION == 1
| extern Rconnection R_GetConnection(SEXP sConn);
| #else
| #error this.path is only implemented for R_CONNECTIONS_VERSION 1
| #endif
| 
| but the NOTE still remains. I think I've taken all the precautions I
| can, is there anything more I can do? Will I be unable to submit the
| update for my package? Will the CRAN team ignore the NOTE if I explain
| the precautions I added?

The R API is owned by R Core. So they can do as they please.

And so they do as they are acutely aware of the cost of maintaining an
'enlarged surface'. And they try to keep it small. Understandably so.

Some of us package developers have asked for more interfaces. Repeatedly so
for connections for what is (likely already, else soon) twenty years. Alas...

Then there is 
https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
so eventually we run out of patience.

Hence, as both trial baloons as well as intial use case I published two packages
  RApiDatetimeexposing some unexported datetime conversion
  RApiSerialize   exposing some (basic) connections facilities

RApiSerialize really owes a Thank You! to RhpcBLASctl as Junji and Ei-ji
showed me the way of what one could do here.

Now, do I think these packages are the best answer? Far from it. Vendoring,
as done here, casts existing interfaces (and behavior) in conrete. It is less
than ideal. The code can atrophy. But it provides access when those who own
the access refuse to provide it (for what remain defensible reasons).

All told, not ideal either way. But venues for workarounds exist. So
sometimes they are taken. Because we can. Just look for the least-evil way.

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] Compiled code should not call non-API entry points in R

[Andrew Simmons]

Hi everyone,


I had some R code for dealing with connections, and I was using
summary.connection(). I rewrote it in C, so I was doing something more
like:

#include 

Rconnection Rcon = R_GetConnection(file);
Rcon->description or Rcon->class

but now, when checking my package, I get the following note:

* checking compiled code ... NOTE
File 'this.path/libs/x64/this.path.dll':
  Found non-API call to R: 'R_GetConnection'

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

See 'Writing portable packages' in the 'Writing R Extensions' manual.

This isn't surprising,  (seen here:
https://github.com/wch/r-source/blob/50ff41b742a1ac655314be5e25897a12d3096661/src/include/R_ext/Connections.h#L21)
says that it is not part of the R API, and later on says that it is
subject to change without notice or backwards compatibility.

R_GetConnection was added in R 3.3.0, so I added "Depends: R (>=
3.3.0)" to my DESCRIPTION, then I added something like this to my
header:

#if !defined(R_CONNECTIONS_VERSION)
#error why is R_CONNECTIONS_VERSION not defined
#elif R_CONNECTIONS_VERSION == 1
extern Rconnection R_GetConnection(SEXP sConn);
#else
#error this.path is only implemented for R_CONNECTIONS_VERSION 1
#endif

but the NOTE still remains. I think I've taken all the precautions I
can, is there anything more I can do? Will I be unable to submit the
update for my package? Will the CRAN team ignore the NOTE if I explain
the precautions I added?

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

Re: [Rd] as.Date withoug "origin"

[Therneau, Terry M., Ph.D. via R-devel]

Add my name to those who think this is a good change.

As someone who works daily with medical research data, the number of times I 
have been 
caugth by failure of statements like
    as.Date(ifelse( is.na(prog.dt), lastfu.dt, prog.dt)
is a large annoyance.    Replace ifelse by any number of selection processes 
for choosing 
among ending dates.

Terry T.

-- 
Terry M Therneau, PhD
Department of Quantitative Health Sciences
Mayo Clinic
thern...@mayo.edu

"TERR-ree THUR-noh"

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] [EXTERNAL] Re: Bioconductor package rcellminerData

[Kern, Lori]

The experimentData packages are still on a Tue/Thur build schedule. They have 
not run yet since the bump and branch.  I would expected to see the new version 
after today's report.

Cheers


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Elloumi, Fathi (NIH/NCI) [E] 
Sent: Thursday, November 3, 2022 8:19 AM
To: Kern, Lori 
Cc: Herv� Pag�s ; bioc-devel 
Subject: Re: [EXTERNAL] Re: Bioconductor package rcellminerData


Hi Lori,



The package rcellminerData did not bump to version 2.20.0. Is it related to the 
build warning? Please let me know what is the issue. And how to fix it?



Thanks,



Fathi



From: "Kern, Lori" 
Date: Monday, April 18, 2022 at 9:16 AM
To: "Elloumi, Fathi (NIH/NCI) [E]" 
Cc: Herv� Pag�s , bioc-devel 
Subject: [EXTERNAL] Re: Bioconductor package rcellminerData



CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and are confident the 
content is safe.



Experiment Data packages are built every Tue and Thur.  as shown on the build 
report header page 
http://bioconductor.org/checkResults/



The changes pushed up last Thur 14 would have been too late to be included in a 
Thursday build report.  I expect the changes to be visible after Tomorrow's 
build report posts.



Cheers,



Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263



From: Elloumi, Fathi (NIH/NCI) [E] 
Sent: Monday, April 18, 2022 9:12 AM
To: Kern, Lori 
Cc: Herv� Pag�s ; bioc-devel 
Subject: Re: Bioconductor package rcellminerData



Hello Lori,



I bumped the rcellminerData dev version from 2.17.0 to 2.17.1 since 4/14 and I 
did see it on devel builders: 
http://bioconductor.org/checkResults/3.15/data-experiment-LATEST/rcellminerData/



Could help me with this issue?



Thanks,



Fathi



From: "Kern, Lori" 
Date: Tuesday, June 29, 2021 at 10:50 AM
To: "lu...@cbio.mskcc.org" , "Rajapakse, Vinodh (NIH/NCI) 
[C]" , "Elloumi, Fathi (NIH/NCI) [C]" 

Subject: Bioconductor package rcellminerData



Hello package maintainer,



We would like to bring to your attention that your package is failing on the 
devel builders of Bioconductor:



http://bioconductor.org/checkResults/3.14/data-experiment-LATEST/rcellminerData



Please fix your package as soon as possible. If the package remains broken for 
an extended period of time, we will deprecate the package.



The ERROR results from an update in the knitr package as announced here:

Re: [Bioc-devel] [EXTERNAL] Re: Bioconductor package rcellminerData

[Elloumi, Fathi (NIH/NCI) [E] via Bioc-devel]

Hi Lori,

The package rcellminerData did not bump to version 2.20.0. Is it related to the 
build warning? Please let me know what is the issue. And how to fix it?

Thanks,

Fathi

From: "Kern, Lori" 
Date: Monday, April 18, 2022 at 9:16 AM
To: "Elloumi, Fathi (NIH/NCI) [E]" 
Cc: Hervé Pagès , bioc-devel 
Subject: [EXTERNAL] Re: Bioconductor package rcellminerData

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and are confident the 
content is safe.

Experiment Data packages are built every Tue and Thur.  as shown on the build 
report header page 
http://bioconductor.org/checkResults/

The changes pushed up last Thur 14 would have been too late to be included in a 
Thursday build report.  I expect the changes to be visible after Tomorrow's 
build report posts.

Cheers,


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Elloumi, Fathi (NIH/NCI) [E] 
Sent: Monday, April 18, 2022 9:12 AM
To: Kern, Lori 
Cc: Hervé Pagès ; bioc-devel 
Subject: Re: Bioconductor package rcellminerData


Hello Lori,



I bumped the rcellminerData dev version from 2.17.0 to 2.17.1 since 4/14 and I 
did see it on devel builders: 
http://bioconductor.org/checkResults/3.15/data-experiment-LATEST/rcellminerData/



Could help me with this issue?



Thanks,



Fathi



From: "Kern, Lori" 
Date: Tuesday, June 29, 2021 at 10:50 AM
To: "lu...@cbio.mskcc.org" , "Rajapakse, Vinodh (NIH/NCI) 
[C]" , "Elloumi, Fathi (NIH/NCI) [C]" 

Subject: Bioconductor package rcellminerData



Hello package maintainer,



We would like to bring to your attention that your package is failing on the 
devel builders of Bioconductor:



http://bioconductor.org/checkResults/3.14/data-experiment-LATEST/rcellminerData



Please fix your package as soon as possible. If the package remains broken for 
an extended period of time, we will deprecate the package.



The ERROR results from an update in the knitr package as announced here:

Re: [Rd] as.Date without "origin"

[Simon Urbanek]

Dan,

as.Date() and as.POSIXct() have been updated to allow replacement of the hidden 
functions .POSIXct() and .Date() which were the only way to correctly convert 
the numeric representation of the objects as Johannes explained. Given that 
this is a very common operation (especially with POSIXct) it makes sense to not 
rely on hidden functions and will allow us to possibly deprecate them. And as 
Peter pointed out, this is R-devel so manuals won't be necessarily updated 
until the full functionality is implemented and this is part of a larger 
overhaul of the date/time functions which has not been finished yet.

Cheers,
Simon



> On Nov 3, 2022, at 2:38 AM, Dan Dalthorp via R-devel  
> wrote:
> 
> I don't see a compelling rationale for changing the default behavior as.Date 
> to deviate from the wholly reasonable status quo of "as.Date will accept 
> numeric data (the number of days since an epoch), but only if origin is 
> supplied." That has been the expectation for a long, long time. 
> 
> In any case, the manual should match the behavior.
> 
> -DHD
> 
> 
> 
> 
> --- Original Message ---
> On Wednesday, November 2nd, 2022 at 6:20 AM, Spencer Graves 
>  wrote:
> 
> 
>> 
>> 
>> I've felt that "as.Date" should default to origin "1970-01-01", so I
>> added a modification to Ecfun:
>> 
>> 
>> Ecfun::as.Date1970(0)
>> 
>> 
>> If R-devel chose to change the default on this, I would happily
>> deprecate Ecfun::as.Date1970 in favor of base::as.Date ;-)
>> 
>> 
>> I would therefore support changing the documentation to match the new
>> behavior.
>> 
>> 
>> Spencer Graves
>> 
>> 
>> On 11/2/22 7:30 AM, Dan Dalthorp via R-devel wrote:
>> 
>>> The new (2022-10-11 r83083 ucrt) as.Date function returns a date rather 
>>> than an error when called without "origin" specified.
>>> 
>>> # previous versions of R
>>> as.Date(0)
>>> # Error in as.Date.numeric(0) : 'origin' must be supplied
>>> 
>>> # new:
>>> as.Date(0)
>>> # [1] "1970-01-01"
>>> 
>>> This is at odds with the help file, which gives:
>>> 
>>> origin
>>> 
>>> aDateobject, or something which can be coerced byas.Date(origin, ...)to 
>>> such an object.
>>> 
>>> And:
>>> as.Datewill accept numeric data (the number of days since an epoch), 
>>> butonlyiforiginis supplied.
>>> 
>>> The behavior described in the help file and implemented in previous 
>>> versions seems more reasonable than returning a date with an arbitrary 
>>> "origin". In any case, in the r-devel there is a mismatch between the 
>>> function and its description.
>>> 
>>> -Dan
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

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