Okay, it took me a while, but I now have a very small reprex for quartz
(not xquartz) failing. I cannot repro this on linux with R-4.4.3 and the
same package versions.
This is using emacs/ess, though it behaves the same on the console. I do
not have RStudio installed.
|R.version # _ # platform aarch64-apple-darwin20 # arch aarch64 # os
darwin20 # system aarch64, darwin20 # status # major 4 # minor 4.3 #
year 2025 # month 02 # day 28 # svn rev 87843 # language R #
version.string R version 4.4.3 (2025-02-28) # nickname Trophy Case
Sys.info()[c("release","version")] # release # "24.5.0" # version #
"Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025;
root:xnu-11417.121.6~2/RELEASE_ARM64_T6041" plot(1:10) |
(This can also be reproduced using |ggplot(mtcars, aes(mpg, disp)) +
geom_point()|.)
At this point, change to the quartz window, it looks fine. Press |cmd-p|
and a print dialog comes up, normal. Escape out. Press |cmd-p| again,
and a bunch of rows dump all at once:
|2025-07-03 22:12:31.320 R[85631:98913917] The behavior of the
UICollectionViewFlowLayout is not defined because: 2025-07-03
22:12:31.320 R[85631:98913917] the item width must be less than the
width of the UICollectionView minus the section insets left and right
values, minus the content insets left and right values. 2025-07-03
22:12:31.320 R[85631:98913917] The relevant UICollectionViewFlowLayout
instance is <NSCollectionViewFlowLayout: 0x15b623740>, and it is
attached to <NSCollectionView: 0x15b623000>. 2025-07-03 22:12:31.320
R[85631:98913917] Make a symbolic breakpoint at
UICollectionViewFlowLayoutBreakForInvalidSizes to catch this in the
debugger. 2025-07-03 22:12:31.322 R[85631:98913917] The behavior of the
UICollectionViewFlowLayout is not defined because: 2025-07-03
22:12:31.322 R[85631:98913917] the item width must be less than the
width of the UICollectionView minus the section insets left and right
values, minus the content insets left and right values. 2025-07-03
22:12:31.322 R[85631:98913917] The relevant UICollectionViewFlowLayout
instance is <NSCollectionViewFlowLayout: 0x15b623740>, and it is
attached to <NSCollectionView: 0x15b623000>. 2025-07-03 22:12:31.322
R[85631:98913917] Make a symbolic breakpoint at
UICollectionViewFlowLayoutBreakForInvalidSizes to catch this in the
debugger. 2025-07-03 22:12:31.324 R[85631:98913917] The behavior of the
UICollectionViewFlowLayout is not defined because: 2025-07-03
22:12:31.324 R[85631:98913917] the item width must be less than the
width of the UICollectionView minus the section insets left and right
values, minus the content insets left and right values. 2025-07-03
22:12:31.324 R[85631:98913917] The relevant UICollectionViewFlowLayout
instance is <NSCollectionViewFlowLayout: 0x15b623740>, and it is
attached to <NSCollectionView: 0x15b623000>. 2025-07-03 22:12:31.324
R[85631:98913917] Make a symbolic breakpoint at
UICollectionViewFlowLayoutBreakForInvalidSizes to catch this in the
debugger. |
(Repeating the |cmd-p| for the above messages is not required, it’s just
an oh-by-the-way. Not sure why it’s complaining, and I don’t entirely
understand what the messages are really saying. But since it’s neither a
warning nor a device-breaking error, I have been ignoring them.)
Now, load |kableExtra|. I haven’t tried many other packages, so far it
is just this one package.
|library(kableExtra) |
That’s all, no more code/expressions/evaluation required. Back to the
quartz window and press again |cmd-p|, and on the R console one of these
errors appears. I say “one of” because it varies slightly based on base
graphics or ggplot2, or CRAN-vs-P3M ggplot2. Since the message-component
is the same, I believe it to be the same underlying problem.
|### with base graphics alone, I see this: Error in
getNamespace("grDevices") : Start tag expected, '<' not found [4] ###
using ggplot2 from P3M, this is the only message I see Error in
diff.default(xscale) : Start tag expected, '<' not found [4] ### using
ggplot2 from CRAN, I see the p3m-error above or one of these two Error
in length(x) : Start tag expected, '<' not found [4] Error in is.unit(y)
: Start tag expected, '<' not found [4] |
The quartz window for that R process is now unresponsive, R will plot
nothing more, and R will not open a new quartz window. I can |dev.off()
; dev.list()| and it suggests there are no windows, but the window is
still present and unresponsive. |dev.new()| does nothing. Additional
plot expressions (base or grid) do nothing, no error or warning, no
rendering.
Interestingly, when I do this with base graphics, the print dialog
remains up and is now unresponsive. (Does it matter that it says “no
printer found”?) When I repro this using |ggplot2|, the print dialog
does go away when the error hits, suggesting it is slightly later in
code execution?
Variations attempted:
* R is just the default R installer, I have not compiled it or any of
its components manually;
* base graphics vs |ggplot2| grid, barely-different behavior, same failure
* |ggplot2_3.5.2| installed from CRAN (source) and from p3m.dev (mac
binary), same behavior
* |kableExtra_1.4.0| installed from p3m.dev, and
|remotes::install_github("haozhu233/kableExtra")| installed
|1.4.0.15|, same behavior
* R from the shell and R from emacs/ess
* I tried |library(kableExtra); detach("package:kableExtra",
unload=TRUE)| (no attempt to print) and it still erred/broke
* though I think it was a red-herring, I have uninstalled XQuartz, no
change
* this has been in multiple versions of R-4.4, not just 4.4.3, and not
just one download/install; I have not yet tried R-4.5
* XCode updated itself to 16.2 (I don’t recall upgrading it), though I
would not expect this to be an issue if I compiled neither R nor the
packages using its compilers; I’m happy to be wrong here!
I do not think that the two packages have any collisions,
|intersect(ls(getNamespace("ggplot2")), ls(getNamespace("kableExtra")))|
yields nothing in common. But since this repros with base graphics
without |ggplot2| loaded, that’s a non-player anyway.
I’m hoping someone here can help with a couple requests/questions:
* can anyone else repro this on their machine, or is it just me?
* any ideas of what I might try to recompile, reinstall, or otherwise
debug or deep-dive to see if there are any clear markers of what is
causing the error?
Thanks!
Bill
On 6/2/25 17:28, Kasper Daniel Hansen wrote:
> I have been using quartz from inside Emacs for a long time and I
> basically never (or at least very rarely) have any issues. I rarely
> use XQuartz and never with R installed on my local machine (mostly to
> start X windows from a remote server). There is a way to configure the
> default device in R, so I would try to start the quartz device
> manually with
> R> quartz()
> R> plot(1:10)
> and check that is the same as
> R> plot(1:10)
> to rule out any configuration issues and make sure we're talking about
> the same device.
>
> Are you compiling R from source or are you using the CRAN binaries?
> That might have an impact.
>
> Best,
> Kasper
>
>
>
> On Sun, Jun 1, 2025 at 8:26 AM <bill+rsig...@8pawexpress.com
> <mailto:bill%2brsig...@8pawexpress.com>> wrote:
>
> Thank you, Peter. I think that’s a misunderstanding of mine based on
> mis-reading mac.r-project.org <http://mac.r-project.org> and
> incomplete research. I have since
> uninstalled XQuartz and indeed |quartz()| still works, so my
> bug-report
> has been a misdirection. With this, I’ve changed the here from
> “xquartz
> hanging” to “quartz hanging”.
>
> I’m still working on a reprex, haven’t found the culprit yet. (I
> haven’t
> had a repeat since I uninstalled and reinstalled then uninstalled
> XQuartz.)
>
> Thank you again,
> Bill
>
> On 6/1/25 07:24, peter dalgaard wrote:
>
> > I'm puzzled why you need XQuartz in the first place. R in a
> terminal usually fires up the quartz() graphics device and that
> has nothing to do with XQuartz (which is X on top of Quartz, not
> the other way around).
> >
> > We do have an annoyance with XQuartz though: When
> install.packages() goes looking for a CRAN mirror (*), it fires up
> a Tk selector and that will require XQuartz to fire up. Every now
> and again that hangs for me too, but as it is usually the first
> thing I do in an R session, I can ctr-Z and kill the process and
> start over. But it really could do with a looking into. (I do miss
> strace/truss from days of yore, where you could just probe into a
> running process and see what it is up to.)
> >
> > -pd
> >
> > (*) Yeah, I know, it should be in a configuration file ...
> somewhere.
> >
> >> On 1 Jun 2025, at 00.08,bill+rsig...@8pawexpress.com
> <mailto:bill%2brsig...@8pawexpress.com> wrote:
> >>
> >> Thanks for the feedback, Marc! Very interesting.
> >>
> >> On 5/31/25 13:04, Marc Schwartz wrote:
> >>
> >>> Hi,
> >>>
> >>> I am currently running R 4.5.0 on macOS 15.5 (Sequoia), and I
> also use emacs (30.1) and ess (25.1.0), the latter from elpa,
> along with other emacs packages.
> >> It seems we (emacs/ess users) are a diminishing crowd :-(
> >>> I do not have the issue that you are referring to below, and
> did not under prior versions to the best of my recollection.
> >> Then there’s hope :-)
> >>> I do tend to stay up to date on the versions of all of the
> above and do clean installs of R and packages with each new
> version, fully removing the older version file tree first
> (/Library/Frameworks/R.framework).
> >>>
> >>> Thus, you might consider updating both macOS and R to current
> versions.
> >> I had already planned to upgrade to macos-15.5. I’m not able to
> >> upgrade (fully) to R-4.5 in the immediate future … worse, I need
> >> to have multiple R versions on-hand for some
> backwards-compatibility
> >> testing (work apps/apis).
> >>
> >> I do subscribe occasionally to the “three-finger salute” way of
> >> fixing some OS or program issues, but I really dislike the fact
> that
> >> it works much more frequently than I think it should.
> >>
> >>> I don't use ggplot*, so cannot comment if there may be
> something specific to that package causing any issues,
> >> |ggplot2| does tend to be more complex and test the graphics device
> >> more than typical base graphics; I recall an issue with ggplot on
> >> windows several years ago that caused the window to dump,
> >> occasionally causing R to dump and crash as well, triggered by a
> >> mouse-wheel action on a ggplot graphics pane. This is not the same
> >> issue, certainly, but speaks to the difference with base graphics.
> >>
> >> For the record, while I use it much much less frequently, I
> have yet
> >> to see the issue appear when a base-graphics plot is displayed.
> This
> >> is not conclusive.
> >>
> >>> One thing that you should do, if you have not, is to be sure
> to re-install XQuartz after upgrading R versions, and this is
> referenced on the R macOS CRAN page.
> >> The only mentions I can find of XQuartz on the R-Mac pages are:
> >>
> >> * Big Sur and newer require XQuartz 2.8.5 (I’m good,
> installed 2.8.5
> >> from the start)
> >> * “Always re-install XQuartz when upgrading your macOS to a new
> >> major version”: not applicable, I’ve been on 15.3 or newer
> on this
> >> laptop (unless … is 15.4 a “major version” over 15.3?)
> >>
> >> Regardless of that, I don’t understand how an xorg-server would be
> >> at all tied to (needing to be reinstalled/relinked after)
> changes in
> >> a client library (R plotting services). Can you provide more
> >> information (a link) where they say XQuartz needs to be reinstalled
> >> with each R upgrade? I apologize if I’m missing it on
> mac.r-project.org <http://mac.r-project.org>.
> >>
> >>> See if re-installing XQuartz has any impact on the issues that
> you are observing.
> >> Regardless of “why” it may work, I think I’m going to uninstall and
> >> reinstall XQuartz when I do the macos upgrade. “It can’t hurt”,
> >> famous last words.
> >>> You might also want to fully uninstall XQuartz first, before
> re-installing it, and the instructions for that are available on
> their FAQ page:
> >>>
> >>> https://www.xquartz.org/FAQs.html
> >> Sage advice, I appreciate it.
> >>> One additional thing to consider is to try to replicate the
> behavior that you are observing by running R in Terminal and/or
> via R.app, to try to exclude the possibility that there is
> something going on with your emacs/ess installation.
> >> That’s been on my list, but since I still don’t know exactly what
> >> causes it to hang, I have not spent the time trying to repeat it
> >> from outside of my normal R use.
> >>
> >> Once thing I find interesting is that it is particular to one R
> >> process, but not to XQuartz. That is, when one R process’ graphics
> >> device is hung, I can open a new R process and plotting works
> >> without issue. I can close the first process, eventually its hung
> >> window closes, and other processes continue to plot without
> issue. I
> >> don’t know if this narrows it down at all, since a bug in either R
> >> or XQuartz could show that specificity. (The major pain is that
> >> often I’m working with many GBs of data, and reloading and
> >> reprocessing is a not-free chore. Usually not impossible, just many
> >> many minutes and reacquiring my mental focus.)
> >>
> >> Thanks again for your experience, Marc!
> >>
> >>> If you can replicate the issues in Terminal and/or R.app, that
> would help to exclude emacs/ess from involvement at least. If you
> cannot, then you might be sure that you are running the latest
> versions of emacs and ess to see if that helps, in case they are
> adding a source of conflict.
> >>>
> >>> Regards,
> >>>
> >>> Marc Schwartz
> >>>
> >>>
> >>>> On May 31, 2025, at 10:35 AM,bill+rsig...@8pawexpress.com
> <mailto:bill%2brsig...@8pawexpress.com> wrote:
> >>>>
> >>>> Are there easy fixes or alternatives to using XQuartz for R
> plots?
> >>>>
> >>>> I’m running R-4.4.3 (emacs/ess) on macos 15.4.1 and have
> xquartz-2.8.5
> >>>> installed. Most of the time plotting in R works well enough
> (I tend to
> >>>> use ggplot2, I don’t know if it happens as often with base
> plots).
> >>>> Occasionally (several times a week), “something” happens with
> the plot
> >>>> window, and from then on that R process can no longer plot
> anything
> >>>> more. The “something” is not well defined for me yet, I think
> it’s a
> >>>> mouse-wheel or mouse-click or similar; the snark in me says
> “well don’t
> >>>> do that”, but I cannot nail down exactly how/when it breaks,
> it just does.
> >>>>
> >>>> When it happens, the current device window is still open, but
> it has a
> >>>> mac spinning-colorwheel, no new plotting commands work, and I
> cannot
> >>>> close the window myself. I cannot dev.off() it, nor does
> dev.new <http://dev.new>() give
> >>>> me a new plotting window. When this happens for a particular
> R process,
> >>>> my only options for plotting are either (a) close the R
> process and
> >>>> start over, or (b) manually plot to a PDF or similar one-shot
> graphics
> >>>> device, viewing in a different app.
> >>>>
> >>>> There are several related issues I can find:
> >>>>
> >>>> https://github.com/XQuartz/XQuartz/issues/431, specific to
> macos 15.4 or
> >>>> newer I think; some mention of “minimizing windows” but I
> don’t minimize
> >>>> my plot windows, so perhaps not that
> >>>> https://github.com/XQuartz/XQuartz/issues/168, closed as “not
> planned”,
> >>>> though this one is much older than the first (431) issue
> >>>>
> >>>> I’ve tried using something like |httpgd|
> >>>> <https://github.com/nx10/httpgd/> since it can (mostly)
> provide an
> >>>> “always updating graphics device” for example without xquartz.
> >>>> Unfortunately, with some other packages (namely plumber that
> I use
> >>>> frequently-enough) it can put the R’s REPL into an
> unbreakable state
> >>>> (#215<https://github.com/nx10/httpgd/issues/215>). If that
> were fixed
> >>>> I’d be a lot more comfortable using that as my workaround.
> >>>>
> >>>> My research has not shown any other options for fixing or
> replacing
> >>>> xquartz with a more stable solution. Are there good ways to
> troubleshoot
> >>>> and try to fix the xquartz issue? Does anybody else have a
> workaround or
> >>>> alternative that is less unwieldy than pdf(..); plot(..);
> dev.off()?
> >>>>
> >>>> Thanks,
> >>>> Bill
> >>>>
> >>>> ​
> >>>> ​
> >>>> [[alternative HTML version deleted]]
> >>>>
> >>>> _______________________________________________
> >>>> R-SIG-Mac mailing list
> >>>> R-SIG-Mac@r-project.org
> >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >> ​
> >> [[alternative HTML version deleted]]
> >>
> >> _______________________________________________
> >> R-SIG-Mac mailing list
> >> R-SIG-Mac@r-project.org
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> ​
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>
>
> --
> Best,
> Kasper
​
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
