[Rd] Rscript Bug Report (improper parsing of [args])
Hi, A user of my `optparse` package discovered a bug in Rscript's parsing of [args]. (https://github.com/trevorld/optparse/issues/24) I've reproduced the bug on my machine including compiling and checking the development version of R. I couldn't find a mention of it in the Bug Tracker or New Features. Can be minimally reproduced on the UNIX command line with following commands: bash$ touch test.R bash$ Rscript test.R -g 5 WARNING: unknown gui '5', using X11 This is a bug because according to the documentation in ?Rscript besides `-e` the only [options] Rscript should attempt to parse should 1) Come before the file i.e. `Rscript -g X11 test.R` and not `Rscript test.R -g X11` 2) Begin with two dashes and not one i.e. `--` and not `-' i.e. `Rscript --gui=X11 test.R` and not `Rscript -g X11 test.R` (although I'm not sure if the command-line Rscript even needs to be supporting the gui option). Thanks, Trevor [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
Hi, It would be nice if `grDevices::dev.capabilities()` could also be used to query whether the current graphics device supports Unicode. In such a case I'd expect it to return `FALSE` if `pdf()` is the current graphics device and something else for the Cairo or Quartz devices. Thanks, Trevor [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] List's `[[` method with "" tag
Hi, I notice that one can assign a variable to an R list by using an empty string key but one cannot get that variable back from the list by using the empty string key: ```r l <- list() l[[""]] <- "An empty string as list key" names(l) l[[""]] # Returns a `NULL` l[[names(l) == ""]] # Returns first value with `""` tag ``` Instead of `l[[""]]` returning a `NULL` I'd "expect" it to instead return the first variable named `""` i.e. in this case "An empty string as list key". It would be nice if the `[[` method of a list was updated to "fix" this. Additionally, I observe that if a list is named but has certain elements without names then those are currently "named" `""`: ```r names(list(a = 1, 2, c = 3, 4)) ``` This latter change may be a breaking change but I speculate that perhaps it may be more intuitive if missing names were indicated with `NA_character_` instead of `""`. Thanks, Trevor [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
> However, pdf() *does* support Unicode.
When I run a simple Unicode example like:
```
f <- tempfile(fileext = ".pdf")
pdf(f)
# U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans,
Arimo, etc.
# However, it is not in the Latin-1 encoding
grid::grid.text("\u2665")
dev.off()
```
I observe the following output:
```
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
```
When I open up the pdf file I just see three dots and not a heart as I
expected even if I open it up with `xpdf`.
In contrast the pdf generated by `cairo_pdf()` has a heart without
generating any warnings.
Avoiding such WARNINGs on certain CRAN check machines when I have a Unicode
graphics example that is worth including in a package's examples (if
protected by an appropriate if statement) is my main use case for such a
new feature. However, a new feature like `dev.capabilities()$unicode`
could certainly return something more sophisticated than a crude `TRUE` and
`FALSE` to distinguish between levels of Unicode support provided by
different graphics devices.
Thanks,
Trevor
On Wed, Sep 20, 2023 at 3:39 AM Martin Maechler
wrote:
> >>>>> Trevor Davis
> >>>>> on Thu, 31 Aug 2023 13:49:03 -0700 writes:
>
> > Hi,
>
> > It would be nice if `grDevices::dev.capabilities()` could also be
> used to
> > query whether the current graphics device supports Unicode. In such
> a case
> > I'd expect it to return `FALSE` if `pdf()` is the current graphics
> device
> > and something else for the Cairo or Quartz devices.
>
> > Thanks,
> > Trevor
>
> I agree in principle that this would be useful new feature for
> dev.capabilities()
>
> However, pdf() *does* support Unicode.
>
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts {which *are* on the machine; good old `xpdf`
> does in that case show the glyphs}.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems caused by dev.off() behaviour
> Use it just like dev.off(), but it *will* restore the previous device.
I'm observing that if there were no previously open graphics devices then
your `safe.dev.off()` opens up a new graphics device which may be an
undesired side effect (because "surprisingly" `dev.set()` on the null
graphics device opens up a new graphics device). To avoid that you could
check if `dev.list()` is greater than length 1L:
safe.dev.off <- function(which = dev.cur(), prev = dev.prev()) {
force(prev)
dev.off(which)
if (length(dev.list()) > 1L) {
dev.set(prev)
}
}
Trevor
On Mon, Oct 2, 2023 at 11:54 AM Duncan Murdoch
wrote:
> I found some weird behaviour and reported it as
> https://bugs.r-project.org/show_bug.cgi?id=18604 and
> https://github.com/yihui/knitr/issues/2297, but it turns out it was user
> error.
>
> The dev.off() function was behaving as documented, but it behaves in an
> unexpected (by me) way, and that caused the "bugs".
>
> The issue is that
>
> dev.off()
>
> doesn't always result in the previous graphics device being made
> current. If there are two or more other open graphics devices, it won't
> choose the previous one, it will choose the next one.
>
> I'm letting people know because this might affect other people too. If
> you use dev.off(), don't assume it restores the previous device!
>
> Here's my little workaround alternative:
>
>safe.dev.off <- function(which = dev.cur(), prev = dev.prev()) {
> force(prev)
> dev.off(which)
> dev.set(prev)
>}
>
> Use it just like dev.off(), but it *will* restore the previous device.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems caused by dev.off() behaviour
> Thanks! However, isn't length(dev.list()) == 0 when there are no
devices? That's what I'm seeing on MacOS.
If there is only one graphics device then R should automatically set it as
the active graphics device so it isn't really necessary to manually set
it. Although there wouldn't be any harm in manually setting it you only
really need to worry about setting the previous graphics device when there
are two or more devices open.
Trevor
On Mon, Oct 2, 2023 at 5:25 PM Duncan Murdoch
wrote:
> Thanks! However, isn't length(dev.list()) == 0 when there are no
> devices? That's what I'm seeing on MacOS.
>
> Duncan Murdoch
>
> On 02/10/2023 4:21 p.m., Trevor Davis wrote:
> > > Use it just like dev.off(), but it *will* restore the previous device.
> >
> > I'm observing that if there were no previously open graphics devices
> > then your `safe.dev.off()` opens up a new graphics device which may be
> > an undesired side effect (because "surprisingly" `dev.set()` on the null
> > graphics device opens up a new graphics device). To avoid that you
> > could check if `dev.list()` is greater than length 1L:
> >
> > safe.dev.off <- function(which = dev.cur(), prev = dev.prev()) {
> > force(prev)
> > dev.off(which)
> > if (length(dev.list()) > 1L) {
> > dev.set(prev)
> > }
> > }
> >
> > Trevor
> >
> > On Mon, Oct 2, 2023 at 11:54 AM Duncan Murdoch > <mailto:murdoch.dun...@gmail.com>> wrote:
> >
> > I found some weird behaviour and reported it as
> > https://bugs.r-project.org/show_bug.cgi?id=18604
> > <https://bugs.r-project.org/show_bug.cgi?id=18604> and
> > https://github.com/yihui/knitr/issues/2297
> > <https://github.com/yihui/knitr/issues/2297>, but it turns out it
> > was user
> > error.
> >
> > The dev.off() function was behaving as documented, but it behaves in
> an
> > unexpected (by me) way, and that caused the "bugs".
> >
> > The issue is that
> >
> > dev.off()
> >
> > doesn't always result in the previous graphics device being made
> > current. If there are two or more other open graphics devices, it
> > won't
> > choose the previous one, it will choose the next one.
> >
> > I'm letting people know because this might affect other people too.
> If
> > you use dev.off(), don't assume it restores the previous device!
> >
> > Here's my little workaround alternative:
> >
> > safe.dev.off <- function(which = dev.cur(), prev = dev.prev()) {
> > force(prev)
> > dev.off(which)
> > dev.set(prev)
> > }
> >
> > Use it just like dev.off(), but it *will* restore the previous
> device.
> >
> > Duncan Murdoch
> >
> > __
> > R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> > <https://stat.ethz.ch/mailman/listinfo/r-devel>
> >
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Vignettes with long compute time
> Is there a way to include the compiled version of a vignette in the doc
directory but mark
it to NOT be rerun by CRAN?
Some developers "precompute" their vignettes so CRAN has nothing left to
run: https://ropensci.org/blog/2019/12/08/precompute-vignettes/
> Beth Atkinson and I are splitting out many of the vignettes from the
survival
package into a separate package survivalVignettes.
An alternative some authors use is to temporarily use a special
`.Rbuildignore` file to omit large vignettes when building the CRAN package
but don't use that file for the normal development version (so that all the
vignettes are available in the `{pkgdown}` website and for users who
install using alternative channels like `remotes::install_github()`).
Trevor
On Mon, Mar 11, 2024 at 8:44 AM Therneau, Terry M., Ph.D. via R-devel <
r-devel@r-project.org> wrote:
> Is there a way to include the compiled version of a vignette in the doc
> directory but mark
> it to NOT be rerun by CRAN? I think I remember that this is possible,
> but have forgotton
> how. (It might even be a false memory.)
>
> Terry T.
>
> Background: Beth Atkinson and I are splitting out many of the vignettes
> from the survival
> package into a separate package survivalVignettes. There are a few reasons
>
> 1. Some vignettes use packages outside of the base + recommended set;
> psueodovalues for
> instance are normally used as input to a subsequent GEE model.Since
> survival is itself
> a recommended package, it can't legally host the pseudo.Rnw vignette.
> 2. The set of vignettes for survival is large, and likely to get
> larger.It makes
> sense to slim down the size of the package itself.
> 3. It allows us to use Rmd. (Again, survival can't use anything outside
> of base +
> recommended).
> 4. We have a couple of 'optional' vignettes that talk about edge cases,
> useful to some
> people but not worth the size cost of cluttering up the main package.
>
> The current submission fails due to one vignette in group 4 which takes a
> looong time to
> run. This vignette in particular is talking about compute time, and
> illustrates a cases
> where an O(n^2) case arises. As sentence that warns the use "of you do
> this it will take
> hours to run" is a perfect case for a pdf that should not be recreated by
> R CMD check.
>
> --
> Terry M Therneau, PhD
> Department of Quantitative Health Sciences
> Mayo Clinic
> thern...@mayo.edu
>
> "TERR-ree THUR-noh"
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paths capability FALSE on devel?
In the past I've observed similar behaviour with R compiled with support for cairo but no pango: https://stat.ethz.ch/pipermail/r-devel/2022-April/081587.html Despite cairo support if no pango then the documentation in ?X11 says R defaults to type "Xlib" instead of type "cairo" even though both seem to work and only type "cairo" supports all the new grid features like paths... What happens if you set `X11.options(type = "cairo")`? Trevor [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
> This is a good solution. Do I need to specify the original License etc? And > what about a helper function such as stats:::n.knots? This will not appear > in the manual of my package. Is it sufficient in this case to document the > authorship in the source (and perhaps a README as you suggested)? If the license is the same as your projects you just need the proper copyright notice. As Hadley suggests it is a good idea to also document the appropriate authorship in the Authors field in the DESCRIPTION as well. If the license is different but permissive than then it typically doesn't need go into DESCRIPTION or a separate LICENSE file but the permissive license text does usually need to either go into inst/COPYRIGHT or at the top of the relevant code file: https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html https://www.softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html If the license is more restrictive you must either convert your project or not use the code at all although for very small code snippets you might have fair use rights (at least in the United States). - Trevor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Tue, May 13, 2014 at 9:14 AM, Knut Krueger wrote: > Is there another new solution for this issue? > especially I would like to use: > > utils:::.win32consoleCompletion > the use of this is suggested in the completion.r file of utils: > Besides forking the function (i.e. "copy-and-paste" it) if you think the function provides useful functionality you can try to persuade the maintainer to export it (and hence agree to support the function API for the foreseeable future) or even contribute the function to another more appropriate package (maybe even creating a new package in the process). - Trevor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsolata font for building vignettes with R-devel
> So is there a safe fallback or not? Should I install texlive-fonts-extra too > when building? > > Dirk > Today I needed to run sudo apt-get install texlive-fonts-extra in order to build a package in R 2.14.1 Ubuntu 11.10 Else I get the following warning/error: * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: ! LaTeX Error: File `inconsolata.sty' not found. Type X to quit or to proceed, or enter new name. (Default extension: sty) ! Emergency stop. l.267 ^^M ! ==> Fatal error occurred, no output PDF file produced! If you don't use the latest Ubuntu build from CRAN but instead use the build of R in the normal Ubuntu repos (i.e. R 13.2) than this error/warning does not occur... Probably wisest to install texlive-fonts-extra for now. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FR: improve "use" function
> Of course, it would be preferable if didn't need to detach the namespace.
Here's a version only detaches the namespace when necessary:
```r
use <- function(package, include.only) {
package <- as.character(package)[[1L]]
if (!requireNamespace(package, quietly = TRUE)) {
warning("there is no package called ", sQuote(package))
return (invisible(FALSE))
}
if (missing(include.only)) {
ns <- asNamespace(package, base.OK = FALSE)
include.only <- getNamespaceExports(ns)
}
if (package %in% .packages()) {
name <- paste0("package:", package)
previously_attached <- ls(name, all.names = TRUE)
if (!all(include.only %in% previously_attached)) {
detach(name, character.only = TRUE)
include.only <- union(include.only, previously_attached)
attachNamespace(package, include.only = include.only)
} # else no need to detach and re-attach
} else {
attachNamespace(package, include.only = include.only)
}
invisible(TRUE)
}
```
On Fri, May 23, 2025 at 3:40 AM Roland Fuß via R-devel <
r-devel@r-project.org> wrote:
> Hello,
>
> Currently `use` fails silently if you try to attach functions from the
> same namespace. It would be nice and more similiar to the use of
> roxygen2 if it could add (and maybe even remove?) functions. Here is a
> simple proof of concept I have posted on Stack Overflow [1]. Something
> similar could be done within `use`. Of course, it would be preferable if
> it didn't need to detach the namespace.
>
> |use("data.table", "fread") ls("package:data.table") #[1] "fread"
> use("data.table", "nafill") ls("package:data.table") #[1] "fread"
> useplus <- function(package, include.only) { loaded <-
> ls(sprintf("package:%s", package), all.names = TRUE)
> unloadNamespace(package) if (missing(include.only)) { use(package) }
> else { use(package, union(loaded, include.only)) } }
> useplus("data.table", "nafill") ls("package:data.table") #[1] "fread"
> "nafill"|
>
>
> [1] https://stackoverflow.com/q/79633064/1412059
>
> --
> Dr. Roland Fuß
>
> Thünen-Institut für Agrarklimaschutz/
> Thünen Institute of Climate-Smart Agriculture
>
> Bundesallee 65
> D-38116 Braunschweig, Germany
>
> Tel./Webex: ++49 531 25701967
> Email: roland.f...@thuenen.de
>
> Arbeitsgruppe "Emissionsberichterstattung"/
> Working group "Emission Inventories"
> Email: emissionsinvent...@thuenen.de
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
