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+rsig...@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+rsig...@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@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
