Re: [R-pkg-devel] function name conflict problem
Thanks to all who responded. Correct that package ‘karon’ is the problem. The current package has a more meaningful name. ‘karon’ was the earlier name; functions have been renamed. I deleted all the old function files, though they had been Committed to GitHub. A colleague working with me wrote: I found that one of the objects in /data were loading the old 'karon' library when that data object was loaded. The old 'karon' library was then loading all of the mgcv and ellipse packages, rather than just the specific functions we are using. I have no idea why one of the data objects (used in the examples) would load the library. From: Hugh Parsonage Sent: Wednesday, February 5, 2020 12:31 AM To: sierras...@mindspring.com Cc: r-package-devel@r-project. org Subject: Re: [R-pkg-devel] function name conflict problem Package karon is the problem. Is that package in your depends or imports? Does that package use Depends? On Wed, 5 Feb 2020 at 8:24 am, mailto:sierras...@mindspring.com> > wrote: In trying to develop a package to be submitted to CRAN, when I do Install and Reload or devtools::check(), I get the warning: Warning: replacing previous import 'ellipse::pairs' by 'graphics::pairs' when loading 'karon' Warning: replacing previous import 'MVN::mvn' by 'mgcv::mvn' when loading 'karon' I need one function each from the packages ellipse and mgcv (I do not need pairs from ellipse and mvn from mgcv). To restrict to the function that I need, I have used the commands @importFrom ellipse ellipse @importFrom mgcv in.out NAMESPACE includes the lines importFrom(ellipse,ellipse) importFrom(mgcv,in.out) However, DESCRIPTION does not restrict the functions imported from ellipse and mgcv; it has Imports: MVN, MASS, scatterplot3d, rgl, mgcv, randomForest, rpart, partykit, Formula, ellipse,.. Do these warnings need to be solved before submitting to CRAN? Is it necessary to edit DESCRIPTION If so, what should be done? Is there some other potential solution? Thanks! [[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] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
On 5 February 2020 at 08:39, Brian G. Peterson wrote: | We've noticed over the past week that Winbuilder/R-Hub's 'experimental' Are you refering to winbuilder, or to rhub? | Rtools4 toolchain images for Windows are approximately 4-5x slower than | all other containers to build and check several packages we maintain. That made me curious and I just did a quick run at rhub comparing windows builds of r-devel (ie "old" toolchain) and r-devel using the new tools4. AFAICT the difference is due to more prebuilt packages coming in for the former, and more packages building from source for the latter. I used a small package with few depends---but critically with the knitr/rmarkdown stack which leads to stringi building from source building libicu first. That alone will set up back a good couple of minutes. FWIW I ended up with 4 minutes for the old tools versus 24 minutes with rtools4. But as a cross-check, I used an even smaller package with no depends. And there the time difference was neglible and both took about 3 minutes. So I would recommend to try calling rhub _on that platform_ with the added check_args="--no-manual --no-vignettes" argument so suppress vignette and manual builds and tests. I think that may help you with shorter setup times. | This affects everything, including example timings, where this | architecture is the only architecture that shows any example run-times | over 5 seconds. (including Windows under the older toolchain). | | Does CRAN expect us to optimize our code for the clearly non-performant | 'experimental' Windows toolchain? | | I'd like to send a new version of our package PerformanceAnalytics to | CRAN, but the Windows experimental toolchain is preventing a 100% clean | set of checks. I think CRAN is fairly reasonable and lenient about run-time of examples, and the local check time. Could you possibly demonstrate an actual slowdown in example timings? If there is one, I am sure Jeroen would like to know more. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
On 05.02.2020 16:42, Uwe Ligges wrote: Then this is specific to your package, I meant the new one, not the one on CRAN which is also similarly quick (less than 10% difference). Best, Uwe Ligges see the overall timings for the whole CRAN check: https://cran.r-project.org/web/checks/check_timings.html which is 2379156 sec for old and 2516120 sec for the new toolchain, i.e. roughly a 6%. Given the machines runs with very different loads it could even be the other way round. And for PerformanceAnalytics I get overall 418 sec for old and 446 sec (without vignettes each) for the new toolchain (again, load may have varied): https://cran.r-project.org/web/checks/check_results_PerformanceAnalytics.html Best, Uwe Ligges On 05.02.2020 16:32, Brian G. Peterson wrote: For every other architecture, Travis-CI and R-Hub take approximately 10-12 minutes to build and check PerformanceAnalytics. On the Windows Rtools4 experimental toolchain, the build/check on Winbuilder and R-Hub take over an hour, sometimes as much as an hour and a half. Non-trivial example timings are similarly 4-5x slower on the Windows experimental toolchain. Brian On Wed, 2020-02-05 at 14:59 +, Gábor Csárdi wrote: Can you please show some numbers? Thanks, Gabor On Wed, Feb 5, 2020 at 2:40 PM Brian G. Peterson wrote: We've noticed over the past week that Winbuilder/R-Hub's 'experimental' Rtools4 toolchain images for Windows are approximately 4-5x slower than all other containers to build and check several packages we maintain. This affects everything, including example timings, where this architecture is the only architecture that shows any example run- times over 5 seconds. (including Windows under the older toolchain). Does CRAN expect us to optimize our code for the clearly non- performant 'experimental' Windows toolchain? I'd like to send a new version of our package PerformanceAnalytics to CRAN, but the Windows experimental toolchain is preventing a 100% clean set of checks. Regards, Brian -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ 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] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
Then this is specific to your package, see the overall timings for the whole CRAN check: https://cran.r-project.org/web/checks/check_timings.html which is 2379156 sec for old and 2516120 sec for the new toolchain, i.e. roughly a 6%. Given the machines runs with very different loads it could even be the other way round. And for PerformanceAnalytics I get overall 418 sec for old and 446 sec (without vignettes each) for the new toolchain (again, load may have varied): https://cran.r-project.org/web/checks/check_results_PerformanceAnalytics.html Best, Uwe Ligges On 05.02.2020 16:32, Brian G. Peterson wrote: For every other architecture, Travis-CI and R-Hub take approximately 10-12 minutes to build and check PerformanceAnalytics. On the Windows Rtools4 experimental toolchain, the build/check on Winbuilder and R-Hub take over an hour, sometimes as much as an hour and a half. Non-trivial example timings are similarly 4-5x slower on the Windows experimental toolchain. Brian On Wed, 2020-02-05 at 14:59 +, Gábor Csárdi wrote: Can you please show some numbers? Thanks, Gabor On Wed, Feb 5, 2020 at 2:40 PM Brian G. Peterson wrote: We've noticed over the past week that Winbuilder/R-Hub's 'experimental' Rtools4 toolchain images for Windows are approximately 4-5x slower than all other containers to build and check several packages we maintain. This affects everything, including example timings, where this architecture is the only architecture that shows any example run- times over 5 seconds. (including Windows under the older toolchain). Does CRAN expect us to optimize our code for the clearly non- performant 'experimental' Windows toolchain? I'd like to send a new version of our package PerformanceAnalytics to CRAN, but the Windows experimental toolchain is preventing a 100% clean set of checks. Regards, Brian -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ 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] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
For every other architecture, Travis-CI and R-Hub take approximately 10-12 minutes to build and check PerformanceAnalytics. On the Windows Rtools4 experimental toolchain, the build/check on Winbuilder and R-Hub take over an hour, sometimes as much as an hour and a half. Non-trivial example timings are similarly 4-5x slower on the Windows experimental toolchain. Brian On Wed, 2020-02-05 at 14:59 +, Gábor Csárdi wrote: > Can you please show some numbers? > > Thanks, > Gabor > > On Wed, Feb 5, 2020 at 2:40 PM Brian G. Peterson > wrote: > > We've noticed over the past week that Winbuilder/R-Hub's > > 'experimental' > > Rtools4 toolchain images for Windows are approximately 4-5x slower > > than > > all other containers to build and check several packages we > > maintain. > > > > This affects everything, including example timings, where this > > architecture is the only architecture that shows any example run- > > times > > over 5 seconds. (including Windows under the older toolchain). > > > > Does CRAN expect us to optimize our code for the clearly non- > > performant > > 'experimental' Windows toolchain? > > > > I'd like to send a new version of our package PerformanceAnalytics > > to > > CRAN, but the Windows experimental toolchain is preventing a 100% > > clean > > set of checks. > > > > > > Regards, > > > > Brian > > > > -- > > Brian G. Peterson > > ph: +1.773.459.4973 > > im: bgpbraverock > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Conditionally use packages from Bioconductor
Thanks for the quick reply! I was a bit uncertain about this due to the CRAN check notes from this package: https://cran.r-project.org/web/checks/check_results_BiocManager.html That made me think that the reason why the packages which are not available for testing are hosted on Bioconductor. Daniel -Ursprüngliche Nachricht- Von: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] Gesendet: Mittwoch, 5. Februar 2020 16:08 An: Daniel Lüdecke ; r-package-devel@r-project.org Betreff: Re: [R-pkg-devel] Conditionally use packages from Bioconductor On 05.02.2020 16:05, Daniel Lüdecke wrote: > Dear all, > > for a package that is already published on CRAN, we plan to include a > function that relies on the M3C-package, which is on Bioconductor only. > Since this function in M3C is not essential for most other functions > of our package, we thought about adding M3C to the "Suggests" field in > the DESCRIPTION file, and from the "Writing R Extensions" page we > found that we could also add the URL to the "Additional_repositories" > field of the DESCRIPTION file (Additional_repositories: > https://bioconductor.org/packages/release/bioc/html/M3C.html). BioC is a standard repository that you do not need to delcare. Best, Uwe Ligges > Would this be the correct way to conditionally use a package from > Bioconductor in own packages? > > Best > Daniel > > > -- > > _ > > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen > Rechts; Gerichtsstand: Hamburg | www.uke.de > Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. > Dr. Uwe Koch-Gromus, Joachim Prölß, Marya Verdel > _ > > SAVE PAPER - THINK BEFORE PRINTING > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- _ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg | www.uke.de Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Marya Verdel _ SAVE PAPER - THINK BEFORE PRINTING __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Conditionally use packages from Bioconductor
On 05.02.2020 16:05, Daniel Lüdecke wrote: Dear all, for a package that is already published on CRAN, we plan to include a function that relies on the M3C-package, which is on Bioconductor only. Since this function in M3C is not essential for most other functions of our package, we thought about adding M3C to the "Suggests" field in the DESCRIPTION file, and from the "Writing R Extensions" page we found that we could also add the URL to the "Additional_repositories" field of the DESCRIPTION file (Additional_repositories: https://bioconductor.org/packages/release/bioc/html/M3C.html). BioC is a standard repository that you do not need to delcare. Best, Uwe Ligges Would this be the correct way to conditionally use a package from Bioconductor in own packages? Best Daniel -- _ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg | www.uke.de Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Marya Verdel _ SAVE PAPER - THINK BEFORE PRINTING __ 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] Conditionally use packages from Bioconductor
Dear all, for a package that is already published on CRAN, we plan to include a function that relies on the M3C-package, which is on Bioconductor only. Since this function in M3C is not essential for most other functions of our package, we thought about adding M3C to the "Suggests" field in the DESCRIPTION file, and from the "Writing R Extensions" page we found that we could also add the URL to the "Additional_repositories" field of the DESCRIPTION file (Additional_repositories: https://bioconductor.org/packages/release/bioc/html/M3C.html). Would this be the correct way to conditionally use a package from Bioconductor in own packages? Best Daniel -- _ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg | www.uke.de Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Marya Verdel _ SAVE PAPER - THINK BEFORE PRINTING __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
Can you please show some numbers? Thanks, Gabor On Wed, Feb 5, 2020 at 2:40 PM Brian G. Peterson wrote: > > We've noticed over the past week that Winbuilder/R-Hub's 'experimental' > Rtools4 toolchain images for Windows are approximately 4-5x slower than > all other containers to build and check several packages we maintain. > > This affects everything, including example timings, where this > architecture is the only architecture that shows any example run-times > over 5 seconds. (including Windows under the older toolchain). > > Does CRAN expect us to optimize our code for the clearly non-performant > 'experimental' Windows toolchain? > > I'd like to send a new version of our package PerformanceAnalytics to > CRAN, but the Windows experimental toolchain is preventing a 100% clean > set of checks. > > > Regards, > > Brian > > -- > Brian G. Peterson > ph: +1.773.459.4973 > im: bgpbraverock > > __ > 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] Winbuilder 'experimental' toolchain 4-5x slower than all other architectures
We've noticed over the past week that Winbuilder/R-Hub's 'experimental' Rtools4 toolchain images for Windows are approximately 4-5x slower than all other containers to build and check several packages we maintain. This affects everything, including example timings, where this architecture is the only architecture that shows any example run-times over 5 seconds. (including Windows under the older toolchain). Does CRAN expect us to optimize our code for the clearly non-performant 'experimental' Windows toolchain? I'd like to send a new version of our package PerformanceAnalytics to CRAN, but the Windows experimental toolchain is preventing a 100% clean set of checks. Regards, Brian -- Brian G. Peterson ph: +1.773.459.4973 im: bgpbraverock __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CXX14 not defined on Windows
On 5 February 2020 at 11:47, Ralf Stubner wrote: | On Tue, Feb 4, 2020 at 5:51 PM Guido Kraemer wrote: | > I have also set `~/.R/Makevars.win` as suggested in the manual "Writing | > R extensions", Section 1.2.5 "Using C++14 code". | | What exactly do you have in src/Makevars.win? Just the simple CXX_STD | = CXX14 or the more complex set-up from the end of section 1.2.5.. | | The rstan package is on CRAN including windows binaries and uses | C++14. In src/Makevars.win they have | | CXX_STD = CXX14 | CXX14STD = -std=c++1y | | c.f. https://github.com/stan-dev/rstan/blob/40e93534e771d8c536ddb60fc62e86a5b55596de/rstan/rstan/src/Makevars.win#L2-L3 Good catch. I think I also noticed at least one other package using C++14 with the current toolchain (xtensor) and it used eg by one other package (rray) which has an even simpler src/Makevars.win just setting CXX_STD as advised (plus tweaks to PKG_CXXFLAGS, see https://github.com/r-lib/rray/blob/master/src/Makevars.win So notwithstanding my earlier message Guido's package should work with the current Rtools. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warning: parse error in file 'Rraven-Ex.R'
On 05.02.2020 04:44, Jeff Newmiller wrote: In your examples. On February 4, 2020 5:53:08 PM PST, Marcelo Araya Salas wrote: Hi all I got this error from CRAN tests: Warning: parse error in file 'Rraven-Ex.R': '\.' is an unrecognized escape in character string starting ""\." ... Where you probably have \. and need \\. Best, Uwe Ligges However, I can't find the original file where the error is found. I have try unsuccessfully for several hours :( any suggestions on how to find it? thanks! Marcelo El mar., 4 feb. 2020 a las 8:34, Dirk Eddelbuettel () escribió: On 4 February 2020 at 08:15, Marcelo Araya Salas wrote: | I found it here: | | ftp://cran.r-project.org/incoming/archive/ | | not sure what that's suppose to mean "It's dead." It generally means you will have gotten an email with the reasoning. But whatever is in archive/ is no longer processed. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org [[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
