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
