7/2025, at 16:01, Ken Beath wrote:
>
> The problem is that it uses the Electron framework, and it isn’t supported on
> earlier versions of MacOS.
>
> Ken
>
>> On 17 Jul 2025, at 1:15 pm, Simon Urbanek
>> wrote:
>>
>> Kevin,
>>
>> You may
ting
>> much
>>> closer to what I hope for. There are discussions on migrating (keyboard
>>> shortcuts, mental assumptions, etc) from RStudio IDE to reduce the
>> change,
>>> and I believe there are few things one can do in RStudio that are not
>> also
&g
are discussions on migrating (keyboard shortcuts,
> mental assumptions, etc) from RStudio IDE to reduce the change, and I believe
> there are few things one can do in RStudio that are not also feasible in
> Positron.
> Good luck,
> Bill
> On 7/15/25 18:36, Simon Urbanek wrote
José,
I agree that latest RStudio dropping support for a very large number of Macs is
unfortunate. It may be worth raising it with Posit - we have very deliberately
not increased the macOS version requirement of R binaries, because it would
affect way too may R users based on the estimates from
Naras,
it does if you use latest version please see
https://stat.ethz.ch/pipermail/r-sig-mac/2025-April/015155.html
Cheers,
Simon
> On Jun 12, 2025, at 9:17 AM, Balasubramanian Narasimhan
> wrote:
>
> R 4.5.0's addition of two new routines to BLAS
> (https://cran.r-project.org/doc/manual
> Clang: Apple clang version 17.0.0 (clang-1700.0.13.3)
> Fortran: GNU Fortran (GCC) 8.2.0 (from
> https://mac.r-project.org/tools/gfortran-14.2-universal.pkg)
> SDK version: 15.4
> SDK path: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
>
> and could reproduce the issue
Heather,
yes, please, since we cannot reproduce it, please provide your complete
configure flags, full info about your macOS version, tools used (toolchain
version and SDK). We are adding -Wl,-headerpad_max_install_names for libraries
(see etc/Makeconf, added by configure.ac for darwin), but th
Philipp,
the instructions (if really insist on using Xcode 16.3 - not recommended) are
here: https://mac.r-project.org/openmp/ relevant part quoted:
"Note: If you are using CRAN R binary and there is a potential conflict between
its run-time and your run-time (which is generally a bad idea!) th
Gavin,
thanks, quick updates inline.
> On Apr 25, 2025, at 9:53 PM, Gavin Simpson wrote:
>
> Thanks Simon, that's really helpful - I find the R manuals confusing on this
> issue in part because things MacOS X related are bound up in "Unix-alike"
> sections and there are often clauses and / o
to go that route shipped
their own (or linked statically) then chaos would ensue breaking all of them.
Cheers,
Simon
> On Apr 25, 2025, at 11:38 AM, bill+rsig...@8pawexpress.com wrote:
>
> If it’s not compiled in, why is |libomp.dylib| distributed in R for Mac?
>
> Bill
>
>
Gavin,
> On Apr 24, 2025, at 9:58 PM, Gavin Simpson wrote:
>
> Dear list,
>
> I'm trying to clarify my understanding of what is and is not implemented /
> expected in terms of openMP support in R and CRAN package *binaries* for
> MacOS on apple silicon.
>
> I have the CRAN's R binary for Ma
ar?
Without exact output we can only guess ...
Cheers,
Simon
> Duncan Murdoch
>
>
> On 2025-04-19 5:40 p.m., Simon Urbanek wrote:
>> Gavin,
>> there are few issues here with different possible solutions.
>> In general, you cannot mix R from Homebrew and CRAN - they
Bill,
the libomp.dylib inside R is there solely for the CRAN binaries to make sure
that package binaries on CRAN can use the correct OpenMP runtime. Is it not
intended to be used outside of that setup.
That is also why we don’t ship the headers as anyone compiling from sources
will have to do
Roy,
Please update to R 4.5.0 Patched from https://mac.R-proejct.org as discussed
here before - see
https://stat.ethz.ch/pipermail/r-sig-mac/2025-April/015155.html
Cheers,
Simon
> On Apr 21, 2025, at 1:48 PM, roy wrote:
>
> After executing the following:
> cd /Library/Frameworks/R.framework
Gavin,
there are few issues here with different possible solutions.
In general, you cannot mix R from Homebrew and CRAN - they use different
toolchains and libraries so you have to pick one.
1) Despite what you said, what you are showing below is output from CRAN R, so
one option (which I'd r
TL;DR latest R 4.5.0 Patched (r88147 or higher) from https://mac.R-project.org
should work.
Ulrich,
Thanks for the report. Yes, the whole purpose of the R shared BLAS is that you
can point it to any BLAS implementation as long as it is complete enough for R
to use. Unfortunately, R 4.5.0 now r
This looks like a case where an attempt is made to update with type="both"
which will take into account both source and binary repositories for
comparison, but packages can be installed from source only if the user has the
tools and acknowledged that they really want to do that. As Peter said, i
> On Mar 31, 2025, at 10:04 PM, Naresh Gurbuxani
> wrote:
>
> Simon,
>
> Website mac.r-project.org/tools/ lists mandatory libraries. In the next
> paragraph, it has a link to “binaries of libraries and tools for Mac OS
> page”. Clicking on the link takes user to mac.r-project.org/bin. H
aries.
> A similar problem will arise when a new version of R uses updated versions of
> liblzma and PCRE2.
>
The versions are quite irrelevant since they are used statically so R doesn't
care which version you use in packages and vice-versa.
Cheers,
Simon
> Thanks ever
Please ignore this "advice" - it makes the mess even worse. As you can tell if
you look closer at the output it's about 3rd party tools like homebrew messing
up the build which causes the problem in the first place.
BTW: the page you quote is complete nonsense: CRAN does provide binaries -
that
Naresh,
please ignore all "advice" you go so far - most of it was wrong. From your
earlier reports it looks like your system is messed up which the the core of
the problem - please remove 3rd party libraries from your path (like homebrew,
macports, /opt/local etc.) as that will interfere with t
> On Feb 20, 2025, at 2:36 AM, peter dalgaard wrote:
>
> Do we expect to stay with gfortran 12.2.0 for 4.4.3 and then switch for
> 4.5.0?
>
Most likely - changing version for patch releases doesn't seem necessary.
Cheers,
Simon
> -pd
>
>> On 19 Fe
Stefano,
please note that the CRAN page is talking about the R 4.4.2 release and the
developer tools page says
"CRAN R Big Sur builds used gfortran-12.2-universal.pkg for R 4.3.0 up to 4.4.2"
so they are both correct and very explicit with the corresponding links, so I’m
not entirely sure w
Jennifer,
as usual, it was announced on the mac.R-project.org webpage since it only
affects the builds there. R-devel is "unstable" so it may be subject to change,
but at this point gfortran 14.2 seems most likely to be the compiler we'll use
for 4.5.0 unless we find any issues with that.
Chee
Kasper,
TL;DR working on it should be within a week or so.
The main constraint is the disk space on the package builds machines, I'll have
to stop building packages for 4.3 to accommodate R-devel (yes, disk is cheap
and all that, but you can't just plug in SSDs into a Mac so more involved...).
> On Dec 12, 2024, at 10:00 AM, Duncan Murdoch wrote:
>
> On 2024-12-11 3:43 p.m., Michael Hall wrote:
>>>
>>> Message: 1
>>> Date: Wed, 11 Dec 2024 12:25:42 -0500
>>> From: Duncan Murdoch
>>> To: R-SIG-Mac
>>> Subject: [R-SIG-Mac] R.app not handling events
>>> Message-ID:
>>> Content-Type
e Internet or R admin but with no luck.
> I guess some includes or other configuration is missing but I have no
> experience with such huge build system.
>
> I am generally aiming at testing different BLASes or own implementations of
> matrix operations (matmul mainly),
> perf and c
Tomek,
see R-admin C.3.5.1:
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Accelerate
so essentially just add the following to the regular flags:
--enable-BLAS-shlib --with-blas='-framework Accelerate'
Cheers,
Simon
> On Nov 30, 2024, at 2:10 AM, Tomek Gieorgijewski
> wrote:
Carl,
R itself is just a single process. However, there are plenty of ways to have
multiple R processes running on your system.
The "parallel" package provides various ways in which you can start more
parallel R processes for parallel computing. Those will typically appear
without a logo. Eve
Gilberto,
thanks! TLDR; its a bug in the torch package - fix below.
It took a while to sort out your example as it was very incomplete, here are
the full required steps:
---
## sits doesn't install tests, so have the get them from sources:
download.packages("sits", type='source')
untar(Sys.glob
n96B 31 Out 22:11 pkgconfig
>
>
>
> Prof Dr Gilberto Camara
> Senior Researcher
> Getulio Vargas Foundation (FGV)
> National Institute for Space Research (INPE), Brazil
> https://gilbertocamara.org/
> =
>
error.
>>>>
>>>> The problem affects only Intel-based MacMinis with R-4.4.2. Running
>>>> MacMinis with R-4.2.3 work will. All is also well with R-4.4.2 in Macs
>>>> with ARM, in Windows and in Lunix/Ubuntu and Linux/Fedora.
>>>>
>
Spencer,
I strongly recommend NOT selecting compilation from sources as that is
non-trivial and requires a whole list of tools and libraries that you don't
have - I would recommend using type="binary" in
install.packages/update.packages to make sure the get the versions that haven
been checked
Gilberto,
please read https://www.r-project.org/bugs.html first, in particular about how
to report a problem. Just saying "cannot execute my scripts" is not helpful at
all - please provide exact output, how it differs between the versions etc. For
example, the problem may be in your code or pac
Jeroen,
yes, you're right, that is incorrect. It should read "binary" as that is the
only value that automatically picks the correct binary repository for the
current R build regardless of platform. Or it should say
"mac.binary.big-sur-x86_64" corresponds to bin/macosx/big-sur-x86_64/contrib
a
packages are not compatible between R versions.
Cheers,
Simon
> On 26 Sep 2024, at 11:42, Simon Urbanek wrote:
>
> Sebastian,
>
> thanks, I can replicate the crash in the R GUI and it’s due to a missing
> symbol detected at run-time (I’m attaching the traceback even thoug
is fully up-to-date, see
>> https://www.stats.ox.ac.uk/pub/bdr/M1mac/README.txt
>>
>> Following the instructions in the R-admin manual and not by some third party
>> is always a good idea before posting.
>>
>> Do please stop sending HTML, as required in t
Sebastian,
if you want to replicate the CRAN builds, you have to also use the same
settings, otherwise you may have a build which is not binary compatible. It is
unclear from your description how you built R (there are several variants such
as framework install vs "unix"-style install and they
>From the help page:
The encodings ‘"UCS-2LE"’ and ‘"UTF-16LE"’ are treated specially,
as they are appropriate values for Windows ‘Unicode’ text files.
If the first two bytes are the Byte Order Mark ‘0xFEFF’ then these
are removed as some implementations of ‘iconv’ do not accep
Peter,
hasseDiagram unfortunately depends on packages outside of CRAN, namely in
Bioconductor, so you have to add the corresponding repositories before you
install it, e.g.:
setRepositories(ind=1:4)
install.packages("hasseDiagram")
# also installing the dependencies ‘BiocGenerics’, ‘Rgraphviz’,
On, and I just noticed - you appear to have some legacy Homebrew files as well
in /usr/local - on a Mx Mac you should remove all from /usr/local as that is
just Intel legacy that will cause a lot of problems.
Cheers,
Simon
> On 22/07/2024, at 10:11 AM, Simon Urbanek wrote:
>
> Pro
Probably the best is to remove (aka move aside) *everything* - both
/opt/R/arm64 and /opt/homebrew (or at least rename it to move it aside). The
openssl package provides a fallback, but only if it doesn't detect something
that gets in its way. It gets really confused if you have various various
rocessor option ...
>
> Mikael
>
> On 2024-07-05 4:53 pm, Mikael Jagan wrote:
>> Some thoughts in line below, not "certified" but maybe helpful. Corrections
>> welcome ...
>> Mikael
>>> From: "Balamuta, James"
>>> To: Simon Ur
s/r-release/NEWS.html
> [2]: https://mac.r-project.org/openmp/
> [3]:
> https://github.com/RcppCore/RcppArmadillo/blob/37461ba36472305c699263afc229919d37daa5e3/configure.ac#L109
> From: Simon Urbanek
> Date: Thursday, June 27, 2024 at 10:25 AM
> To: Balamuta, James
> Cc: Timothy Bate
Most of the claims below are false - libomp is shipped with CRAN R for quite
some time specifically so that packages which benefit from it significantly can
enable OpenMP reasonably easily - they only need to add the flags as noted on
the cited page and CRAN takes care of the rest. If there are
Tim,
There is no need to worry about libomp.dylib on macOS with CRAN packages as
libomp is already shipped with R. When the package its built on CRAN, it will
be pointed correctly to the version inside R.
However, in your output it seems that the problem may be that the user is using
the wrong
Spencer,
Since you already have homebrew on your PATH you can simply run "brew install
pandoc".
Otherwise you can just set the path while running R CMD:
PATH="~/Library/Application Support/r-pandoc/3.2:$PATH" R CMD build fda
As of where to set the PATH - it depends on where you run it from - i
Gilberto,
since luz is a contributed package, you should probably start first by asking
the authors. Given that the torch ecosystem is quite complex and has several
layers that need to work together, even if you talk to them, you probably need
to add details such as exact versions used (includi
Carl,
it shows that you apparently had some ancient version of magrittr installed way
back from R 4.2.x. I have no idea why or how you got it, but
update.packages(checkBuilt=TRUE) in R 4.4.0 should have fixed it.
Cheers,
Simon
> On 1/05/2024, at 12:32 AM, Carl Witthoft wrote:
>
> Thanks, P
Y V,
as Duncan pointed out this is usually a problem with the RStudio session. Quit
RStudio, re-install the package (if in doubt, use R), quit R and re-start
RStudio.
Cheers,
Simon
> On 25/03/2024, at 10:54 AM, YV B wrote:
>
> I'm running R 4.3.3 GUI 1.80 Big Sur Intel build (8340) and RStu
f doodling unrelated things on the screen
is now in R-devel and R-patched (85968 and 85969 resp.) so please check R 4.3.3
beta r85969 or higher from mac.R-project.org
Cheers,
Simon
> On 22/02/2024, at 10:57 AM, Simon Urbanek wrote:
>
> I can confirm that this is a bug specific to
I can confirm that this is a bug specific to macOS Sonoma 14.3.1, even earlier
versions of Sonoma don't have that problem. Given the number of previous bugs
in Sonoma chances are Apple may fix in the in the next release, but I'll see if
we can do anything about it on our end in the meantime.
Ch
Maria,
can you, please, include the full output of sessionInfo() in R and
system_profiler SPHardwareDataType | grep Model
in Terminal? I cannot replicate it, either, but then we have no idea which
hardware and macOS you are using.
Thanks,
Simon
> On Feb 16, 2024, at 10:25 PM, María de los Án
Erik,
thanks, this is very unusual. Can you, please, send me more details about your
setup? Please run the following two lines in Terminal and send me the full
output:
system_profiler SPHardwareDataType | grep Model
system_profiler SPDisplaysDataType
Then in R run the following code and also i
Brodie,
thanks. There was a problem between the two build VMs where the x86_64 one
could overwrite arm64's content with a stale content before they got branched.
This should now be fixed - each should be supplying only its own part.
Cheers,
Simon
> On Jan 22, 2024, at 3:09 AM, Brodie Gaslam
Michael,
remotes is a contributed package, so you should contact the author if that is
what fails (you didn't say). FWIW only the latest version package binaries are
available on CRAN, so if you need a specific older version of a package you
need to compile it from sources - so chances are you
Kirill,
Due to the necessary iconv workarounds for Sonoma introduced in the R 4.3.2
build, it complicates the automated nightly builds (they cannot reuse the same
VM anymore) so the nightly process needs to be updated. I'm currently traveling
so it will be restored when I get back later next we
Brian,
you are using Anaconda so all bets are off since that is not supported by CRAN.
It looks like a broken compiler/runtime combination in Anaconda so your best
bet would be to contact their support as this is unrelated to R (updating
Anaconda sounds like an obvious first step, hoping the co
Please read the instruction on the download page - this is typically due to
your system setting disallowing installation from the downloaded location so
you have to move the package to a location from which you have allowed
installation such as your home.
Cheers,
Simon
> On 18/10/2023, at 1:2
Federico,
yes, you can right-click and select Open. The app is signed, but is it not
notarized - we only do that for the R release packages, because that's how our
process works.
Cheers,
Simon
> On Oct 5, 2023, at 11:03 PM, Calboli Federico (LUKE)
> wrote:
>
> “R.app” can’t be opened becau
Kevin,
> On 4/10/2023, at 5:27 AM, Kevin Thorpe wrote:
>
> Hello.
>
> I am wondering if this is just an issue on M1/2 chips or does it also affect
> Intel?
>
It is an issue with Sonoma macOS new TUI classes and not the architecture so it
will affect both.
> I usually hold off upgrading u
I had a look and can reproduce it. What happens is that macOS Sonoma is sending
dozens of notifications that a window will close (even if no window is being
closed!) and since we move the focus to the next window on close it happens
every time macOS sends that notification and thus many times in
Desmond,
thanks for the report. There seem to be windows focus issue in Sonoma so I
would not recommend upgrading at this point. Hopefully this will be fixed in a
future macOS update (the .0 versions are notoriously flaky) - in the meantime
I'll see if there is any work-around we could do in R.
ackages into
> '/private/var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T/RtmpSL7Etm/reprex-bc8b4fff25a6-next-esok/templib'
> #> (as 'lib' is unspecified)
> #>
> #> The downloaded binary packages are in
> #>
> /var/folders/dj/yhk9rkx97wn_ykqtnm
Kirill,
we have no way of knowing when a packages introduced a breaking change (which
it really shouldn't), so the maintainers would have to inform as (Matrix
authors did inform us that 1.6.0 introduces breaking change so that's why we
did a manual re-bulid on that update). Also checking exact
Agreed, no problem here even with Rcmdr in older R 4.2.0. As Peter said, Rcmdr
doesn't use tcltk2 so I'm sure there is a lot you're omitting here. If it
doubt, make sure you don't load some old workspace and have the latest versions
of all packages, e.g. via update.packages(ask=FALSE).
Cheers,
Daniel,
I'm not sure I understand your question. The package mmrm 0.2.2 fails its tests
for me as well. If you can reproduce the problem locally (as you indicated),
then that's good as you should be in the position to fix it.
Cheers,
Simon
> On 26/07/2023, at 1:50 AM, Sabanes Bove, Daniel via
Avi,
thanks. Everything seems to work for me. 404 for the link shown in the response
will occur if the job has not yet been picked up, because the system is
somewhat optimistic about assuming a job will be picked up faster than you can
click on the link. The result page is only generated as the
ot a good idea since the instructions on CRAN should be fully
self-sufficient *and* we want to avoid other incompatible Fortran compilers. (I
have trouble reaching the x86_64 build machine from home right now, so I'll
change it on Monday).
Thanks,
Simon
>
> On 07/07/2023
> On 7/07/2023, at 10:15 AM, Spencer Graves wrote:
>
> Hi, Simon:
>
>
> Thanks for this. I have more questions:
>
>
> On 7/6/23 4:52 PM, Simon Urbanek wrote:
>> In the shell:
>> PATH=/opt/gfortran/bin:$PATH R CMD INSTALL ...
>
>
>
current path, than appended
> ":/opt/gfortran/bin" to that and executed the revised
> "PATH=...:/opt/gfortran/bin export PATH". However, when I checked with "env"
> again, the change was not displayed. I rebooted with the same result.
>
>
>
2023, at 11:45 PM, Peter Dalgaard wrote:
>
> AFAICT, Spencer followed the implied instructions and it still didn't work.
>
> There may also be a PATH issue when upgrading to 4.3.x, /usr/local ->
> /opt/R/ Does gfortran 12.2 install to /opt/R/.../bin ?
>
> -pd
Already answered to you and on R-pkg-devel [9 mins after you posted there - now
more than 5h ago...]:
To quote from the page you downloaded R from:
This release uses Xcode 14.2/14.3 and GNU Fortran 12.2. If you wish to compile
R packages which contain Fortran code, you may need to download the
Roy,
thanks (this is the proper place to report it). We had a power failure on one
of the circuits, and it so happened that the MacBuilder was on it. I have now
restarted the services so please give it a go and let me know if there are
issues
Thanks,
Simon
> On Jun 30, 2023, at 8:42 AM, Roy
r
>
> Middlebury Institute of International Studies at Monterey
> ------
>
> [Sent from Outlook for Mac –MacBook Pro]
>
> My working hours (US Pacific time zone) may not be your working hours. Please
> do not feel
Fernando,
I don't think you posted the error you get when running R on the command line -
can you copy/paste what you get when running R in the Terminal? Similarly, do
you also get an error when running the R app (in Applications)?
Cheers,
Simon
> On 6/06/2023, at 6:32 AM, DePaolis, Fernando
Dennis,
PS1 is an internal shell environment variable (modifying prompt) which has
nohting to do with R (and nothing to do with the computer name by default) so
it won't be set in R, only in a shell.
If you want the machine's hostname you'd typically use system("hostname") in R.
Cheers,
Simon
Jarrett,
Duncan's suggestion was correct, but you are using older R, so I'd recommend
simply upgrading R to the latest release.
If you want to use old R, you have to install the older Fortran binaries that
match your R version, but that's not entirely trivial so it's easier to just
upgrade R i
oring previous
>> �/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/nftbart�
>>
>>> sessionInfo()
>> R version 4.3.0 Patched (2023-04-27 r84338)
>> Platform: x86_64-apple-darwin20 (64-bit)
>> Running under: macOS Ventura 13.2.1
>>
hat actally point to thw wrong directory.
> That is not yet fixed on the master.
>
> Best,
> Uwe
>
>
>
> On 24.04.2023 23:19, Simon Urbanek wrote:
>> This has been fixed a while time ago so I suspect the culprit are outdated
>> mirrors. If in doubt, please use
Kenneth,
type="mac.binary" is not appropriate as forces is only for old High-Sierra
binaries which don't exist for R 4.3.0 anymore as that build is no longer
supported. You should leave type="both" (default, recommended) or type="binary".
Cheers,
Simon
> On Apr 25, 2023, at 1:12 AM, Kenneth
This has been fixed a while time ago so I suspect the culprit are outdated
mirrors. If in doubt, please use
https://mac.R-project.org/bin/macosx
which is the most up-to-date.
Cheers,
Simon
> On Apr 25, 2023, at 12:51 AM, Uwe Ligges
> wrote:
>
>
>
> On 24.04.2023 14:41, Kenneth Knoblauch
Dirk,
thanks - the problem is that there is not a single installer package (for
several years now), so that URL is ambiguous. Whether the missing link is a
good or bad depends on how it is used. I would argue that any link to that URL
is inherently bad, because there is no way of knowing that t
Varin,
you're missing the Fortran compiler which the package requires. To make the
life a bit easier on you, upgrade to R 4.3.0 and then install GNU Fortran from
https://mac.r-project.org/tools/
If you don't want to upgrade R then you'll need the Fortran from here:
https://github.com/R-macos/g
not need
>
>CPPFLAGS += -I/usr/local/include
>LDFLAGS += -L/usr/local/lib
>
> just to include the header or link the shared library.
>
> Mikael
>
>> Date: Tue, 18 Apr 2023 15:18:03 +1200
>> From: Simon Urbanek
>> To: R list
>> Subject: [R-S
Dear Mac users,
the next major R release R 4.3.0 is coming very soon so I would like to ask you
to, please, test the pre-releases from
https://mac.R-project.org
such that any possible new issues are detected *before* the release. The
upcoming release will be for macOS 11 and higher only to lev
Mikael,
the SDK version (=system libraries) is independent of the Xcode version
(=toolchain version). We are using macOS 11 SDK, because we want the binaries
to run on macOS 11. R packages typically don't use run-time weak symbol guards,
so they would likely crash when compiled against higher S
Jennifer,
that build in only for macOS 11 (Big Sur) and higher, older versions are no
longer supported (neither by Apple nor by us). I'll update the installer to
disallow installation on older macOS version to avoid confusion.
Thanks,
Simon
> On Apr 5, 2023, at 6:04 AM, Jennifer Wokaty
> wr
Hasan,
packages shouldn't be using gomp as it is not supported - it seems that gmm is
hard-coding -lgomp even if it is not enabled by R. Although this is a bug in
gmm (which the authors should fix), you can try to work around it by installing
the GNU Fortran compiler as follows:
open the Termi
Nicolas,
we can't tell unless you post the error log and you didn't even tell us your
macOS version, but in recent versions security settings prevent the
installation from the Downloads folder, so make sure you move it away from
there to some safe location (home, Desktop or /tmp). Otherwise, su
Gilberto,
Please note that size checks are not really relevant for binary packages - it
is normal for binaries to be large as they may include static libraries (e.g.,
rgdal has 273Mb). Also note that 4.8Mb is rather small for a library since it
also includes debugging symbols (CRAN packages are
don't see that problem myself, but I
don't use Homebrew (at least not on the default PATH).
Cheers,
Simon
> On 15/03/2023, at 9:45 AM, Michael Hall wrote:
>
>
>
>> On Mar 14, 2023, at 3:32 PM, Simon Urbanek
>> wrote:
>>
>> If that is the case, c
Federico,
given that Homebrew is likely the cause for the mess, advising to install a
custom installation seems like a very bad idea. It is likely very dependent on
the versions of the tools from Homebrew which is what breaks. Therefore I would
strongly advise against it (unless you know what y
If that is the case, can you actually post what the issue is? The original post
had no details and did not follow up when asked for details. When googling the
issue seems to arise in Homebrew, not the Apple tools so as I noted removing
Homebrew should work.
Cheers,
Simon
> On 15/03/2023, at
Andrea,
Make sure you don't have any outdated tools or flags overrides (e.g. in ~/.R).
If it doubt clean /usr/local and uninstall Homebrew. The error suggests your
are using compilers that don't support your system.
If you cleaned out those and still needs help, please post the full output of
Bill,
to answer the general part of you question, there are quite a few packages that
allow you to use your GPU. At the low level you can use OpenCL which allows you
to write code directly on the GPU and turn it into R functions. At a higher
level there are frameworks like Torch and Tensorflow
> On Feb 19, 2023, at 3:50 AM, Spencer Graves
> wrote:
>
> On 2/18/23 6:40 AM, Prof Brian Ripley wrote:
>> Are you using R.app (you failed to say)?
>
>
> I'm "using the newest version of RStudio" [Version 2022.12.0+353
> (2022.12.0+353)]. This means I am running R.app?
>
No, it
Christofer,
yes, unfortunately this is a known bug in macOS Ventura affecting a lot of
command-line programs that use GUI. Do not upgrade to Ventura (usually a good
advice given the long list of known bugs in Ventura) or wait for a fix from
Apple.
Cheers,
Simon
> On Feb 11, 2023, at 11:28 P
Apparently there is a bug in Ventura that prevents software installation from
the Downloads folder. Once the installer package is moved someplace else - the
home or Desktop - it works. So if you see "Installation failed", make sure you
move the package (typically that would be the R-4.2.2-arm64.
t; Head of Biostatistics, Applied Health Research Centre (AHRC)
> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> Assistant Professor, Dalla Lana School of Public Health
> University of Toronto
> email: kevin.tho...@utoronto.ca Tel: 416.864.5776 Fax: 416.864.3016
>
&
1 - 100 of 1035 matches
Mail list logo
