On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
| Dear all,
|
| I have a question regarding the R-devel version of .make_numeric_version()
function. As far as I can understand, the current code
(https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/libr
Dear all,
I have a question regarding the R-devel version of .make_numeric_version()
function. As far as I can understand, the current code
(https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
runs the following steps in case of no
On 29/03/2024 11:59 a.m., Antoine Fabri wrote:
I think there are too many packages that would need changes under this
scheme.
There would be zero if the registration of options is not required for
packages first uploaded on CRAN before the feature is implemented.
If an option is not re
>
> I think there are too many packages that would need changes under this
> scheme.
There would be zero if the registration of options is not required for
packages first uploaded on CRAN before the feature is implemented.
If an option is not registered no validation is triggered and nothing
brea
On 29/03/2024 10:52 a.m., Antoine Fabri wrote:
Dear r-devel,
options() are basically global variables and they come with several issues:
* they're not really truly owned by a package aside from loose naming
conventions
* they're not validated
* their documentation is not standard, and they're of
Dear r-devel,
options() are basically global variables and they come with several issues:
* they're not really truly owned by a package aside from loose naming
conventions
* they're not validated
* their documentation is not standard, and they're often not documented at
all, it's hard to know what
