[R-SIG-Mac] quartz hanging
Sparapani, Rodney
r@p@r@p@ @end|ng |rom mcw@edu
Sat Jul 5 22:59:32 CEST 2025
Sorry, I can’t reproduce. The second Cmd-P behaves as expected
with Apple M1 Max, emacs 29.4, ESS 24.01.1 and…
R Under development (unstable) (2024-11-10 r87316) -- "Unsuffered Consequences"
Copyright (C) 2024 The R Foundation for Statistical Computing
Platform: aarch64-apple-darwin20
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> setwd('/Users/rsparapa/')
> library(ggplot2)
> ggplot(mtcars, aes(mpg, disp)) + geom_point()
> 2025-07-05 15:53:31.754 R[72603:17617108] It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
> sessionInfo()
R Under development (unstable) (2024-11-10 r87316)
Platform: aarch64-apple-darwin20
Running under: macOS Sonoma 14.7.2
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.12.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
time zone: America/Chicago
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] ggplot2_3.5.1
loaded via a namespace (and not attached):
[1] labeling_0.4.3 utf8_1.2.4 R6_2.5.1 tidyselect_1.2.1
[5] farver_2.1.2 magrittr_2.0.3 gtable_0.3.6 glue_1.8.0
[9] tibble_3.2.1 pkgconfig_2.0.3 generics_0.1.3 dplyr_1.1.4
[13] lifecycle_1.0.4 cli_3.6.3 fansi_1.0.6 scales_1.3.0
[17] grid_4.5.0 vctrs_0.6.5 withr_3.0.2 compiler_4.5.0
[21] tools_4.5.0 munsell_0.5.1 pillar_1.9.0 colorspace_2.1-1
[25] rlang_1.1.4
>
--
Rodney Sparapani, Associate Professor of Biostatistics
President, Wisconsin Chapter of the American Statistical Association
Division of Biostatistics, Data Science Institute
Medical College of Wisconsin, Milwaukee Campus
From: R-SIG-Mac <r-sig-mac-bounces using r-project.org> on behalf of bill+rsigmac using 8pawexpress.com <bill+rsigmac using 8pawexpress.com>
Date: Friday, July 4, 2025 at 12:33 AM
To: r-mac <r-sig-mac using r-project.org>
Subject: Re: [R-SIG-Mac] quartz hanging
ATTENTION: This email originated from a sender outside of MCW. Use caution when clicking on links or opening attachments.
________________________________
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 <https://urldefense.com/v3/__http://mac.r-project.org__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSBJ6fv7c$ > 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 <https://urldefense.com/v3/__http://mac.r-project.org__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSBJ6fv7c$ >.
> >>
> >>> 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://urldefense.com/v3/__https://www.xquartz.org/FAQs.html__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuS4wUPUQ4$<https://urldefense.com/v3/__https:/www.xquartz.org/FAQs.html__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuS4wUPUQ4$>
> >> 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 <https://urldefense.com/v3/__http://dev.new__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSn5Yjmlc$ >() 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://urldefense.com/v3/__https://github.com/XQuartz/XQuartz/issues/431__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSR3JjMhM$<https://urldefense.com/v3/__https:/github.com/XQuartz/XQuartz/issues/431__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSR3JjMhM$> , 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://urldefense.com/v3/__https://github.com/XQuartz/XQuartz/issues/168__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSOLaWiU8$<https://urldefense.com/v3/__https:/github.com/XQuartz/XQuartz/issues/168__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSOLaWiU8$> , closed as “not
> planned”,
> >>>> though this one is much older than the first (431) issue
> >>>>
> >>>> I’ve tried using something like |httpgd|
> >>>> <https://urldefense.com/v3/__https://github.com/nx10/httpgd/__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSEW4yGLE$ > 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://urldefense.com/v3/__https://github.com/nx10/httpgd/issues/215__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSCcqEGuU$ >). 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://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$<https://urldefense.com/v3/__https:/stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$>
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> _______________________________________________
> >> R-SIG-Mac mailing list
> >> R-SIG-Mac using r-project.org
> >> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$<https://urldefense.com/v3/__https:/stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac using r-project.org
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$<https://urldefense.com/v3/__https:/stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$>
>
>
>
> --
> Best,
> Kasper
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac using r-project.org
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$<https://urldefense.com/v3/__https:/stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!-YEpBLrLI6b_Mk0zf1f5h0O-bWSg2UBs07TqCgYQIYE-X-ULQQ1uoZD_NBd2nUVAzcNTm05C3SDAzebn0WuSPVCkDVU$>
[[alternative HTML version deleted]]
More information about the R-SIG-Mac
mailing list