[R-pkg-devel] Suppressing compiler warnings?
An update of a package of mine got immediately kicked off CRAN because an externally-bundled file which had not been changed for years, and which included "pragma clang system_header" to suppress warnings. The concern is fair enough. Removing that nevertheless now generates a heap of warnings which CRAN will have to wade through / grep to assess whether any are of concern. These can be easily suppressed by replacing cheap "system_header" with targeted suppression of just two classes of warnings for that bundled header file only. But I guess this is also forbidden? Should I now just leave those warnings, and rely on CRAN's grep policies to assess them? Is there any public list of what such grep policies might be? (And no, I can't adapt the code to remove the warnings, because most are "zero-as-null-pointer-constant", but the "0" is actually better than nullptr the way the code is constructed. The rest are - currently - unimportant deprecation warnings, all of one specific class.) Thanks, Mark __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suppressing compiler warnings?
On 14/08/2023 14:43, Dirk Eddelbuettel wrote: On 14 August 2023 at 11:51, Mark Padgham wrote: | An update of a package of mine got immediately kicked off CRAN because | an externally-bundled file which had not been changed for years, and | which included "pragma clang system_header" to suppress warnings. The | concern is fair enough. Removing that nevertheless now generates a heap | of warnings which CRAN will have to wade through / grep to assess | whether any are of concern. These can be easily suppressed by replacing | cheap "system_header" with targeted suppression of just two classes of | warnings for that bundled header file only. But I guess this is also | forbidden? Should I now just leave those warnings, and rely on CRAN's | grep policies to assess them? Is there any public list of what such grep | policies might be? (And no, I can't adapt the code to remove the | warnings, because most are "zero-as-null-pointer-constant", but the "0" | is actually better than nullptr the way the code is constructed. The | rest are - currently - unimportant deprecation warnings, all of one | specific class.) It is in the CRAN Repostory Policy: - Packages should not attempt to disable compiler diagnostics, nor to remove other diagnostic information such as symbols in shared objects. Per 'svn blame' it goes back to commit 4049 from Apr 2019, but a commit from Nov 2017 has 'memtion (sic!) not disabling compiler diagnostics'. FWIW I have had to do it for BH and RcppEigen for some time leading to both of them 'spamming' package users with a lot of noise. I don't particularly like that, but I also do not have too many choices here. Dirk Thanks Dirk! I've seen also that a couple of tidyverse and r-lib pkgs bundle the same header, and they also do nothing to suppress this compiler spam. But gee it would be good to have some "official" reference for what compiler warnings CRAN are likely to complain about, and which ones they'll ignore! __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
On 21/08/2023 14:34, Dirk Eddelbuettel wrote:
On 21 August 2023 at 15:16, Ivan Krylov wrote:
| On Mon, 21 Aug 2023 12:02:55 +0100
| Scott Ritchie wrote:
|
| > remotes::install_github("sritchie73/ukbnmr")
| > library(ukbnmr)
| > system.time({ remove_technical_variation(test_data) })
|
| data.tables, you say? Can you show us the NOTE message you're getting?
| It could be that your example takes too much CPU time (as opposed to
| "real", "wallclock" time) due to running too many threads started by
| data.table.
Yep, and that is a new test AFAIK.
| It's not obvious why data.table would start too many threads (it's
| supposed to honour the limits that CRAN expresses in environment
| variables), but at least it should be easy to check and discount.
It grabs all it can get which is what you want for performance (I am on a
six-core machine here):
$ R -q
> library(data.table)
data.table 1.14.8 using 6 threads (see ?getDTthreads). Latest news:
r-datatable.com
>
and it honors variables if set
$ OMP_THREAD_LIMIT=2 R -q
> library(data.table)
data.table 1.14.8 using 2 threads (see ?getDTthreads). Latest news:
r-datatable.com
>
so I presume that variable is NOT set by CRAN. It might help if it were.
Dirk
I had to update a package recently to get around this by putting
explicit 'data.table::setDTthreads(1)' in all examples, tests, and
vignettes. The incoming checks now do these CPU/elapsed tests, so you
can test by submitting, and if you're still over the ratio it will
auto-reject and tell you there. That was the only way to get my
submission to pass incoming.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] The problem with resubmitting the package to the Cran
You'll need to fix that note before resubmitting. If you can share a link to a public repository, people in this list will likely be able to help. regards, Mark On 11/8/23 17:54, Karolina Marek wrote: Hello, I have the following case. I would like to resubmit a package to the Cran - per ARMA, which was archived on 2022-05-25, as it required the archived package 'matlab'. The new version of the 'matlab' was resubmitted to the Cran on 2022-06-01. So we would like that our package will also return to the Cran. I didn't change anything significant in the code inside. However, when I try to submit the package, I receive the following NOTES: checking CRAN incoming feasibility ... NOTE * checking for non-standard things in the check directory ... NOTE Found the following files/directories: ‘PARMA21del1_ident' I don't know really what this note mean and can I put the package anyway to Cran? Best regards, Karolina [[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] cpp11 and "non-API calls to R"
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-pkg-devel] Link compiled C object to internal package file
Dear All,
I'm developing a package which primarily relies on C code that itself
has to call an external text file representing a dictionary or lookup
table. The location of this file is defined in a C macro, the file
itself packaged in "./inst/dict/" and so currently called as
"#define mylocation './dict/'". I can load the package and
all works well, yet the tests fail because the compiled object
("./src/") can not find this file **in tests only**. My
primary request would then be advice for where best to place such files
that need to be called directly by compiled objects, and how to direct
the compiled object to such files? Failing that, advice on why such
attempts at linking compiled objects to external files might fail only
during tests, yet work otherwise, would be appreciated.
Other important info: Yes, the external dictionary file **must** be
linked directly from the compiled object, not at run time. This means
that no R-based solutions can be implemented, and so the problem can
only be solved in this case through figuring out how to direct a
compiled object to connect to an additional package-internal file.
Thanks in advance,
mark
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Link compiled C object to internal package file
Yeah, but that would require completely rewriting the C code to accept a
variable for something that is used hundreds of times as a simple macro.
(Most of that C code is an old library bundled with the package, so not
my work in that regard.) It would still be enormously easier to robustly
provide a relative location within the compiled source object to direct
it to the file ... but how?
On 19/06/2019 14:10, Jeff Newmiller wrote:
What do you mean by
"call an external text file"
? Text files are data... do you want to open it and read it? Are you familiar
with the system.file() function?
On June 19, 2019 5:45:51 AM CDT, mark padgham wrote:
Dear All,
I'm developing a package which primarily relies on C code that itself
has to call an external text file representing a dictionary or lookup
table. The location of this file is defined in a C macro, the file
itself packaged in "./inst/dict/" and so currently called
as
"#define mylocation './dict/'". I can load the package and
all works well, yet the tests fail because the compiled object
("./src/") can not find this file **in tests only**. My
primary request would then be advice for where best to place such files
that need to be called directly by compiled objects, and how to direct
the compiled object to such files? Failing that, advice on why such
attempts at linking compiled objects to external files might fail only
during tests, yet work otherwise, would be appreciated.
Other important info: Yes, the external dictionary file **must** be
linked directly from the compiled object, not at run time. This means
that no R-based solutions can be implemented, and so the problem can
only be solved in this case through figuring out how to direct a
compiled object to connect to an additional package-internal file.
Thanks in advance,
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] Link compiled C object to internal package file
Dear All,
Thanks for the input - it was sufficient for me to figure out a
solution, which I'll briefly describe here for future reference. This
draws primarily on the section of Writing R Extensions quoted by Martin
Morgan below, giving rise to the idea of combining environmental
variables, and the idea of Iñaki Ucar (not posted to list) of defining
functional macros. Then it's quite simple:
1. Use system.file to set environmental variable on package load giving
full path to desired file.
2. Define macro as `#define MY_FILE_PATH getPath()`
3. Define the `getPath()` function as simply `char * getenv
("MY_FILE_PATH");`.
4. Insert `MY_FILE_PATH` macro for every desired reference to locally
packaged file.
Works perfectly! Thanks again,
mark
On 19/06/2019 17:46, Martin Morgan wrote:
Section 1.2 of 'Writing R Extensions' says
Another example is when a package installs support files that are required at
run time, and their location is substituted into an R data structure at
installation time. The names of the top-level library directory (i.e.,
specifiable via the ‘-l’ argument) and the directory of the package itself are
made available to the installation scripts via the two shell/environment
variables R_LIBRARY_DIR and R_PACKAGE_DIR. Additionally, the name of the
package (e.g. ‘survival’ or ‘MASS’) being installed is available from the
environment variable R_PACKAGE_NAME. (Currently the value of R_PACKAGE_DIR is
always ${R_LIBRARY_DIR}/${R_PACKAGE_NAME}, but this used not to be the case
when versioned installs were allowed. Its main use is in configure.win scripts
for the installation path of external software’s DLLs.) Note that the value of
R_PACKAGE_DIR may contain spaces and other shell-unfriendly characters, and so
should be quoted in makefiles and configure scripts
which sounds approximately similar to your situation and suggests using the full path
to the installed file R_PACKAGE_DIR/dict/.
It's not really clear what your two use cases are below, specifically the
unique circumstances of 'in tests only'. I would guess that a relative path
would not work, in general, because the path would be relative to the current
working directory, which of course changes, rather than relative to the path of
the shared object...
Martin Morgan
On 6/19/19, 10:46 AM, "R-package-devel on behalf of mark padgham"
wrote:
Yeah, but that would require completely rewriting the C code to accept a
variable for something that is used hundreds of times as a simple macro.
(Most of that C code is an old library bundled with the package, so not
my work in that regard.) It would still be enormously easier to robustly
provide a relative location within the compiled source object to direct
it to the file ... but how?
On 19/06/2019 14:10, Jeff Newmiller wrote:
> What do you mean by
>
> "call an external text file"
>
> ? Text files are data... do you want to open it and read it? Are you
familiar with the system.file() function?
>
>
> On June 19, 2019 5:45:51 AM CDT, mark padgham
wrote:
>> Dear All,
>>
>> I'm developing a package which primarily relies on C code that itself
>> has to call an external text file representing a dictionary or lookup
>> table. The location of this file is defined in a C macro, the file
>> itself packaged in "./inst/dict/" and so currently called
>> as
>> "#define mylocation './dict/'". I can load the package and
>> all works well, yet the tests fail because the compiled object
>> ("./src/") can not find this file **in tests only**. My
>> primary request would then be advice for where best to place such files
>> that need to be called directly by compiled objects, and how to direct
>> the compiled object to such files? Failing that, advice on why such
>> attempts at linking compiled objects to external files might fail only
>> during tests, yet work otherwise, would be appreciated.
>>
>> Other important info: Yes, the external dictionary file **must** be
>> linked directly from the compiled object, not at run time. This means
>> that no R-based solutions can be implemented, and so the problem can
>> only be solved in this case through figuring out how to direct a
>> compiled object to connect to an additional package-internal file.
>>
>> Thanks in advance,
>>
>> 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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
