Along the same lines: I have been working with Prof Ripley to get rgl
to work on M1. Since OpenGL isn't available, it produces only WebGL
output (viewable using rglwidget()) and can't do snapshots or Postscript
output, but it should be enough to let its reverse dependencies install.
Anyone interested in testing it can install from R-forge or Github:
install.packages("rgl", repos="http://R-Forge.R-project.org";, type =
"source")
or
remotes::install_github("https://github.com/r-forge/rgl";, subdir =
"pkg/rgl")
To see what it looks like without OpenGL on Windows, try
Sys.setenv(RGL_NO_OPENGL = TRUE)
before the install, or on a Unix-alike,
install.packages("rgl", repos="http://R-Forge.R-project.org";,
INSTALL_opts = '--configure-args="--disable-opengl"',
type = "source")
Duncan Murdoch
On 21/12/2020 9:01 a.m., Jeroen Ooms wrote:
On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote:
We have managed a fairly complete check run with natively-compiled R and
packages, and a full one with x86_64 R and packages running under
Rosetta (mainly using CRAN binary distributions).
The bottom line is that running under Rosetta works really well.
Although relative speeds vary widely, using the native build was
1.3-1.5x faster for the central 50% of the distribution. And a MacBook
Air is remarkably capable for a lightweight laptop.
x86_64 tests
------------
I compared the check output to that from my 2012 iMac: typically this
was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini
about that much faster than mine).
A couple of packages ran much slower than on the iMac and hit their
check limits, and one fails because it checks elapsed time (and was
slower than on the iMac).
10 packages segfaulted in their checks (but most of those are known to
segfault intermittently on other platforms).
There were issues with packages attempting to work with Python, which
may be Big Sur differences.
Given that I have 58 packages failing their checks on the iMac under
High Sierra this was a very small amount of degradation.
native tests
------------
Currently I have 57 CRAN packages failing to install, but 650 others
require those or BioC packages which fail to install (the most commonly
required being rgl and V8 [*]). And ca 120 packages are not using
conditionally Suggests packages which fail to install.
There are segfaults from ca 150 packages using minpack.lm::nls.lm,
deSolve::lsoda, rootSolve::stode ... all of which use Fortran.
That platform does not have long doubles nor extended precision but the
CRAN checking on Linux and Sparc with --disable-long-doubles has paid
off: only a handful of check results show numerical differences.
Quite a lot of external software and several packages have had to be
patched, and it is early days for the former (and the Fortran compiler)
- for example I was able to build v8, but V8 segfaulted in its checks.
Thank you for these fantastic efforts. I have added a binary for
libv8, so it works on arm64 now.
Re: the more general problem of external software, are there any
details available on how the external software on your server was
built/configured? For example I don't see libv8 on
https://github.com/R-macos/recipes or
https://mac.r-project.org/libs-arm/ so this makes it difficult for
package authors to debug a problem.
FWIW, Homebrew is quickly catching up on M1 support. Many people are
contributing patches, and François-Xavier Coudert (the same person who
is publishing the gfortran binaries) is publishing the homebrew arm64
binaries (aka bottles), hundreds over the past weekend:
https://github.com/Homebrew/homebrew-core/commits?author=fxcoudert
It is recommended to install homebrew on ARM in /opt/homebrew, and not
/usr/local, to prevent binaries from getting mixed up
(https://github.com/mikelxc/Workarounds-for-ARM-mac ). Using these
standard instructions, I was able to check many R packages that are
flagged on CRAN. For example:
brew install --build-from-source libgit2
Will make it possible to install gert and git2r. And:
brew install --build-from-source imagemagick@6
Will work for 'magick' and:
brew install protobuf
For protolite.
The main bottlenecks are libraries that depend (indirectly) on gcc
(fortran) or rust. FXCoudert is working on gcc, and for Rust, support
for apple-arm is available starting rust 1.49, which will be released
on Jan 1.
_______________________________________________
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
