Re: [R-pkg-devel] LaTeX errors under MacOS on CRAN
В Thu, 1 Aug 2024 10:53:56 -0400 Ben Bolker пишет: >! Undefined control sequence. >l.176 \hlkwd{library}\hldef > {(}\hlsng{"glmmTMB"}\hldef{)} Very strange. This may be related to https://github.com/yihui/knitr/issues/2345 (no diagnosis) and possibly https://github.com/yihui/knitr/pull/2341 (where some of the highlight commands have been renamed). It would be interesting to see the resulting *.tex file: somehow, \hlkwd is defined, but \hldef isn't. Looking at the code, knitr should be generating all these definitions in styler_assistant_latex, called from theme_to_header_latex. This one is either called from theme_to_header (thus from knit_theme$get(name)), or at installation time, converting inst/themes/default.css (which should have both hlkwd and hldef set). Since you aren't setting any knitr highlighting themes or opts_knit$set('header'), you should be getting both \hlkwd and \hldef defined from themes/default.css via knitr::render_latex. Is there a way to inadvertently set the 'header' knitr option? -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] LaTeX errors under MacOS on CRAN
A vague recollections tells me this happened when the set of packages was not fully updated. Best, Uwe LIgges On 02.08.2024 09:39, Ivan Krylov via R-package-devel wrote: В Thu, 1 Aug 2024 10:53:56 -0400 Ben Bolker пишет: ! Undefined control sequence. l.176 \hlkwd{library}\hldef {(}\hlsng{"glmmTMB"}\hldef{)} Very strange. This may be related to https://github.com/yihui/knitr/issues/2345 (no diagnosis) and possibly https://github.com/yihui/knitr/pull/2341 (where some of the highlight commands have been renamed). It would be interesting to see the resulting *.tex file: somehow, \hlkwd is defined, but \hldef isn't. Looking at the code, knitr should be generating all these definitions in styler_assistant_latex, called from theme_to_header_latex. This one is either called from theme_to_header (thus from knit_theme$get(name)), or at installation time, converting inst/themes/default.css (which should have both hlkwd and hldef set). Since you aren't setting any knitr highlighting themes or opts_knit$set('header'), you should be getting both \hlkwd and \hldef defined from themes/default.css via knitr::render_latex. Is there a way to inadvertently set the 'header' knitr option? __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] rhub (version 2) baulking at building a vignette.
Some time back, in the mists of memory, I got advice (on this list, I'm pretty sure) about building vignettes. The advice was to the effect that if the vignette was actually just a *.tex file, one could (after putting in some preparatory code, in the form of comments, before the documentclass command) pre-process the file (with pdflatex) and the build would use the *.pdf file that was created, without any processing being required. Being a Bear of Very Little Brain (and understanding almost nothing of the underlying intricacies) I simply followed instructions. It seemed to work, I was able to build and install the package containing the vignette in question. Now I want to build a Windoze binary of the package. Trying to do this with rhub led to a failure. The build process seemed to ignore the pre-processed *.pdf file, tried to create it, and complained that pdflatex was not available. I raised an "issue" about this on rhub: https://github.com/r-hub/rhub/issues/629 I got a response from the redoubtable Gábor Csárdi saying that when he tried a local build of my package, the build command threw effectively the same error as did rhub. So there's "something about my system" that is different. What could it be? I have attached my session info in a *.txt file, to avoid cluttering the email window too much. If anyone should wish to experiment, they can clone the package in question (I think!) by executing: git clone https://github.com/rolfTurner/kanova.git Can anyone give me some avuncular advice as to how: (a) to get rhub_check() to use the pre-compiled file testStat.pdf, or (b) to make pdflatex available to rhub_check() (c) to do something else that will permit me to build a Windoze binary using rhub? Grateful for any tips. cheers, Rolf Turner -- Honorary Research Fellow Department of Statistics University of Auckland Stats. Dep't. (secretaries) phone: +64-9-373-7599 ext. 89622 Home phone: +64-9-480-4619 > sessionInfo() R version 4.4.1 (2024-06-14) Platform: x86_64-pc-linux-gnu Running under: Ubuntu 22.04.4 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 LAPACK: /usr/lib/x86_64-linux-gnu/atlas/liblapack.so.3.10.3; LAPACK version 3.10.0 locale: [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_GB.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_GB.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C time zone: Pacific/Auckland tzcode source: system (glibc) attached base packages: [1] stats graphics grDevices datasets utils methods base other attached packages: [1] brev_0.0-8 loaded via a namespace (and not attached): [1] vctrs_0.6.5 cli_3.6.3 rlang_1.1.4 stringi_1.8.4 [5] purrr_1.0.2 pkgload_1.4.0 promises_1.3.0shiny_1.8.1.1 [9] xtable_1.8-4 glue_1.7.0htmltools_0.5.8.1 httpuv_1.6.15 [13] pkgbuild_1.4.4ellipsis_0.3.2fastmap_1.2.0 lifecycle_1.0.4 [17] memoise_2.0.1 stringr_1.5.1 compiler_4.4.1miniUI_0.1.1.1 [21] sessioninfo_1.2.2 fs_1.6.4 htmlwidgets_1.6.4 Rcpp_1.0.13 [25] urlchecker_1.0.1 later_1.3.2 digest_0.6.36 R6_2.5.1 [29] usethis_2.2.3 magrittr_2.0.3tools_4.4.1 mime_0.12 [33] devtools_2.4.5bspm_0.5.7profvis_0.3.8 remotes_2.5.0 [37] cachem_1.1.0 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] rhub (version 2) baulking at building a vignette.
В Fri, 2 Aug 2024 11:10:59 + Rolf Turner пишет: > The advice was to the effect that if the vignette was actually just a > *.tex file, one could (after putting in some preparatory code, in the > form of comments, before the documentclass command) pre-process the > file (with pdflatex) and the build would use the *.pdf file that was > created, without any processing being required. I think that you are looking for the "asis" vignette engine from the R.rsp package: https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf > Now I want to build a Windoze binary of the package. If the vignette uses LaTeX packages unavailable on the computer (rhub2 virtual machine) running R CMD build or R CMD check, that would indeed not work. Not sure about CRAN. Since your package doesn't seem to contain any native code, wouldn't the Windows users be satisfied with a source package? Unless running R CMD build --no-build-vignettes, it will include the PDF file. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] A function in one of my package is now a method in base R
Hi All, I have a function (not a method), sort_by(), in one of my packages. A new method with the same name was introduced in the recent versions of R (4.4.0 or 4.4.1, I forgot which one), resulting in potential conflict in users' code. Certainly, users can simply use pkg_name::function_name() to solve the conflict. However, I would like to be consistent with base R and so I am thinking about converting my function to a method for the class for which my function is intended to work on (e.g, est_table). However, my function has arguments different from those in the base R sort_by(): Base R: sort_by(x, y, ...) My function: sort_by( object, by = c("op", "lhs", "rhs"), op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"), number_rows = TRUE ) If I write the function sort_by.est_table(), I would need to match the argument names of the base R sort_by(). However, I think it is a bad idea to rename the arguments in my function and it will break existing code. Any suggestions on how I should proceed? Is keeping my function as-is a better option? Name conflict is not unusual across packages and so users need to learn how to solve this problem anyway. Nevertheless, if possible, I would like to solve the conflict internally such that users do not need to do anything. Regards, Shu Fai Cheung __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] rhub (version 2) baulking at building a vignette.
On 2 August 2024 at 16:12, Ivan Krylov via R-package-devel wrote: | В Fri, 2 Aug 2024 11:10:59 + | Rolf Turner пишет: | | > The advice was to the effect that if the vignette was actually just a | > *.tex file, one could (after putting in some preparatory code, in the | > form of comments, before the documentclass command) pre-process the | > file (with pdflatex) and the build would use the *.pdf file that was | > created, without any processing being required. | | I think that you are looking for the "asis" vignette engine from the Or the zero-dependency approach by Mark van der Loo of embedding a whole (pre-made pdf) in a five-line Rnw sweave file described in https://www.r-bloggers.com/2019/01/add-a-static-pdf-vignette-to-an-r-package/ So no real pdf processing requirement (besides the minimal include), so no random failing over a .sty or font one uses suddenly missing on another machine. 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
Re: [R-pkg-devel] A function in one of my package is now a method in base R
On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote: Hi All, I have a function (not a method), sort_by(), in one of my packages. A new method with the same name was introduced in the recent versions of R (4.4.0 or 4.4.1, I forgot which one), resulting in potential conflict in users' code. Certainly, users can simply use pkg_name::function_name() to solve the conflict. However, I would like to be consistent with base R and so I am thinking about converting my function to a method for the class for which my function is intended to work on (e.g, est_table). However, my function has arguments different from those in the base R sort_by(): Base R: sort_by(x, y, ...) My function: sort_by( object, by = c("op", "lhs", "rhs"), op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"), number_rows = TRUE ) If I write the function sort_by.est_table(), I would need to match the argument names of the base R sort_by(). However, I think it is a bad idea to rename the arguments in my function and it will break existing code. Any suggestions on how I should proceed? Is keeping my function as-is a better option? Name conflict is not unusual across packages and so users need to learn how to solve this problem anyway. Nevertheless, if possible, I would like to solve the conflict internally such that users do not need to do anything. I think it's impossible to avoid some inconvenience to your users. Here's what I'd suggest: - Create a method for base::sort_by(), as you suggested you could. Use the generic's variable names for compatibility, but also add your extra variable names as additional arguments, e.g. sort_by.est_table <- function(x, y, object, by = c("op", "lhs", "rhs"), op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"), number_rows = TRUE, ...) { # This test seems unlikely: how would we have dispatch here if we specified object explicitly? if (!missing(object) { if (!missing(x)) stop("both x and object specified!") x <- object } # This one is more likely to do something: if (!missing(by)) { if (!missing(y)) stop("both y and by specified!") y <- by } # Now proceed using x and y ... } - Create a separate function, e.g. sort_by_old() which is exactly compatible with your old sort_by(). For users where the above doesn't just work, they can switch to sort_by_old(). Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel