Re: [R-pkg-devel] dates in NEWS.Rd headers are ignored
On 29.08.2022 11:01, Adelchi Azzalini wrote: Hi. In the last version of package ’sn’ (v. 2.1.0) the old NEWS text file has been converted to inst/NEWS.Rd. The headers in this file are of the form \section{Changes in sn version 2.1.0 (2022-07-30)} \section{Changes in sn version 2.0.2 (2022-03-07)} and so on However, when I now look at the package documentation in the HTML rendering, the “NEWS in packages ’sn’” does NOT display the dates! Details on the session are reported below, in case they are relevant. Can anyone explain how show these dates? In an interacticve session news(package="sn") open a web page in some web browser and the html code does not contain the dates, but the text form does: print(news(package="sn"), doBrowse=FALSE) To analyzse more precisely, we can directly look at the database if the format was read correctly: db <- news(package="sn") str(db) db$Date and all dates were read correctly. Best, Uwe Ligges --- Adelchi Azzalini http://azzalini.stat.unipd.it R> sessionInfo() R version 4.2.1 (2022-06-23) Platform: aarch64-apple-darwin20 (64-bit) Running under: macOS Monterey 12.5.1 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib Random number generation: RNG: Mersenne-Twister Normal: Inversion Sample: Rounding locale: [1] en_US.UTF-8/UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] grid stats4stats utils datasets grDevices graphics methods base other attached packages: [1] gtable_0.3.0 ggplot2_3.3.6 sn_2.1.0 loaded via a namespace (and not attached): [1] Rcpp_1.0.8.3highr_0.9 pillar_1.7.0compiler_4.2.1 [5] tools_4.2.1 digest_0.6.29 evaluate_0.15 lifecycle_1.0.1 [9] tibble_3.1.7lattice_0.20-45 pkgconfig_2.0.3 rlang_1.0.2 [13] Matrix_1.4-1cli_3.3.0 xfun_0.31 stringr_1.4.0 [17] withr_2.5.0 dplyr_1.0.9 knitr_1.39 generics_0.1.2 [21] vctrs_0.4.1 isoband_0.2.5 tidyselect_1.1.2glue_1.6.2 [25] R6_2.5.1fansi_1.0.3 purrr_0.3.4 farver_2.1.0 [29] magrittr_2.0.3 scales_1.2.0ellipsis_0.3.2 mnormt_2.1.0 [33] colorspace_2.0-3numDeriv_2016.8-1.1 labeling_0.4.2 utf8_1.2.2 [37] stringi_1.7.6 munsell_0.5.0 crayon_1.5.1 R> __ 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] dates in NEWS.Rd headers are ignored
On 29.08.2022 13:06, Adelchi Azzalini wrote: Thanks, Uwe. What you write illustrates in greater detail the state of affairs, but from here I cannot see a way of sorting out the problem, which is as follows (as I see it): 1. the inst/NEWS.Rd file contains the required dates; 2. when the package is built and installed, the dates do not show, specifically by help(package="sn”), followed by a click on “Package NEWS; 3. I do not know how to control the proper translation from Rd to HTML. So the specific question is: how can I enforce the presence on the dates show by help(package="sn”) + click on “Package NEWS ? Currently you cannot, as the code that translates to html does not handle the dates. We will discuss this. Best, Uwe Best wishes, Adelchi On 29 Aug 2022, at 12:36, Uwe Ligges wrote: On 29.08.2022 11:01, Adelchi Azzalini wrote: Hi. In the last version of package ’sn’ (v. 2.1.0) the old NEWS text file has been converted to inst/NEWS.Rd. The headers in this file are of the form \section{Changes in sn version 2.1.0 (2022-07-30)} \section{Changes in sn version 2.0.2 (2022-03-07)} and so on However, when I now look at the package documentation in the HTML rendering, the “NEWS in packages ’sn’” does NOT display the dates! Details on the session are reported below, in case they are relevant. Can anyone explain how show these dates? In an interacticve session news(package="sn") open a web page in some web browser and the html code does not contain the dates, but the text form does: print(news(package="sn"), doBrowse=FALSE) To analyzse more precisely, we can directly look at the database if the format was read correctly: db <- news(package="sn") str(db) db$Date and all dates were read correctly. Best, Uwe Ligges --- Adelchi Azzalini http://azzalini.stat.unipd.it R> sessionInfo() R version 4.2.1 (2022-06-23) Platform: aarch64-apple-darwin20 (64-bit) Running under: macOS Monterey 12.5.1 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib Random number generation: RNG: Mersenne-Twister Normal: Inversion Sample: Rounding locale: [1] en_US.UTF-8/UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] grid stats4stats utils datasets grDevices graphics methods base other attached packages: [1] gtable_0.3.0 ggplot2_3.3.6 sn_2.1.0 loaded via a namespace (and not attached): [1] Rcpp_1.0.8.3highr_0.9 pillar_1.7.0compiler_4.2.1 [5] tools_4.2.1 digest_0.6.29 evaluate_0.15 lifecycle_1.0.1 [9] tibble_3.1.7lattice_0.20-45 pkgconfig_2.0.3 rlang_1.0.2 [13] Matrix_1.4-1cli_3.3.0 xfun_0.31 stringr_1.4.0 [17] withr_2.5.0 dplyr_1.0.9 knitr_1.39 generics_0.1.2 [21] vctrs_0.4.1 isoband_0.2.5 tidyselect_1.1.2glue_1.6.2 [25] R6_2.5.1fansi_1.0.3 purrr_0.3.4 farver_2.1.0 [29] magrittr_2.0.3 scales_1.2.0ellipsis_0.3.2 mnormt_2.1.0 [33] colorspace_2.0-3numDeriv_2016.8-1.1 labeling_0.4.2 utf8_1.2.2 [37] stringi_1.7.6 munsell_0.5.0 crayon_1.5.1 R> __ 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] Dispatch for S3 and Ordinary Function with Same Name
Hi Dario, I would have suggested using randomForest::predict.randomForest but you cannot because it is not exported by randomForest :-( There is probably a better way but my workaround would be for you to define your own class to avoid the ambiguity in scope. Whenever you want to use the predict from randomForest rather than yours, I would just strip out your specific class name. Hopefully someone will advise something more elegant to force the scoping... ++ On Mon, 29 Aug 2022 at 17:00, Dario Strbenac wrote: > Good day, > > If there is a function named predict in my package and another in another > package, such as randomForest, which is also called in a particular wrapper > function in my package, how may I ensure that the call to predict inside of > the wrapper function will call randomForest's prediction function and not > the predict function defined elsewhere in my package? To illustrate > > randomForestPredictInterface <- function(forest, measurementsTest, ...) > { > predictions <- predict(forest, measurementsTest) # Currently, executes > predict defined in my package. > > -- > Dario Strbenac > University of Sydney > Camperdown NSW 2050 > Australia > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Alexandre Courtiol, www.datazoogang.de [[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] [Solved, sort-of] CRAN valgrind reports with zero leaks - actionable?
Based on further (off-list) follow-ups with Simon and Uwe, the situation can now be summarized as follows: - there appears to be no word about non-leak errors reported by valgrind in the official documentation; I will have to plead that those with the power to amend these documents maybe address that one day - it has been confirmed that when such a valgrind report is present, there is no auto-processing of the package and a manual re-check is done; as a package maintainer I rather avoid that to minimize manual interventions by both the CRAN team and the package maintainer (i.e. myself) - using `VALGRIND_OPTS="-s" R -d valgrind -f nameOfTheFile.R` is helpful, especially for the test framework I use where test files are standard R scripts; this helps in locating the issue - in the case that spawned this, the error actually comes from just one test and is tickled by a third-party system library so there is nothing for us to do here, besides not to run the test - so I moved the test into a testfile matching 'test_.*_extra.R' and now exclude files with that pattern via .Rbuildignore; that gives us a fuller test surface when testing locally via the full the test directory yet permits to isolate-away tests we would rather not be running at CRAN. My thanks to everybody who helped with the question and clarified the context. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel