Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
I am not sure who has maintenance access to all the links shown by Bobs checker
but they are dead since almost two weeks now.
Appreciated if someone could take this on - in the end it is the official
resource for getting the R 3.6 branch for Mac (if one wants to avoid the GUI
components).
Also the dead and outdated Rswitch links (last updated in 2011) do not add a
professional look to the site. One could link Bobs Switch app to enhance the
experience for R users on macOS: https://rud.is/rswitch/
On 26. Feb 2020, 15:00 +0100, Bob Rudis , wrote:
> Just a list FYI I'm keeping the status site up
> (https://rud.is/mac-r-project-links/) but since the current, remaining broken
> links aren't getting fixed I'm disabling Pushover notifications to me so I
> won't be able to proactively notify here if more links go bad.
>
> > On Feb 21, 2020, at 11:02, Bob Rudis wrote:
> >
> > Hey Simon (et al),
> >
> > I setup a 2x daily link checker job for mac.r-project.org. It outputs
> > tabular results to https://rud.is/mac-r-project-links/ (timestamp at top is
> > when the job ran). One table is for HTTP HEAD results and the other is for
> > HTTPS HEAD results since the server doesn't auto-upgrade HTTP to HTTPS
> > which could mean different status codes depending the underlying config.
> >
> > It's also configured to send me a pushover notification for anything but
> > 200 return status code an I'll post here or privately when you give me the
> > go-ahead to do that (since it cld take a bit to fix the below :-).
> >
> > Right now, the following links have non-200 status codes:
> >
> > - 404
> > http://mac.r-project.org/mavericks/R-3.4-branch/R-3.4-branch-mavericks-signed.pkg
> > - 404 http://mac.r-project.org/RSwitch-1.1.dmg
> > - 404 http://mac.r-project.org/RSwitch-1.2.tar.gz
> > - 404 http://mac.r-project.org/RSwitch-1.1.tar.gz
> > - 403
> > http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
> >
> > Lemme know if I can do any more monitoring/alerting for the site.
> >
> > -boB
> >
> > > On Feb 21, 2020, at 09:12, Patrick Schratz
> > > wrote:
> > >
> > > Simon, sorry I was wrong with the version.
> > > In fact, I am getting a 403 with the R-3.6 branch. Other branches work
> > > fine.
> > >
> > > curl -Osv
> > > http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
> > > I
> > > * Trying 184.172.231.50...
> > > * TCP_NODELAY set
> > > * Connected to mac.r-project.org (184.172.231.50) port 80 (#0)
> > > > GET /el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
> > > > HTTP/1.1
> > > > Host: mac.r-project.org
> > > > User-Agent: curl/7.64.1
> > > > Accept: */*
> > > >
> > > < HTTP/1.1 403 Forbidden
> > > < Date: Fri, 21 Feb 2020 14:08:51 GMT
> > > < Server: Apache
> > > < Content-Length: 266
> > > < Content-Type: text/html; charset=iso-8859-1
> > > <
> > > { [266 bytes data]
> > > * Connection #0 to host mac.r-project.org left intact
> > > * Closing connection 0
> > >
> > > Can anyone reproduce this or is this really on my side? If you, any hints
> > > on resolving this?
> > > On 20. Feb 2020, 20:36 +0100, Simon Urbanek
> > > , wrote:
> > > > Patrick,
> > > >
> > > > it works just fine for me:
> > > >
> > > > $ curl -s -v -o /dev/null
> > > > https://mac.r-project.org/bin/macosx/R-latest.pkg
> > > > * Trying 184.172.231.50...
> > > > * TCP_NODELAY set
> > > > * Connected to mac.r-project.org (184.172.231.50) port 443 (#0)
> > > > * ALPN, offering h2
> > > > * ALPN, offering http/1.1
> > > > * Cipher selection:
> > > > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> > > > * successfully set certificate verify locations:
> > > > [...]
> > > > * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> > > > * ALPN, server accepted to use http/1.1
> > > > * Server certificate:
> > > > * subject: CN=mac.r-project.org
> > > > * start date: Jan 26 18:55:18 2020 GMT
> > > > * expire date: Apr 25 18:55:18 2020 GMT
> > > > * subjectAltName: host "mac.r-project.org" matched cert's
> > > > "mac.r-project.org"
> > > > * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
> >
Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
Thanks Simon. I am aware that this site is targeted to “developers” though I’d argue “end users” would also search for previous R releases and land at mac.R-project.org and not necessarily jump away because they are no “devs”. Also the URL does not make it obvious that its for devs only. There is only one hint in the title of the page. Just pointing this out as hints for possible improvements, not as a personal critic. Also on mac.R-project.org there is no link whom to contact / who is responsible for the content. I am just pointing out that there is room for improvement which could help lots of people out there :) Sorry for going off-topic - I’ll start a separate one dedicated to possible improvements of that page. Please tell me in case I am wrong that R-sig-mac is the correct place to do so. I’ve seen no other reference/link/forum mentioning where to put feedback for this effort/site. Thanks for all your efforts! Cheers, Patrick On 2. Mar 2020, 00:42 +0100, Simon Urbanek , wrote: > Also I'd like to clarify some things - the mac.R-project.org page is a > *developer* page, so it is not intended for end users. It is provided for > developers that want to test pre-releases and their packages. The content is > *not* expected to be stable in any way shape or form*. > > The mac.R-project.org server also provides a primary mirror of the official > CRAN Mac master binary content in /bin/macosx. The CRAN content *is* expected > to be stable and that is what this thread was originally about. However, some > people then confused the developer page with CRAN - they are not the same! > > Cheers, > Simon > > * - that said, I do appreciate reports to me if something is amiss, since > there are instances where I can fix things - but please think before > reporting such things (e.g. if R-devel is broken and thus there is no binary, > that's not something you need to report as that is expected). > > > > On 2/03/2020, at 11:53 AM, Simon Urbanek > > wrote: > > > > Patrick, > > > > those links are dead for years now so nothing surprising - the binaries got > > lost in a server crash many years ago, so checking them is actually > > somewhat pointless. > > > > Also note that some of them are not valid - not all builds are signed. > > > > That said, I have removed those that are not recoverable and added a link > > to Bob's page (we talked about it for a while with Bob). > > > > Bob, in your checks, can you, please, reduce it to valid checks, i.e. those > > that are actually expected to work? It seems to confuse people ;). > > > > Thanks, > > Simon > > > > > > > > > On 2/03/2020, at 3:31 AM, Patrick Schratz > > > wrote: > > > > > > I am not sure who has maintenance access to all the links shown by Bobs > > > checker but they are dead since almost two weeks now. > > > > > > Appreciated if someone could take this on - in the end it is the official > > > resource for getting the R 3.6 branch for Mac (if one wants to avoid the > > > GUI components). > > > > > > Also the dead and outdated Rswitch links (last updated in 2011) do not > > > add a professional look to the site. One could link Bobs Switch app to > > > enhance the experience for R users on macOS: https://rud.is/rswitch/ > > > > > > > > > On 26. Feb 2020, 15:00 +0100, Bob Rudis , wrote: > > > > Just a list FYI I'm keeping the status site up > > > > (https://rud.is/mac-r-project-links/) but since the current, remaining > > > > broken links aren't getting fixed I'm disabling Pushover notifications > > > > to me so I won't be able to proactively notify here if more links go > > > > bad. > > > > > > > > > On Feb 21, 2020, at 11:02, Bob Rudis wrote: > > > > > > > > > > Hey Simon (et al), > > > > > > > > > > I setup a 2x daily link checker job for mac.r-project.org. It outputs > > > > > tabular results to https://rud.is/mac-r-project-links/ (timestamp at > > > > > top is when the job ran). One table is for HTTP HEAD results and the > > > > > other is for HTTPS HEAD results since the server doesn't auto-upgrade > > > > > HTTP to HTTPS which could mean different status codes depending the > > > > > underlying config. > > > > > > > > > > It's also configured to send me a pushover notification for anything > > > > > but 200 return status code an I'll post here or privately when you > > > > > give me the go-ahead to do that (sinc
Re: [R-SIG-Mac] Using R on MacOS Catalina.....
Why not use the official installer and adjust the installation path? https://cran.r-project.org/bin/macosx/ Also allows multiple versions being installed, all from the CLI (but I guess guess it's a normal desktop machine and you can just use the gui installer). 256GB is a normal size for a disk, don't see the problem. 90% of all macs probably don't have more. Homebrew R differs slightly from the official R installer and might cause problems in some cases. Matthias Krawutschke schrieb am Di., 28. Jan. 2020, 20:15: > Thank you so much for you assistance. > > My problem is not solved, because I must install R, etc. on a different > Volume like SYS-Volume & I can´t find this option under "homebrew". > > > Best regards from Berlin, Germany > Herzlichst grüßt Sie das HPC - Team > > > > Matthias Krawutschke > > Universität Potsdam > ZIM - Zentrum für Informationstechnologie und Medienmanagement > Team High-Performance-Computing > Campus Am Neuen Palais: Am Neuen Palais 10 | 14469 Potsdam > Tel: +49 331 977-, Fax: +49 331 977-1750 > > Internet: http://www.uni-potsdam.de/zim > > -Ursprüngliche Nachricht- > Von: Dr Eberhard W Lisse > Gesendet: Dienstag, 28. Januar 2020 11:09 > An: Byron Ellis ; Matthias Krawutschke < > krawutsc...@uni-potsdam.de> > Cc: e...@lisse.na; R-SIG-Mac@r-project.org > Betreff: Re: [R-SIG-Mac] Using R on MacOS Catalina. > > For me it usually had to resort to the latter when there were connectivity > issues (more common in Namibia than in Potsdam :-)-O). > > And maybe once or twice when I wanted to try something special. > > It also has a 'cask' option with which it installs apps so I do > > brew install r > brew cask install rstudio > > > All in all rock solid. > > el > > On 28/01/2020 11:43, Byron Ellis wrote: > > Homebrew is Linux-style packaging for OS X. Think of it as an > > equivalent to apt-get—either it will retrieve a binary or it will > > attempt to build one. > > > > ___ > 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
[R-SIG-Mac] Robust compiler toolchain for R-devel
Hi, I am experimenting since some days to find the “best” compiler toolchain for R-devel to get R-devel package source installs on the new macOS Github Actions runners work in a somewhat stable way. I am also on macOS locally which I use for testing as well. I am aware of https://github.com/rmacoslib/r-macos-rtools. However, using clang7 for all (CC, CXX, etc) leads to some packages failing to build (sometimes due to missing OpenMP capabilities, sometimes undefined). Therefore I decided to try out gcc (v8 and v9). While this solves most of the OpenMP issues, I am running into problems for other packages regarding CC compilation. Turns out that using any clang version for CC solves most problems but not all. However then I have a mix of gcc and clang which is most likely cause other issues. Currently Jeroen is developing a new gcc8 based toolchain for Windows. I was reading the macOS CRAN dev pages but could not find any reasoning why • clang7 is suggested • gcc is not used • What future plans are there for the toolchain on macOS Could someone shine some light on this? Thanks :) Cheers, Patrick [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Robust compiler toolchain for R-devel
Matthias, Thanks for your reply. My questions was not about how to install gcc on macOS - this is very simple using homebrew (brew install gcc). Also I am familiar with the xcode basics and so on. Homebrew is the de-facto standard package manager on macOS - mentioning it again explicitly because I remember from one of your last posts that you were not familiar with it. My question was rather about the reasoning for the current toolchain of CC and friends on macOS and if there could be more robust settings than using clang7. Cheers On 18. Feb 2020, 10:36 +0100, Matthias Krawutschke , wrote: > Hey Patrick, > > i had the same issue /problem on my MAC. > First of all you need from Apple XCODE the Command-Line. > > I find here a good instruction to do that: > https://wiki.helsinki.fi/display/HUGG/GNU+compiler+install+on+Mac+OS+X > > But, I´m not sure if you can compile the GNU-C 9.x - Version. > Try it and if you have found out, how - please let me know. > > Best regards…. > > > > Matthias Krawutschke, Dipl. Inf. > > Universität Potsdam > ZIM - Zentrum für Informationstechnologie und Medienmanagement > Arbeitsbereich: High-Performance-Computing on Cluster - Environment > > Campus Am Neuen Palais: Am Neuen Palais 10 | 14469 Potsdam > Tel: +49 331 977-, Fax: +49 331 977-1750 > > Internet: https://www.uni-potsdam.de/de/zim/angebote-loesungen/hpc.html > > > -Ursprüngliche Nachricht- > Von: R-SIG-Mac Im Auftrag von Patrick > Schratz > Gesendet: Dienstag, 18. Februar 2020 09:15 > An: Martin Jean via R-SIG-Mac > Betreff: [R-SIG-Mac] Robust compiler toolchain for R-devel > > Hi, > > I am experimenting since some days to find the “best” compiler toolchain for > R-devel to get R-devel package source installs on the new macOS Github > Actions runners work in a somewhat stable way. > I am also on macOS locally which I use for testing as well. > > I am aware of https://github.com/rmacoslib/r-macos-rtools. However, using > clang7 for all (CC, CXX, etc) leads to some packages failing to build > (sometimes due to missing OpenMP capabilities, sometimes undefined). > > Therefore I decided to try out gcc (v8 and v9). While this solves most of the > OpenMP issues, I am running into problems for other packages regarding CC > compilation. > > Turns out that using any clang version for CC solves most problems but not > all. > However then I have a mix of gcc and clang which is most likely cause other > issues. > > Currently Jeroen is developing a new gcc8 based toolchain for Windows. > > I was reading the macOS CRAN dev pages but could not find any reasoning why > > • clang7 is suggested > • gcc is not used > • What future plans are there for the toolchain on macOS > > Could someone shine some light on this? Thanks :) > > Cheers, Patrick > > [[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
Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
Simon, sorry I was wrong with the version.
In fact, I am getting a 403 with the R-3.6 branch. Other branches work fine.
curl -Osv
http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
I
* Trying 184.172.231.50...
* TCP_NODELAY set
* Connected to mac.r-project.org (184.172.231.50) port 80 (#0)
> GET /el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz HTTP/1.1
> Host: mac.r-project.org
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Date: Fri, 21 Feb 2020 14:08:51 GMT
< Server: Apache
< Content-Length: 266
< Content-Type: text/html; charset=iso-8859-1
<
{ [266 bytes data]
* Connection #0 to host mac.r-project.org left intact
* Closing connection 0
Can anyone reproduce this or is this really on my side? If you, any hints on
resolving this?
On 20. Feb 2020, 20:36 +0100, Simon Urbanek ,
wrote:
> Patrick,
>
> it works just fine for me:
>
> $ curl -s -v -o /dev/null https://mac.r-project.org/bin/macosx/R-latest.pkg
> * Trying 184.172.231.50...
> * TCP_NODELAY set
> * Connected to mac.r-project.org (184.172.231.50) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> * successfully set certificate verify locations:
> [...]
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> * ALPN, server accepted to use http/1.1
> * Server certificate:
> * subject: CN=mac.r-project.org
> * start date: Jan 26 18:55:18 2020 GMT
> * expire date: Apr 25 18:55:18 2020 GMT
> * subjectAltName: host "mac.r-project.org" matched cert's "mac.r-project.org"
> * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
> * SSL certificate verify ok.
> > GET /bin/macosx/R-latest.pkg HTTP/1.1
> > Host: mac.r-project.org
> > User-Agent: curl/7.54.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Thu, 20 Feb 2020 19:31:51 GMT
> < Server: Apache
> < Last-Modified: Sun, 15 Dec 2019 14:09:32 GMT
> < ETag: "4d4a72f-599bea4d7df00"
> < Accept-Ranges: bytes
> < Content-Length: 81045295
> <
>
> Please make sure you clear your caches and try directly without proxies.
>
> Cheers,
> Simon
>
>
>
> > On 20/02/2020, at 9:41 PM, Patrick Schratz
> > wrote:
> >
> > @Simon
> >
> > As of today the link still returns a 403 - other R versions work.
> > Could you have a look? Especially because the Travis CI runner by Jim
> > relies on it, this is somewhat pressing.
> >
> > Thanks.
> > On 18. Feb 2020, 07:43 +0100, Matthias Krawutschke
> > , wrote:
> > > Dear Simon,
> > >
> > > thank you so much.
> > > If I want to download the latest R-package with this link - i´ve got the
> > > cryptic signs in the window, but not the file ☹
> > >
> > > Best regars….
> > >
> > >
> > >
> > > Matthias Krawutschke, Dipl. Inf.
> > >
> > > Universität Potsdam
> > > ZIM - Zentrum für Informationstechnologie und Medienmanagement
> > > Team High-Performance-Computing on Cluster - Environment
> > >
> > > Campus Am Neuen Palais: Am Neuen Palais 10 | 14469 Potsdam
> > > Tel: +49 331 977-, Fax: +49 331 977-1750
> > >
> > > Internet: https://www.uni-potsdam.de/de/zim/angebote-loesungen/hpc.html
> > >
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: R-SIG-Mac Im Auftrag von Simon
> > > Urbanek
> > > Gesendet: Freitag, 14. Februar 2020 19:15
> > > An: Jim Hester
> > > Cc: r-sig-mac@r-project.org
> > > Betreff: Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
> > >
> > > Thanks, should be fixed now (adding index removed symlink following
> > > permission).
> > > Simon
> > >
> > >
> > > > On Feb 15, 2020, at 4:50 AM, Jim Hester
> > > > wrote:
> > > >
> > > > The link https://mac.r-project.org/bin/macosx/R-latest.pkg which
> > > > previously served the latest version of R is now returning a 403. Is
> > > > this an intentional change, or is it an unintentional? This link is
> > > > used by the Travis-CI build scripts for macOS, so if the link is no
> > > > longer valid we will need to update the script.
> > > >
> > > > Thanks,
> > > >
> > > > Jim
> > > >
> > >
> > > ___
> > > R-SIG-Mac mailing list
> > > R-SIG-Mac@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> > >
> > > ___
> > > 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
Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
@Simon As of today the link still returns a 403 - other R versions work. Could you have a look? Especially because the Travis CI runner by Jim relies on it, this is somewhat pressing. Thanks. On 18. Feb 2020, 07:43 +0100, Matthias Krawutschke , wrote: > Dear Simon, > > thank you so much. > If I want to download the latest R-package with this link - i´ve got the > cryptic signs in the window, but not the file ☹ > > Best regars…. > > > > Matthias Krawutschke, Dipl. Inf. > > Universität Potsdam > ZIM - Zentrum für Informationstechnologie und Medienmanagement > Team High-Performance-Computing on Cluster - Environment > > Campus Am Neuen Palais: Am Neuen Palais 10 | 14469 Potsdam > Tel: +49 331 977-, Fax: +49 331 977-1750 > > Internet: https://www.uni-potsdam.de/de/zim/angebote-loesungen/hpc.html > > > -Ursprüngliche Nachricht- > Von: R-SIG-Mac Im Auftrag von Simon Urbanek > Gesendet: Freitag, 14. Februar 2020 19:15 > An: Jim Hester > Cc: r-sig-mac@r-project.org > Betreff: Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error > > Thanks, should be fixed now (adding index removed symlink following > permission). > Simon > > > > On Feb 15, 2020, at 4:50 AM, Jim Hester wrote: > > > > The link https://mac.r-project.org/bin/macosx/R-latest.pkg which > > previously served the latest version of R is now returning a 403. Is > > this an intentional change, or is it an unintentional? This link is > > used by the Travis-CI build scripts for macOS, so if the link is no > > longer valid we will need to update the script. > > > > Thanks, > > > > Jim > > > > ___ > R-SIG-Mac mailing list > R-SIG-Mac@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > ___ > 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
Re: [R-SIG-Mac] R 3.6.3 for MacOS
You can use the installer/binaries from the R developer page in the meantime: https://mac.r-project.org/ Am 5. März 2020, 18:39 +0100 schrieb Shepherd, Lori : > Is there any update on when R 3.6.3 will be available for download from > https://cloud.r-project.org/bin/macosx/ ? > It seems like there was a release of R 3.6.3 for linux and windows on > February 29th that is available but nothing yet for Mac. > > > > Lori Shepherd > > Bioconductor Core Team > > Roswell Park Comprehensive Cancer Center > > Department of Biostatistics & Bioinformatics > > Elm & Carlton Streets > > Buffalo, New York 14263 > > > This email message may contain legally privileged and/or confidential > information. If you are not the intended recipient(s), or the employee or > agent responsible for the delivery of this message to the intended > recipient(s), you are hereby notified that any disclosure, copying, > distribution, or use of this email message is prohibited. If you have > received this message in error, please notify the sender immediately by > e-mail and delete this email message from your computer. Thank you. > [[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
Re: [R-SIG-Mac] Problem R-4.0 beta and Rmpfr (pre-release)
Works just fine for me on 10.15.4 and r78227. You might want to check your compiler setup against the recommended toolchain and reinstall all packages for R 4.0. ``` r library(gmp) #> #> Attaching package: 'gmp' #> The following objects are masked from 'package:base': #> #> %*%, apply, crossprod, matrix, tcrossprod library(Rmpfr) #> C code of R package 'Rmpfr': GMP using 64 bits per limb #> #> Attaching package: 'Rmpfr' #> The following object is masked from 'package:gmp': #> #> outer #> The following objects are masked from 'package:stats': #> #> dbinom, dgamma, dnorm, dpois, pnorm #> The following objects are masked from 'package:base': #> #> cbind, pmax, pmin, rbind x <- 1400+ 0:10 print(dpois(x, 1000), digits =18) #> [1] 1.46677334419659338e-33 1.04694742626454156e-33 7.46752800474106016e-34 #> [4] 5.32254312525935864e-34 3.79098513195210765e-34 2.69821005832831136e-34 #> [7] 1.91906832029070091e-34 1.36394336907638670e-34 9.68709779173582432e-35 #> [10] 6.87515812046484244e-35 4.87599866699657026e-35 dpois(mpfr(x, 120), 1000)## #> 11 'mpfr' numbers of precision 120 bits #> [1] 1.4667733441965683030895281895730571526e-33 #> [2] 1.0469474262645027145535533116153155973e-33 #> [3] 7.4675280047396769939625771156584564775e-34 #> [4] 5.3225431252599265815841604530708884358e-34 #> [5] 3.7909851319515146592479775306772709641e-34 #> [6] 2.698210058328480184518133473791651932e-34 #> [7] 1.9190683202905264470256994834933513035e-34 #> [8] 1.363943369076422492788795261914005e-34 #> [9] 9.6870977917359552028095090875439730376e-35 #> [10] 6.8751581204655466308087360450986323895e-35 #> [11] 4.8759986669968415821338553511337818329e-35 ``` Created on 2020-04-16 by the [reprex package](https://reprex.tidyverse.org) (v0.3.0) On 16. Apr 2020, 08:56 +0200, Berend Hasselman , wrote: > > If the pre-release binary of Rmpfr is intended for the R-4.0 beta then I am > experiencing "illegal operations" with "illegal opcode" errors. > > > > R version 4.0.0 beta (2020-04-14 r78227) > Platform: x86_64-apple-darwin17.0 (64-bit) > Running under: macOS Catalina 10.15.4 > > Matrix products: default > BLAS: > /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib > LAPACK: > /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib > > locale: > [1] en_IE.UTF-8/en_IE.UTF-8/en_IE.UTF-8/C/en_IE.UTF-8/en_IE.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.0.0 > > > > A simple example session is > > <(in+output)> > > > library(gmp,lib.loc=".");library(Rmpfr,lib.loc=".") > > Attaching package: 'gmp' > > The following objects are masked from 'package:base': > > %*%, apply, crossprod, matrix, tcrossprod > > C code of R package 'Rmpfr': GMP using 64 bits per limb > > > Attaching package: 'Rmpfr' > > The following object is masked from 'package:gmp': > > outer > > The following objects are masked from 'package:stats': > > dbinom, dgamma, dnorm, dpois, pnorm > > The following objects are masked from 'package:base': > > cbind, pmax, pmin, rbind > > > x <- 1400+ 0:10 > > print(dpois(x, 1000), digits =18) ## standard R's double precision > [1] 1.46677334419659338e-33 1.04694742626454156e-33 7.46752800474106016e-34 > [4] 5.32254312525935864e-34 3.79098513195210765e-34 2.69821005832831136e-34 > [7] 1.91906832029070091e-34 1.36394336907638670e-34 9.68709779173582432e-35 > [10] 6.87515812046484244e-35 4.87599866699657026e-35 > > dpois(mpfr(x, 120), 1000)## more accuracy for the same > > *** caught illegal operation *** > address 0x10a6e1c42, cause 'illegal opcode' > > Traceback: > 1: .class1(object) > 2: as(value, dataClass) > 3: setDataPart(x, .Call(Math_mpfr, x, .Math.codes[[.Generic]])) > 4: exp(-lambda) > 5: exp(-lambda) > 6: dpois(mpfr(x, 120), 1000) > > Possible actions: > 1: abort (with core dump, if enabled) > 2: normal R exit > 3: exit R without saving workspace > 4: exit R saving workspace > > > Other trials seem to experience similar issues. > > > regards > > Berend > > ___ > 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
Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!
Thanks Simon,
This simplifies things a lot and clears up the process. While the instructions
on https://mac.r-project.org/ are more clear now I think there is still
simplification needed for the install process and custom modifications that are
needed.
This not only applies to the dev page but finally also to production end users
if the SDK 10.15 issues (see below) persists.
I’ve scripted all installation steps (R-devel, gfortran, SDK 10.13) and will
probably write a blog post about it to make the R community more aware about
it. Let me know if anything is wrong about it - otherwise I’ll use the code
below in the blog post.
# install R-devel
wget
https://mac.r-project.org/el-capitan/R-devel/R-devel-el-capitan-sa-x86_64.tar.gz
sudo tar fvxz R*.tar.gz -C /
rm R-devel-el-capitan-sa-x86_64.tar.gz
# install gfortran
wget
https://github.com/fxcoudert/gfortran-for-macOS/releases/download/8.2/gfortran-8.2-Mojave.dmg
sudo hdiutil attach gfortran*.dmg
sudo installer -package /Volumes/gfortran*/gfortran*/gfortran*.pkg -target /
sudo hdiutil detach /Volumes/gfortran-8.2-Mojave
# install SDK10.13
wget
https://github.com/phracker/MacOSX-SDKs/releases/download/10.15/MacOSX10.13.sdk.tar.xz
tar fvxz MacOSX10.13.sdk.tar.xz
sudo mv MacOSX10.13.sdk /Library/Developer/CommandLineTools/SDKs/
rm -rf MacOSX10.13*
In addition people need to set custom CFLAGS in ~/.R/Makevars to actually use
it:
CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
In addition there really seem to be major problems regarding the 10.15 SDK. For
example, {igraph} which is a package on which lots of other packages depend,
cannot be installed from source with SDK 10.15 but works with SDK 10.13.
Patrick
On 1. Apr 2020, 09:38 +0200, Simon Urbanek , wrote:
> Hervé,
>
>
> > On 1/04/2020, at 6:19 PM, Hervé Pagès wrote:
> >
> > Thanks Simon. A couple of days ago we've started to use the R 4.0.0 alpha
> > build from https://mac.r-project.org/ for the Bioconductor build system.
> > Bioconductor packages depend on thousands of CRAN packages and one thing
> > that makes it hard for us and for our users to build/check Bioconductor
> > packages at the moment is the absence of Mac binary packages for R 4.0.0 on
> > CRAN. Do you have an estimate of when they will become available?
> >
>
> Both the packages and R are now available. I always recommend using the
> Mac-master https://mac.R-project.org as "mirror" since that one is most
> up-to-date.
>
>
> > Another question is where they are going to be hosted on CRAN. We need to
> > follow CRAN's layout for Bioconductor package repositories.
> >
>
>
> We have removed the extra layer, the package type is back to "mac.binary", so
> bin/macosx/contrib is the location.
>
> Cheers,
> Simon
>
>
>
> > Thanks!
> > H.
> >
> >
> > On 3/31/20 21:27, Simon Urbanek wrote:
> > > Dear Mac users,
> > > R 4.0.0 will be using an entirely new toolchain, entirely new build
> > > system on entirely new macOS version and hardware. Therefore I would like
> > > to ask you kindly to test the binaries from
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.R-2Dproject.org=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=FJYxweW9WiMXbNMPpMM0bHXy020Gx9P-dHMrWmt7YzE=
> > > before the release as much as you can. Raising any issues after the
> > > release is too late! So please, please, test the pre-releases. Report any
> > > issues either directly to me or this mailing list.
> > > The nightly builds are signed, but not necessarily notarized. However,
> > > the build fulfils Apple's conditions and is known to pass notarization
> > > (in fact the the package available for download today is actually
> > > notarized) so it should be a good test for the release which will be
> > > notarized and should work on Catalina.
> > > For those that want to replicate our setup - technical details: we are
> > > now building with macOS 10.13 (High Sierra) as target (i.e. the oldest
> > > supported system), regular Apple Xcode/command line tools and GNU Fortran
> > > 8.2. R builds are running on macOS 10.15 (Catalina) with Xcode 11.4 using
> > > macOS 10.13 target. Packages are built on macOS 10.13 VMs with just Apple
> > > command line tools (this should make it easy to replicate the setup using
> > > Travis, for example). All 3rd party libraries that CRAN uses are
> > > available in
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mac.r-2Dproject.org_libs-2D4_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=3ZbcXBticg_8MfXltGKdQ9SFNqqeLqqwK_pUhEet7QY=
> > > The new R build system is in
> > >
Re: [R-SIG-Mac] OpenMP on CRAN
Simon, thanks. While this feels like a somewhat 1/1 discussion now, I also think that others might profit from it. 1. I am aware that LLVM is a wrapper bundling more than just the compiler and that it comes with its own copy of clang 2. I don’t use homebrew because it does not easily allow multiple R installations next to each other. This is possible via the official installers. Combining this with RSwitch from Bob I can switch between R interpreters with a keystroke. I am using homebrew for everything else and even contribute to some formulas from time to time. 3. In the end everyone if responsible for their own setup and deviating from standards make its more complicated to get help (if at all). However, I am still considering blogging about my setup in the future once I have found a robust one that worked for some time across all instances I faced issues with in the past (focusing on source installs). And don’t worry, I will make sure to point out that this is custom, what the CRAN setup is and the differences between homebrew and the CRAN thing. There are quite some myths floating around that this should be clarified in more depth on a static page (maybe even from you as the expert? ;) ) Regarding CI and testing SDK 10.15: A pointer to this discussion where the toolchain for GitHub Actions is discussed. I’ll move my thoughts about this to a new thread. On 3. Apr 2020, 22:11 +0200, Simon Urbanek , wrote: > Patrick, > > > > On 4/04/2020, at 1:33 AM, Patrick Schratz wrote: > > > > Simon, > > > > thanks. I assume that you mean “clang from homebrew” = llvm (from homebrew)? > > LLVM is the compiler infrastructure project, clang is the C/C++ compiler from > that project. We don't use any of the other compilers form LLVM. > > > > Indeed I am currently trying that out and it looks really robust for source > > installations (more than the systems clang (+ eventual openMP flags like > > suggested by Kevin) and other variants (gcc from homebrew or openMP enabled > > clang7 or 8). > > > > Note that I do not use R via homebrew. > > > > However, all in all I am essentially mixing the custom llvm from homebrew > > with the official R installer and the old 10.13 SDK. > > It looks quite complex and I’d wish everything would be easier. However, in > > the end I just want to have a stable “install from source” environment that > > works for all packages out there (I do not use the binaries). > > > > Why don't use use Homebrew? That's exactly what Homebrew provides - its own > ecosystem, everything form source (with cached binaries if you want them). > > > > All in all I am a bit confused now about all the mixing and options > > available. Let’s see what the foreseeable future brings and where things > > are going. > > > > Mixing is not available. You pick one system and go with it, but can't mix > between them, because of the different run-time libraries. > > > > Regarding the SDK issue: I think most users just use the binaries on macOS > > (across all OS versions) and rarely face such issues. And there are > > presumably not many people out there that do actual R-devel testing on > > Catalina (?), otherwise I’d expect way more people to jump into the > > discussion. However, I am not alone with these issues as you can see in the > > Rcpp issue we were talking about. > > Maybe you can even reproduce the issues by linking a custom install of the > > 10.15 SDK on a non-Catalina machine? I don’t know how much trouble that > > would bring up when trying to jump into the future - but this ist just an > > idea :) > > > > That's an entirely different, unrelated topic. Testing cutting edge (or even > pre-release) systems makes sense, but that's not our current worry (there was > a separate thread about CI). > > Cheers, > Simon > > > > Thanks for your work! > > On 3. Apr 2020, 14:13 +0200, Simon Urbanek , > > wrote: > > > Patrick, > > > > > > you were commenting on the thread where we talked about CRAN R - that one > > > is now compiled using Apple clang. You were talking about using clang > > > from Homebrew - those are incompatible as they use different run-time. > > > Unfortunately, the Intel OpenMP run-time varies by clang compiler version > > > and is known to fail when used with the wrong compiler. Analogously, > > > mixing gomp (from gcc) and iomp is problematic (and GNU Fortran uses > > > gomp). As discussed in the Homebrew thread, if you are compiling > > > everything via Homebrew including R then it's all good, you just can't > > > mix Apple tools and Homebrew in general. > &g
[R-SIG-Mac] R4.0 toolchain for GitHub Actions
Hi,
Porting this discussion about the future R 4.0 toolchain on GitHub Actions
(GHA) to the mailing list.
GHA will be the new standard regarding CI for the R community in the
foreseeable future since the tidyverse is moving there with full power and the
community usually follows.
Even leaving the tidyverse out, Jim (in cc since I don’t know if he is in the
list) maintains the installers for R which will be used by everyone, even if
one deviates from the general tidyverse templates (like {tic} does).
The discussion is about whether these installers try to mimic the CRAN
toolchain (system clang and SDK 10.13 (?)) or go a different way.
There are many options as we have seen in prior discussions about the compilers
on this mailing list. However, most are restricted by the fact that there is
only Catalina (10.15) available as the base system for the runners. While the
tidyverse wants to use binaries mainly, the toolchain installed should also be
able to have a robust source installation behavior: One might want to test on
R-devel for which there are no binaries - or test in general if source
installations works.
Now if the GHA toolchain deviates from CRAN one might get different results
when testing on GHA and when uploading to CRAN. This might cause confusion.
Installing custom compilers and linking such in .R/Makevars is tedious to set
up and requires download time and bandwidth for each run.
So we should think in detail about how to proceed here and also how to
communicate the setup to the users.
Users do not browse the source code by default and check with compilers are
used, which CFLAGS are set and so on. They just “hope” that they can trust the
setup and that things “will just work”, on the CI and on CRAN then.
For whatever will be decided in the end: I wish that the reasons for the final
setup are communicated top-level.
Let’s discuss this here as a community: Simon as the one responsible for the
CRAN toolchain and Jim who implements the R installer for GHA. It would be
great if we could find a consensus for R 4.0 that everyone agrees on rather
than being sad afterwards that no-one can do anything about how things are (and
how others have chosen their toolchain).
The possibility for change is there now due to the major version bump and we
should take advantage of it.
Best, Patrick
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!
R versions on macOS are installed next to each other - you just need to “switch” between them during initialization. In the end R CMD * will use the R interpreter that is first in your $PATH. https://rud.is/rswitch/ helps - but you can also do so without by writing custom CLI wrappers. On 2. Apr 2020, 23:13 +0200, Spencer Graves , wrote: > Is there a procedure for dual install, e.g., so I could run "R4 > CMD check", etc.? > > > Please excuse if this has already been answered. > > > Thanks, > Spencer Graves > > > On 2020-04-02 02:50, Rainer M Krug wrote: > > > > > On 1 Apr 2020, at 16:07, Patrick Schratz > > > wrote: > > > > > > The same goes here regarding support. > > > > > > I am (co-)maintaining a package on ropensci focusing on provider-agnostic > > > CI approaches for R (tic) and have quite some experience with all the > > > little culprits there. > > > > > > Since you mentioned Travis: Be aware that the R community is (slowly but > > > actively) moving away from Travis for a few reasons. > > > Also on GitHub Actions you can only build on 10.15 (Catalina) right now. > > So where is the R community moving too? > > > > Rainer > > > > > Best, Patrick > > > On 1. Apr 2020, 15:41 +0200, Bob Rudis , wrote: > > > > I shall pile on with an additional offer of assistance, Simon and a > > > > huge #ty for this and all the work you do. > > > > > > > > > On Apr 1, 2020, at 09:30, Balamuta, James Joseph > > > > > wrote: > > > > > > > > > > Simon, > > > > > > > > > > Thanks for the overview! A few quick questions: > > > > > > > > > > 1. Compiler-wise, the external clang compiler requirement was removed > > > > > and, so, there is no guarantee of OpenMP on macOS again? > > > > > 2. Why was 10.13 chosen as the oldest system instead of 10.14 given > > > > > the new push for increased security by Apple? > > > > > 3. How likely is the oldest system requirement to be bumped in a > > > > > patch release? > > > > > > > > > > Also, if you need help with mac-builder, Travis, or GitHub Actions, > > > > > I'm more than happy to help! > > > > > > > > > > Best, > > > > > > > > > > JJB > > > > > > > > > > On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of Simon Urbanek" > > > > > > > > > simon.urba...@r-project.org> wrote: > > > > > > > > > > Dear Mac users, > > > > > > > > > > R 4.0.0 will be using an entirely new toolchain, entirely new build > > > > > system on entirely new macOS version and hardware. Therefore I would > > > > > like to ask you kindly to test the binaries from > > > > > > > > > > https://mac.R-project.org > > > > > > > > > > before the release as much as you can. Raising any issues after the > > > > > release is too late! So please, please, test the pre-releases. Report > > > > > any issues either directly to me or this mailing list. > > > > > > > > > > The nightly builds are signed, but not necessarily notarized. > > > > > However, the build fulfils Apple's conditions and is known to pass > > > > > notarization (in fact the the package available for download today is > > > > > actually notarized) so it should be a good test for the release which > > > > > will be notarized and should work on Catalina. > > > > > > > > > > For those that want to replicate our setup - technical details: we > > > > > are now building with macOS 10.13 (High Sierra) as target (i.e. the > > > > > oldest supported system), regular Apple Xcode/command line tools and > > > > > GNU Fortran 8.2. R builds are running on macOS 10.15 (Catalina) with > > > > > Xcode 11.4 using macOS 10.13 target. Packages are built on macOS > > > > > 10.13 VMs with just Apple command line tools (this should make it > > > > > easy to replicate the setup using Travis, for example). All 3rd party > > > > > libraries that CRAN uses are available in > > > > > http://mac.r-project.org/libs-4/ > > > > > > > > > > The new R build system is in > > > > >
Re: [R-SIG-Mac] OpenMP on CRAN
Thanks Kevin, interesting approach.
However, when testing it against a few packages I get symbol pointer issues
(e.g. for data.table and xgboost).
Using llvm everything works.
Could llvm be the best middle way? Easy installation via brew and still clang
compliant.
Currently my Makevars look as follows
CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
[…]
CC = ccache /usr/local/opt/llvm/bin/clang
[…]
Where llvm was installed via `brew install llvm`.
SDK 10.13 because of {igraph} and {Rcpp} issues with SDK 10.14 and SDK 10.15
On 2. Apr 2020, 23:01 +0200, Simon Urbanek , wrote:
> Tim,
>
>
> > On 3/04/2020, at 2:01 AM, BATES Timothy wrote:
> >
> > Moving to a compiler that drops support for OpenMP seems a sad choice,
> > especially now we’ve all climbed the learning curve of the non-Apple
> > compiler (the real barrier was lack of a pkg installer and that’s done now).
> >
>
> It has caused a lot of issues, it trips people on a daily basis which is just
> not worth it. Also with Apple's increasingly strict rules about what can be
> distributed we don't want to be in the business in maintaining a separate
> toolchain. There have been numerous issues with C++ exceptions so the fall
> out was much bigger than originally expected and it would only get worse.
>
>
> > Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would
> > be a big loss for users (for whom the CRAN version now supports OpenMP
> > giving them a 2-12x speed up). In general, R on Mac is made more viable by
> > having OpenMP
> >
> > Re Brian’s points, I’d say that the distribution problem is crucial:
> > Packages not on CRAN have dramatically diminished accessibility/useage.
> >
>
> The idea is that if a package deems this critical, it can enable this for the
> users. As it is now, packages can still supply iomp and use it.
>
> That said, I would open for discussion the ability to distribute iomp with
> the R binary, but it would not be supported by R directly, i.e., it would be
> on the package author to make sure that the way the package operates is
> compatible with that binary. Let me know what you think.
>
>
> > Second, a great range of compute-intensive problems are amenable to
> > division amongst cores, including nearly all models that take more than a
> > nominal amount of time to run: So simulations, CIs, bootstrapping, nearly
> > everything in genetics all speeds up.
> >
>
> Yes, but OpenMP is rarely used for those tasks. In R OpenMP can be only used
> for very small subset of such tasks - which is why alternative approaches are
> much more common.
>
> Cheers,
> Simon
>
>
> > I’d say especially on desktop/laptop. The big advantage of multi blade
> > systems requires snowfall-type solutions, but desktops profit automatically
> > from their multi-core structure and don;’t have multiple processors (except
> > graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP
> > is their one trick. I’d hope not to lose it.
> >
> > Best, t
> >
> >
> > > On 2 Apr 2020, at 05:18, Prof Brian Ripley wrote:
> > >
> > > On 01/04/2020 22:02, Simon Urbanek wrote:
> > > > JJB,
> > > > 1. correct, there was too much trouble in this. But please feel free to
> > > > start a new thread about this here if you have strong opinions.
> > >
> > > Also note that it is possible (and not hard) to install packages from
> > > source with an OpenMP-supporting compiler, and how to do so is in the
> > > R-admin manual. The problems come in distributing them.
> > >
> > > The benefits of OpenMP are often overestimated, especially on
> > > desktop/laptop level hardware. But it is available for the small (tiny?)
> > > proportion of users who need it.
> > The University of Edinburgh is a charitable body, registered in Scotland,
> > with registration number SC005336.
> > ___
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
> ___
> 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
Re: [R-SIG-Mac] OpenMP on CRAN
Simon, thanks. I assume that you mean “clang from homebrew” = llvm (from homebrew)? Indeed I am currently trying that out and it looks really robust for source installations (more than the systems clang (+ eventual openMP flags like suggested by Kevin) and other variants (gcc from homebrew or openMP enabled clang7 or 8). Note that I do not use R via homebrew. However, all in all I am essentially mixing the custom llvm from homebrew with the official R installer and the old 10.13 SDK. It looks quite complex and I’d wish everything would be easier. However, in the end I just want to have a stable “install from source” environment that works for all packages out there (I do not use the binaries). All in all I am a bit confused now about all the mixing and options available. Let’s see what the foreseeable future brings and where things are going. Regarding the SDK issue: I think most users just use the binaries on macOS (across all OS versions) and rarely face such issues. And there are presumably not many people out there that do actual R-devel testing on Catalina (?), otherwise I’d expect way more people to jump into the discussion. However, I am not alone with these issues as you can see in the Rcpp issue we were talking about. Maybe you can even reproduce the issues by linking a custom install of the 10.15 SDK on a non-Catalina machine? I don’t know how much trouble that would bring up when trying to jump into the future - but this ist just an idea :) Thanks for your work! On 3. Apr 2020, 14:13 +0200, Simon Urbanek , wrote: > Patrick, > > you were commenting on the thread where we talked about CRAN R - that one is > now compiled using Apple clang. You were talking about using clang from > Homebrew - those are incompatible as they use different run-time. > Unfortunately, the Intel OpenMP run-time varies by clang compiler version and > is known to fail when used with the wrong compiler. Analogously, mixing gomp > (from gcc) and iomp is problematic (and GNU Fortran uses gomp). As discussed > in the Homebrew thread, if you are compiling everything via Homebrew > including R then it's all good, you just can't mix Apple tools and Homebrew > in general. > > Also at the bottom I was only talking about 10.14 SDK - that's what we use on > CRAN and I have not seen any issues with it - you were claiming that it > doesn't work with Rcpp and igraph. > > Cheers, > Simon > > > > > On 4/04/2020, at 1:00 AM, Patrick Schratz wrote: > > > > Simon, > > > > I don’t understand fully. I am using llvm for all C variants (just now > > shown) in combination with the 10.13 SDK. > > So far this combination works flawlessly for all “problematic” packages > > like data.table, igraph or Rcpp. > > > > I don’t have deeper knowledge about the “iomp” setup but as of right now I > > don’t know what I am mixing up here. Can you shine more light on this? > > If it is about llvm in general: data.table recommends to use llvm openly in > > their wiki due to the lack of openMP for the standard clang. > > And while this could be handled as “any other package” in R, we all know > > that it has quite some impact and probably devs who know what they do in > > terms of C configs. > > > > Regarding the SDK issue: Both Rcpp v1.0.4 and igraph 1.2.5 can’t be > > installed from source with SDK 10.15 and standard apple clang (or any C > > compiler). Switching to SDK 10.13 solves the issue. You were even > > commenting on the Rcpp issue. > > Since SDK 10.15 is the current release and many users have no choice on > > which OS version they are (for different reasons), this issue should imo be > > inspected in more detail. What do you think? > > > > Best, Patrick > > On 2. Apr 2020, 23:38 +0200, Simon Urbanek , > > wrote: > > > Patrick, > > > > > > you can't mix compilers - it really matters which iomp your'e using. llvm > > > has its own modified version which may not be the same as the official > > > Intel release. From your tests it looks like you're using the llvm one > > > which will likely work only with that compiler. Since Apple doesn't have > > > official omp support it's hard to say which versions work and which don't. > > > > > > > > > > On 3/04/2020, at 10:20 AM, Patrick Schratz > > > > wrote: > > > > > > > > Thanks Kevin, interesting approach. > > > > > > > > However, when testing it against a few packages I get symbol pointer > > > > issues (e.g. for data.table and xgboost). > > > > Using llvm everything works. > > > > Could llvm be the best middle way? Easy installation via
Re: [R-SIG-Mac] OpenMP on CRAN
Simon,
I don’t understand fully. I am using llvm for all C variants (just now shown)
in combination with the 10.13 SDK.
So far this combination works flawlessly for all “problematic” packages like
data.table, igraph or Rcpp.
I don’t have deeper knowledge about the “iomp” setup but as of right now I
don’t know what I am mixing up here. Can you shine more light on this?
If it is about llvm in general: data.table recommends to use llvm openly in
their wiki due to the lack of openMP for the standard clang.
And while this could be handled as “any other package” in R, we all know that
it has quite some impact and probably devs who know what they do in terms of C
configs.
Regarding the SDK issue: Both Rcpp v1.0.4 and igraph 1.2.5 can’t be installed
from source with SDK 10.15 and standard apple clang (or any C compiler).
Switching to SDK 10.13 solves the issue. You were even commenting on the Rcpp
issue.
Since SDK 10.15 is the current release and many users have no choice on which
OS version they are (for different reasons), this issue should imo be inspected
in more detail. What do you think?
Best, Patrick
On 2. Apr 2020, 23:38 +0200, Simon Urbanek , wrote:
> Patrick,
>
> you can't mix compilers - it really matters which iomp your'e using. llvm has
> its own modified version which may not be the same as the official Intel
> release. From your tests it looks like you're using the llvm one which will
> likely work only with that compiler. Since Apple doesn't have official omp
> support it's hard to say which versions work and which don't.
>
>
> > On 3/04/2020, at 10:20 AM, Patrick Schratz
> > wrote:
> >
> > Thanks Kevin, interesting approach.
> >
> > However, when testing it against a few packages I get symbol pointer issues
> > (e.g. for data.table and xgboost).
> > Using llvm everything works.
> > Could llvm be the best middle way? Easy installation via brew and still
> > clang compliant.
> >
> > Currently my Makevars look as follows
> >
> > CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> > […]
> >
> > CC = ccache /usr/local/opt/llvm/bin/clang
> > […]
> >
> > Where llvm was installed via `brew install llvm`.
> > SDK 10.13 because of {igraph} and {Rcpp} issues with SDK 10.14 and SDK 10.15
>
>
> I mentioned that before, but I do not see issues with 10.14 SDK.
>
> Cheers,
> Simon
>
>
> > On 2. Apr 2020, 23:01 +0200, Simon Urbanek ,
> > wrote:
> > > Tim,
> > >
> > >
> > > > On 3/04/2020, at 2:01 AM, BATES Timothy wrote:
> > > >
> > > > Moving to a compiler that drops support for OpenMP seems a sad choice,
> > > > especially now we’ve all climbed the learning curve of the non-Apple
> > > > compiler (the real barrier was lack of a pkg installer and that’s done
> > > > now).
> > > >
> > >
> > > It has caused a lot of issues, it trips people on a daily basis which is
> > > just not worth it. Also with Apple's increasingly strict rules about what
> > > can be distributed we don't want to be in the business in maintaining a
> > > separate toolchain. There have been numerous issues with C++ exceptions
> > > so the fall out was much bigger than originally expected and it would
> > > only get worse.
> > >
> > >
> > > > Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages)
> > > > would be a big loss for users (for whom the CRAN version now supports
> > > > OpenMP giving them a 2-12x speed up). In general, R on Mac is made more
> > > > viable by having OpenMP
> > > >
> > > > Re Brian’s points, I’d say that the distribution problem is crucial:
> > > > Packages not on CRAN have dramatically diminished accessibility/useage.
> > > >
> > >
> > > The idea is that if a package deems this critical, it can enable this for
> > > the users. As it is now, packages can still supply iomp and use it.
> > >
> > > That said, I would open for discussion the ability to distribute iomp
> > > with the R binary, but it would not be supported by R directly, i.e., it
> > > would be on the package author to make sure that the way the package
> > > operates is compatible with that binary. Let me know what you think.
> > >
> > >
> > > > Second, a great range of compute-intensive problems are amenable to
> > > > division amongst cores, including nearly all models that take more than
> > > > a nominal amount of time to run: So simulations, CIs, bootstrapping,
>
Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!
The same goes here regarding support. I am (co-)maintaining a package on ropensci focusing on provider-agnostic CI approaches for R (tic) and have quite some experience with all the little culprits there. Since you mentioned Travis: Be aware that the R community is (slowly but actively) moving away from Travis for a few reasons. Also on GitHub Actions you can only build on 10.15 (Catalina) right now. Best, Patrick On 1. Apr 2020, 15:41 +0200, Bob Rudis , wrote: > I shall pile on with an additional offer of assistance, Simon and a huge #ty > for this and all the work you do. > > > On Apr 1, 2020, at 09:30, Balamuta, James Joseph > > wrote: > > > > Simon, > > > > Thanks for the overview! A few quick questions: > > > > 1. Compiler-wise, the external clang compiler requirement was removed and, > > so, there is no guarantee of OpenMP on macOS again? > > 2. Why was 10.13 chosen as the oldest system instead of 10.14 given the new > > push for increased security by Apple? > > 3. How likely is the oldest system requirement to be bumped in a patch > > release? > > > > Also, if you need help with mac-builder, Travis, or GitHub Actions, I'm > > more than happy to help! > > > > Best, > > > > JJB > > > > On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of Simon Urbanek" > > > > wrote: > > > > Dear Mac users, > > > > R 4.0.0 will be using an entirely new toolchain, entirely new build system > > on entirely new macOS version and hardware. Therefore I would like to ask > > you kindly to test the binaries from > > > > https://mac.R-project.org > > > > before the release as much as you can. Raising any issues after the release > > is too late! So please, please, test the pre-releases. Report any issues > > either directly to me or this mailing list. > > > > The nightly builds are signed, but not necessarily notarized. However, the > > build fulfils Apple's conditions and is known to pass notarization (in fact > > the the package available for download today is actually notarized) so it > > should be a good test for the release which will be notarized and should > > work on Catalina. > > > > For those that want to replicate our setup - technical details: we are now > > building with macOS 10.13 (High Sierra) as target (i.e. the oldest > > supported system), regular Apple Xcode/command line tools and GNU Fortran > > 8.2. R builds are running on macOS 10.15 (Catalina) with Xcode 11.4 using > > macOS 10.13 target. Packages are built on macOS 10.13 VMs with just Apple > > command line tools (this should make it easy to replicate the setup using > > Travis, for example). All 3rd party libraries that CRAN uses are available > > in http://mac.r-project.org/libs-4/ > > > > The new R build system is in > > https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4 > > Packages build system has not changed and is in > > https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages > > > > We also plan to have a mac-builder available with similar function as the > > win-builder where pre-submission tests can be performed and potentially a > > Travis template. > > > > Please test R pre-releases and provide feedback! > > > > Thanks, > > Simon > > > > ___ > > R-SIG-Mac mailing list > > R-SIG-Mac@r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > > > > > ___ > > R-SIG-Mac mailing list > > R-SIG-Mac@r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > ___ > 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
Re: [R-SIG-Mac] R 4.0 toolchain
Thanks Simon. Branching off here to discuss the toolchain in general. I see the danger posting not 100% correct scripts and in blog posts in general because they might get outdated and not always reflect the official documentation. On the other side: What is the middle way? Arguably installing a robust toolchain (on Catalina especially but for macOS in general) is not just done with the installation of the signed package. Most normal users are not aware about all the little specialties on macOS (missing openMP enabled compiler, SDK issues) and why adjustments might be needed. Even though the idea is to require as less manual configuration as possible, this is not always practical in the end (unless all maintainers agree on configuring their package without the need of an openMP enabled C compiler for example). And I also think that “installing from source” is not a dev-only thing. 1. By using the Apple internal clang as the default, will maintainers be indirectly forced to remove the dependency on an openMP enabled compiler with respect to getting source installations on macOS working? 2. Can there be an official section easily accessible for users which recommends which compiler to use (and how to set the Makevars) if users really need/want to do so? a. Regarding openMP enabled compilers: llvm is probably the one with the least differences to Apples clang. It can be installed via brew (brew install llvm) and then linked in Makevars. Would that be an alternative? 3. SDK: I did not wanted to induce that setting the SDK vars is needed for the CRAN build chain (maybe we got each other wrong here). However, as of now, there are real issues with SDK 10.15 that result in errors that are really hard to track down or even fall under the radar when testing (if someone does not run Catalina). Therefore I am linking locally against SDK 10.13 since some days and that resolved many issues (see again the Rcpp issue and the igraph issue). Since Catalina is the latest release and many people run it there should be test/instructions somewhere on mac.rproject that deal with this/suggest not to use SDK 10.15 for R IMO. Maybe this issue deserves a special thread. Cheers, Patrick On 1. Apr 2020, 22:29 +0200, Simon Urbanek , wrote: > Patrick, > > firstly, please don't post such things - they are often wrong (as are parts > of what you included it this e-mail) and it's impossible for us to track all > blogs that have incorrect advice. Unfortunately, a lot of the issues we see > out there are due to people finding bad advice and using it. Ideally, it > should be sufficient to point to the official R documentation since that is > the canonical source. If you post a blog, it should point to the official > documentation. If that documentation is missing or not covering a need, > please post here so we can fix it. It is more important that the official > source is complete and much better for the community than to have random > tidbits that may or may not be correct floating around. > > As for the script, please do not use R tar balls - first, you're picking the > wrong one (there is no R-devel for el-capitan. R 4.0.0 pre-releases are in > R-4-0-branch and they are built for high sierra). Second, the tar ball > doesn't have the entitlements enabled so it doesn't match the release. Please > use the signed R package. This may change, but with the complications of the > Apple notarization process that's what it is today. > > Then there is the question of the SDK. What are you trying to setup here? > What you posted here has nothing to do with the CRAN setup. You don't need > 10.13 SDK to compile igraph, it compiles just fine using stock command line > tools on High Sierra which is what we use on CRAN. You can, of course, pick > any SDK you like, but please don't tell people that's what they should do. > One of the most annoying issues is that people are recommending messing with > Makevars which is incredibly fragile and will cause things to break left and > right with any update. It's ok to do that for a very special purpose, but no > regular user should have Makevars in their home. > > So if you really want to serve the community, please suggest improvements to > the official documentation and post them here. If you have special needs, ask > about them here. > > Thanks, > Simon > > > > > On 1/04/2020, at 9:47 PM, Patrick Schratz wrote: > > > > Thanks Simon, > > > > This simplifies things a lot and clears up the process. While the > > instructions on https://mac.r-project.org/ are more clear now I think there > > is still simplification needed for the install process and custom > > modifications that are needed. > > This not only applies to the dev page but finally also to production end > > users if
Re: [R-SIG-Mac] R devel == 4.0.0?
Even if the R-devel build failed for a day, why does the tarball link/contain the R 3.6 source then? I update my R-devel install every few days automatically and would not notice that I suddenly got R-release via that URL. Rather I would prefer a 404 or (better) the latest successful R-devel build? @Simon Clarification would be appreciated. Cheers, Patrick On 26. Mar 2020, 09:51 +0100, peter dalgaard , wrote: > FWIW, r-devel builds happily on my machine (MB Air '19, Mojave, clang8, > gfortran 6.1.0 from CRAN), regression tests and all. > > -pd > > > On 25 Mar 2020, at 21:53 , Simon Urbanek > > wrote: > > > > Constantin, > > > > no, as you can see from the log the regression tests failed for R-devel, so > > it doesn't currently build. You'll have to wait until that has been fixed. > > > > Cheers, > > Simon > > > > > > > > > On 26/03/2020, at 4:17 AM, Constantin Ahlmann-Eltze via R-SIG-Mac > > > wrote: > > > > > > Hi, > > > > > > I wanted to install R 4.0.0 on my Mac (Mojave) to test some of my packages > > > with the development version before it is released. I saw that > > > https://mac.r-project.org/ is recommended to get a pkg or tar.gz file with > > > the latest version. However, the R-devel version linked there points to > > > 3.6.3. > > > > > > Is that the expected behavior? Am I right then, that I will have install R > > > 4.0.0 from source? And if so what is the recommended tool chain at the > > > moment for doing so? > > > > > > Best Regards, > > > Constantin Ahlmann-Eltze > > > > > > [[alternative HTML version deleted]] > > > > > > ___ > > > R-SIG-Mac mailing list > > > R-SIG-Mac@r-project.org > > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > > > ___ > > R-SIG-Mac mailing list > > R-SIG-Mac@r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > > ___ > 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
Re: [R-SIG-Mac] Install r-devel with homebrew?
Rainer, Be aware that the homebrew build of R used a different underlying C standard (if that is the correct way to name it?) which may cause issues when compiling certain packages from source. I think most people in this mailing list do not recommend it. In addition, you might want to change your compiler to an openmp enabled clang one. I use a small script which installs R-dev: wget https://mac.r-project.org/el-capitan/R-devel/R-devel-el-capitan-sa-x86_64.tar.gz sudo tar fvxz R*.tar.gz -C / rm R-devel-el-capitan-sa-x86_64.tar.gz Cheers, Patrick On 23. Mar 2020, 15:09 +0100, Balamuta, James Joseph , wrote: > Rainer, > > Download the R-devel build from http://mac.r-project.org > > The build is available under "Universal nightly builds for Mac OS X (10.6+ > and 10.9+)" table. > > R-devel-el-capitan-sa-x86_64.tar.gz (67Mb) > http://mac.r-project.org/el-capitan/R-devel/R-devel-el-capitan-sa-x86_64.tar.gz > > R-devel-el-capitan-signed.pkg (77Mb, installer incl. GUI) > http://mac.r-project.org/el-capitan/R-devel/R-devel-el-capitan-signed.pkg > > Best, > > JJB > > On 3/23/20, 9:06 AM, "R-SIG-Mac on behalf of Rainer M Krug" > wrote: > > Hi > > I know - homebrew is not a supported installation approach to R, but I am > asking anyway: > > Is there a way of installing r-devel via homebrew? Otherwise, what is the > easiest way of getting r-devel on my Mac, without interfering with the > homebrew install? > > Thanks, > > Rainer > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch > rai...@krugs.de > Skype: RMkrug > > PGP: 0x0F52F982 > > ___ > R-SIG-Mac mailing list > R-SIG-Mac@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > > ___ > 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
Re: [R-SIG-Mac] catalina humbug
This is a common error after major macOS upgrades. Install the xcode CLT standalone from Apple and try again. You might also need to install/link to the 10.14 SDK to get certain packages installed from source. On 14. Oct 2020 at 11:39:09 CEST, Dr Eberhard Lisse wrote: Wait a while and try again :-)-O el On 14/10/2020 11:28, Koenker, Roger W wrote: [...] > 3. Attempted to reinstall command line tools with Xcode-select > —install. This fails with > a popup that says: > > Can’t install the software because it is not currently > available from the Software Update server. [...] -- If you want to email me, replace nospam with el ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
Works fine in both RStudio and in the terminal for me (10.15.6). R 4.0.2, official binary On 3 Aug 2020, at 15:21, Marc Schwartz via R-SIG-Mac wrote: Hi, Just installed rgl and I get the same crash and error message from the original post below, running R from the CLI. If I run R from within ESS (what I normally use), I get: Process R abort trap: 6 at Mon Aug 3 09:15:32 2020 If I run R from R.app (the default macOS GUI), the command runs fine and I get the graphic. I am running R 4.0.2 (2020-06-22) on macOS 10.15.6. R was cleanly installed, and XQuartz (2.7.11) was updated afterwards. Regards, Marc Schwartz On Aug 3, 2020, at 9:05 AM, Duncan Murdoch wrote: I just got a message from someone else using Catalina 10.15.5 who still gets a crash from library(rgl) plot(1:10) I don't have Catalina, and haven't seen it. Has anyone else? Duncan Murdoch On 31/05/2020 4:44 p.m., Richard M. Heiberger wrote: I upgraded last night to Catalina 10.15.5 (19F96). The crash has gone away and that example now works normally. On Fri, May 29, 2020 at 3:25 PM Richard M. Heiberger wrote: my 12:35 email and the attached tmp.txt are from the Terminal.app, No emacs/ESS involved. On Fri, May 29, 2020 at 3:13 PM Duncan Murdoch wrote: On 29/05/2020 2:21 p.m., Richard M. Heiberger wrote: I attempted to update xquartz when I updated to Catalina, and the same number is still the current version number. Here is a related issue, attached tmp2.txt is the R transcript. The interesting thing here is that rgl.quit() prevents rgl from being reattached. Generally speaking rgl doesn't want to be reloaded in the same R session: detaching it doesn't clean up everything. That's not something that I'd put any priority on fixing, whereas I would look at the problems you're having on startup if I could reproduce them. I wonder if ESS is involved somehow: your sessionInfo listed ESSR on the search list. Do you have the same issues with plain R from the console, or R.app? Is there an rgl equivalent for dev.cur()? There's rgl.cur(). rgl only supports two kinds of devices: on a Mac or Linux they'd be displayed as glX or null. Windows also supports the null device (which doesn't display anything), and a different one to display within R: I forget how the name is displayed. It might be that you'll need to set options(rgl.useNULL) before starting rgl, and only use the null device. It won't display anything in R, but allows you to call rglwidget() for a display in a browser. Duncan Murdoch On Fri, May 29, 2020 at 1:51 PM Duncan Murdoch wrote: On 29/05/2020 12:35 p.m., Richard M. Heiberger wrote: I have the same Xquartz as you. I'd guess it should be updated. Generally XQuartz needs updates with every MacOS release, and your 10.15.4 is two releases further along than my 10.13.6. I have rgl-0.100.50 from CRAN You could update that, but I doubt if it would make any difference. Apple is macOS Catalina, Version 10.15.4 Do you need hardware information? MacBpok Air (13 -inch, Mid 2012) Processor 2GHz Dual-Core Intel Core i7 Memory 8 GB 1600 MHz DDR3 Graphics Intel HD Graphics 4000 1536 MB I think the XQuartz issue is most likely to help, but if it doesn't, I'm not sure what I could suggest: I don't have Catalina. Duncan Murdoch from the Terminal App: The Apple Crash Report is in the attached tmp.txt I didn't send it to Apple. R version 4.0.0 (2020-04-24) -- "Arbor Day" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin17.0 (64-bit) 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. library(rgl) plot(1:10) 2020-05-29 12:30:00.536 R[24961:3275889] *** Assertion failure in BOOL NSScreenConfigurationInvalidateIfNeededForReason(_NSScreenConfigurationUpdateReason)(), /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.40.150/AppKit.subproj/NSScreenConfiguration.m:473 2020-05-29 12:30:00.543 R[24961:3275889] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSScreen reconfig must only happen on the main thread.' *** First throw call stack: ( 0 CoreFoundation 0x7fff371698d7 __exceptionPreprocess + 250 1 libobjc.A.dylib 0x7fff6ff47a9e objc_exception_throw + 48 2 CoreFoundation 0x7fff37192bb0 +[NSException raise:format:arguments:] + 88 3 Foundation
Re: [R-SIG-Mac] R for macOS Big Sur
There is a [native arm64 big sur binary](https://github.com/Homebrew/homebrew-core/blob/8a6807be6abb44634e7d6d153348b6bba2a5ddc6/Formula/r.rb#L16) in homebrew since some days. On 10 Jan 2021, at 22:39, Gregory Coats via R-SIG-Mac wrote: > I purchased a new 13 inch Apple MacBook Pro with the M1 System on a > Chip. I understand that R is not yet available compiled for the M1 SoC > hardware, and so I am using Apple’s Rosetta 2. > However, this MacBook Pro requires Apple macOS Big Sur. From what I > see at https://mac.r-project.org/ R has not been compiled for macOS > Big Sur. Is there an executable of R for macOS Big Sur available to > download? > Greg Coats > > > [[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
Re: [R-SIG-Mac] Non-zero exit status for igraph, rgl and terra packages
{terra}, {sf} and maybe other spatial packages have some issues with source
installation since some time, see [this
discussion](https://github.com/r-spatial/sf/issues/1894) for more info.
The binaries work fine.
On 14 Jun 2022, at 15:17, Duncan Murdoch wrote:
> On 14/06/2022 7:09 a.m., Petar Milin wrote:
>> Hi Mac list,
>>
>> I am wondering if the failure to install/update igraph, rgl and terra
>> packages is macOS specific or more general. I was trying to follow some
>> advice which I have found on the internet, but no luck whatsoever. Any help?
>
> All of those packages have dependencies that need to be installed. I don't
> remember the dependencies for igraph and terra, but for rgl you need to have
> a current version of XQuartz with the development files in the standard
> place, or configure rgl not to use X11.
>
> Duncan Murdoch
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
signature.asc
Description: OpenPGP digital signature
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
