Thanks, this is great!
Why do you say that OpenGL is not available though? M1 has a fully working
OpenGL framework implemented on top of Metal. Apple might have deprecated
OpenGL, but I think it’s unlikely they will drop it any time soon seeing that
they went through the effort of updating their OpenGL wrapper to support
desktop GL.
Best,
Taras
> On 21 Dec 2020, at 17:32, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
>
> 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
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
