[R-pkg-devel] using @inheritParams in documenting data
Dearfriends , with your help I'm rapidly improving package development. When
documenting data, I seem to be helped mpst by making the rda directly from
RStudio via file, new file, R documentation then choosing data. However, my
data files have a lot of params, so I thought I might use @inheritParams
since these params are already documented elsewhere in the package. Hence,
in the rda file created directly from RStudio I tried to add @inheritParams
CMB (since the params are already documented in CMB) but I cannot find
exactly how to put it in the rda file.
The skeleton has
\describe{
\item{\code(x)}{vector}
And if I put some the params in a comma separated row instead of x they are
acknowledged in the final rda file -
BUT where and how to put the @inheritParams CMB I cannot find documented.
Otherwise it seems to run OK
All best wishes
Troels
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Bioc-devel] What is good convention for package-local BiocParallel param?
My current set-up in a variety of packages is that every parallelizable
function has a BPPARAM= argument. This makes it explicit about which steps are
being parallelized. Requiring users to respecify BPPARAM= in each function
isn’t as annoying as you’d think, because not many steps are actually heavy
enough to warrant parallelization.
Ideally, I'd have BPPARAM=bpparam() by default, allowing me to both respond to
the register()'d bpparam() as well as any custom argument that might be
supplied by the user, e.g., if they don't want to change bpparam(). However,
for various reasons (discussed in the other SerialParam() thread), the current
default is BPPARAM=SerialParam().
To be honest, I've never thought it necessary to have a global package-specific
parameter for parallelization as you've done (for scPipe, presumably). The
current options - global across all packages with register(), or local to
individual functions with BPPARAM= - seem to be satisfactory in the vast
majority of cases. At least to me.
And at least for RNGs, if a function from another package is giving greatly
different results upon parallelization (excepting some numerical error with
changed order of summation), I'd say that's a bug of some sort. That should be
fixed on their end, rather than requiring other packages and users to tiptoe
around them.
-A
> On 10 Jan 2019, at 23:59, Shian Su wrote:
>
> Hello Developers,
>
> I’m using BiocParallel for parallelism, and I understand that register() is
> the recommended method for setting threads. But I am reluctant to ask people
> to run code for my package which changes how other packages operate, so I
> figured I’d use local bp params. Recent discussions of RNG has made me
> worried there may be hidden state gotcha’s I’ve not considered. The current
> implementation is
>
> set_mypkg_threads <- function(n) {
> if (n == 1) {
> options(“mypkg.bpparam” = SerialParam())
> } else if (n > 1) {
> if (.Platform$OS.type == "windows") {
> options(“mypkg.bpparam" = SnowParam(nthreads))
> } else {
> options(“mypkg.bpparam" = MulticoreParam(nthreads))
> }
> }
> }
>
> Then elsewhere in my package I make use of parallelism as follows
>
> bplapply(
> BPPARAM = getOption(“mypkg.bpparam”, bpparam()),
> …
> )
>
> Where getOption() either retrieves my set option or the default value given
> by bpparam(). So the behaviour is that if users have not registered params
> for my package specifically then it will take the BiocParallel default, but
> otherwise it will use my package’s local bpparam.
>
> Also I know that as currently implemented, I preclude cluster parallelism on
> non-Windows machines. But it’s easy to fix. Just looking for feedback on the
> approach.
>
> Kind regards,
> Shian Su
>
> ___
>
> The information in this email is confidential and intended solely for the
> addressee.
> You must not disclose, forward, print or use it without the permission of the
> sender.
>
> The Walter and Eliza Hall Institute acknowledges the Wurundjeri people of the
> Kulin
> Nation as the traditional owners of the land where our campuses are located
> and
> the continuing connection to country and community.
> ___
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails
Please report. Best, Uwe Ligges On 11.01.2019 22:15, Sam Albers wrote: Oh you are totally right. And similarly, an .rds file bonks with R CMD build: $ R CMD build foo.rds * checking for file 'foo.rds/DESCRIPTION' ... OK * preparing 'foo.rds': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories Warning in gzfile(file, "rb") : cannot open compressed file 'foo.rds', probable reason 'Permission denied' Error in gzfile(file, "rb") : cannot open the connection Execution halted However this seems like a bug doesn't it? I am able to install a *.rds or *.rdata package but unable to build it. Seems like a) I should be able to install and b) these could be added to the list of unavailable package names. Asking in the context of whether this is worth reporting as a bug. Sam On Fri, Jan 11, 2019 at 12:00 PM Hong Ooi wrote: It looks like the ".rdata" in your package name is confusing R CMD BUILD into thinking there is a .rdata file involved. Consider renaming it to "bcmaps.data" or something similar. -Original Message- From: R-package-devel On Behalf Of Sam Albers Sent: Friday, 11 January, 2019 2:07 PM To: r-package-devel@r-project.org Subject: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails Hello all, I am experiencing some issues with building a package that we are hosting on GitHub. The package itself is quite large. It is a data package with a bunch of spatial files stored as .rds files. The repo is located here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdatadata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3Dreserved=0 If we clone that package to local machine via: git clone https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdatadata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3Dreserved=0 The first oddity is that the package installs successfully using this: $ R CMD INSTALL "./bcmaps.rdata" But fails when I try to build the package: $ R CMD BUILD "./bcmaps.rdata" * checking for file './bcmaps.rdata/DESCRIPTION' ... OK * preparing 'bcmaps.rdata': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added Warning in gzfile(file, "rb") : cannot open compressed file 'bcmaps.rdata', probable reason 'Permission denied' Error in gzfile(file, "rb") : cannot open the connection Execution halted The second oddity is that if I remove the . from the Package name in the DESCRIPTION file, the build proceeds smoothly: $ R CMD build "./bcmaps.rdata" * checking for file './bcmaps.rdata/DESCRIPTION' ... OK * preparing 'bcmapsrdata': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added * building 'bcmapsrdata_0.2.0.tar.gz' I am assuming that R CMD install builds the package internally so I find it confusing that I am not able to build it myself. Similarly confusing is the lack of a . in the package name indicative of anything? Does anyone have any idea what's going on here? Am I missing something obvious? Thanks in advance, Sam __ R-package-devel@r-project.org mailing list https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=0r%2FFfRH6eYqRPLAAFLprWAttPip02VKV0GIqBOtVhI8%3Dreserved=0 __ 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] R CMD INSTALL succeeds while R CMD BUILD fails
Oh you are totally right. And similarly, an .rds file bonks with R CMD build: $ R CMD build foo.rds * checking for file 'foo.rds/DESCRIPTION' ... OK * preparing 'foo.rds': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories Warning in gzfile(file, "rb") : cannot open compressed file 'foo.rds', probable reason 'Permission denied' Error in gzfile(file, "rb") : cannot open the connection Execution halted However this seems like a bug doesn't it? I am able to install a *.rds or *.rdata package but unable to build it. Seems like a) I should be able to install and b) these could be added to the list of unavailable package names. Asking in the context of whether this is worth reporting as a bug. Sam On Fri, Jan 11, 2019 at 12:00 PM Hong Ooi wrote: > > It looks like the ".rdata" in your package name is confusing R CMD BUILD into > thinking there is a .rdata file involved. Consider renaming it to > "bcmaps.data" or something similar. > > > -Original Message- > From: R-package-devel On Behalf Of > Sam Albers > Sent: Friday, 11 January, 2019 2:07 PM > To: r-package-devel@r-project.org > Subject: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails > > Hello all, > > I am experiencing some issues with building a package that we are hosting on > GitHub. The package itself is quite large. It is a data package with a bunch > of spatial files stored as .rds files. > > The repo is located here: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdatadata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3Dreserved=0 > > If we clone that package to local machine via: > git clone > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdatadata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3Dreserved=0 > > The first oddity is that the package installs successfully using this: > > $ R CMD INSTALL "./bcmaps.rdata" > > But fails when I try to build the package: > > $ R CMD BUILD "./bcmaps.rdata" > * checking for file './bcmaps.rdata/DESCRIPTION' ... OK > * preparing 'bcmaps.rdata': > * checking DESCRIPTION meta-information ... OK > * checking for LF line-endings in source and make files and shell scripts > * checking for empty or unneeded directories > * looking to see if a 'data/datalist' file should be added Warning in > gzfile(file, "rb") : > cannot open compressed file 'bcmaps.rdata', probable reason 'Permission > denied' > Error in gzfile(file, "rb") : cannot open the connection Execution halted > > > The second oddity is that if I remove the . from the Package name in the > DESCRIPTION file, the build proceeds smoothly: > > $ R CMD build "./bcmaps.rdata" > * checking for file './bcmaps.rdata/DESCRIPTION' ... OK > * preparing 'bcmapsrdata': > * checking DESCRIPTION meta-information ... OK > * checking for LF line-endings in source and make files and shell scripts > * checking for empty or unneeded directories > * looking to see if a 'data/datalist' file should be added > * building 'bcmapsrdata_0.2.0.tar.gz' > > I am assuming that R CMD install builds the package internally so I find it > confusing that I am not able to build it myself. Similarly confusing is the > lack of a . in the package name indicative of anything? > > Does anyone have any idea what's going on here? Am I missing something > obvious? > > Thanks in advance, > > Sam > > __ > R-package-devel@r-project.org mailing list > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=0r%2FFfRH6eYqRPLAAFLprWAttPip02VKV0GIqBOtVhI8%3Dreserved=0 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] shadowing a method from the stats package
Hello, I created a package for working with a new probability distribution called unifed. The source code can be found at https://gitlab.com/oquijano/unifed . This distribution is suitable for GLMs. I have included a a function called unifed in the package that returns a family that can be used with the glm function. For a unifed glm, it is necessary for the dispersion parameter to be equal to one. The summary method of the glm class does this automatically for the poisson and binomial distributions and I would like the same for the unifed. In order to achieve this, I am including a summary.glm function in the package so it shadows stats::summary.glm when the package is attached. This function is actually just a wrapper around stats::summary.glm. It simply checks if the family is unifed; If this is the case it calls stats::summary.glm with dispersion=1 and otherwise it simply calls stats::summary.glm with the same parameters. Therefore introducing this in the namespace does not break or change the behavior of any existing code that uses summary.glm According to the CRAN policies I need permission from the maintainer of the package for doing this. The maintainer of the package is the R core team. To whom should I write to ask for this permission? Otherwise is there a different way in which I could achieve the right default behavior and respect the CRAN policies? Thank you for your time. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails
--- Begin Message --- It looks like the ".rdata" in your package name is confusing R CMD BUILD into thinking there is a .rdata file involved. Consider renaming it to "bcmaps.data" or something similar. -Original Message- From: R-package-devel On Behalf Of Sam Albers Sent: Friday, 11 January, 2019 2:07 PM To: r-package-devel@r-project.org Subject: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails Hello all, I am experiencing some issues with building a package that we are hosting on GitHub. The package itself is quite large. It is a data package with a bunch of spatial files stored as .rds files. The repo is located here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdatadata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3Dreserved=0 If we clone that package to local machine via: git clone https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdatadata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3Dreserved=0 The first oddity is that the package installs successfully using this: $ R CMD INSTALL "./bcmaps.rdata" But fails when I try to build the package: $ R CMD BUILD "./bcmaps.rdata" * checking for file './bcmaps.rdata/DESCRIPTION' ... OK * preparing 'bcmaps.rdata': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added Warning in gzfile(file, "rb") : cannot open compressed file 'bcmaps.rdata', probable reason 'Permission denied' Error in gzfile(file, "rb") : cannot open the connection Execution halted The second oddity is that if I remove the . from the Package name in the DESCRIPTION file, the build proceeds smoothly: $ R CMD build "./bcmaps.rdata" * checking for file './bcmaps.rdata/DESCRIPTION' ... OK * preparing 'bcmapsrdata': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added * building 'bcmapsrdata_0.2.0.tar.gz' I am assuming that R CMD install builds the package internally so I find it confusing that I am not able to build it myself. Similarly confusing is the lack of a . in the package name indicative of anything? Does anyone have any idea what's going on here? Am I missing something obvious? Thanks in advance, Sam __ R-package-devel@r-project.org mailing list https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364sdata=0r%2FFfRH6eYqRPLAAFLprWAttPip02VKV0GIqBOtVhI8%3Dreserved=0 --- End Message --- __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails
Hello all, I am experiencing some issues with building a package that we are hosting on GitHub. The package itself is quite large. It is a data package with a bunch of spatial files stored as .rds files. The repo is located here: https://github.com/bcgov/bcmaps.rdata If we clone that package to local machine via: git clone https://github.com/bcgov/bcmaps.rdata The first oddity is that the package installs successfully using this: $ R CMD INSTALL "./bcmaps.rdata" But fails when I try to build the package: $ R CMD BUILD "./bcmaps.rdata" * checking for file './bcmaps.rdata/DESCRIPTION' ... OK * preparing 'bcmaps.rdata': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added Warning in gzfile(file, "rb") : cannot open compressed file 'bcmaps.rdata', probable reason 'Permission denied' Error in gzfile(file, "rb") : cannot open the connection Execution halted The second oddity is that if I remove the . from the Package name in the DESCRIPTION file, the build proceeds smoothly: $ R CMD build "./bcmaps.rdata" * checking for file './bcmaps.rdata/DESCRIPTION' ... OK * preparing 'bcmapsrdata': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added * building 'bcmapsrdata_0.2.0.tar.gz' I am assuming that R CMD install builds the package internally so I find it confusing that I am not able to build it myself. Similarly confusing is the lack of a . in the package name indicative of anything? Does anyone have any idea what's going on here? Am I missing something obvious? Thanks in advance, Sam __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NAMESPACE importFrom("stats", "uniroot")
Thanks a lot for your help - now it is fine!
BW
Troels
-Oprindelig meddelelse-
Fra: Iñaki Ucar
Sendt: 11. januar 2019 18:37
Til: Troels Ring
Emne: Re: [R-pkg-devel] NAMESPACE importFrom("stats", "uniroot")
See an example of usage here:
https://github.com/r-simmer/simmer/blob/f75e52fe1e71c7eda594f6cd41adbbed95b05c23/R/monitor-class.R#L124
And how this is processed by roxygen2 and added to the NAMESPACE automatically:
https://github.com/r-simmer/simmer/blob/956bb03ac355052c60e5341c0d16b0dc81ee736c/NAMESPACE#L181
Iñaki
On Fri, 11 Jan 2019 at 18:30, Troels Ring wrote:
>
> Thanks a lot - I have added
> @importFrom stats uniroot
> And #' @importFrom stats uniroot in the NAMESPACE otherwise generated
> by roxygen - I can't make it work - the first is not processed and the
> next makes no difference apart from deleting the former NAMESPACE
> file. I have tried adding the lines to the r file running uniroot - I
> seem to be misunderstanding what goes on
>
> Best wishes
> Troels
>
> -Oprindelig meddelelse-
> Fra: Iñaki Ucar
> Sendt: 11. januar 2019 17:40
> Til: Troels Ring
> Cc: package-develop
> Emne: Re: [R-pkg-devel] NAMESPACE importFrom("stats", "uniroot")
>
> On Fri, 11 Jan 2019 at 17:31, Troels Ring wrote:
> >
> > Dear friends - I'm slowly learning to make packages in RStudio and
> > it seems impressive. I managed now to have my acidbase package pass
> > the check-package test with this result
> >
> >
> >
> > > checking R code for possible problems ... NOTE
> >
> > pH_general: no visible global function definition for 'uniroot'
> >
> > Undefined global functions or variables:
> >
> > uniroot
> >
> > Consider adding
> >
> > importFrom("stats", "uniroot")
> >
> > to your NAMESPACE file.
> >
> >
> >
> > 0 errors v | 0 warnings v | 1 note x
> >
> >
> >
> > R CMD check succeeded
> >
> >
> >
> > So I have much use of uniroot in the package but get this "note"
> > above and a suggestion to augment the NAMESPACE file - so even
> > though it was issuing : # Generated by roxygen2: do not edit by hand
> >
> > I of course tried adding by hand - and in the next run the NAMESPACE
> > file was quite empty and without any exports and the added import
> > while before it exported a number of functions. So I deleted this
> > unwelcome NAMESPACE and got the old one back.
> >
> > I also tried adding importFrom("stats", "uniroot") as #'
> > @importFrom("stats", "uniroot") to the r file with the routine using
> > uniroot but that didn't change the NAMESPACE or remove the note when
> > checking. It may be no big problem - but I'd like to see no notes or
> > warnings
>
> The syntax is "@importFrom stats uniroot". See roxygen2's docs:
>
> https://cran.r-project.org/web/packages/roxygen2/vignettes/namespace.h
> tml#imports
>
> If you don't use this function many many times, it is even better to use
> stats::uniroot instead.
>
> Iñaki
>
--
Iñaki Úcar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] strtoi output of empty string inconsistent across platforms
> Martin Maechler
> on Fri, 11 Jan 2019 09:44:14 +0100 writes:
> Michael Chirico
> on Fri, 11 Jan 2019 14:36:17 +0800 writes:
>> Identified as root cause of a bug in data.table:
>> https://github.com/Rdatatable/data.table/issues/3267
>> On my machine, strtoi("", base = 2L) produces NA_integer_
>> (which seems consistent with ?strtoi: "Values which
>> cannot be interpreted as integers or would overflow are
>> returned as NA_integer_").
> indeed consistent with R's documentation on strtoi().
> What machine would that be?
>> But on all the other machines I've seen, 0L is
>> returned. This seems to be consistent with the output of
>> a simple C program using the underlying strtol function
>> (see data.table link for this program, and for full
>> sessionInfo() of some environments with differing
>> output).
>> So, what is the correct output of strtoi("", base = 2L)?
>> Is the cross-platform inconsistency to be
>> expected/documentable?
> The inconsistency is certainly undesirable. The relevant
> utility function in R's source (/src/main/character.c)
> is
> static int strtoi(SEXP s, int base) { long int res; char
> *endp;
> /* strtol might return extreme values on error */
> errno = 0;
> if(s == NA_STRING) return(NA_INTEGER); res =
> strtol(CHAR(s), , base); /* ASCII */ if(errno ||
> *endp != '\0') res = NA_INTEGER; if(res > INT_MAX || res <
> INT_MIN) res = NA_INTEGER; return (int) res; }
> and so it clearly is a platform-inconsistency in the
> underlying C library's strtol().
(corrected typos here: )
> I think we should make this cross-platform consistent ...
> and indeed it makes much sense to ensure the result of
> strtoi("", base=2L)to become NA_integer_
> but chances are that would break code that has relied on
> the current behavior {on "all but your computer" ;-)} ?
I still think that such a change should be done.
'make check all' on the R source (+ Recommended packages) seems
not to signal any error or warning with such a change, so I plan
to commit that change to "the trunk" / "R-devel" soon, unless
concerns are raised highly (and quickly enough).
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] NAMESPACE importFrom("stats", "uniroot")
On Fri, 11 Jan 2019 at 17:31, Troels Ring wrote:
>
> Dear friends - I'm slowly learning to make packages in RStudio and it seems
> impressive. I managed now to have my acidbase package pass the check-package
> test with this result
>
>
>
> > checking R code for possible problems ... NOTE
>
> pH_general: no visible global function definition for 'uniroot'
>
> Undefined global functions or variables:
>
> uniroot
>
> Consider adding
>
> importFrom("stats", "uniroot")
>
> to your NAMESPACE file.
>
>
>
> 0 errors v | 0 warnings v | 1 note x
>
>
>
> R CMD check succeeded
>
>
>
> So I have much use of uniroot in the package but get this "note" above and a
> suggestion to augment the NAMESPACE file - so even though it was issuing : #
> Generated by roxygen2: do not edit by hand
>
> I of course tried adding by hand - and in the next run the NAMESPACE file
> was quite empty and without any exports and the added import while before it
> exported a number of functions. So I deleted this unwelcome NAMESPACE and
> got the old one back.
>
> I also tried adding importFrom("stats", "uniroot") as #'
> @importFrom("stats", "uniroot") to the r file with the routine using uniroot
> but that didn't change the NAMESPACE or remove the note when checking. It
> may be no big problem - but I'd like to see no notes or warnings
The syntax is "@importFrom stats uniroot". See roxygen2's docs:
https://cran.r-project.org/web/packages/roxygen2/vignettes/namespace.html#imports
If you don't use this function many many times, it is even better to
use stats::uniroot instead.
Iñaki
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] NAMESPACE importFrom("stats", "uniroot")
Dear friends - I'm slowly learning to make packages in RStudio and it seems
impressive. I managed now to have my acidbase package pass the check-package
test with this result
> checking R code for possible problems ... NOTE
pH_general: no visible global function definition for 'uniroot'
Undefined global functions or variables:
uniroot
Consider adding
importFrom("stats", "uniroot")
to your NAMESPACE file.
0 errors v | 0 warnings v | 1 note x
R CMD check succeeded
So I have much use of uniroot in the package but get this "note" above and a
suggestion to augment the NAMESPACE file - so even though it was issuing : #
Generated by roxygen2: do not edit by hand
I of course tried adding by hand - and in the next run the NAMESPACE file
was quite empty and without any exports and the added import while before it
exported a number of functions. So I deleted this unwelcome NAMESPACE and
got the old one back.
I also tried adding importFrom("stats", "uniroot") as #'
@importFrom("stats", "uniroot") to the r file with the routine using uniroot
but that didn't change the NAMESPACE or remove the note when checking. It
may be no big problem - but I'd like to see no notes or warnings
Best wishes
Troels - on Windows version 3.5.1 (2018-07-02)
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Inconsistent returned values of normalizePath(NA_character_) on Windows and *nix
Thanks for the report, fixed in R-devel (one gets NA_character_ as a result and the path is treated as non-existent, so with a warning or error when requested via mustWork argument). Best, Tomas On 12/7/18 7:10 PM, Yihui Xie wrote: Hi, I just noticed normalizePath(NA_character_) returns NA_character_ on *nix but "%HOME%\\NA" on Windows (with a warning by default), where %HOME% denotes the HOME folder like "C:\\Users\\John". I'm not sure if this is a bug or by design. Regards, Yihui -- https://yihui.name __ 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
Re: [Rd] strtoi output of empty string inconsistent across platforms
> Michael Chirico
> on Fri, 11 Jan 2019 14:36:17 +0800 writes:
> Identified as root cause of a bug in data.table:
> https://github.com/Rdatatable/data.table/issues/3267
> On my machine, strtoi("", base = 2L) produces NA_integer_
> (which seems consistent with ?strtoi: "Values which cannot
> be interpreted as integers or would overflow are returned
> as NA_integer_").
indeed consistent with R's documentation on strtoi().
What machine would that be?
> But on all the other machines I've seen, 0L is
> returned. This seems to be consistent with the output of a
> simple C program using the underlying strtol function (see
> data.table link for this program, and for full
> sessionInfo() of some environments with differing output).
> So, what is the correct output of strtoi("", base = 2L)?
> Is the cross-platform inconsistency to be
> expected/documentable?
The inconsistency is certainly undesirable.
The relevant utility function in R's source (/src/main/character.c)
is
static int strtoi(SEXP s, int base)
{
long int res;
char *endp;
/* strtol might return extreme values on error */
errno = 0;
if(s == NA_STRING) return(NA_INTEGER);
res = strtol(CHAR(s), , base); /* ASCII */
if(errno || *endp != '\0') res = NA_INTEGER;
if(res > INT_MAX || res < INT_MIN) res = NA_INTEGER;
return (int) res;
}
and so it clearly is a platform-inconsistency in the underlying C
library's strtol().
I think we should make this cross-platform consistent... and
indeed it make much sense to ensure the result of
strtoi("", base=2L) to become NA_integer_
but changes are that would break code that has relied on the
current behavior {on "all but your computer" ;-)} ?
> Michael Chirico
Thank you for the report,
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
