Hello, Tomas. At nloptr, we are struggling with the recent upgrading of non-API points from NOTES to ERRORs, given that the upstream NLOPT library uses various calls not allowed within R; please see [1]. Reading WRE, the only option we see is to manually adjust the NLOPT source code to use acceptable calls and then have those built into the various toolsets or test servers. You have much more experience with this than we do. Moreover, you are the maintainer of Rtools. Are we correct in thinking we need to replace every "exit" or stderr call with something R-acceptable and then use that as the source for the toolchains, or is there another (hopefully less onerous) option? For that matter, should this really be discussed on R-pkg-devel first? Thank you very much, Avi [1] https://github.com/astamm/nloptr/issues/198
The status of NLOPTR given NLOPT's use of non-API entry points
2 messages · Avraham Adler, Tomas Kalibera
Hi Avi,
On 3/27/25 03:12, Avraham Adler wrote:
Hello, Tomas. At nloptr, we are struggling with the recent upgrading of non-API points from NOTES to ERRORs, given that the upstream NLOPT library uses various calls not allowed within R; please see [1].
these are symbols used from external libraries, not R API. They are disallowed for various reasons, some given in the error message, e.g. "printf" writes to the standard output, but on some systems that wouldn't be visible to the user, e.g. from gui frontend.
Reading WRE, the only option we see is to manually adjust the NLOPT source code to use acceptable calls and then have those built into the various toolsets or test servers.
These checks are not very specific, they can't tell whether the functions at hand could actually get called (and that is not even possible theoretically). Still, every package should make sure that possible log messages, error messages or any other output from the library would be caught by the package and propagated to R in an "R way", so e.g. error messages turned to R errors instead of say ending up in the standard error output. If you did that, in principle I think you can explain it to the CRAN team that the warning in this case can be ignored. The downside is that this needs manual intervention. If you are bundling code where you can at build time disable say some tracing support that is not needed anyway, etc, to avoid such calls, that's better. Now, the checks as done in R? ignore such external symbols in external libraries. So, if nlopt wasn't bundled in the package, but was used from the system, you wouldn't get this check issue.
You have much more experience with this than we do. Moreover, you are the maintainer of Rtools. Are we correct in thinking we need to replace every "exit" or stderr call with something R-acceptable and then use that as the source for the toolchains, or is there another (hopefully less onerous) option?
Customizing the bundled code may not be good for maintenance, especially if you otherwise would use an unmodified version of the library. It would make sense if you were planning to change the code a lot, anyway. Maybe you could refrain from bundling the source code and require external suitable nlopt unconditionally?
For that matter, should this really be discussed on R-pkg-devel first?
Yes, I think it would be more appropriate list for this discussion. This is not Windows specific. Also you ultimately need a response from the part of the CRAN team responsible for handling source packages. Best Tomas
Thank you very much, Avi [1] https://github.com/astamm/nloptr/issues/198
_______________________________________________ R-SIG-windows mailing list R-SIG-windows at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-windows