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,[email protected] 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
>> [email protected]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
​
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
