quartz hanging
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 at 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 at 8pawexpress.com
<mailto:bill%2Brsigmac at 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 at 8pawexpress.com
<mailto:bill%2Brsigmac at 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:
>> 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 at 8pawexpress.com
<mailto:bill%2Brsigmac at 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 at r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> ​
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
​
? ? ? ? [[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Best,
Kasper
​
​