[R-SIG-Mac] quartz hanging
biii+rsigm@c m@iii@g oii 8p@wexpress@com
biii+rsigm@c m@iii@g oii 8p@wexpress@com
Fri Jul 4 21:18:59 CEST 2025
More information, in case it’s useful:
* I installed RStudio, and does not show this problem, but then again
the |cmd-p| is not a keyboard thing in its graphics pane, and it
uses the |RStudioGD| and |quartz_off_screen| devices vice |quartz|
* I installed R-4.5.1 (which is matched better with the version of
Xcode on my system, 16.2), and it still fails in the same way, so it
seems unlikely to be a Xcode version thing
* changing various |quartz.options(family=, dpi=, type=, bg=,
canvas=)| does not change the behavior
* this seems mostly about the printer connection:
o both |cmd-p| (Print) and |cmd-shift-p| (Page Setup) evoke the
failure
o the Print and Page Setup menu items also trigger the failure
without the keyboard shortcut
o all other menu items and keyboard shortcuts (e.g., |cmd-c|) work
without error
* I do have printers installed and I do have a default printer; I’m not
sure what happened with the previous “no default printer” thing but now
the print dialog does show a default printer available
It seems wholly tied to how |quartz| ties into the printer.
The keypress in question |cmd-p| in emacs is “previous input/expression”
(command history), which is something I use almost every minute. Since I
tend to trigger it often enough by switching from emacs to the graphics
window and then back to emacs and rerunning the previous command with a
slight change (and clearly switching windows is an imperfect step for
me), one trick that macos supports is overriding menu keyboard shortcuts
for specific app menu items. Unfortunately, the quartz window is very
special, and not one keyboard-shortcut app out there (specifically base
macos, BetterTouchTool, nor Karabiner) recognizes quartz windows correctly.
So my workaround is to change the menu-item “Print” (and Page Setup,
just in case) for all applications to something else. Fortunately, I use
that keypress to print something less than once per month, possibly once
per year, I think I will not miss it.
I’m still curious if anybody else can reproduce this issue. If not, then
something about my system is different enough :-(
Thanks for your attention :-)
Bill
On 7/3/25 22:55, bill+rsigmac using 8pawexpress.com wrote:
> 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+rsigmac using 8pawexpress.com
>> <mailto:bill%2Brsigmac using 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+rsigmac using 8pawexpress.com
>> <mailto:bill%2Brsigmac using 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+rsigmac using 8pawexpress.com
>> <mailto:bill%2Brsigmac using 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 using r-project.org
>> >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> _______________________________________________
>> >> R-SIG-Mac mailing list
>> >> R-SIG-Mac using r-project.org
>> >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>>
>>
>> --
>> Best,
>> Kasper
>
[[alternative HTML version deleted]]
More information about the R-SIG-Mac
mailing list