Re: [R-pkg-devel] OpenMP on MacOS
See https://cran.r-project.org/doc/manuals/r-release/R-exts.html#OpenMP-support for a way to enable OpenMP when it's available. If you need more detailed checks for the OpenMP support in the toolchain, you would need to use a configure script. For example, I'm using an autoconf configure script for the pense package ( https://github.com/dakep/pense-rpkg/blob/main/configure.ac) to detect if (and how) OpenMP is supported and whether the toolchain supports parts of more recent OpenMP versions. Best, David On Mon, Jun 7, 2021 at 7:52 AM Konrad Krämer via R-package-devel < r-package-devel@r-project.org> wrote: > Dear all, > I have a problem regarding OpenMP on Mac OS. Recently I submitted my > package to CRAN (https://cran.r-project.org/web/packages/paropt/index.html). > However, there seems to be a problem with 'fopenmp' on Mac OS using > clang++. I have read many forums regarding the topic. Thus, I know that > there is no support for OpenMp on Mac OS (at least using the default clang > compiler). > The error was: clang: error: unsupported option '-fopenmp' > Is it possible to detect the operating system and set according to this > the compile flags and use also a sequentiell version of the code? > Or is there a better way to cope with this problem? > Many thanks in advance for your help. > Regards, > Konrad > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- David Kepplinger, PhD https://www.dkepplinger.org [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] I changed my vignette's file name to lowercase, then realized the url was case-sensitive
According to https://www.w3.org/TR/WD-html40-970708/htmlweb.html, "URLs in general are case-sensitive", it's not only a CRAN thing. Your vignette will be shipped with the package, hence if a user has a case-insensitive file system (like macOS has by default), your workaround would not work (see also Section 1.1 in "Writing R Extensions"). In my opinion the only solution is to fix the links, or go back to the old case. There are plenty of tools around to replace all occurrences of "Introduction.html" to "introduction.html" within your package. Of course that doesn't work for all other links pointing to "Introduction.html" that float around the web… Best, David On Mon, Aug 2, 2021 at 3:21 PM Dominic Comtois wrote: > I changed my "Introduction.html" vignette's name to > "introduction.html", realizing only after the fact that CRAN's URLs > are case sensitive. > > Would the solution of adding to my package's source a new > Introduction.html file pointing to introduction.html using a http-equiv="refresh" ...> be a viable one? Or is there maybe another, > better solution? > > Thanks in advance > > Dominic Comtois, summarytools author & maintainer > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- David Kepplinger, PhD https://www.dkepplinger.org [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] NOTE about use of `:::`
Dear List, I am working on updating the pense package and refactored some of the methods. I have several functions which take the same arguments, hence I'm sending all these arguments to an internal function, called `parse_args()`. Since I want to evaluate the arguments in the caller's environment, I'm using the following code call <- match.call(expand.dots = TRUE) call[[1]] <- quote(pense:::parse_args) args <- eval.parent(call) Of course, R CMD CHECK complains about the use of `:::`, as it's almost never needed. I think the above usage would fall into that area of "almost", but I'm not sure if (a) there's a better approach and (b) the CRAN team would agree with me. I would have to test (b) by submitting and working with the CRAN team, but I wanted to ask the list first to see if I'm missing something obvious. I don't want to export the function parse_args() as it's not useful for a user, and the use is truly internal. Thanks and all the best, David [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE about use of `:::`
Thank you both for the suggestions. I would prefer a clean stack trace in case of errors as input errors are caught by this function and hence users might very well see errors emitted from it. It seems more informative to me if the error message would say "Error in .parse_args…" than "Error in new.env(…". But since this solution was suggested by both of you it is likely that CRAN too would demand this or a similar approach instead of using `:::`. I know `:::` is expansive, but the computations that follow are typically at least a few minutes so anything that takes less than a few seconds won't be noticeable. I also thought about using `...` before, but then the signature of the user-facing functions would be incomplete and IDEs won't be able to provide suggestions. Thanks for the help! -- David On Wed, Dec 14, 2022 at 7:11 PM Simon Urbanek wrote: > David, > > why not > > call[[1]] <- parse_args > > The assignment is evaluated in your namespace so that makes sure the call > is that of your function. The only downside I see is that in a stack trace > you'll see the definition instead of the name. > Or possibly > > do.call(parse_args, as.list(call[-1])) > > Cheers, > Simon > > PS: Note that ::: is expensive - it probably doesn't matter here, but > would in repeatedly called functions. > > > > On 15/12/2022, at 12:19 PM, David Kepplinger > wrote: > > > > Dear List, > > > > I am working on updating the pense package and refactored some of the > > methods. I have several functions which take the same arguments, hence > I'm > > sending all these arguments to an internal function, called > `parse_args()`. > > Since I want to evaluate the arguments in the caller's environment, I'm > > using the following code > > > > call <- match.call(expand.dots = TRUE) > > call[[1]] <- quote(pense:::parse_args) > > args <- eval.parent(call) > > > > Of course, R CMD CHECK complains about the use of `:::`, as it's almost > > never needed. I think the above usage would fall into that area of > > "almost", but I'm not sure if (a) there's a better approach and (b) the > > CRAN team would agree with me. I would have to test (b) by submitting and > > working with the CRAN team, but I wanted to ask the list first to see if > > I'm missing something obvious. I don't want to export the function > > parse_args() as it's not useful for a user, and the use is truly > internal. > > > > Thanks and all the best, > > David > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE about use of `:::`
I think I will go with the suggestion of creating a new empty environment,
adding only the argument parsing function. Moreover I will use the same
name as the user-facing function that's being invoked, i.e.,
foo <- function(...) {
call <- match.call(expand.dots = TRUE)
call[[1]] <- quote(parse_args)
envir <- new.env(parent = parent.frame())
envir$foo <- parse_args
eval(call, envir)
}
This way a trace-back shows the function the user expects, without having
to export the parsing function or duplicate the code in the user-facing
functions.
Thanks again everyone for the suggestions.
All the best,
David
On Thu, Dec 15, 2022 at 4:39 AM Duncan Murdoch
wrote:
> If you want the name of the function to appear, then you can put the
> function in an environment whose parent is where most of the evaluation
> should take place. For example,
>
> f <- function(...) {
>call <- match.call(expand.dots = TRUE)
>call[[1]] <- quote(parse_args)
>envir <- new.env(parent = parent.frame())
>envir$parse_args <- parse_args
>
>eval(call, envir)
> }
>
> parse_args <- function(...) {
>cat("args were ", names(list(...)), "\n")
>stop("Error in parse_args")
> }
>
> f(a = 1, b = 2)
> #> args were a b
> #> Error in parse_args(a = 1, b = 2): Error in parse_args
>
> Duncan Murdoch
>
>
> On 14/12/2022 8:35 p.m., David Kepplinger wrote:
> > Thank you both for the suggestions. I would prefer a clean stack trace in
> > case of errors as input errors are caught by this function and hence
> users
> > might very well see errors emitted from it. It seems more informative to
> me
> > if the error message would say "Error in .parse_args…" than "Error in
> > new.env(…". But since this solution was suggested by both of you it is
> > likely that CRAN too would demand this or a similar approach instead of
> > using `:::`. I know `:::` is expansive, but the computations that follow
> > are typically at least a few minutes so anything that takes less than a
> few
> > seconds won't be noticeable.
> >
> > I also thought about using `...` before, but then the signature of the
> > user-facing functions would be incomplete and IDEs won't be able to
> provide
> > suggestions.
> >
> > Thanks for the help!
> >
> > -- David
> >
> > On Wed, Dec 14, 2022 at 7:11 PM Simon Urbanek <
> simon.urba...@r-project.org>
> > wrote:
> >
> >> David,
> >>
> >> why not
> >>
> >> call[[1]] <- parse_args
> >>
> >> The assignment is evaluated in your namespace so that makes sure the
> call
> >> is that of your function. The only downside I see is that in a stack
> trace
> >> you'll see the definition instead of the name.
> >> Or possibly
> >>
> >> do.call(parse_args, as.list(call[-1]))
> >>
> >> Cheers,
> >> Simon
> >>
> >> PS: Note that ::: is expensive - it probably doesn't matter here, but
> >> would in repeatedly called functions.
> >>
> >>
> >>> On 15/12/2022, at 12:19 PM, David Kepplinger <
> david.kepplin...@gmail.com>
> >> wrote:
> >>>
> >>> Dear List,
> >>>
> >>> I am working on updating the pense package and refactored some of the
> >>> methods. I have several functions which take the same arguments, hence
> >> I'm
> >>> sending all these arguments to an internal function, called
> >> `parse_args()`.
> >>> Since I want to evaluate the arguments in the caller's environment, I'm
> >>> using the following code
> >>>
> >>> call <- match.call(expand.dots = TRUE)
> >>> call[[1]] <- quote(pense:::parse_args)
> >>> args <- eval.parent(call)
> >>>
> >>> Of course, R CMD CHECK complains about the use of `:::`, as it's almost
> >>> never needed. I think the above usage would fall into that area of
> >>> "almost", but I'm not sure if (a) there's a better approach and (b) the
> >>> CRAN team would agree with me. I would have to test (b) by submitting
> and
> >>> working with the CRAN team, but I wanted to ask the list first to see
> if
> >>> I'm missing something obvious. I don't want to export the function
> >>> parse_args() as it's not useful for a user, and the use is truly
> >> internal.
> >>>
> >>> Thanks and all the best,
> >>> David
> >>>
> >>>[[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >>
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN incoming checks fail due to non-staged installation
Dear Community, I am trying to update the pense package on CRAN to fix `autoreconf` problems, but the incoming checks fail for Windows (r-devel) with 2 NOTEs. The first NOTE is a HTTP 403 for a http://doi.org URL which I already know about and can not change, but the other NOTE is more obscure to me. It says * checking whether package 'pense' can be installed ... NOTE Found the following notes/warnings: Non-staged installation was used and when I check the install log, it says install for i386 * installing *source* package 'pense' ... ** using staged installation [] install for x64 * installing *source* package 'pense' ... ** using non-staged installation [...] Is this a false positive or is there something I can do to force using a staged installation for both architectures on Windows? Best, David [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation
Thank you, Max, for the clarification. I have added the option "StagedInstall: yes" to the DESCRIPTION file, but it doesn't seem to be forcing a staged installation for x64 on Windows. I get the same NOTE now from winbuilder, but with more explanation which could help isolate the problem: install for i386 * installing *source* package 'pense' ... ** using staged installation [...] install for x64 * installing *source* package 'pense' ... not using staged install with --libs-only ** using non-staged installation [...] Best, David On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon < maxime.turg...@mail.mcgill.ca> wrote: > Hi David, > > Non-staged installation is something new in R-devel: > https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html > > > Package maintainers can opt out of it (through DESCRIPTION), and I'm > assuming CRAN wants a quick way to know if that was the case when > diagnosing a submission. > > To resolutely opt *in* (which will eventually be the default), you could > try adding "StagedInstall: yes" to your DESCRIPTION file. > > Of course, one question still remains: why was the behaviour different for > the two architectures. > > Max > -- > *From:* R-package-devel on behalf > of David Kepplinger > *Sent:* March 13, 2019 3:39 PM > *To:* r-package-devel@r-project.org > *Subject:* [R-pkg-devel] CRAN incoming checks fail due to non-staged > installation > > Dear Community, > > I am trying to update the pense package on CRAN to fix `autoreconf` > problems, but the incoming checks fail for Windows (r-devel) with 2 NOTEs. > > The first NOTE is a HTTP 403 for a http://doi.org URL which I already know > about and can not change, but the other NOTE is more obscure to me. It says > > * checking whether package 'pense' can be installed ... NOTE > Found the following notes/warnings: > Non-staged installation was used > > > and when I check the install log, it says > > install for i386 > * installing *source* package 'pense' ... > ** using staged installation > [] > install for x64 > * installing *source* package 'pense' ... > ** using non-staged installation > [...] > > > Is this a false positive or is there something I can do to force using a > staged installation for both architectures on Windows? > > Best, > David > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation
Dear Community, The issue persists and I don't know if it is something I can fix or if it's a false positive from the CRAN incoming checks. As a result, the package is archived as the old version has other issues with the new R version. Does someone have an idea how I can fix the issue? I have asked the CRAN team last week to flag the issue as a false positive, but I haven't heard back so I assume it's something I have to fix. Thanks, David On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger wrote: > Thank you, Max, for the clarification. > I have added the option "StagedInstall: yes" to the DESCRIPTION file, but > it doesn't seem to be forcing a staged installation for x64 on Windows. I > get the same NOTE now from winbuilder, but with more explanation which > could help isolate the problem: > > install for i386 > * installing *source* package 'pense' ... > ** using staged installation > [...] > install for x64 > * installing *source* package 'pense' ... > not using staged install with --libs-only > ** using non-staged installation > [...] > > > Best, > David > > On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon < > maxime.turg...@mail.mcgill.ca> wrote: > >> Hi David, >> >> Non-staged installation is something new in R-devel: >> https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html >> >> >> Package maintainers can opt out of it (through DESCRIPTION), and I'm >> assuming CRAN wants a quick way to know if that was the case when >> diagnosing a submission. >> >> To resolutely opt *in* (which will eventually be the default), you could >> try adding "StagedInstall: yes" to your DESCRIPTION file. >> >> Of course, one question still remains: why was the behaviour different >> for the two architectures. >> >> Max >> -- >> *From:* R-package-devel on >> behalf of David Kepplinger >> *Sent:* March 13, 2019 3:39 PM >> *To:* r-package-devel@r-project.org >> *Subject:* [R-pkg-devel] CRAN incoming checks fail due to non-staged >> installation >> >> Dear Community, >> >> I am trying to update the pense package on CRAN to fix `autoreconf` >> problems, but the incoming checks fail for Windows (r-devel) with 2 NOTEs. >> >> The first NOTE is a HTTP 403 for a http://doi.org URL which I already >> know >> about and can not change, but the other NOTE is more obscure to me. It >> says >> >> * checking whether package 'pense' can be installed ... NOTE >> Found the following notes/warnings: >> Non-staged installation was used >> >> >> and when I check the install log, it says >> >> install for i386 >> * installing *source* package 'pense' ... >> ** using staged installation >> [] >> install for x64 >> * installing *source* package 'pense' ... >> ** using non-staged installation >> [...] >> >> >> Is this a false positive or is there something I can do to force using a >> staged installation for both architectures on Windows? >> >> Best, >> David >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation
Dear Gábor, Oddly, it does emit a NOTE due to the non-staged install, as can be seen at https://win-builder.r-project.org/86i67mqTD9YY The package source can be found at https://github.com/dakep/pense-rpkg/tree/release/1.2.2 Thanks for your help, David On Tue, Mar 26, 2019, 3:28 AM Gábor Csárdi, wrote: > Hi David, > > if you only see > > install for i386 > * installing *source* package 'pense' ... > ** using staged installation > [] > install for x64 > * installing *source* package 'pense' ... > ** using non-staged installation > [...] > > then everything is fine, there is no NOTE here, AFAICT. > > If you see a NOTE about this, please post 1) a link to your package, > and 2) a link to the win-builder output. > > Thanks, > Gabor > > On Tue, Mar 26, 2019 at 12:13 AM David Kepplinger > wrote: > > > > Dear Community, > > > > The issue persists and I don't know if it is something I can fix or if > it's > > a false positive from the CRAN incoming checks. As a result, the package > is > > archived as the old version has other issues with the new R version. > > > > Does someone have an idea how I can fix the issue? I have asked the CRAN > > team last week to flag the issue as a false positive, but I haven't heard > > back so I assume it's something I have to fix. > > > > Thanks, > > David > > > > On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger < > david.kepplin...@gmail.com> > > wrote: > > > > > Thank you, Max, for the clarification. > > > I have added the option "StagedInstall: yes" to the DESCRIPTION file, > but > > > it doesn't seem to be forcing a staged installation for x64 on > Windows. I > > > get the same NOTE now from winbuilder, but with more explanation which > > > could help isolate the problem: > > > > > > install for i386 > > > * installing *source* package 'pense' ... > > > ** using staged installation > > > [...] > > > install for x64 > > > * installing *source* package 'pense' ... > > > not using staged install with --libs-only > > > ** using non-staged installation > > > [...] > > > > > > > > > Best, > > > David > > > > > > On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon < > > > maxime.turg...@mail.mcgill.ca> wrote: > > > > > >> Hi David, > > >> > > >> Non-staged installation is something new in R-devel: > > >> > https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html > > >> > > >> > > >> Package maintainers can opt out of it (through DESCRIPTION), and I'm > > >> assuming CRAN wants a quick way to know if that was the case when > > >> diagnosing a submission. > > >> > > >> To resolutely opt *in* (which will eventually be the default), you > could > > >> try adding "StagedInstall: yes" to your DESCRIPTION file. > > >> > > >> Of course, one question still remains: why was the behaviour different > > >> for the two architectures. > > >> > > >> Max > > >> -- > > >> *From:* R-package-devel on > > >> behalf of David Kepplinger > > >> *Sent:* March 13, 2019 3:39 PM > > >> *To:* r-package-devel@r-project.org > > >> *Subject:* [R-pkg-devel] CRAN incoming checks fail due to non-staged > > >> installation > > >> > > >> Dear Community, > > >> > > >> I am trying to update the pense package on CRAN to fix `autoreconf` > > >> problems, but the incoming checks fail for Windows (r-devel) with 2 > NOTEs. > > >> > > >> The first NOTE is a HTTP 403 for a http://doi.org URL which I already > > >> know > > >> about and can not change, but the other NOTE is more obscure to me. It > > >> says > > >> > > >> * checking whether package 'pense' can be installed ... NOTE > > >> Found the following notes/warnings: > > >> Non-staged installation was used > > >> > > >> > > >> and when I check the install log, it says > > >> > > >> install for i386 > > >> * installing *source* package 'pense' ... > > >> ** using staged installation > > >> [] > > >> install for x64 > > >> * installing *source* package 'pense' ... > > >> ** using non-staged installation > > >> [...] > > >> > > >> > > >> Is this a false positive or is there something I can do to force > using a > > >> staged installation for both architectures on Windows? > > >> > > >> Best, > > >> David > > >> > > >> [[alternative HTML version deleted]] > > >> > > >> __ > > >> R-package-devel@r-project.org mailing list > > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > >> > > > > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation
Thanks, Gábor, for taking the time to investigate the issue and the detailed elaboration! I resubmitted to CRAN with a brief explanation and a link to this thread. Thanks, David On Tue, Mar 26, 2019 at 2:55 PM Gábor Csárdi wrote: > OK, here is what I think is going on. > > There is a bug in the check code, that creates a false positive when > the package installation is performed with `--merge-multiarch`. In > this case the x64 architecture uses a non-staged install, > deliberately, but the check code still picks this up and reports it as > a NOTE. > > Reproducing it is not easy, because of several reasons: > - win-builder uses package-specific configuration, in this case your > package is listed in > > https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Uwe/make/config/MergeMultiarch > , > so `--merge-multiarch` is added automatically. > - R CMD check cannot pass --merge-multiarch to R CMD INSTALL because > --merge-multiarch only works on tarballs, and R CMD check runs INSTALL > on a directory. > - However, R CMD check has an undocumented --install=... option, which > can be used to pick up the installation output from a certain file. I > am pretty sure that win-builder uses this. I.e. it calls R CMD INSTALL > first, putting the output to a file, and then calls R CMD check with > the --install= option pointing to that file as the install output. > > In summary, I think this an R CMD check bug, added in this commit: > > https://github.com/wch/r-source/commit/44e8faeb1ed30a7603e79988639da7e4e358d497 > > It can be fixed easily by using a slightly different message for the > --merge-multiarch case, or maybe even by not specifying > --no-staged-install here: > > https://github.com/wch/r-source/blob/be469e86046389a0213f22e8b5c7b3227558bb01/src/library/tools/R/install.R#L1913 > and here: > > https://github.com/wch/r-source/blob/be469e86046389a0213f22e8b5c7b3227558bb01/src/library/tools/R/install.R#L1938 > because --libs-only implies --no-staged-install anyway. I am not > entirely certain, but Tomas and/or Prof Ripley will know for sure. > > If you want submit your package before the bug is fixed, I suggest you > explain this directly to CRAN when you submit your package. > > Best, > Gabor > > On Tue, Mar 26, 2019 at 3:18 PM David Kepplinger > wrote: > > > > Dear Gábor, > > > > Oddly, it does emit a NOTE due to the non-staged install, as can be seen > at https://win-builder.r-project.org/86i67mqTD9YY > > > > The package source can be found at > https://github.com/dakep/pense-rpkg/tree/release/1.2.2 > > > > Thanks for your help, > > David > > > > > > On Tue, Mar 26, 2019, 3:28 AM Gábor Csárdi, > wrote: > >> > >> Hi David, > >> > >> if you only see > >> > >> install for i386 > >> * installing *source* package 'pense' ... > >> ** using staged installation > >> [] > >> install for x64 > >> * installing *source* package 'pense' ... > >> ** using non-staged installation > >> [...] > >> > >> then everything is fine, there is no NOTE here, AFAICT. > >> > >> If you see a NOTE about this, please post 1) a link to your package, > >> and 2) a link to the win-builder output. > >> > >> Thanks, > >> Gabor > >> > >> On Tue, Mar 26, 2019 at 12:13 AM David Kepplinger > >> wrote: > >> > > >> > Dear Community, > >> > > >> > The issue persists and I don't know if it is something I can fix or > if it's > >> > a false positive from the CRAN incoming checks. As a result, the > package is > >> > archived as the old version has other issues with the new R version. > >> > > >> > Does someone have an idea how I can fix the issue? I have asked the > CRAN > >> > team last week to flag the issue as a false positive, but I haven't > heard > >> > back so I assume it's something I have to fix. > >> > > >> > Thanks, > >> > David > >> > > >> > On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger < > david.kepplin...@gmail.com> > >> > wrote: > >> > > >> > > Thank you, Max, for the clarification. > >> > > I have added the option "StagedInstall: yes" to the DESCRIPTION > file, but > >> > > it doesn't seem to be forcing a staged installation for x64 on > Windows. I > >> > > get the same NOTE now from winbuilder, but with more explanation > which > >> > > coul
[R-pkg-devel] CRAN Submission Stalled
Dear Community, I am in the process of submitting an update for my package (https://cran.r-project.org/package=pense), but it does not pass the incoming checks. After discussion on this list (thread "CRAN incoming checks fail due to non-staged installation"), I am fairly certain the issue is a false positive, which I also told the CRAN team in the reply to the rejection (to cran-submissi...@r-project.org). I haven't heard back from the CRAN team since over a week and I wanted to double check if I have to take other steps (other than just replying to the automated message) or if I simply have to be more patient. I am concerned because the old release of the package did not pass the CRAN checks for R-devel anymore, but the submission for the updated version has been taking longer than expected and the package is now archived on CRAN. I have been given 2 weeks to fix the problems, but the submission process is already taking 3 weeks. Thanks, David __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN incoming checks email
Dear List-Members: The email from the automatic incoming checks says to "reply-all" in case one suspects a false-positive, yet the reply-to header is set only to " cran-submissi...@r-project.org". My email program (just as myself) interprets this as "reply-all means replying only to cran-submissi...@r-project.org". The wording in the email, on the other hand, suggests I also should reply to Uwe Ligges. I find the current disagreement of wording and email headers more than confusing. Can someone clarify the correct protocol of replying to the email? I wouldn't want to unnecessarily bother Uwe Ligges with even more emails. Thanks, David [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster
Dear list members, I submitted an update for my package and got automatically rejected by the incoming checks (as expected from my own checks) for using `:::` calls to access the package's namespace. "There are ::: calls to the package's namespace in its code. A package *almost* never needs to use ::: for its own objects:…" (emphasis mine) This was a conscious decision on my part as the package runs code on a user-supplied parallel cluster and I consider cluster-exporting the required functions a no-go as it would potentially overwrite objects in the clusters R sessions. The package code does not own the cluster and hence the R sessions. Therefore overwriting objects could potentially lead to unintended behaviour which is opaque to the user and difficult to debug. Another solution to circumvent the R CMD check note is to export the functions to the public namespace but mark them as internal. This was also suggested in another thread on this mailing list (c.f. "Etiquette for package submissions that do not automatically pass checks?"). I do not agree with this work-around as the methods are indeed internal and should never be used by users. Exporting truly internal functions for the sake of satisfying R CMD check is a bad argument, in particular if there is a clean, well-documented, solution by using `:::`. I argue `:::` is the only clean solution to this problem and no dirty work-arounds are necessary. This is a prime example of where `:::` is actually useful and needed inside a package. If the R community disagrees, I think R CMD check should at least emit a WARNING instead of a NOTE and elaborate on the problem and accepted work-arounds in "Writing R extensions". Or keep emitting a NOTE but listing those nebulous reasons where `:::` would be tolerated inside a package. Having more transparent criteria for submitting to CRAN would be really helpful to the entire R community and probably also reduce the traffic on this mailing list. Best, David [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster
Thank you all for the discussion and suggestions.
so making a package function baz available makes all functions in the
> package available -- a function in the package already has access to other
> functions in the namespace, whether those functions are exported or not, so
> there is no need to use :::.
>
Thanks, Martin. I completely missed that the parallel package serializes
the entire environment of the function, including the package namespace and
so `:::` is indeed unnecessary in my use case. I probably experimented in
the global environment first and extrapolated the observed behaviour to the
package. Sorry for annoying everyone with this.
I also have another use of `:::` for which I am not sure if it's considered
disallowed use of `:::`, so I'm throwing it out there for feedback.
I have one internal function which checks a long list of common arguments
to several other functions, similar to
internal_check_args <- function (sd = 2, type = c("bootstrap",
"theoretical"), ...) {
# check arguments for valid ranges, etc.
return(list(sd = sd, type = match.arg(type))
}
And several functions which use the internal function for argument checking
and such, similar to
exported_foo <- function (x, sd = 2, type = c("bootstrap", "theoretical")) {
args_call <- match.call()
args_call[[1]] <- quote(mypackage:::internal_check_args)
args <- eval.parent(args_call)
}
exported_foo_cv <- function (x, cv_folds = 3, ...) {
args_call <- match.call(expand.dots = TRUE)
args_call[[1]] <- quote(mypackage:::internal_check_args)
args <- eval.parent(args_call)
}
This is modelled after what, e.g., `lm()` does with `model.frame()`, only
that `internal_check_args()` is not exported, hence I use `:::`. There are
other solutions for this type of use of `:::` (probably some considered
cleaner) but again without guidelines on when `:::` is acceptable it's
difficult for package maintainers to know when to use/not use it. From all
the discussions it seems that there is absolutely no acceptable use of
`:::` and work-arounds are always the better alternative.
In light of the other interesting points brought up by discussants, I also
want to honor their time and reply here.
You may argue that you prefer pkg:::foo for some reason: to which I'd
> respond that you are being rude to the CRAN volunteers. I've offered
> two options (one in the previous thread, a different one here), and
> there was a third one in that thread offered by Ivan Krylov. Surely one
> of these is good enough for your needs, and you shouldn't force CRAN to
> handle you specially.
>
I am sorry it came across rude when I tried to solicit arguments for why
the use of `:::` is considered "bad practice", while work-arounds are
considered to be okay. I wouldn't force CRAN to handle my case specially; I
rather wanted to challenge the general "attitude" towards the use of `:::`.
I am sure there is a need to discourage the use of `:::` in packages as
CRAN volunteers probably have seen hundreds of cases where `:::` was abused
(such as mine, as Martin Morgan pointed out).
you can use
>
> get("internal_function", asNamespace("mypackage"))(arg1, arg2)
>
> In fact, if you look at the source code of `:::`, that's exactly how
> it is implemented:
>
That would be a work-around I would have used if necessary. But my general
question remains: why should I reinvent the wheel when R already comes with
`:::`? The only advantage of all the work-arounds I've seen would be to
trick R CMD check that the code is okay, when in fact the same "bad
practice" is practiced.
Best,
David
On Sun, Sep 13, 2020 at 3:04 PM Martin Morgan
wrote:
> At least in the 'parallel' package
>
> library(parallel)
> cl = makePSOCKcluster(2)
>
> and because of the nature of the R language, the entire namespace is
> exported, analogous to
>
> baz <- local({
> foo <- function() 2
> function(...) foo()
> })
>
> so making a package function baz available makes all functions in the
> package available -- a function in the package already has access to other
> functions in the namespace, whether those functions are exported or not, so
> there is no need to use :::.
>
> > parSapply(1:2, baz)
> [1] 2 2
>
> This is in contrast to what one might expect from exploring things on the
> command line, where foo is defined in the global environment and, by
> convention, the global environment is not serialized to the workers
>
> > foo <- function() 1
> > bar <- function(...) foo()
> > parLapply(cl, 1:2, bar)
> Error in checkForRemoteErrors(val) :
> 2 nodes produced errors; first error: could not find function "foo"
>
> Do you really need to use `::
Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster
Yes, my view is certainly rigid and I agree that in the cases where the
function is actually used directly by the user, exporting it is the correct
step.
However, it seems some packages actually need to access internal functions
from an outside context, but the code that accesses the function is
logically contained completely inside the package. In these cases, package
maintainers seem to be looking for alternatives to `:::` for the sake of
avoiding the R CMD check note. I argue that the work arounds, however,
either (a) achieve the exact same result as `:::`, but in a less
transparent and likely more error prone way, or (b) unnecessarily making an
internal function available to the user.
I also agree with the CRAN team that package maintainers need to be made
aware of the issue when using `:::` inside their package as it is most
likely unnecessary. But the phrasing of the note ("almost never needs to
use :::") combined with a lack of transparent guidelines on when it is
acceptable leads to maintainers looking for alternatives mimicking the
behavior of `:::`. I haven't found any official instructions in Writing R
extensions or on the mailing list under what circumstances `:::` is deemed
to be acceptable by the CRAN team (I have to admit searching for `:::` in
the archives yields so many results I haven't looked at all of them). It's
probably impossible to conceive every possible use case for `:::`, but a
good start may be to have something in the documentation explicitly
mentioning commonly observed patterns where `:::` is not acceptable, and
the common exceptions to the rule (if there are any).
Maybe this issue is so miniscule and almost never comes up that it's not
worth mentioning in the documentation.
Best,
David
On Mon, Sep 14, 2020 at 3:19 AM Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:
> You may have a case to argue to CRAN that you can get the "almost"
> exemption (can't say without details) but your views look overly rigid.
>
> Exporting an object and marking it as internal is not a "work around",
> even less a "dirty trick".
> Export makes the object available outside the package's namespace and
> makes it clear that this is intentional.
> If you can't drop the 'package:::' prefix in your use case, this means
> that this is what you actually do (i.e. use those objects outside the
> namespace of the package). I would be grateful to CRAN for asking me to
> export and hence document this.
>
>
> Georgi Boshnakov
>
> PS Note that there is no such thing as "public namespace".
>
>
> -Original Message-
> From: R-package-devel On Behalf
> Of David Kepplinger
> Sent: 13 September 2020 20:52
> To: R Package Devel
> Subject: [R-pkg-devel] Use of `:::` in a package for code run in a
> parallel cluster
>
> Dear list members,
>
> I submitted an update for my package and got automatically rejected by the
> incoming checks (as expected from my own checks) for using `:::` calls to
> access the package's namespace.
> "There are ::: calls to the package's namespace in its code. A package
> *almost* never needs to use ::: for its own objects:…" (emphasis mine)
>
> This was a conscious decision on my part as the package runs code on a
> user-supplied parallel cluster and I consider cluster-exporting the
> required functions a no-go as it would potentially overwrite objects in the
> clusters R sessions. The package code does not own the cluster and hence
> the R sessions. Therefore overwriting objects could potentially lead to
> unintended behaviour which is opaque to the user and difficult to debug.
>
> Another solution to circumvent the R CMD check note is to export the
> functions to the public namespace but mark them as internal. This was also
> suggested in another thread on this mailing list (c.f. "Etiquette for
> package submissions that do not automatically pass checks?"). I do not
> agree with this work-around as the methods are indeed internal and should
> never be used by users. Exporting truly internal functions for the sake of
> satisfying R CMD check is a bad argument, in particular if there is a
> clean, well-documented, solution by using `:::`.
>
> I argue `:::` is the only clean solution to this problem and no dirty
> work-arounds are necessary. This is a prime example of where `:::` is
> actually useful and needed inside a package. If the R community disagrees,
> I think R CMD check should at least emit a WARNING instead of a NOTE and
> elaborate on the problem and accepted work-arounds in "Writing R
> extensions". Or keep emitting a NOTE but listing those nebulous reasons
> where `:::` would be tolerated inside a package. Having more transparent
>
Re: [R-pkg-devel] Dependency needs to be loaded manually even its specified in the package
Hi Núria, I've never used qmap, but looking at the source code it seems it's not using S3 or S4 methods in `doQmap()` but is looking for the proper method using `exists()`. Given that your package doesn't import the required function, it's not found by `exists()` and the `doQmap()` function complains. I think the only way around it is to declare the qmap package in the Depends field, rather than the Imports field. Best, David On Fri, Sep 18, 2020 at 9:39 AM Nuria Perez-Zanon wrote: > Dear all, > > I am maintaining a package call CSTools which is aimed for > post-processing climate simulations. > > The package is already published on CRAN with all dependencies correctly > state in DESCRIPTION, NAMESPACE and roxygen2 headers. > > However, when using one specific function which depends on 'qmap' > package, I should loaded both packages by executing: > > library(CSTools) > library(qmap) > > In case I don't load the second library, I get the error > > Error in doQmap(x = sample_cor, fobj = adjust, ...) : >doQmap not defined for class(fobj) ==fitQmapQUANT > > Has anyone an idea for needing to manually load a dependency? I provide > a code below if someone wants to test it. > > Thanks in advace, > > Núria > > P.S.: Here is the code: library(CSTools) exp <- lonlat_data$exp > obs <- lonlat_data$obs > res <- CST_QuantileMapping(exp, obs) > > > > http://bsc.es/disclaimer > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] warning: binary constants are a C++14 feature or GCC extension
Dear Dan,
As the warning says, the binary notation you use is only valid with
C++14 and onwards. You can either add SystemRequirements: C++14 to
your DESCRIPTION file, or use decimal (or hex) notation.
In my opinion it's even better to name your constants to convey their
meaning to the reader of the code. Then it wouldn't be a big issue if
you use binary, decimal, or hex notation.
Best,
David
On Sat, Nov 21, 2020 at 4:59 PM Dan Zigmond wrote:
>
> Hi, all. In re-submitting a package to CRAN, I'm getting the following
> warnings in the Debian pre-test:
>
> Found the following significant warnings:
> sort.cpp:12:28: warning: binary constants are a C++14 feature or GCC
> extension
> sort.cpp:12:43: warning: binary constants are a C++14 feature or GCC
> extension
>
> I added some C++ code to speed up the package and the warnings refer to
> this line of C++:
>
>while ((s[p + length] & 0b1100) == 0b1000) {
>
> The line has to do with parsing UTF-8 strings by figuring out how many
> bytes are used in each character. Is the 0b... notation not allowed in
> CRAN? I could substitute decimal constants, but that will be a bit more
> obtuse. The other platforms seems to allow this; only the Debian check
> failed.
>
> Dan
>
> .
> --
> Dan Zigmond
> d...@shmonk.com
>
> [[alternative HTML version deleted]]
>
> ______
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
David Kepplinger, PhD
https://www.dkepplinger.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to get rid of R CMD check warning/note for new S4 classes
Dear Sabastien,
Your second approach is correct, but as the warning suggests, you have to
document the S4 class "character or NULL". The documentation at
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Documenting-S4-classes-and-methods
should get you started.
Best,
David
On Tue, Feb 9, 2021 at 6:54 PM Sebastien Bihorel <
sebastien.biho...@cognigencorp.com> wrote:
> Hi
>
> I posted the following message on Jan 2nd and got no response... Assuming
> that my timing was off (everybody was probably still on vacation or
> recovering from New Year's celebration), I am taking the liberty to post it
> again, hoping that I'll reach a larger audience today.
>
> --
>
> I am creating a few S4 classes for a package. These classes include slots
> set to classes obtained using setClassUnion (some common across the new S4
> classes). The code is functional but `R CMD check` keeps on reporting notes
> or warnings whatever I try. I am pulling my hair on this one and would
> really appreciate some insight on what I am doing wrong.
>
>
> Below are some simplified versions of a real function, which each gives
> different note/warning:
>
> * Option 1 returns a note
>
> createyNewClass <- function(){
> setClassUnion("character or NULL",c("character","NULL"),where =
> .GlobalEnv)
> setClass('newS4Classe',
> where = .GlobalEnv,
> slots = c(type = 'character or NULL'),
> prototype = list(type = NULL)
> )
> }
>
> R CMD check
> ...
> * checking whether the namespace can be loaded with stated dependencies
> ... NOTE
> Warning: class "NULL" is defined (with package slot "methods") but no
> metadata object found to revise superClass information---not exported?
> Making a copy in package ".GlobalEnv"
> Warning: class "character" is defined (with package slot "methods") but no
> metadata object found to revise superClass information---not exported?
> Making a copy in package ".GlobalEnv"
> ...
>
> * Option 2: returns a WARNING
>
> createyNewClass <- function(){
> setClassUnion("character or NULL",c("character","NULL"))
> setClass('newS4Classe',
> slots = c(type = 'character or NULL'),
> prototype = list(type = NULL)
> )
> }
>
> R CMD check:
> ...
> * checking for missing documentation entries ... WARNING
> Undocumented S4 classes:
>"character or numeric"
> All user-level objects in a package (including S4 classes and methods)
> should have documentation entries.
> ...
>
> Bit of information: I am running the R CMD check with R 3.6.1 (sorry, I
> cannot update on my corporate machine :( )
>
> Thanks in advance for your help
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
David Kepplinger, PhD
https://www.dkepplinger.org
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
