Message-ID: <CAC2h7uvMP4NZpgzZbO1BkCgkZZgLyXLk4Scb8FDjxZfkq2yiqA@mail.gmail.com>
Date: 2025-06-02T21:28:23Z
From: Kasper Daniel Hansen
Subject: quartz hanging
In-Reply-To: <a09657ad-c746-490b-9866-50c2625fde83@8pawexpress.com>
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> wrote:
> Thank you, Peter. I think that?s a misunderstanding of mine based on
> mis-reading 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 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
> .
> >>
> >>> 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 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()
> 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
[[alternative HTML version deleted]]