To sum up there are two issues one of which is intentional and the other one is
not:
- gmp is using optimized instructions and we are currently targeting
SandyBridge architecture as the oldest supported Mac. That works for Macs in
about the last decade so seems like a reasonable compromise.
I have the oldest MacBook Pro: mid 2010. Is it too early to upgrade to
an M1Max one, for R purposes? Anyway, I get (this is R, but RStudio
aborts too):
> x1 <- mpfr(-50, 200)
*** caught illegal operation ***
address 0x10fd8c23b, cause 'illegal opcode'
Traceback:
1: mpfr.default(-50, 200)
This works normally on my rather new-ish Mac (2020), Monterey 12.0.1, using:
> R.version
_
platform x86_64-apple-darwin17.0
arch x86_64
os darwin17.0
system x86_64, darwin17.0
status
major 4
minor 1.1
year 2021
month
Okay, I've reproduced the crash on my 2013 Intel MacBook Pro. In this case,
the issue reproduces more readily because RStudio is calling str() behind
the scenes (which is the cause of the crash in this case). So, a plain R
reproducible example:
library(Rmpfr)
x <- mpfr(-50.1, 200)
str(x)
and I
Kevin,
that is a different story, yes, Rosetta2 is incomplete - the advice on M1 is to
use native R.
Cheers,
Simon
> On Nov 29, 2021, at 12:30 PM, Kevin Ushey wrote:
>
> I can reproduce something similar on my M1 macOS machine, when using the
> x86_64 build of R. I see:
>
>> x1 <-
I am using:
RStudio 2021.09.0+351 "Ghost Orchid" Release
(077589bcad3467ae79f318afe8641a1899a51606, 2021-09-20) for macOS
Mozilla/5.0 (Macintosh; Intel Mac OS X 12_0_1) AppleWebKit/537.36 (KHTML,
like Gecko) QtWebEngine/5.12.10 Chrome/69.0.3497.128 Safari/537.36
It is an RStudio issue; the
One more thing:
After compiling Rmpfr from source,
things worked.
> On 29.11.2021, at 00:30, Kevin Ushey wrote:
>
> I can reproduce something similar on my M1 macOS machine, when using the
> x86_64 build of R. I see:
>
>> x1 <- mpfr(-50, 200)
> *** caught illegal operation ***
> address
My iMac ist Late 2014, so it is rather old (and x86 architecture)
As I already wrote, I am experiencing the crash also.
> On 29.11.2021, at 00:30, Kevin Ushey wrote:
>
> I can reproduce something similar on my M1 macOS machine, when using the
> x86_64 build of R. I see:
>
>> x1 <- mpfr(-50,
I can reproduce something similar on my M1 macOS machine, when using the
x86_64 build of R. I see:
> x1 <- mpfr(-50, 200)
*** caught illegal operation ***
address 0x10c5f623b, cause 'illegal opcode'
This is with the binary of Rmpfr 0.8-7 as from CRAN, with R 4.1.2. Here's
what LLDB says:
*
Dev,
as a first step, please don't use RStudio - we have to establish if this is an
R issue or not first (RStudio is not R). Second, if it still crashes, please
provide
1) the crash report
2) the output od sesionInfo() in R and
3) the output of
system_profiler SPHardwareDataType
I just downloaded
RStudio
2021.09.1 Build 372
This is an Intel RStudio running on my Apple M1 chip.
The example works normally.
Do you have the most recent RStudio?
I tried on the earlier RStudio I downloaded in January, right after getting
this M1 computer, and that version Rstudio wouldn't
I still get the crash. I tried to recreate your commands on my machine
(macOS Monterey, Version 12.0.1). Here is a summary; further details are
below.
1. Installing from CRAN downloaded file Rmpfr_0.8-7.tar.gz failed, see
further details.
2. Therefore I had to instal the binary file from CRAN,
Works normally in R-4.1.2 with Rmpfr_0.8-7 on Macintosh aarch64-apple-darwin20
I am running inside Emacs using ESS
> packageVersion("Rmpfr")
[1] ‘0.8.7’
> library(Rmpfr)
Loading required package: gmp
Attaching package: ‘gmp’
The following objects are masked from ‘package:base’:
%*%, apply,
13 matches
Mail list logo
