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 > > 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.
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 > 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
__
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
[Rd] Should `expand.grid()` consistently drop `NULL` inputs?
Hi all,
I noticed that `expand.grid()` has somewhat inconsistent behavior with
dropping `NULL` inputs. In particular, if there is a leading `NULL`,
then it ends up as a column in the resulting data frame, which seems
pretty undesirable. Also, notice in the last example that `Var3` is
used as the column name on the `NULL`, which is wrong.
I think the most consistent behavior would be to unconditionally drop
`NULL`s anywhere they appear (i.e. treat an `expand.grid()` call with
`NULL` inputs as semantically equivalent to the same call without
`NULL`s).
```
dropattrs <- function(x) {
attributes(x) <- list(names = names(x))
x
}
# `NULL` dropped
dropattrs(expand.grid(NULL))
#> named list()
# `NULL` dropped
dropattrs(expand.grid(1, NULL))
#> $Var1
#> numeric(0)
# Oh no! Leading `NULL` ends up in the data frame!
dropattrs(expand.grid(NULL, 1))
#> $Var2
#> NULL
#>
#> [[2]]
#> numeric(0)
# Oh no! This one does too!
dropattrs(expand.grid(1, NULL, 2))
#> $Var1
#> numeric(0)
#>
#> $Var3
#> NULL
#>
#> [[3]]
#> numeric(0)
```
Thanks,
Davis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] After package update, old S4 method is dispatched
Jan, have you re-installed all packages? If you change (update) any package that uses S4 it may be necessary to re-install all its reverse-dependencies as well since they may include cached values in their namespaces, so the easiest is to make sure you re-install all packages. Cheers, Simon > On Oct 3, 2023, at 4:18 AM, Jan Netík wrote: > > Hello R-devel, > > I hope that you are all doing well and that this is the right place to > discuss my somewhat mysterious issue with S4. > > On our Ubuntu server, we have "mirt" package installed which defines S4 > method for "coef" standard generic. We updated the package with the usual > "install.packages", restarted, and observer error calling coef on mirt > object that should not be possible: "Error in which: argument "nfact" is > missing, with no default" (which has no such argument). > > After days of investigation, I found that from mirt 1.37 to current 1.40, > the method changed as well as some internal functions used by the method. > The aforementioned error stems from the fact that these internal ordinary > functions were changed properly as we updated the package, but the S4 > method dispatched stuck with the 1.37 version. I am by no means an expert > on S4 matter, but I know that these are cached to some extent. I thought > the cache is session-bound and have no idea how the issue can possibly > persist even after a complete reboot of the machine. I can detach and > library() mirt in one R session which solves the issue temporarily, but > emerges right back in any new R session. > > Sadly, I cannot provide any reproducible example as I am completely unaware > of the cause and even I cannot reproduce this issue outside of the server. > > Any insights on how this issue could have started would be highly > appreciated. > > Best regards, > Jan Netík > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems caused by dev.off() behaviour
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
Re: [Rd] [R-pkg-devel] Problem with "compacting" pdf files.
Dear Ivan
I was bitten by this recently but fortunately Rolf had beaten me to
writing a question. The one thing which really surprised me is that the
current message tells me how much space it would have saved if it had
compressed the files in which case my immediate response was "Well, why
didn't you compress them then?".
Thank you for your help on this.
Michael
On 02/10/2023 12:58, Ivan Krylov wrote:
Dear Rolf,
(Moving this one to R-devel...)
On Sun, 1 Oct 2023 21:01:13 +
Rolf Turner wrote:
I *really* think that the instructions from CRAN could have been
clearer! Without your guidance I'd have been at a total loss.
Since the CRAN e-mails quote the R CMD check messages verbatim, would
it have been enough if R CMD check suggested using --compact-vignettes?
Index: src/library/tools/R/check.R
===
--- src/library/tools/R/check.R (revision 85249)
+++ src/library/tools/R/check.R (working copy)
@@ -3079,7 +3079,8 @@
" 'qpdf' made some significant size reductions:\n",
paste(" ", res, collapse = "\n"),
"\n",
- " consider running tools::compactPDF() on these
files\n")
+ " consider running tools::compactPDF() on these
files,\n",
+ " or build the source package with
--compact-vignettes\n")
}
if (R_check_doc_sizes2) {
gs_cmd <- find_gs_cmd()
@@ -3093,7 +3094,8 @@
" 'gs+qpdf' made some significant size
reductions:\n",
paste(" ", res, collapse = "\n"),
"\n",
- ' consider running tools::compactPDF(gs_quality =
"ebook") on these files\n')
+ ' consider running tools::compactPDF(gs_quality =
"ebook") on these files,\n',
+ ' or build the source package with
--compact-vignettes=both\n')
}
} else {
if (!any) noteLog(Log)
Or is there anything else you would prefer to be reworded? Should the
message link to Writing R Extensions, section 1.4? Recently there was a
project to improve the R CMD check messages [*], but I managed to miss
almost all of it.
--
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] After package update, old S4 method is dispatched
Hello R-devel, I hope that you are all doing well and that this is the right place to discuss my somewhat mysterious issue with S4. On our Ubuntu server, we have "mirt" package installed which defines S4 method for "coef" standard generic. We updated the package with the usual "install.packages", restarted, and observer error calling coef on mirt object that should not be possible: "Error in which: argument "nfact" is missing, with no default" (which has no such argument). After days of investigation, I found that from mirt 1.37 to current 1.40, the method changed as well as some internal functions used by the method. The aforementioned error stems from the fact that these internal ordinary functions were changed properly as we updated the package, but the S4 method dispatched stuck with the 1.37 version. I am by no means an expert on S4 matter, but I know that these are cached to some extent. I thought the cache is session-bound and have no idea how the issue can possibly persist even after a complete reboot of the machine. I can detach and library() mirt in one R session which solves the issue temporarily, but emerges right back in any new R session. Sadly, I cannot provide any reproducible example as I am completely unaware of the cause and even I cannot reproduce this issue outside of the server. Any insights on how this issue could have started would be highly appreciated. Best regards, Jan Netík [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-pkg-devel] Problem with "compacting" pdf files.
Dear Rolf,
(Moving this one to R-devel...)
On Sun, 1 Oct 2023 21:01:13 +
Rolf Turner wrote:
> I *really* think that the instructions from CRAN could have been
> clearer! Without your guidance I'd have been at a total loss.
Since the CRAN e-mails quote the R CMD check messages verbatim, would
it have been enough if R CMD check suggested using --compact-vignettes?
Index: src/library/tools/R/check.R
===
--- src/library/tools/R/check.R (revision 85249)
+++ src/library/tools/R/check.R (working copy)
@@ -3079,7 +3079,8 @@
" 'qpdf' made some significant size reductions:\n",
paste(" ", res, collapse = "\n"),
"\n",
- " consider running tools::compactPDF() on these
files\n")
+ " consider running tools::compactPDF() on these
files,\n",
+ " or build the source package with
--compact-vignettes\n")
}
if (R_check_doc_sizes2) {
gs_cmd <- find_gs_cmd()
@@ -3093,7 +3094,8 @@
" 'gs+qpdf' made some significant size
reductions:\n",
paste(" ", res, collapse = "\n"),
"\n",
- ' consider running
tools::compactPDF(gs_quality = "ebook") on these files\n')
+ ' consider running
tools::compactPDF(gs_quality = "ebook") on these files,\n',
+ ' or build the source package with
--compact-vignettes=both\n')
}
} else {
if (!any) noteLog(Log)
Or is there anything else you would prefer to be reworded? Should the
message link to Writing R Extensions, section 1.4? Recently there was a
project to improve the R CMD check messages [*], but I managed to miss
almost all of it.
--
Best regards,
Ivan
[*] https://github.com/r-devel/r-project-sprint-2023/issues/55
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
