[R-SIG-Mac] Some M3 upgrade notes
I've got a new M3 Macbook Air. My previous laptop was Intel based, so
there were a few issues with the update. I wanted to leave some notes
here in case anyone else has these problems.
1. The notes in the Installation and Administration guide suggest using
FFLAGS="-g -O2 -mmacos-version-min=11.0"
FCFLAGS="-g -O2 -mmacos-version-min=11.0"
in the config.site file. That causes an error; the last option needs to
be "-mmacosx-version-min=11.0", or it can be left out completely.
2. The Xcode command line tools that I installed on the Intel Mac
conflict somehow with the new ones installed by
xcode-select --install
I deleted /Library/Developer/CommandLineTools and reinstalled them.
3. Simon's script that is installed by
source("https://mac.R-project.org/bin/install.R;)
doesn't report permission errors. For me it worked at first, but then
at some point (not sure when) it started failing to be able to create
directories to hold the libs it was installing, but its output still
looked like it was working. Running R under sudo fixed this. Changing
ownership as suggested in the Installation and Admin manual section
C.3.1 should also have worked, but I didn't notice that until later.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] error when installing the robustbase package (robustbase.rdb is corrupt)
I would simplify things, and leave RStudio out of the process. Start
R.app, and run
install.packages("robustbase")
library(robustbase)
and let us know what happens. I just ran those commands in MacOS
Monterey and R 4.3.1, and saw this:
> install.packages("robustbase")
trying URL
'https://cloud.r-project.org/bin/macosx/big-sur-x86_64/contrib/4.3/robustbase_0.99-2.tgz'
Content type 'application/x-gzip' length 3221520 bytes (3.1 MB)
==
downloaded 3.1 MB
The downloaded binary packages are in
/var/folders/d6/s97fjjxd3_9353x_lwb69210gn/T//RtmptD64D6/downloaded_packages
> library(robustbase)
Warning message:
package ‘robustbase’ was built under R version 4.3.2
so it worked with just a warning because I'm using an old version of R.
Duncan Murdoch
On 24/03/2024 5:54 p.m., YV B wrote:
I'm running R 4.3.3 GUI 1.80 Big Sur Intel build (8340) and RStudio Version
2023.12.1+402 on macOS Sonoma Version 14.4 (23E214) Intel Core i7.
I downloaded the package of robustbase
- macosx/big-sur-x86_64/contrib/4.3/robustbase_0.99-2.tgz .
, and tried to install it.
After installing it through Tools/Install Packages,
it shows up in the Packages tab.
Clicking on the checkbox results in
```
install.packages(“path/to/robustbase_0.99-2.tgz", repos = NULL, type =
.Platform$pkgType)
library(robustbase)
Error: package or namespace load failed for ‘robustbase’ in get(Info[i, 1],
envir = env):
lazy-load database
'/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/robustbase/R/robustbase.rdb'
is corrupt
In addition: Warning message:
In get(Info[i, 1], envir = env) : internal error -3 in R_decompress1
```
I've reported this to r-project tracker. They cannot help me because this
is not due to a problem of the source. Could you help me solving this
problem?
Thank you.
Y V
[[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
Re: [R-SIG-Mac] Permission issues running R in terminal
On 19/02/2024 5:22 a.m., peter dalgaard wrote: To be precise: execute access, not write access. However, neither that nor deleting the dir gives the exact "Operation not permitted" error. I had deleted the directory using the Finder, so "cd .." led to "~/.Trash". If I delete it using "rm -r", I get a slightly different message. Duncan -pd On 19 Feb 2024, at 10:43 , Jeroen Ooms wrote: On Sun, Feb 18, 2024 at 11:57 PM Duncan Murdoch wrote: I wanted to see the options to R CMD INSTALL, and was surprised to see this output: $ R CMD INSTALL --help shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted Error in tools:::.install_packages() : current working directory cannot be ascertained shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted I installed R from CRAN, and am not running the current version: I'm still on 4.3.1, with OS also kind of old: Monterey 12.7.3, so I was surprised by this. Is anyone else seeing it? This happens when you don't have write access in the current dir: mkdir /tmp/test cd /tmp/test chmod 0 . R CMD INSTALL --help [[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
Re: [R-SIG-Mac] Permission issues running R in terminal
Yes, that was it. Thanks! Duncan On 19/02/2024 4:28 a.m., peter dalgaard wrote: I have the same setup, and not seeing this. That is, _unless_ I try from a shell running in a deleted diretory: Peters-iMac:BUILD-dist pd$ R CMD INSTALL --help shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory ... (because BUILD-dist is wiped and re-created by the automatic builds, but the shell still refers to the unlinked directory.) -pd On 18 Feb 2024, at 23:57 , Duncan Murdoch wrote: I wanted to see the options to R CMD INSTALL, and was surprised to see this output: $ R CMD INSTALL --help shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted Error in tools:::.install_packages() : current working directory cannot be ascertained shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted I installed R from CRAN, and am not running the current version: I'm still on 4.3.1, with OS also kind of old: Monterey 12.7.3, so I was surprised by this. Is anyone else seeing it? Duncan Murdoch ___ 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] Permission issues running R in terminal
I wanted to see the options to R CMD INSTALL, and was surprised to see this output: $ R CMD INSTALL --help shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted Error in tools:::.install_packages() : current working directory cannot be ascertained shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted I installed R from CRAN, and am not running the current version: I'm still on 4.3.1, with OS also kind of old: Monterey 12.7.3, so I was surprised by this. Is anyone else seeing it? Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Graphics in R, version 4.3.2, does not work well in MacOS
I don't think you have described how you installed R. Did you use the installer from CRAN, or build it yourself, or get it from some other source like Homebrew or MacPorts? Duncan Murdoch On 16/02/2024 4:25 a.m., María de los Ángeles Casares de Cal via R-SIG-Mac wrote: Dear Simon and anyone else who might be interested in this: I have studied in more detail the problem referred to in the message below, and can confirm that R does not work well on macOS when I do graphics (plots). I have only tested with the "abline” command, using the examples that are in R’s help. And it does not work. I have tested it on several computers, in Terminal and with RGUI. I have also checked it in RStudio in macOS (it does work) and with R in Windows (it does work). What I have done is the following: In the "abline" command help, the first example is: ## Setup up coordinate system (with x == y aspect ratio): plot(c(-2,3), c(-1,5), type = "n", xlab = "x", ylab = "y", asp = 1) ## the x- and y-axis, and an integer grid abline(h = 0, v = 0, col = "gray60") text(1,0, "abline( h = 0 )", col = "gray60", adj = c(0, -.1)) abline(h = -1:5, v = -2:3, col = "lightgray", lty = 3) abline(a = 1, b = 2, col = 2) text(1,3, "abline( 1, 2 )", col = 2, adj = c(-.1, -.1)) if I run line by line, R does not do the plots (only open the Quartz window). If I run all together, R does the plots sometimes yes and sometimes no. I have the latest stable version of XQuartz (2.8.5) What could be the problem? Thank you in advance. Best regards. María-Ángeles Casares-de-Cal Inicio del mensaje reenviado: De: María de los Ángeles Casares de Cal Asunto: Spanish version of R, version 4.3.2, does not work Fecha: 14 de febrero de 2024, 20:29:09 CET Para: r-sig-mac@r-project.org Hi everyone, I have a problem since I have installed the last version of R 4.3.2 (spanish version) R does not work! For example: x <- 1:20#this is ok y <- 10 + rnorm(n=20,mean=0,sd=1)#this is ok plot(x,y,pch=20,col="red")#this is ok, but I have to run some times this model <- lm(y~x)#this is ok summary(model) #this is ok abline(model) #R does not plot the regression line in the window where I have the points. (And this code in RStudio works well). (I have installed the last version of XQuartz.) I do not know what is the problem. Perhaps, because is the Spanish version? How can I install the English version? Any help? Thank you in advance. Best regards. María-Ángeles Casares-de-Cal [[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
Re: [R-SIG-Mac] R
You appear to have tried to download R from a posit.co website, but you haven't given us enough details to work out what went wrong: - What URL did you download from? - What type of Mac are you using? What version of MacOS is it running? Generally posit.co does a good job of mirroring CRAN, but in case they messed up this time, you might try downloading from the main site instead: https://cran.r-project.org/bin/macosx/ Duncan Murdoch On 17/10/2023 8:25 a.m., nina.moel...@uni-jena.de wrote: Hello, I wanted to Download R for a Seminar at FSU Jena and read the posting Guide and all relevant Information that was Provided but i cant install the Package, Mac informed me to contact the platform as shown in the attachment. What can i do ? Greetings Nina Möller ___ 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] 4.3.1 fails to load
On 23/07/2023 11:51 a.m., Carl Witthoft wrote:
Problem fixed but not solved.
On previous updates to R, I always copied all the packages (that aren't
part of the base installation) from the previous version's Library
folder to the new version's Library folder, and then updated when I
actually use them.
The fix for my problem was to run "Update All" before trying to load any
library.
You should run
update.packages(ask = FALSE, checkBuilt = TRUE)
to make sure all packages are properly installed for 4.3.1. In general,
installing a package for x.y.z should let it work in x.y.(z+1), but not
in x.(y+1).z'. Errors like that are what "checkBuilt" is looking for.
I don't know what "Update All" is doing; that's some front end calling R.
Duncan Murdoch
The problem remains not-solved, because (prior to updating everything),
any attempt to run
>> library(any_package)
would cause failure similar to those I posted previously. So, while
I'm reasonably confident that R 4.3.1 doesn't play nicely with 4.2 -
level libraries, I most definitely cannot point to any particular
library. The deepest level of the traceback report for ggplot2 was
1: dyn.load(file, DLLpath = DLLpath, ...)
but when trying to load gmp, get the traceback quoted below.
carl
On 7/22/23 8:09 PM, r-sig-mac-requ...@r-project.org wrote:
Send R-SIG-Mac mailing list submissions to
r-sig-mac@r-project.org
To subscribe or unsubscribe via the World Wide Web, visit
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
or, via email, send a message with subject or body 'help' to
r-sig-mac-requ...@r-project.org
You can reach the person managing the list at
r-sig-mac-ow...@r-project.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of R-SIG-Mac digest..."
Today's Topics:
1. R 4.3.1 fails to load (Carl Witthoft)
2. Re: R 4.3.1 fails to load (David Winsemius)
3. Re: R 4.3.1 fails to load (David Winsemius)
4. Re: R 4.3.1 fails to load (Carl Witthoft)
5. Re: R 4.3.1 fails to load (Duncan Murdoch)
--
Message: 1
Date: Sat, 22 Jul 2023 16:29:59 -0400
From: Carl Witthoft
To: "r-sig-mac@r-project.org"
Subject: [R-SIG-Mac] R 4.3.1 fails to load
Message-ID:
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Neither R.app Gui nor R from command line will work.
This is 4.3.1 , MacOS 13.4 on an x86 (and yes, that's the version I
installed).
Heres the error traceback from the command line:
*** caught segfault ***
address 0x0, cause 'memory not mapped'
Traceback:
1: as.bigz(NA)
2: fun(libname, pkgname)
3: doTryCatch(return(expr), name, parentenv, handler)
4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
5: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatch(fun(libname, pkgname), error = identity)
7: runHook(".onLoad", env, package.lib, package)
8: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]])
9: asNamespace(ns)
10: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc,
.libPaths()), versionCheck = vI[[j]]), i[[2L]], from = package)
11: loadNamespace(package, lib.loc)
12: doTryCatch(return(expr), name, parentenv, handler)
13: tryCatchOne(expr, names, parentenv, handlers[[1L]])
14: tryCatchList(expr, classes, parentenv, handlers)
15: tryCatch({attr(package, "LibPath") <- which.lib.locns <-
loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos,
deps, exclude, include.only)}, error = function(e) {P <- if
(!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L])
else ""msg <- gettextf("package or namespace load failed for
%s%s:\n %s", sQuote(package), P, conditionMessage(e))if
(logical.return && !quietly) message(paste("Error:", msg),
domain = NA)else stop(msg, call. = FALSE, domain = NA)})
16: library(cgwtools)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
___
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.3.1 fails to load
Do you know where the `library(cgwtools)` call came from? It appears to
be the culprit.
I'd try (command line)
R --vanilla
for a minimal load, then update packages, etc. Then try the regular
load. If it still fails, go back to vanilla, and source your .Rprofile
with echo = TRUE to see which line in it is causing this (if it is
actually .Rprofile that is the problem).
Duncan Murdoch
On 22/07/2023 4:29 p.m., Carl Witthoft wrote:
Neither R.app Gui nor R from command line will work.
This is 4.3.1 , MacOS 13.4 on an x86 (and yes, that's the version I
installed).
Heres the error traceback from the command line:
*** caught segfault ***
address 0x0, cause 'memory not mapped'
Traceback:
1: as.bigz(NA)
2: fun(libname, pkgname)
3: doTryCatch(return(expr), name, parentenv, handler)
4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
5: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatch(fun(libname, pkgname), error = identity)
7: runHook(".onLoad", env, package.lib, package)
8: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]])
9: asNamespace(ns)
10: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc,
.libPaths()), versionCheck = vI[[j]]), i[[2L]], from = package)
11: loadNamespace(package, lib.loc)
12: doTryCatch(return(expr), name, parentenv, handler)
13: tryCatchOne(expr, names, parentenv, handlers[[1L]])
14: tryCatchList(expr, classes, parentenv, handlers)
15: tryCatch({attr(package, "LibPath") <- which.lib.locns <-
loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos,
deps, exclude, include.only)}, error = function(e) {P <- if
(!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L])
else ""msg <- gettextf("package or namespace load failed for
%s%s:\n %s", sQuote(package), P, conditionMessage(e))if
(logical.return && !quietly) message(paste("Error:", msg),
domain = NA)else stop(msg, call. = FALSE, domain = NA)})
16: library(cgwtools)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Serious problem with R on macOS
The symbolic link is the standard way R is installed on a Mac. It's
installed as a "framework", but the symlink in /usr/local/bin/R makes
Unix-like tools see it as a standard program, which is what you want
from the terminal.
The warnings and errors Fernando was seeing, like
package ‘datasets’ in options("defaultPackages") was not found
make it look as though the framework is broken. I have no idea how that
would happen. Maybe he'll learn more by running
.libPaths()
in R. It should print something like
[1] "/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library"
but maybe not identical to that. Running ls on that directory in the
terminal should list all the installed packages (including datasets and
everything else that is supposed to be installed).
Duncan Murdoch
On 08/06/2023 3:16 p.m., John Helly via R-SIG-Mac wrote:
Not clear why there is a symbolic link. Maybe try using the fullpath
name to invoke R and see if that works. It seems to me that
'sometimes', on OSX, some symbolic links behave oddly. This may be
related to the Privacy/Security settings but I don't have any clear
understanding of what's going on.
J.
On 6/8/23 06:37, DePaolis, Fernando wrote:
This is what I get after the current failure, where neither R.app nor the call
from the command line work.
fernandodepaolis@MacBook-Pro-2 ~ % ls -l `which R`
lrwxr-xr-x 1 root admin 47 Jun 5 10:23 /usr/local/bin/R ->
/Library/Frameworks/R.framework/Resources/bin/R
fernandodepaolis@MacBook-Pro-2 ~ % ls -l
/Library/Frameworks/R.framework/Resources/bin/R
-rwxrwxr-x 1 root admin 9196 Apr 21 14:47
/Library/Frameworks/R.framework/Resources/bin/R
which is identical to what I got when it was working fine a couple of days ago.
Thank you
Fernando DePaolis, Ph.D.
Dean of Academic Operations & Integration
Associate Professor
Middlebury Institute of International
Studies<https://urldefense.com/v3/__http://www.middlebury.edu/institute__;!!Mih3wA!Fr3HvZOZi4Vn9PoE48tKxAfj3AtOpcj4qLfq1EJ9yNCh3wNtCoPAjKvY7X98gkORFUN5nZHSXmGRARZ26qcicJyf$
> 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 obligated to respond outside your normal work hours, unless
otherwise indicated.
From: DePaolis, Fernando
Date: Tuesday, June 6, 2023 at 10:20 AM
To: peter dalgaard
Cc: Calboli Federico (LUKE) , r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] Serious problem with R on macOS
Thank you!! I will do that.
PS: No, no additional or different scrubbers/antivirus/etc have been added.
Fernando DePaolis, Ph.D.
Dean of Academic Operations & Integration
Associate Professor
Middlebury Institute of International
Studies<https://urldefense.com/v3/__http://www.middlebury.edu/institute__;!!Mih3wA!Fr3HvZOZi4Vn9PoE48tKxAfj3AtOpcj4qLfq1EJ9yNCh3wNtCoPAjKvY7X98gkORFUN5nZHSXmGRARZ26qcicJyf$
> 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 obligated to respond outside your normal work hours, unless
otherwise indicated.
From: peter dalgaard
Date: Tuesday, June 6, 2023 at 9:50 AM
To: DePaolis, Fernando
Cc: Calboli Federico (LUKE) , r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] Serious problem with R on macOS
[You don't often get email from pda...@gmail.com. Learn why this is important
at
https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!Mih3wA!Fr3HvZOZi4Vn9PoE48tKxAfj3AtOpcj4qLfq1EJ9yNCh3wNtCoPAjKvY7X98gkORFUN5nZHSXmGRARZ26tXIOdrG$
]
Hum...
Best I can think of is to take the hint (from Simon Urbanek) and move the .pkg
file from Downloads and into another folder before installing. Some system
cleaner-upper or virus checker could be moving stuff around. You haven't
perchance some virus scrubber running which might be restoring your executable
directories to a previous state?
You might want to make a note of the location and ownership of installed files,
like in
Peters-Air:R pd$ ls -l `which R`
lrwxr-xr-x 1 root wheel 47 Jun 6 17:41 /usr/local/bin/R ->
/Library/Frameworks/R.framework/Resources/bin/R
Peters-Air:R pd$ ls -l /Library/Frameworks/R.framework/Resources/bin/R
-rwxrwxr-x 1 root admin 9196 Apr 21 23:47
/Library/Frameworks/R.framework/Resources/bin/R
and then, if/when it stops working, see if files have disappeared or changed
owner or permissions.
-pd
On 6 Jun 2023, at 18:05 , DePaolis, Fernando wrote:
OS: Ventura 13.4 (22F66)
Downloaded R-4.3.0-x86_64.pkg from CRAN
Installation: Successful�everything works fine
Suggestion to move the installer to Trash: Declined (because I know I will need
the installer again).
CRAN suggests reinstalling Xquartz, which I did a few time
Re: [R-SIG-Mac] Issue with Installer on Mac OS Ventura 13.4
Adrian's comment reminded me of a post from Simon on Feb 8: 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.pkg file) out of the Downloads folder. (Thanks to Max for sending the installer log so we could trace the cause!). Cheers, Simon On 25/05/2023 4:28 a.m., Agostino Gnasso wrote: Dear all, I tried to install R on my MacBook M1 pro, with MacOS Ventura 13.4. I downloaded the R version 4.3.0 ( R-4.3.0-arm64.pkg ) but I’m unable to install it. When I try to install it the following error message is shown: "Installation failed. Installer encountered an error that prevented installation. Contact the software manufacturer for assistance.” Please help me to solve this issue. Thanks in advance, Best regards. Agostino Gnasso [[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
Re: [R-SIG-Mac] Problems compiling with R CMD build and devtools::build()
Sorry, I don't have an ARM64 Mac. On my Intel Mac, gfortran is located
somewhere else, not in the location you listed. The output
corresponding to the line that failed on your system looks like this on
mine:
clang++ -arch x86_64 -std=gnu++11 -dynamiclib
-Wl,-headerpad_max_install_names -undefined dynamic_lookup
-single_module -multiply_defined suppress
-L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/x86_64/lib -o
HACSim.so RcppExports.o accumulate.o
-L/Library/Frameworks/R.framework/Resources/lib -lRlapack
-L/Library/Frameworks/R.framework/Resources/lib -lRblas
-L/opt/gfortran/lib/gcc/x86_64-apple-darwin20.0/12.2.0
-L/opt/gfortran/lib -lgfortran -lquadmath
-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
-Wl,CoreFoundation
Notice that mine has
-L/opt/gfortran/lib/gcc/x86_64-apple-darwin20.0/12.2.0
-L/opt/gfortran/lib
-lgfortran
where yours had
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
-L/opt/R/arm64/gfortran/lib
-lgfortran
i.e. gfortran is in /opt/gfortran, not /opt/R/arm64/gfortran. But I
don't know if that difference is expected or not.
Duncan Murdoch
On 17/05/2023 2:43 p.m., Jarrett Phillips wrote:
Hi Duncan,
I did exactly that, but still got the error above when I try building in
both RStudio via devtools::build() and the Terminal via R CMD build.
To confirm that the right gfortran successfully installed in the correct
location, I did
jarrettphillips@Jarretts-MacBook-Pro ~ % /opt/gfortran/bin/gfortran
*aarch64-apple-darwin20.0-gfortran:* *fatal error: *no input files
compilation terminated.
Any other ideas?
On Wed, May 17, 2023 at 2:13 PM Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
I think the simplest solution is to remove the gfortran you installed,
and then install it back using the installer on
https://mac.r-project.org/tools/ <https://mac.r-project.org/tools/>
Duncan Murdoch
On 17/05/2023 1:26 p.m., Jarrett Phillips wrote:
> Hi Rodney,
>
> When I paste the directories into the Terminal, I get
>
> no such file or directory:
>
>
>
> suggesting that they don't exist.
>
>
> Seems like I need to create them (I'm a newbie)?
>
>
> What should be my next steps?
>
>
> Thanks!
>
>
> Cheers,
>
>
> Jarrett
>
>
>
>
> On Wed, May 17, 2023 at 1:25 PM Jarrett Phillips
mailto:phillipsjarre...@gmail.com>>
> wrote:
>
>> Hi Rodney,
>>
>> When I paste the directories into the Terminal, I get
>>
>> no such file or directory:
>>
>>
>>
>> suggesting that they don't exist.
>>
>>
>> Seems like I need to create them (I'm a newbie)?
>>
>>
>> What should be my next steps?
>>
>>
>> Thanks!
>>
>>
>> Cheers,
>>
>>
>> Jarrett
>>
>>
>>
>>
>>
>> On Wed, May 17, 2023 at 1:07 PM Sparapani, Rodney
mailto:rspar...@mcw.edu>>
>> wrote:
>>
>>> Hi Jarrett:
>>>
>>>
>>>
>>> Do the two directories exist that clang is warning you about?
>>>
>>>
>>>
>>> '/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
>>> '/opt/R/arm64/gfortran/lib'
>>>
>>>
>>>
>>> --
>>>
>>> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
>>>
>>> Director, Wisconsin Chapter of the American Statistical Association
>>>
>>> Institute for Health and Equity, Division of Biostatistics
>>>
>>> Medical College of Wisconsin, Milwaukee Campus
>>>
>>>
>>>
>>> *From: *R-SIG-Mac mailto:r-sig-mac-boun...@r-project.org>> on behalf of Jarrett
>>> Phillips mailto:phillipsjarre...@gmail.com>>
>>> *Date: *Wednesday, May 17, 2023 at 11:54 AM
>>> *To: *r-sig-mac@r-project.org <mailto:r-sig-mac@r-project.org>
mailto:r-sig-mac@r-project.org>>
>>> *Subject: *[R-SIG-Mac] Problems compiling with R CMD build and
>>> devtools::build()
>>>
>>> ATTENTION: This email originated from a sender outside of MCW. Use
>>> caution when clicking on links or opening attachments.
>>>
Re: [R-SIG-Mac] Problems compiling with R CMD build and devtools::build()
I think the simplest solution is to remove the gfortran you installed,
and then install it back using the installer on
https://mac.r-project.org/tools/
Duncan Murdoch
On 17/05/2023 1:26 p.m., Jarrett Phillips wrote:
Hi Rodney,
When I paste the directories into the Terminal, I get
no such file or directory:
suggesting that they don't exist.
Seems like I need to create them (I'm a newbie)?
What should be my next steps?
Thanks!
Cheers,
Jarrett
On Wed, May 17, 2023 at 1:25 PM Jarrett Phillips
wrote:
Hi Rodney,
When I paste the directories into the Terminal, I get
no such file or directory:
suggesting that they don't exist.
Seems like I need to create them (I'm a newbie)?
What should be my next steps?
Thanks!
Cheers,
Jarrett
On Wed, May 17, 2023 at 1:07 PM Sparapani, Rodney
wrote:
Hi Jarrett:
Do the two directories exist that clang is warning you about?
'/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
'/opt/R/arm64/gfortran/lib'
--
Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
Director, Wisconsin Chapter of the American Statistical Association
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus
*From: *R-SIG-Mac on behalf of Jarrett
Phillips
*Date: *Wednesday, May 17, 2023 at 11:54 AM
*To: *r-sig-mac@r-project.org
*Subject: *[R-SIG-Mac] Problems compiling with R CMD build and
devtools::build()
ATTENTION: This email originated from a sender outside of MCW. Use
caution when clicking on links or opening attachments.
Hi All,
I'm trying to generate a `tar.gz` file on a Mac for R package submission
to
CRAN but am having issues.
I'm using `devtools`, specifically `build()` and `install()`.
My package relies on compiled code via `Rcpp/RcppArmadillo`.
build("HACSim_OO")
── R CMD build
─
✔ checking for file ‘/Users/jarrettphillips/Desktop/HAC
simulation/HACSim_OO/DESCRIPTION’ ...
─ preparing ‘HACSim’:
✔ checking DESCRIPTION meta-information ...
─ cleaning src
─ installing the package to process help pages
---
─ installing *source* package ‘HACSim’ ...
** using staged installation
** libs
clang++ -arch arm64 -std=gnu++11 -
I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
-I/opt/R/arm64/include-fPIC -falign-functions=64 -Wall -g -O2 -Wall
-pedantic -fdiagnostics-color=always -c RcppExports.cpp -o RcppExports.o
clang++ -arch arm64 -std=gnu++11
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
-I/opt/R/arm64/include-fPIC -falign-functions=64 -Wall -g -O2 -Wall
-pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
clang++ -arch arm64 -std=gnu++11 -dynamiclib
-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
-multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib
-L/opt/R/arm64/lib -o HACSim.so RcppExports.o accumulate.o
-L/Library/Frameworks/R.framework/Resources/lib -lRlapack
-L/Library/Frameworks/R.framework/Resources/lib -lRblas
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
-L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath
-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
-Wl,CoreFoundation
ld: warning: directory not found for option
'-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
ld: warning: directory not found for option
'-L/opt/R/arm64/gfortran/lib'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [HACSim.so] Error 1
ERROR: compilation failed for package ‘HACSim’
─ removing
‘/private/var/folders/r4/xm5blbcd2tn06tjv00lm1c78gn/T/RtmpN4uaYR/Rinstdf4219594de/HACSim’
---
ERROR: package installation failed
Error in `(function (command = NULL, args = character(),
error_on_status = TRUE, …`:
! System command 'R' failed
---
Exit status: 1
stdout & stderr:
---
Type .Last.error to see the more details.
`clang` is installed (since I am able to run the code within my package)
and I've verified by typing `gcc` in the Mac Terminal. I've also installed
`Homebrew` and `gfortran`, verifying via typing in the Terminal.
Any idea on what's going on and how to fix the is
Re: [R-SIG-Mac] [R-pkg-devel] 'Default' macos (x86) download URL now gone?
On 23/04/2023 11:25 a.m., Dirk Eddelbuettel wrote:
The URL ${CRAN}/bin/macosx/R-latest.pkg is in fairlt widespread use. A quick
Google query [1] reveals about 1.1k hits. And it happens to be used too in a
CI job a colleague noticed failing yesterday.
The bin/macosx/ page now prominently displays both leading flavours
R-4.3.0-arm64.pkg
R-4.3.0-x86_64.pkg
which makes sense give the architecture choices. We can of course update the
CI script, and likely will.
But given that this was apparently a somewhat widely-used URL to fetch R on
macOS, may I suggest that the convenience link be reestablished as a courtesy?
[Moved from R-pkg-devel]
Would that make sense? You suggest pointing to R-4.3.0-x86_64.pkg, but
I think fewer and fewer MacOS users would want that, so maybe it's not a
good idea.
On the other hand, maybe R-latest-arm64.pkg and R-latest-x86_64.pkg
should be created.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] question about using edit() function on mac
On 21/04/2023 7:54 a.m., Barry Zeeberg wrote: I have a question about using the edit() function inside an R program that I am running in the standard R console, and on a mac mini with the most recent OS. I believe you mean R.app. (1) I was wondering if there is a way to programmatically control the screen location where the edit window appears, and the size of the edit window. I don't think there's anything in R, but it does remember the size from invocation to invocation (even across sessions), so it must be saving it somewhere. Maybe if you found that spot you could change the value before opening it. (2) I also notice that the edit window for an array with say 4 columns shows up with a fifth column that is empty and that stretches all the way across to the right edge of the screen. Can I suppress this extra empty column from showing up? Again, I don't think so: that wouldn't really be compatible with maintaining the size. (3) Finally, and less importantly to me, is there any way to select the font style and the font size that is used in the edit window? As far as I can see, no. Duncan Murdoch ___ 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.3.0 RC, more information below
On 18/04/2023 12:58 p.m., Duncan Murdoch wrote: Hi Simon. I'm seeing crashes when I try to compile rgl and run it in the new R on my Intel notebook. I only installed R, I didn't update all the libs/tools/etc. The crash report is copied below. One oddity I notice on the 4th line of the report: it says it is running "R 4.2.3 GUI 1.79 Big Sur Intel build (8220)". When I run R.app and `version`, I see > version _ platform x86_64-apple-darwin20 arch x86_64 os darwin20 system x86_64, darwin20 status RC major 4 minor 3.0 year 2023 month 04 day13 svn rev84266 language R version.string R version 4.3.0 RC (2023-04-13 r84266) nickname Already Tomorrow but when I choose "About R" in the GUI, I see 4.2.3 reported. Maybe I've got both installed, and that's the cause of the crash? Duncan Murdoch Sorry, I think that was (mostly) a false alarm. I may have had some old object files which weren't recompiled after the install; at least after a new clean build I'm not seeing the crash any more. The bad version report in R.app is still there. Duncan Murdoch ___ 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.3.0 RC, more information below
Hi Simon. I'm seeing crashes when I try to compile rgl and run it in the new R on my Intel notebook. I only installed R, I didn't update all the libs/tools/etc. The crash report is copied below. One oddity I notice on the 4th line of the report: it says it is running "R 4.2.3 GUI 1.79 Big Sur Intel build (8220)". When I run R.app and `version`, I see > version _ platform x86_64-apple-darwin20 arch x86_64 os darwin20 system x86_64, darwin20 status RC major 4 minor 3.0 year 2023 month 04 day13 svn rev84266 language R version.string R version 4.3.0 RC (2023-04-13 r84266) nickname Already Tomorrow but when I choose "About R" in the GUI, I see 4.2.3 reported. Maybe I've got both installed, and that's the cause of the crash? Duncan Murdoch - Translated Report (Full Report Below) - Process: R [73019] Path: /Applications/R.app/Contents/MacOS/R Identifier:org.R-project.R Version: R 4.2.3 GUI 1.79 Big Sur Intel build (8220) Code Type: X86-64 (Native) Parent Process:launchd [1] User ID: 501 Date/Time: 2023-04-18 12:52:03.3210 -0400 OS Version:macOS 12.6.5 (21G531) Report Version:12 Anonymous UUID:2FE3AC85-3E2D-5190-5592-56ECA0EE7FA1 Sleep/Wake UUID: 26969829-5168-4FF8-8E98-CBCCF23BAFDB Time Awake Since Boot: 23 seconds Time Since Wake: 2451 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0004c9f0 Exception Codes: 0x0001, 0x0004c9f0 Exception Note:EXC_CORPSE_NOTIFY Termination Reason:Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [73019] VM Region Info: 0x4c9f0 is not in any region. Bytes before following region: 4414989840 REGION TYPESTART - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 1072c3000-10734f000[ 560K] r-x/r-x SM=COW ...tents/MacOS/R Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libR.dylib 0x124689ab9 Rf_install + 73 1 rgl.so 0x11ff0f504 rgl::X11GUIFactory::createWindowImpl(rgl::Window*) + 52 (x11gui.cpp:655) 2 rgl.so 0x11ff00806 rgl::Window::Window(rgl::View*, rgl::GUIFactory*) + 118 (gui.cpp:162) 3 rgl.so 0x11fedf294 rgl::Device::Device(int, bool) + 148 (device.cpp:16) 4 rgl.so 0x11fedfec5 rgl::DeviceManager::createTestWindow() + 37 (devicemanager.cpp:167) 5 rgl.so 0x11ff00f39 rgl_init + 313 (init.cpp:97) 6 libR.dylib 0x10799dfde R_doDotCall + 862 (dotcode.c:877) 7 libR.dylib 0x1079ee818 bcEval + 105112 (eval.c:8002) 8 libR.dylib 0x1079d4713 Rf_eval + 531 (eval.c:1013) 9 libR.dylib 0x1079f47ac R_execClosure + 2284 10 libR.dylib 0x1079f34e3 Rf_applyClosure + 483 (eval.c:2113) 11 libR.dylib 0x1079dba87 bcEval + 27911 (eval.c:7414) 12 libR.dylib 0x1079d4713 Rf_eval + 531 (eval.c:1013) 13 libR.dylib 0x1079f47ac R_execClosure + 2284 14 libR.dylib 0x1079f34e3 Rf_applyClosure + 483 (eval.c:2113) 15 libR.dylib 0x1079dba87 bcEval + 27911 (eval.c:7414) 16 libR.dylib 0x1079d4713 Rf_eval + 531 (eval.c:1013) 17 libR.dylib 0x1079f2bac forcePromise + 172 (eval.c:833) 18 libR.dylib 0x107a00434 FORCE_PROMISE + 8 (eval.c:5467) [inlined] 19 libR.dylib 0x107a00434 getvar + 372 (eval.c:5508) 20 libR.dylib 0x1079d8b5f bcEval + 15839 (eval.c:7198) 21 libR.dylib 0x1079d4713 Rf_eval + 531 (eval.c:1013) 22 libR.dylib 0x1079f2bac forcePromise + 172 (eval.c:833) 23 libR.dylib 0x107a00434 FORCE_PROMISE + 8 (eval.c:5467) [inlined] 24 libR.dylib 0x107a00434 getvar + 372 (eval.c:5508) 25 libR.dylib 0x1079d8b5f bcEval + 15839 (eval.c:7198) 26 libR.dylib 0x1079d4713 Rf_eval + 531 (eval.c:1013) 27 libR.dylib 0x1079f2bac forcePromise + 172 (
Re: [R-SIG-Mac] List of unnecessary messages when I plot something in R from Terminal
That's right. The releases are based on what's known when they are released, not what will be known in the future. And statisticians are supposed to be good at prediction... Duncan Murdoch On 11/02/2023 4:53 p.m., Jeff Newmiller wrote: Operating systems are designed to be as backward-compatible as possible... R Core doesn't generally know what distinguishing features will identify a new OS until it is released, nor what it will be called, so R has a handicap. On February 11, 2023 1:12:42 PM PST, Christofer Bogaso wrote: Actually when I check from the Apple icon, then I see that I am actually running Ventura For some reason, R's sessionInfo() is reporting that I am running Big Sur. Not sure why R is reporting wrong. Thanks, On Sun, Feb 12, 2023 at 2:38 AM Christofer Bogaso wrote: Hi, I am running Big Sur. Below is my sessionInfo() sessionInfo() R version 4.2.1 (2022-06-23) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Big Sur ... 10.16 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRblas.0.dylib LAPACK: /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib locale: [1] C/UTF-8/C/C/C/C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.2.1 On Sun, Feb 12, 2023 at 1:55 AM Simon Urbanek wrote: 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 PM, Christofer Bogaso wrote: Hi, When I plot something in R, then it open Quartz and in the console I see below messages plot(1:4) 1 HIToolbox 0x7ff8229a2726 _ZN15MenuBarInstance22EnsureAutoShowObserverEv + 102 2 HIToolbox 0x7ff8229a22b8 _ZN15MenuBarInstance14EnableAutoShowEv + 52 3 HIToolbox 0x7ff822946908 SetMenuBarObscured + 408 4 HIToolbox 0x7ff8229464ca _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 164 5 HIToolbox 0x7ff822940996 _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 252 6 HIToolbox 0x7ff822908bd2 _NotifyEventLoopObservers + 153 7 HIToolbox 0x7ff8229403e6 AcquireEventFromQueue + 494 8 HIToolbox 0x7ff82292f3ec ReceiveNextEventCommon + 285 9 HIToolbox 0x7ff82292f2b3 _BlockUntilNextEventMatchingListInModeWithFilter + 70 10 AppKit 0x7ff81c136f33 _DPSNextEvent + 909 11 AppKit 0x7ff81c135db4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1219 12 grDevices.so0x0001086f7a3b input_handler + 155 13 libR.dylib 0x000108b142cf Rstd_ReadConsole + 2127 14 libR.dylib 0x000108a15b74 Rf_ReplIteration + 100 15 libR.dylib 0x000108a174b1 R_ReplConsole + 161 16 libR.dylib 0x000108a17402 run_Rmainloop + 82 17 libR.dylib 0x000108a1753e Rf_mainloop + 14 18 R 0x00010847af5b main + 27 19 dyld0x7ff818bde310 start + 2432 1 HIToolbox 0x7ff822aa952b _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 259 2 HIToolbox 0x7ff8229a233e _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 34 3 HIToolbox 0x7ff8229117a4 _ZN15MenuBarInstance16ForEachMenuBarDoEU13block_pointerFvPS_E + 46 4 HIToolbox 0x7ff8229a293d _ZN15MenuBarInstance20AutoShowHideObserverEjP14OpaqueEventRefPv + 165 5 HIToolbox 0x7ff822908bd2 _NotifyEventLoopObservers + 153 6 HIToolbox 0x7ff82293afb8 PostEventToQueueInternal + 700 7 HIToolbox 0x7ff82293c871 _ZL29CreateAndPostEventWithCGEventP9__CGEventjhP17__CFMachPortBoost + 404 8 HIToolbox 0x7ff822948ee9 _ZL15Convert1CGEventh + 246 9 HIToolbox 0x7ff822948d91 _ZL16MainLoopObserverjP14OpaqueEventRefPv + 41 10 HIToolbox 0x7ff822908bd2 _NotifyEventLoopObservers + 153 11 HIToolbox 0x7ff82292f726 RunCurrentEventLoopInMode + 228 12 HIToolbox 0x7ff82292f396 ReceiveNextEventCommon + 199 13 HIToolbox
Re: [R-SIG-Mac] Cannot open PDF Vignettes on Ventura
That worked for me. I deleted two plugins from the global
/Library/Internet\ Plug-Ins folder named
AdobePDFViewer.plugin
AdobePDFViewerNPAPI.plugin
and dated from 2020. Now things are fine.
Duncan Murdoch
On 06/02/2023 7:36 p.m., Simon Urbanek wrote:
Kevin,
oh, that's something entirely different - what I was talking about was if you
use
vignette("survival")
in R it opens a Preview with the vignette.
What you describe seems like a browser plugin issue, because the help system is
just an html page (assuming you are talking about the html help system). So it
seems that you may have installed some Adobe browser plugin that doesn't work
anymore. The plugins live in ~/Library/Internet\ Plug-Ins/ (user) and
/Library/Internet\ Plug-Ins/ (global), so you should remove it from there.
Cheers,
Simon
On 7/02/2023, at 12:01 PM, Kevin Thorpe wrote:
When I try to open a PDF vignette (say a vignette from the survival
package)from the help system in R it does not open Preview. I cannot actually
open any PDF vignettes. All I get is a finder window with the error I
previously described. It asks me to select an appropriate viewer. Selecting
Preview opens nothing and more errors are thrown to the Console. I could send
you and Duncan screenshots off-list, since I know that theses lists are picky
about attachments.
The steps I take are:
1. Open the R app.
2. Start the Help system.
3. Navigate to the survival package vignettes.
4. Click the PDF link for the The survival package
Then the errors happen.
I will send a screenshot of the result off list.
Kevin
--
Kevin E. Thorpe
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
On Feb 6, 2023, at 4:58 PM, Simon Urbanek wrote:
Kevin,
can you then describe in more detail what you are taking about? If you open a PDF
vignette in R, it simply calls "open" so it will open in Preview (as that is
your system viewer). And you have confirmed that it is what happens, so are you taking
about something else? If so, please describe every step you make to reproduce whatever
issue you are having.
Thanks,
Simon
On Feb 7, 2023, at 9:58 AM, Kevin Thorpe wrote:
Yes, it does.
Kevin
--
Kevin E. Thorpe
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
On Feb 6, 2023, at 3:56 PM, Duncan Murdoch wrote:
On 06/02/2023 3:47 p.m., Kevin Thorpe wrote:
Simon,
Preview is my default viewer. In the finder window that came up I tried
selecting Preview as the viewer to use and it still failed. The following
errors went to the Console.
2023-02-06 15:43:55.448 R[62964:5174302] +[CATransaction synchronize] called
within transaction
2023-02-06 15:43:55.568 R[62964:5174302] +[CATransaction synchronize] called
within transaction
2023-02-06 15:44:03.253 R[62964:5174302] +[CATransaction synchronize] called
within transaction
2023-02-06 15:44:16.012 R[62964:5174302] +[CATransaction synchronize] called
within transaction
Kevin
Hi Kevin.
If you just run `open some.pdf` in a terminal, does it open properly in Preview?
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Cannot open PDF Vignettes on Ventura
On 06/02/2023 6:01 p.m., Kevin Thorpe wrote: When I try to open a PDF vignette (say a vignette from the survival package)from the help system in R it does not open Preview. I cannot actually open any PDF vignettes. All I get is a finder window with the error I previously described. It asks me to select an appropriate viewer. Selecting Preview opens nothing and more errors are thrown to the Console. I could send you and Duncan screenshots off-list, since I know that theses lists are picky about attachments. The steps I take are: 1. Open the R app. 2. Start the Help system. 3. Navigate to the survival package vignettes. 4. Click the PDF link for the The survival package Then the errors happen. I will send a screenshot of the result off list. Kevin I don't have Ventura installed (I'm still on Monterey 12.6.3), and following the procedure you describe I get similar results. On the other hand, if I choose Help | Vignettes I get a preview in the R.app vignette window, then if I double click on it, it opens in Acrobat reader (which is the default PDF viewer on my system). Duncan ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Cannot open PDF Vignettes on Ventura
On 06/02/2023 3:47 p.m., Kevin Thorpe wrote: Simon, Preview is my default viewer. In the finder window that came up I tried selecting Preview as the viewer to use and it still failed. The following errors went to the Console. 2023-02-06 15:43:55.448 R[62964:5174302] +[CATransaction synchronize] called within transaction 2023-02-06 15:43:55.568 R[62964:5174302] +[CATransaction synchronize] called within transaction 2023-02-06 15:44:03.253 R[62964:5174302] +[CATransaction synchronize] called within transaction 2023-02-06 15:44:16.012 R[62964:5174302] +[CATransaction synchronize] called within transaction Kevin Hi Kevin. If you just run `open some.pdf` in a terminal, does it open properly in Preview? Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] CRAN installer for macOS - directory permissions
Henrik, you posted this a couple of days ago and I didn't address the _R_CHECK_DEPENDS_ONLY_ point you raised. You're right that the current implementation of _R_CHECK_DEPENDS_ONLY_ doesn't work if all packages are installed in one lib. This is a flaw, with one fix being to never put contributed packages into the system lib. (I haven't done a Linux install in a long time; don't they by default put recommended packages there? They can also be Suggested packages, so if they're in the system lib, that's a bug.) Another possible fix is to change how _R_CHECK_DEPENDS_ONLY_ works, so that it affects package loading directly, by allowing the user to specify a whitelist of packages (e.g. based on the dependencies in the DESCRIPTION file) and having the package loader refuse to load any package unless it's in there. I think I like the current implementation better. So I'd change my recommendation for single-user systems: they should have two libs. One contains base packages and nothing else, the other contains all contributed packages, including recommended ones. Assuming the single user is in the admin group, they could modify the second lib, but only reinstalls of R would change the first one. On a multi-user system there would typically be another lib in the user account. Duncan Murdoch On 03/06/2022 12:45 p.m., Henrik Bengtsson wrote: I see two fairly big problems with users installing R packages to .Library by default. One is related to package checking and CRAN, and one is related to translation of expectations when moving between operating systems (as Patrick already pointed out). At the end, I'll also argue that R_LIBS_SITE exists for those who wish to maintain site-wide R package libraries to be shared among users, which is better than using .Library for this. # R CMD check When you check a package with 'R CMD check --as-cran', or, with environment variable `_R_CHECK_DEPENDS_ONLY_` set to true, the checks are run in a sandbox where only declared package dependencies and any packages in the system package library (= .Library) are on the library path (= .libPaths()), e.g. print(.libPaths()) [1] "/tmp/alice/RtmpYDq3KF/RLIBS_2410b74eb16752" [2] "/path/to/R-4.2.0/lib/R/library" What's in the user's library (= R_LIBS_USER) or in the site library (= .Library.site/R_LIBS_SITE) is not part of the testing. This mechanism is very valuable since it helps to identify undeclared package dependencies. **The default behavior on macOS discussed here, where R packages are installed to .Library, breaks this.** Developers with non-base R packages in .Library will not benefit from the 'R CMD check --as-cran' checks for undeclared packages. This increases the risk of them not being aware of the problem of undeclared packages, which is a discussion we see from time to time on R-devel and R-pkg-devel, e.g. when it comes to what should be listed under Suggests: or not. BTW, this makes me wonder how many macOS developers notice this problem only as they submit to CRAN, and have to resubmit. Also, this issue might add extra work to the CRAN Team, e.g. spending time locking at and responding to possible false positives, handling more emails, and handling more re-submissions. # Social expectations The second problem with the current default macOS behavior is when people hop between systems and operating systems. Particularly, a macOS user coming to Unix or Windows does not immediately understand how and where R packages are installed. They get a prompt about a "personal library" and might choose to decline because it's not what they're used to seeing. Then they might end up in the Stack Overflow cut'n'paste rabbit hole, where they find some instructions on setting 'R_LIBS_USER=$HOME/R-lib' without version specifiers. Works fine until they upgrade R next year, when they start getting weird warnings or errors of some packages not working that they slowly start to accept as the normal behavior of R. I see this problem on large HPC environments where I help out thousands of HPC users. Also, reading various support forums out there, I think this is a real problem. It's only recently, thanks to Patrick, I learned about this rather odd macOS behavior, and I do think it is a cause for confusion and miscommunication. Another problem with different OS behaviors is that it complicated documentation and instructions. I strongly believe, it would be beneficial to the R community if we all have the same experience and expectations regardless of OS. I believe the above problems are best addressed by changing the *default* settings on macOS so that it is *not* possible to install to .Library, and instead require a user to install to their personal package library. Advanced users who prefer to install to .Library, can still configure R, or .Library, to do so. As Patrick suggests, defaulting .Library to 755, instead of 775, or avoid setting the "admin&q
Re: [R-SIG-Mac] CRAN installer for macOS - directory permissions
On 03/06/2022 1:43 p.m., Jeff Newmiller wrote: That would be a disaster. The computer sysadmin's whims should not override my userland analysis setup. This is not so hard to understand that even a beginner won't "get" it if you just remind them that their user library is the primary place to look. On my system, as is the default on most single user MacOS systems, there is no difference between the sysadmin and the user, nor between the system library and the user library. That's where this discussion started in April. The only reason people get confused is because various experts make suggestions that they should even try to manage the system library in R. No, it's because they have two libraries where one is sufficient. The longer I work with R, the less I think anyone should mess with the system R library... it should come with R and only change when the software is updated. To do that would require doing away with "recommended" packages. That might be a good idea: only have base packages in the system library; by definition they will never be updated except when R is updated. Every contributed package goes into the user library. That's functionally equivalent to having only one library, because there would be no way to install duplicate versions of packages. Any other changes made to it involve unnecessary privilege escalation and/or mucking with the default behavior of any other users who might use that machine, and if I (or any hypothetical new user) decide to make a change, it should always be resolvable by wiping the user library and starting over. No, changes to it don't require privilege escalation. Most MacOS users on single user machines are already in the admin group, and that group has permission to change the system library. That's the point that Patrick made in his original message. He was asking to change the installer so that privilege escalations *would* be required. Duncan Murdoch On June 3, 2022 10:01:25 AM PDT, Duncan Murdoch wrote: Hi Henrik. You didn't address the issue of having different versions of a package installed in the system library versus the personal library, an issue that causes lots of confusion for unsophisticated users. A possible solution for this is for R by default to refuse to install a package in the personal library if it is already installed in the system library. Duncan Murdoch On 03/06/2022 12:45 p.m., Henrik Bengtsson wrote: I see two fairly big problems with users installing R packages to .Library by default. One is related to package checking and CRAN, and one is related to translation of expectations when moving between operating systems (as Patrick already pointed out). At the end, I'll also argue that R_LIBS_SITE exists for those who wish to maintain site-wide R package libraries to be shared among users, which is better than using .Library for this. # R CMD check When you check a package with 'R CMD check --as-cran', or, with environment variable `_R_CHECK_DEPENDS_ONLY_` set to true, the checks are run in a sandbox where only declared package dependencies and any packages in the system package library (= .Library) are on the library path (= .libPaths()), e.g. print(.libPaths()) [1] "/tmp/alice/RtmpYDq3KF/RLIBS_2410b74eb16752" [2] "/path/to/R-4.2.0/lib/R/library" What's in the user's library (= R_LIBS_USER) or in the site library (= .Library.site/R_LIBS_SITE) is not part of the testing. This mechanism is very valuable since it helps to identify undeclared package dependencies. **The default behavior on macOS discussed here, where R packages are installed to .Library, breaks this.** Developers with non-base R packages in .Library will not benefit from the 'R CMD check --as-cran' checks for undeclared packages. This increases the risk of them not being aware of the problem of undeclared packages, which is a discussion we see from time to time on R-devel and R-pkg-devel, e.g. when it comes to what should be listed under Suggests: or not. BTW, this makes me wonder how many macOS developers notice this problem only as they submit to CRAN, and have to resubmit. Also, this issue might add extra work to the CRAN Team, e.g. spending time locking at and responding to possible false positives, handling more emails, and handling more re-submissions. # Social expectations The second problem with the current default macOS behavior is when people hop between systems and operating systems. Particularly, a macOS user coming to Unix or Windows does not immediately understand how and where R packages are installed. They get a prompt about a "personal library" and might choose to decline because it's not what they're used to seeing. Then they might end up in the Stack Overflow cut'n'paste rabbit hole, where they find some instructions on setting 'R_LIBS_USER=$HOME/R-lib' without version specifiers. Works fine until they upgrade R next year, when t
Re: [R-SIG-Mac] CRAN installer for macOS - directory permissions
On 03/06/2022 1:45 p.m., Henrik Bengtsson wrote: Hi Duncan, thank you for the follow-up. You didn't address the issue of having different versions of a package installed in the system library versus the personal library, an issue that causes lots of confusion for unsophisticated users. I think this is a problem that applies to all operating systems and is not specific to macOS. Whatever the solution, or best practices, is for that, I think it should be addressed uniformly across platforms. I have, some experience and thoughts around this too, but wouldn't it be better if we move that discussion to R-devel? I think you misunderstood. As I pointed out in my earlier message (a month ago!), duplicate installs typically aren't such a problem on MacOS, because by default for many users (like me), all installs go to the system library. Consistency is generally a positive thing, but creating problems on MacOS for the sake of consistency with other systems isn't. My latest message was an attempt to find a compromise: make it harder to create this problem. As to taking this discussion to R-devel, I think that's a bad idea before we agree on a specific proposal to make. Duncan Murdoch /Henrik On Fri, Jun 3, 2022 at 10:38 AM Duncan Murdoch wrote: On 03/06/2022 1:21 p.m., Peter Dalgaard wrote: Eek! No, just no... That way users can't upgrade a package for himself on a multi-user system if the sysop won't do it for everyone. "by default" Duncan Murdoch - pd On 3 Jun 2022, at 19:01 , Duncan Murdoch wrote: Hi Henrik. You didn't address the issue of having different versions of a package installed in the system library versus the personal library, an issue that causes lots of confusion for unsophisticated users. A possible solution for this is for R by default to refuse to install a package in the personal library if it is already installed in the system library. Duncan Murdoch On 03/06/2022 12:45 p.m., Henrik Bengtsson wrote: I see two fairly big problems with users installing R packages to .Library by default. One is related to package checking and CRAN, and one is related to translation of expectations when moving between operating systems (as Patrick already pointed out). At the end, I'll also argue that R_LIBS_SITE exists for those who wish to maintain site-wide R package libraries to be shared among users, which is better than using .Library for this. # R CMD check When you check a package with 'R CMD check --as-cran', or, with environment variable `_R_CHECK_DEPENDS_ONLY_` set to true, the checks are run in a sandbox where only declared package dependencies and any packages in the system package library (= .Library) are on the library path (= .libPaths()), e.g. print(.libPaths()) [1] "/tmp/alice/RtmpYDq3KF/RLIBS_2410b74eb16752" [2] "/path/to/R-4.2.0/lib/R/library" What's in the user's library (= R_LIBS_USER) or in the site library (= .Library.site/R_LIBS_SITE) is not part of the testing. This mechanism is very valuable since it helps to identify undeclared package dependencies. **The default behavior on macOS discussed here, where R packages are installed to .Library, breaks this.** Developers with non-base R packages in .Library will not benefit from the 'R CMD check --as-cran' checks for undeclared packages. This increases the risk of them not being aware of the problem of undeclared packages, which is a discussion we see from time to time on R-devel and R-pkg-devel, e.g. when it comes to what should be listed under Suggests: or not. BTW, this makes me wonder how many macOS developers notice this problem only as they submit to CRAN, and have to resubmit. Also, this issue might add extra work to the CRAN Team, e.g. spending time locking at and responding to possible false positives, handling more emails, and handling more re-submissions. # Social expectations The second problem with the current default macOS behavior is when people hop between systems and operating systems. Particularly, a macOS user coming to Unix or Windows does not immediately understand how and where R packages are installed. They get a prompt about a "personal library" and might choose to decline because it's not what they're used to seeing. Then they might end up in the Stack Overflow cut'n'paste rabbit hole, where they find some instructions on setting 'R_LIBS_USER=$HOME/R-lib' without version specifiers. Works fine until they upgrade R next year, when they start getting weird warnings or errors of some packages not working that they slowly start to accept as the normal behavior of R. I see this problem on large HPC environments where I help out thousands of HPC users. Also, reading various support forums out there, I think this is a real problem. It's only recently, thanks to Patrick, I learned about this rather odd macOS behavior, and I do think it is a cause for confusion and miscommunication. Another problem with different OS behavi
Re: [R-SIG-Mac] CRAN installer for macOS - directory permissions
Hi Henrik. You didn't address the issue of having different versions of a package installed in the system library versus the personal library, an issue that causes lots of confusion for unsophisticated users. A possible solution for this is for R by default to refuse to install a package in the personal library if it is already installed in the system library. Duncan Murdoch On 03/06/2022 12:45 p.m., Henrik Bengtsson wrote: I see two fairly big problems with users installing R packages to .Library by default. One is related to package checking and CRAN, and one is related to translation of expectations when moving between operating systems (as Patrick already pointed out). At the end, I'll also argue that R_LIBS_SITE exists for those who wish to maintain site-wide R package libraries to be shared among users, which is better than using .Library for this. # R CMD check When you check a package with 'R CMD check --as-cran', or, with environment variable `_R_CHECK_DEPENDS_ONLY_` set to true, the checks are run in a sandbox where only declared package dependencies and any packages in the system package library (= .Library) are on the library path (= .libPaths()), e.g. print(.libPaths()) [1] "/tmp/alice/RtmpYDq3KF/RLIBS_2410b74eb16752" [2] "/path/to/R-4.2.0/lib/R/library" What's in the user's library (= R_LIBS_USER) or in the site library (= .Library.site/R_LIBS_SITE) is not part of the testing. This mechanism is very valuable since it helps to identify undeclared package dependencies. **The default behavior on macOS discussed here, where R packages are installed to .Library, breaks this.** Developers with non-base R packages in .Library will not benefit from the 'R CMD check --as-cran' checks for undeclared packages. This increases the risk of them not being aware of the problem of undeclared packages, which is a discussion we see from time to time on R-devel and R-pkg-devel, e.g. when it comes to what should be listed under Suggests: or not. BTW, this makes me wonder how many macOS developers notice this problem only as they submit to CRAN, and have to resubmit. Also, this issue might add extra work to the CRAN Team, e.g. spending time locking at and responding to possible false positives, handling more emails, and handling more re-submissions. # Social expectations The second problem with the current default macOS behavior is when people hop between systems and operating systems. Particularly, a macOS user coming to Unix or Windows does not immediately understand how and where R packages are installed. They get a prompt about a "personal library" and might choose to decline because it's not what they're used to seeing. Then they might end up in the Stack Overflow cut'n'paste rabbit hole, where they find some instructions on setting 'R_LIBS_USER=$HOME/R-lib' without version specifiers. Works fine until they upgrade R next year, when they start getting weird warnings or errors of some packages not working that they slowly start to accept as the normal behavior of R. I see this problem on large HPC environments where I help out thousands of HPC users. Also, reading various support forums out there, I think this is a real problem. It's only recently, thanks to Patrick, I learned about this rather odd macOS behavior, and I do think it is a cause for confusion and miscommunication. Another problem with different OS behaviors is that it complicated documentation and instructions. I strongly believe, it would be beneficial to the R community if we all have the same experience and expectations regardless of OS. I believe the above problems are best addressed by changing the *default* settings on macOS so that it is *not* possible to install to .Library, and instead require a user to install to their personal package library. Advanced users who prefer to install to .Library, can still configure R, or .Library, to do so. As Patrick suggests, defaulting .Library to 755, instead of 775, or avoid setting the "admin" group, seems like a simple solution that would help harmonize the user experience of R. # Maintaining a site-wide package library I would argue that the current setup tends to be a lot safer than the alternatives, because it allows commonly used packages to be installed at the system level and private packages to be installed at user level. This is also the design typically used on shared machines, where you separate local packages from user packages where local ones are installed by administrators - so exactly the same setup. Moreover R upgrades are a lot cleaner, since you can easily upgrade all system packages at once so you don't have to worry about individual users having stale packages - the biggest problem for admins. I believe .Library.site/R_LIBS_SITE exists to address this purpose, and I argue it is better suited for this than using .Library. It also has the benefit of *not* conflicting with the _R_CHECK_DEP
Re: [R-SIG-Mac] Contributing to documentation [Was: Installing gfortran]
On 30/04/2022 1:10 p.m., Jeff Newmiller wrote: Re revision numbers... yes, you might have to take care to handle aligning the baseline code against which the patch was generated manually. Given that outside contributions would tend to start from specific releases though this shouldn't be too onerous. I hope contributions wouldn't start from releases. Hopefully they'd start from the head of R-devel on svn or its Github mirror. R-devel is where almost all changes go first, but releases may have split from it a long time ago. For example, right now R 4.2.0 is very recent, but there have been 309 revisions in svn since 4.2.0 was split off from R-devel back in March, many of which affected the documentation. The previous release (4.1.3 in March) split from R-devel more than a year ago. It's true that people recognize problems in the docs in releases, but that's not what they should be editing. Often problems there were dealt with months ago, and just weren't seen as important enough to backport to the R-patched branch so they never made it into a release. Duncan Murdoch The bigger impedance is that people who are good with documentation but not with code have a significant impedance in learning how patches work. In these days where you can use the GitHub web interface to clone a repo, edit a file, and submit a pull request without ever leaving the web browser, tools like diff and patch seem excessive. Only fogeys/nerds like us view them as the fabric of computing. Re git and empty directories... git is structurally incapable of recording them in the repo. A common workaround is to touch a .gitkeep file in the directory, but I suspect this will never become an automated feature of git because it cannot be hidden from the user without making the chosen filename off-limits to the user. That seems like a design flaw, but a pretty easy one to work around. Git only cares about the data in files, not how those files are identified. Attempting to pretend that a directory is identifiable by its content breaks that principle. There is a significant benefit from the implementation and user mental model perspectives associated with this shift, but if you don't utilize those benefits then git is probably not for you. It has been a worthwhile shift for many, many others though... so calling it a design "flaw" might seem innocuous but misses the significant value associated with that design principle for others. Yes, the workaround is easy. But it cannot be hidden unfortunately, so automating it within the git software itself has so far been rejected since the idea that empty directories exist in git is anathema and pretending otherwise breaks the canonical mental model. On April 30, 2022 9:06:53 AM PDT, Duncan Murdoch wrote: On 30/04/2022 11:07 a.m., Jeff Newmiller wrote: Generating patch files is one of the most fundamental capabilities of git. Changes to the Linux kernel are (almost?) universally submitted via patch files generated from git. svn uses nearly standard patch files, but they record svn revision numbers. I'd guess directly applying a git patch file to an svn working copy would almost always work, but I'm not sure it would always be applied correctly in the case where the patch was created from rev X and applied to rev Y. Re git and empty directories... git is structurally incapable of recording them in the repo. A common workaround is to touch a .gitkeep file in the directory, but I suspect this will never become an automated feature of git because it cannot be hidden from the user without making the chosen filename off-limits to the user. That seems like a design flaw, but a pretty easy one to work around. Duncan Murdoch On April 30, 2022 7:45:40 AM PDT, Duncan Murdoch wrote: On 30/04/2022 9:53 a.m., Patrick Schratz wrote: If that is the case, why not contribute to the documentation? That is the whole point of an open source project after all. Because often it is not easily accessible, e.g. living in an ancient SVN repo or lacking (an easy) and clear contribution guide. There's a mirror of that repo at https://github.com/wch/r-source . It is of course unofficial and not maintained by R Core so I could understand you might worry about using it, but as far as I know it is well maintained. The only difference that I ever heard about in the past was that the official svn repo had an empty directory somewhere or other, and git at the time didn't support empty directories. I don't know if either of those is still true. WRT to the Mac dev instructions, I can see that the source lives in https://github.com/R-macos/R-mac-dev <https://github.com/R-macos/R-mac-dev> which is definitely a good start. Yet I think it needs way more cross-linking between the repos, more “official” pointers and “how-tos” to really also encourage people to contribute. The README could give more detailed contribut
Re: [R-SIG-Mac] Contributing to documentation [Was: Installing gfortran]
On 30/04/2022 9:53 a.m., Patrick Schratz wrote: If that is the case, why not contribute to the documentation? That is the whole point of an open source project after all. Because often it is not easily accessible, e.g. living in an ancient SVN repo or lacking (an easy) and clear contribution guide. There's a mirror of that repo at https://github.com/wch/r-source . It is of course unofficial and not maintained by R Core so I could understand you might worry about using it, but as far as I know it is well maintained. The only difference that I ever heard about in the past was that the official svn repo had an empty directory somewhere or other, and git at the time didn't support empty directories. I don't know if either of those is still true. WRT to the Mac dev instructions, I can see that the source lives in https://github.com/R-macos/R-mac-dev <https://github.com/R-macos/R-mac-dev> which is definitely a good start. Yet I think it needs way more cross-linking between the repos, more “official” pointers and “how-tos” to really also encourage people to contribute. The README could give more detailed contribution instructions, such as whom to tag for a PR, what should go there and what not, possibly stating that it’s the official documentation and define it from other “random” orgs on developer portals - all of these could e.g. go into a |CONTRIBUTING.md| which is a widely known source for such information. Just some personal thoughts though which could potentially considered to improve things. To be clear, I acknowledge your effort in opening things up to platforms like GH - which not all parts of R/CRAN are doing at the moment AFAIK. And yes, when complaining about things not being optimal, one should also put in effort to make things better. So I’ll see if I can put some time in to improve things and see how the experience is. If you're happier working in git than in svn, what you could do is fork the mirror repo to your own git repo, and make your proposed changes there. If they are good changes it won't be hard for someone (maybe even you) to convert into the appropriate format to merge into svn. The way R development changes is when a change makes things easier for the devs. I suspect whether it's easier for you is only important to them if you've got a history of making helpful contributions: they like help, they don't like arguments about how to do things. (I'm saying this as a former member of R Core.) Duncan Murdoch The problem is that generally they cannot. You are looking something up, because you don't know about it so you can't judge whether it is a good answer (SO is good example proving why crowd-souring the definition of truth doesn't generally work). At best you may know the person and thus judge by that, but even then you may not know if the information is still accurate. I see your point here and generally agree that it’s hard making such judgements in this position. Yet I disagree on referring to Stackoverflow as a “crowd-souring the definition of truth doesn't generally work”. Without SO, we would be nowhere where we are today and I’d argue it has done a lot more positive things than negative ones to every single person who ever accessed it. > Cheers Patrick On 25 Apr 2022, at 1:04, Simon Urbanek wrote: On Apr 23, 2022, at 7:44 PM, Patrick Schratz wrote: FWIW blog posts which explain such things usually have a (good) reason - they aim to help people getting started when the official documentation is either unclear, hard to find or incomplete. If that is the case, why not contribute to the documentation? That is the whole point of an open source project after all. The problem with random blogs is that many of them are written by people trying to find an answer without much knowledge on the subject and often post very bad advice that does not necesarily address the actual issue. There are rare exceptions of knowledgeable people posting explanatory blogs, but if you search for an answer you have no way of knowing whether it is of the good kind. In addition, blogs tend to get out of date quickly, so what used to be a good advice may not be anymore (prime example was the R 4.0.0 release which made a lot of the "hacks" obsolete and the well-meant advice out there has only led to more problems). It’s on the readers themselves to decide whether such blog posts are trustworthy or useful. The problem is that generally they cannot. You are looking something up, because you don't know about it so you can't judge whether it is a good answer (SO is good example proving why crowd-souring the definition of truth doesn't generally work). At best you may know the person and thus judge by that, but even then you may not know if the information is still a
Re: [R-SIG-Mac] Compiling Cairo package
On 26/12/2021 6:04 a.m., Erich Neuwirth wrote:
I am trying to compile Cairo.
I get the following error
xlib-backend.c:34:10: fatal error: 'X11/Intrinsic.h' file not found
#include /*->Xlib.h Xutil.h Xresource.h .. */
I have X11/Intrinsic.h in /opt/X11/include
I tried
Sys.setenv(LD_LIBRARY_PATH="/opt/X11:/opt/X11/lib")
Sys.getenv("LD_LIBRARY_PATH")
system("export LD_LIBRARY_PATH”)
and compiled again, but I get the same error.
What do I need to do so Intrinsic.h is found by the compiler?
Usually the location of include files is set at configure time. For R,
I use
../R-devel-src/configure --with-x --x-includes=/opt/X11/include
--x-libraries=/opt/X11/lib
It's not clear to me whether Cairo is the R package or an external
library, but if it's the R package, you might try
install.packages("Cairo", type = "source", configure.args =
"--x-includes=/opt/X11/include --x-libraries=/opt/X11/lib")
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Rmpfr crashes on Mac
On 28/11/2021 7:05 a.m., Erich Neuwirth wrote: I checked, and I also get the crash in Rstudio. In Rgui, it works. I don't get the crash, using R 4.1.0 in MacOS 10.15.7, with the same Rmpfr version in RStudio or R.app. Duncan Murdoch On 27.11.2021, at 21:46, Dev Chakraborty wrote: I used package Rmpfr ca. 2017 and it worked fine. The latest version (0.8-7) causes R (running under RStudio) to crash. A simple example is: library(Rmpfr) x1 <- mpfr(-50, 200) x2 <- mpfr(-50.1, 200) Which gives the message: R Session Aborted R encountered a fatal error The session was terminated Start New Session I am using R version 4.1.1 on a Mac running MacOS 12.0.1. and an older iMac running 10.15.7. The problem occurs with both machines. When I install from the CRAN archive file Rmpfr_0.6-1.tar.gz (the version of the package around 2017, corresponding to the last time I used it) the problem goes away. [[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 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Retrieving Script Path in R.app
See https://stackoverflow.com/a/47045368/2554330 for a risky-looking method.
I think the non-RStudio method is equivalent to this function:
this.path <- function() {
sys.frame(-5)$srcfile
}
which works for me using Cmd-E, but of course it doesn't work using
Cmd-Enter, because that doesn't call source().
My conclusion would be to use RStudio rather than the R.app editor. I
prefer R.app for interactive use, but not at all for code development.
Duncan Murdoch
On 09/10/2021 11:23 p.m., Andrew Simmons wrote:
Hello,
I'd like to programmatically retrieve the path of the currently open script
in R.app.
Something like, if I had written:
this.path()
within a script that was open in R.app, and I ran that line with
Command+Enter,
I'd like it to return the path of the script.
It seems like this should be possible since Command+E runs the following:
source("/absolute/path/to/file")
so R.app knows the path of the open script, but I was unable to find
anything that would retrieve it on my own. First, I tried looking through
the environment 'as.environment("tools:RGUI")', but I didn't find anything
that looked like what I was looking for. Second, I tried comparing the
functions available in the base packages between Windows and macOS, and
while there are a few functions available for macOS that are not for
Windows, none of them looked like what I was looking for.
Any help will be greatly appreciated, thank you!
Regards,
Andrew Simmons
[[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
Re: [R-SIG-Mac] .libPaths and library directory
On 05/09/2021 6:16 a.m., Adrian Dușa wrote:
Dear All,
My .libPaths for the user defined directory shows:
"/Users/dusadrian/Library/R/x86_64/4.1/library"
and indeed, the command install.packages() does install the packages in
this location.
However, when installing from the RGUI menu, using Packages & Data /
Package installer,
the installation directory is:
"/Users/dusadrian/Library/R/4.1/library"
Neither of those is the default library location for a standard install
of R on a Mac. The first one looks like it's the default value of
R_LIBS_USER. Are you specifying the environment variable R_LIBS? By
default, I think
Sys.getenv("R_LIBS")
will give a blank.
Regarding the install from R.app (which I assume is what you mean by
RGUI), there is a selection of 4 locations:
- At System Level (in R framework)
- At User Level
- In Other Location
- As defined by .libPaths()
Which of those are you choosing?
Duncan Murdoch
I don't remember at which exact version this started to happen (it was also
present in 4.1.0), and could not find any particular setting that I should
tweak to make these equal.
This is the R.version result:
_
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 08
day10
svn rev80725
language R
version.string R version 4.1.1 (2021-08-10)
nickname Kick Things
running under MacOS BigSur version 11.5.2
Thanks for any hint,
Adrian
--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu
[[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
Re: [R-SIG-Mac] rgl in R version 4.1.1 Patched (2021-08-13 r80752)
The rgl patch was accepted by CRAN an hour ago, so you should see it soon.
Duncan Murdoch
On 19/08/2021 8:57 p.m., Simon Urbanek wrote:
Duncan,
using that checkout I get
* checking package dependencies ... ERROR
Package suggested but not available: ‘webshot2’
but otherwise it works as advertised.
However, I just found out that there is another problem in R that rgl exposed.
Using non-session terminal:
png("/tmp/1.png", type="quartz")
plot(1)
Warning in axis(side = side, at = at, labels = labels, ...) :
no font could be found for family "Arial"
so requests for fonts using Quartz-back-end without an UI session fail. It
works fine inside a session, but since checks are normally run without a
session that explains the check failures. I can run checks in a session, so I
think that's what I'll do for now.
Now, back to rgl - so checks can be run in a session, but oddly, rgl manages to
segfault XQuartz in the checks. I don't think it's rgl's fault - more likely
something in XQuartz (a TCP connection shouldn't be able to segfault the other
end...).
Anyway, so if you can post the fixed release I'd be happy the recompile and
publish manually.
Cheers,
Simon
PS: I found yet another problem - XQuartz has moved the location of fonts from
X11/lib to X11/shared so our fontconfig configuration in R needs to add that
directory as well. So all is all this has highlighted quite a few related
issues ;)
On Aug 20, 2021, at 11:43 AM, Duncan Murdoch wrote:
Thanks Simon (and Prof Ripley, offline). The --static modifier needs to be
added in two places in configure.ac, which leads to it being added in two
places in configure.
If anyone wants to build from source, you could get the CRAN release plus this
modification using
remotes::install_github("dmurdoch/rgl@configpatch")
Duncan Murdoch
On 19/08/2021 6:08 p.m., Simon Urbanek wrote:
R (and the CRAN builds) use more recent static freetype with harfbuzz support
so it does not depend for those in XQuartz.
The issue is that rgl doesn't use sufficient flags to compile against freetype
since it misses the dependencies - in fact is fails checks,
https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/rgl-00check.html
pkg-config has to be used with --static --libs otherwise the linking doesn't
have all the dependencies included that are necessary:
$ pkg-config freetype2 --libs
-L/opt/R/arm64/lib -lfreetype
$ pkg-config freetype2 --static --libs
-L/opt/R/arm64/lib -lfreetype -lbz2 -lpng16 -lz -lharfbuzz -lm -lglib-2.0
-lintl -liconv -lm -Wl,-framework,CoreFoundation -Wl,-framework,Carbon
-Wl,-framework,Foundation -Wl,-framework,AppKit -lpcre
The CRAN binaries are built against static libraries to make sure the user
doesn't have to install 3rd party dependencies.
It looks line rgl does the right thing for libpng but not for freetype.
Cheers,
Simon
On Aug 19, 2021, at 9:54 PM, Stefan Evert wrote:
On 19 Aug 2021, at 10:40, Duncan Murdoch wrote:
Error in dyn.load(dynlib <- getDynlib(dir)) :
unable to load shared object
'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so':
dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so,
6): Symbol not found: _hb_buffer_add_utf8
Referenced from:
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
Expected in: flat namespace
in
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
That looks like a symbol in the harfbuzz lib. rgl doesn't reference it
directly, I think FreeType does. I don't know what you need to do to fix this,
but maybe that's enough of a hint.
I just ran into the same problem with a M1 MacBook and XQuartz 2.8.1 installed. My
MacBook has no developer tools installed, not even XCode – just R, "rgl" (and
various other packages) from CRAN, and XQuartz.
XQuartz doesn't include libharfbuzz, so I doubt that it's libfreetype depends
on it. Any chance that the CRAN machine that builds the aarch64 binary package
links against some other version of freetype that pulls in the dependency?
Best,
Stefan
___
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] rgl in R version 4.1.1 Patched (2021-08-13 r80752)
On 19/08/2021 8:57 p.m., Simon Urbanek wrote:
Duncan,
using that checkout I get
* checking package dependencies ... ERROR
Package suggested but not available: ‘webshot2’
webshot2 still hasn't been sent to CRAN, so I've been putting tarballs
on a Drat repos, and the DESCRIPTION has this:
Additional_repositories: https://dmurdoch.github.io/drat
Do you know if your check looked in that repos and didn't see it, or did
it not look there?
BTW, the reason I am including a non-CRAN package is because it has
several advantages over the internal rgl.snapshot. rgl.snapshot
requires that the scene be displayed on a local screen so it can't run
on a headless machine; it also uses the very old rendering built in to
rgl's in-R display, so typically produces poorer quality screenshots
than webshot2 produces. The main disadvantages of webshot2 are that
it's not on CRAN and it's typically quite a bit slower than rgl.snapshot.
but otherwise it works as advertised.
However, I just found out that there is another problem in R that rgl exposed.
Using non-session terminal:
png("/tmp/1.png", type="quartz")
plot(1)
Warning in axis(side = side, at = at, labels = labels, ...) :
no font could be found for family "Arial"
so requests for fonts using Quartz-back-end without an UI session fail. It
works fine inside a session, but since checks are normally run without a
session that explains the check failures. I can run checks in a session, so I
think that's what I'll do for now.
Now, back to rgl - so checks can be run in a session, but oddly, rgl manages to
segfault XQuartz in the checks. I don't think it's rgl's fault - more likely
something in XQuartz (a TCP connection shouldn't be able to segfault the other
end...).
I don't have an ARM machine to test on, but on my machine when running
in lldb I see messages like these on startup:
2021-08-20 08:00:26.791865-0400 R[79608:1971631] flock failed to lock
maps file: errno = 35
2021-08-20 08:00:26.796823-0400 R[79608:1971631] flock failed to lock
maps file: errno = 35
and when I actually do some plotting I see lots like these:
2021-08-20 08:00:47.459884-0400 R[79608:1971542]
apple_glx_create_context: ac 0x100a99830 ac->context_obj 0x106f4ea00
2021-08-20 08:00:47.460043-0400 R[79608:1971542]
apple_glx_drawable_create: new drawable 0x103363e00
2021-08-20 08:00:47.461620-0400 R[79608:1971542] create_surface: created
a surface for drawable 0x600067 with uid 49
2021-08-20 08:00:47.461657-0400 R[79608:1971542] surface_make_current:
ac->context_obj 0x106f4ea00 s->surface_id 9
2021-08-20 08:00:47.462172-0400 R[79608:1971542] surface_make_current:
drawable 0x600067
2021-08-20 08:00:47.462203-0400 R[79608:1971542] applegl_bind_context:
error NO
2021-08-20 08:00:47.469827-0400 R[79608:1971542] caller is the same
thread for uid 49
2021-08-20 08:00:47.470001-0400 R[79608:1971542] surface notify updated 0
2021-08-20 08:00:47.470340-0400 R[79608:1971542] caller is the same
thread for uid 49
They don't seem to lead to any problems, but maybe on an ARM they're
more serious.
Anyway, so if you can post the fixed release I'd be happy the recompile and
publish manually.
Okay, I'll package it up and send it to CRAN.
Duncan Murdoch
Cheers,
Simon
PS: I found yet another problem - XQuartz has moved the location of fonts from
X11/lib to X11/shared so our fontconfig configuration in R needs to add that
directory as well. So all is all this has highlighted quite a few related
issues ;)
On Aug 20, 2021, at 11:43 AM, Duncan Murdoch wrote:
Thanks Simon (and Prof Ripley, offline). The --static modifier needs to be
added in two places in configure.ac, which leads to it being added in two
places in configure.
If anyone wants to build from source, you could get the CRAN release plus this
modification using
remotes::install_github("dmurdoch/rgl@configpatch")
Duncan Murdoch
On 19/08/2021 6:08 p.m., Simon Urbanek wrote:
R (and the CRAN builds) use more recent static freetype with harfbuzz support
so it does not depend for those in XQuartz.
The issue is that rgl doesn't use sufficient flags to compile against freetype
since it misses the dependencies - in fact is fails checks,
https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/rgl-00check.html
pkg-config has to be used with --static --libs otherwise the linking doesn't
have all the dependencies included that are necessary:
$ pkg-config freetype2 --libs
-L/opt/R/arm64/lib -lfreetype
$ pkg-config freetype2 --static --libs
-L/opt/R/arm64/lib -lfreetype -lbz2 -lpng16 -lz -lharfbuzz -lm -lglib-2.0
-lintl -liconv -lm -Wl,-framework,CoreFoundation -Wl,-framework,Carbon
-Wl,-framework,Foundation -Wl,-framework,AppKit -lpcre
The CRAN binaries are built against static libraries to make sure the user
doesn't have to install 3rd party dependencies.
It looks line rgl does the right thing for libpng but not for freetype.
C
Re: [R-SIG-Mac] rgl in R version 4.1.1 Patched (2021-08-13 r80752)
Thanks Simon (and Prof Ripley, offline). The --static modifier needs to
be added in two places in configure.ac, which leads to it being added in
two places in configure.
If anyone wants to build from source, you could get the CRAN release
plus this modification using
remotes::install_github("dmurdoch/rgl@configpatch")
Duncan Murdoch
On 19/08/2021 6:08 p.m., Simon Urbanek wrote:
R (and the CRAN builds) use more recent static freetype with harfbuzz support
so it does not depend for those in XQuartz.
The issue is that rgl doesn't use sufficient flags to compile against freetype
since it misses the dependencies - in fact is fails checks,
https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/rgl-00check.html
pkg-config has to be used with --static --libs otherwise the linking doesn't
have all the dependencies included that are necessary:
$ pkg-config freetype2 --libs
-L/opt/R/arm64/lib -lfreetype
$ pkg-config freetype2 --static --libs
-L/opt/R/arm64/lib -lfreetype -lbz2 -lpng16 -lz -lharfbuzz -lm -lglib-2.0
-lintl -liconv -lm -Wl,-framework,CoreFoundation -Wl,-framework,Carbon
-Wl,-framework,Foundation -Wl,-framework,AppKit -lpcre
The CRAN binaries are built against static libraries to make sure the user
doesn't have to install 3rd party dependencies.
It looks line rgl does the right thing for libpng but not for freetype.
Cheers,
Simon
On Aug 19, 2021, at 9:54 PM, Stefan Evert wrote:
On 19 Aug 2021, at 10:40, Duncan Murdoch wrote:
Error in dyn.load(dynlib <- getDynlib(dir)) :
unable to load shared object
'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so':
dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so,
6): Symbol not found: _hb_buffer_add_utf8
Referenced from:
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
Expected in: flat namespace
in
/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
That looks like a symbol in the harfbuzz lib. rgl doesn't reference it
directly, I think FreeType does. I don't know what you need to do to fix this,
but maybe that's enough of a hint.
I just ran into the same problem with a M1 MacBook and XQuartz 2.8.1 installed. My
MacBook has no developer tools installed, not even XCode – just R, "rgl" (and
various other packages) from CRAN, and XQuartz.
XQuartz doesn't include libharfbuzz, so I doubt that it's libfreetype depends
on it. Any chance that the CRAN machine that builds the aarch64 binary package
links against some other version of freetype that pulls in the dependency?
Best,
Stefan
___
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] rgl in R version 4.1.1 Patched (2021-08-13 r80752)
s On 18/08/2021 11:56 p.m., Richard M. Heiberger wrote: R version 4.1.1 Patched (2021-08-13 r80752) aarch64-apple-darwin20 library(rgl) Error in dyn.load(dynlib <- getDynlib(dir)) : unable to load shared object '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so': dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so, 6): Symbol not found: _hb_buffer_add_utf8 Referenced from: /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so Expected in: flat namespace in /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so That looks like a symbol in the harfbuzz lib. rgl doesn't reference it directly, I think FreeType does. I don't know what you need to do to fix this, but maybe that's enough of a hint. Duncan Murdoch ___ 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-sig-mac@r-project.org - "You can’t open the application “R” because this application is not supported on this Mac"
On 17/07/2021 3:39 a.m., Lindsay Foreman wrote: To whom it may concern, I am so sorry for being such a dunce. I have been trying and trying to get the R App to work on my MacBook Air running Big Sur V11.4, and am just not making any progress. It says that the package I have downloaded below should have all the elements I need including the R app GUI. I get this error message "You can’t open the application “R” because this application is not supported on this Mac"., are you able to help please? Is that an Intel or M1 MacBook? If it's an Intel one, you don't want the arm64 download, you want https://cran.r-project.org/bin/macosx/base/R-4.1.0.pkg It is listed on the web site as "High Sierra and higher", so it should work on Big Sur, but only if you have an Intel chip. Duncan Murdoch Your support is much appreciated. Lindsay Foreman R-4.1.0-arm64.pkg <https://cran.r-project.org/bin/macosx/big-sur-arm64/base/R-4.1.0-arm64.pkg> (notarized and signed) SHA1-hash: 7354c1b249cab9bafea6ae67c73563303a05fa17 (ca. 88MB) R 4.1.0 binary for macOS 11 (Big Sur) and higher, Apple silicon arm64 build, signed and notarized package. Contains R 4.1.0 framework, R.app GUI 1.76 for Apple silicon Macs (M1 and higher), Tcl/Tk 8.6.11 X11 libraries and Texinfo 6.7. Important: this version does NOT work on older Intel-based Macs. The above installer package will be misidentified by Apple Installer as Intel architecture although it contains no Intel code. This means you may be asked to install Rosetta 2 even though it is not required. This issue has been fixed in the packaging for future R versions, so if you don't want to install Rosetta 2 please use R-4.1-branch big-sur arm64 installer from mac.R-project.org <https://mac.r-project.org/>. Note: the use of X11 (including tcltk) requires XQuartz <http://xquartz.macosforge.org/>. Always re-install XQuartz when upgrading your macOS to a new major version. This release uses Xcode 12.4 and experimental GNU Fortran 11 arm64 fork. If you wish to compile R packages from sources, you may need to download GNU Fortran for arm64 from https://mac.R-project.org/libs-arm64 <https://mac.r-project.org/libs-arm64/>. Any external libraries and tools are expected to live in /opt/R/arm64 to not conflict with Intel-based software and this build will not use /usr/local to avoid such conflicts. On 13 Jul 2021, at 16:32, Dr. Alessio Pruneddu wrote: Hi Lindsay, Thanks a lot for your kind words. I am sorry to hear R is giving you troubles with Mac. I know for a fact that this might be the case with very new version of any mac. If you cannot access any standard Windows PC or laptop, try to download R studio, and in any case, check the compatibility requirements of the software (R and/or R studio) before you download it, so that you will not have any surprises. I hope it helps!! Alessio. Il giorno mar 13 lug 2021 alle ore 07:54 Lindsay Foreman <19038...@brookes.ac.uk <mailto:19038...@brookes.ac.uk>> ha scritto: Thank you again for your time and dedication Alessio, I cannot thank you enough. The thought of doing this in isolation, without you or the Q gang for support is a terrifying one! I have to confess how out of my comfort zone I feel, with the data, the statistics and the code. I have tried several time to install the R software from https://cran.r-project.org/ <https://cran.r-project.org/>, but no matter which one I select and download, when I try and open it I just an error message "You can’t open the application “R” because this application is not supported on this Mac.” I have read the FAQ’s but no joy and I cannot seem to find where I ask for help. I know you said this is out of your remit, but any pointers you are able to give to help resolve this would be much appreciated. As you say, we will get there, I am just in the midst of a painful part of the process where I feel completely out of my depth! Hopefully I can be a trailblazer for Leo and Elizabeth so that when they are at this stage I can offer some support and guidance. Onwards and upwards, Lindsay On 10 Jul 2021, at 12:02, Dr. Alessio Pruneddu mailto:i...@qsortouch.com>> wrote: Dear members of the Q squad, I cannot stress enough how much I am happy to have a chat with you. I just thought you would appreciate a few details after yesterday's video chat. Please see my comments below; Lindsay. Huge apologies for yesterday!. I still hope I was able to give you a flavour of what you can expect from the data analysis in R. In your case, I would recommend performing the data analysis using the code. Please find attached the code specifically related to your study. You will find out a slightly more sophisticated line, as you have to instruct the software about the free distribution in your sample. However, the sophistication is only apparent; the analysis is giving you the same
Re: [R-SIG-Mac] Minor bug in R.app GUI
Just updated to R 4.1.0 and R.app 1.76 (7976), and this has apparently been fixed. Sorry for the noise! Duncan Murdoch On 07/06/2021 10:07 a.m., Duncan Murdoch wrote: When running in R.app (sessionInfo below; this is not quite the latest, sorry) I see the following minor issue: When typing in the console, entering an opening paren causes the GUI to insert a matching closing paren. When it does this, the text in the display all drops down half a line. As soon as I type anything else, it pops back up. Duncan Murdoch Sessioninfo: R version 4.0.5 Patched (2021-04-30 r80294) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Catalina 10.15.7 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_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.5 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Minor bug in R.app GUI
When running in R.app (sessionInfo below; this is not quite the latest, sorry) I see the following minor issue: When typing in the console, entering an opening paren causes the GUI to insert a matching closing paren. When it does this, the text in the display all drops down half a line. As soon as I type anything else, it pops back up. Duncan Murdoch Sessioninfo: R version 4.0.5 Patched (2021-04-30 r80294) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Catalina 10.15.7 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_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.5 ___ 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] tcltk on M1 mac?
On 25/05/2021 10:44 a.m., Roy Mendelssohn - NOAA Federal via R-SIG-Mac wrote: I seem to remember a discussion not too long ago that the very latest version fo XQuartz did not install all the libraries needed by R, and to install the previous on instead (I hav XQuartz 2.7.11, the latest is 2.8.1). Is this still the case? You may be thinking of a different discussion, but when the 2.8.x betas started coming out, they included incompatible versions of the libs needed by R on Intel machines. That's no longer true. I don't have any experience with M1 machines, so this may not be relevant. Duncan Murdoch ___ 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 CMD …
On 20/02/2021 10:04 a.m., Peter West wrote:
I see a lot of references to R CMD on the command line. Can I assume that the R in
question is the R executable in Contents > MacOS within R.app?
No. The one that will run on the command line is the one returned by
"which R". On my system that's /usr/local/bin/R, which is a soft link
to /Library/Frameworks/R.framework/Resources/bin/R, a shell script.
The one you see is the GUI front end, and it doesn't understand the "R
CMD ..." type of command.
You can run the shell script version from within the GUI using
system("R CMD ...")
Duncan Murdoch
___
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: more rgl problems
If you are set up to install from source, could you try this?
devtools::install_github("dmurdoch/rgl@quartzbug", type="source")
If you only have some of the requirements (e.g. no devel versions of
packages) you might find you only get a partial build with no X11
display; that won't really test the workaround. In that case I'll try
to build a binary for your R version.
Duncan Murdoch
On 18/02/2021 6:07 p.m., Richard M. Heiberger wrote:
This is from my MacBook Air mid-2012 running Catalina 10.15.7
with Xquartz 2.7.11
I never placed the beta on this machine.
I also see from a fresh R session
plot(1:10, col=7)
library(rgl)
open3d()
is fine, whereas this:
library(rgl)
plot(1:10, col=7)
open3d()
segfaults
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
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.
setwd('/Users/rmh/Rwd/')
library(rgl)
plot(1:10, col=7)
open3d()
library(rgl)
plot(1:10, col=7)
open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'memory not mapped'
Traceback:
1: rgl.open(useNULL)
2: open3d()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Warning message:
In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window
Process R finished at Thu Feb 18 17:57:37 2021
________
From: Duncan Murdoch
Sent: Thursday, February 18, 2021 3:20 PM
To: Richard M. Heiberger; r-sig-mac@r-project.org
Subject: [External] Re: more rgl problems
I've made some progress on this, but I don't know how to fix it properly.
What's happening is that rgl is trying to open the new window that
open3d() asks for. It gets most of the way through that operation, then
calls glXMakeCurrent, which associates the OpenGL context with that
window. That call fails, but without generating any of the documented
errors: it just fails, triggering an X11 error handler with error code
0 (which typically means no error).
In the released versions of rgl, that failure leads to a segfault,
because I wasn't doing enough error checking. I've fixed the segfault,
but I'm still getting the error (in fact I'm getting it a lot more than
I used to; not sure if it's my debugging code causing that), and after I
get the error reported on screen, the new rgl window opens but doesn't
work to display anything.
I think it's probably something wrong in the rgl initialization code;
running this:
plot(1:10, col=7)
library(rgl)
open3d()
is fine, whereas this:
library(rgl)
plot(1:10, col=7)
open3d()
is always failing for me. Or possibly this is an Xquartz bug, maybe a
leftover from when I installed the beta.
I'd guess what's happening is that calling quartz() invalidates part of
the initialization done by rgl.init(), but I don't know what part yet.
I do want to call rgl.init() when loading rgl, because it might fail,
and then I can drop back to the off-screen drawing. It's too late to do
that later.
A workaround that works for me is for the .onload() function in rgl to
execute
dev.new()
dev.off()
before calling rgl.init(). It is less irritating than you might guess,
because the window doesn't have time to appear before being destroyed,
but I still don't like it. I'll try it out a bit, and then push it to
Github for others to test.
Duncan Murdoch
On 18/02/2021 6:28 a.m., Duncan Murdoch wrote:
I can reproduce this on a Catalina machine, working in R from the terminal.
This definitely looks similar to the problem that
rgl::setGraphicsDelay() was designed to solve, but even adding a 10
second delay doesn't help. I get a slightly different message than you:
> open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'memory not mapped'
but that might just be a different way of reporting the same underlying
issue.
It's clearly some kind of interaction between the Quartz device and rgl.
I'll see if I can track it down.
Duncan Murdoch
On 17/02/2021 7:36 p.m., Richard M. Heiberger wrote:
This is repeatable when the lines are all pasted in at once.
The example works if I allow some time delay between lines.
This is might be a relative of the one from a few months ago.
But this mes
Re: [R-SIG-Mac] more rgl problems
I've made some progress on this, but I don't know how to fix it properly.
What's happening is that rgl is trying to open the new window that
open3d() asks for. It gets most of the way through that operation, then
calls glXMakeCurrent, which associates the OpenGL context with that
window. That call fails, but without generating any of the documented
errors: it just fails, triggering an X11 error handler with error code
0 (which typically means no error).
In the released versions of rgl, that failure leads to a segfault,
because I wasn't doing enough error checking. I've fixed the segfault,
but I'm still getting the error (in fact I'm getting it a lot more than
I used to; not sure if it's my debugging code causing that), and after I
get the error reported on screen, the new rgl window opens but doesn't
work to display anything.
I think it's probably something wrong in the rgl initialization code;
running this:
plot(1:10, col=7)
library(rgl)
open3d()
is fine, whereas this:
library(rgl)
plot(1:10, col=7)
open3d()
is always failing for me. Or possibly this is an Xquartz bug, maybe a
leftover from when I installed the beta.
I'd guess what's happening is that calling quartz() invalidates part of
the initialization done by rgl.init(), but I don't know what part yet.
I do want to call rgl.init() when loading rgl, because it might fail,
and then I can drop back to the off-screen drawing. It's too late to do
that later.
A workaround that works for me is for the .onload() function in rgl to
execute
dev.new()
dev.off()
before calling rgl.init(). It is less irritating than you might guess,
because the window doesn't have time to appear before being destroyed,
but I still don't like it. I'll try it out a bit, and then push it to
Github for others to test.
Duncan Murdoch
On 18/02/2021 6:28 a.m., Duncan Murdoch wrote:
I can reproduce this on a Catalina machine, working in R from the terminal.
This definitely looks similar to the problem that
rgl::setGraphicsDelay() was designed to solve, but even adding a 10
second delay doesn't help. I get a slightly different message than you:
> open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'memory not mapped'
but that might just be a different way of reporting the same underlying
issue.
It's clearly some kind of interaction between the Quartz device and rgl.
I'll see if I can track it down.
Duncan Murdoch
On 17/02/2021 7:36 p.m., Richard M. Heiberger wrote:
This is repeatable when the lines are all pasted in at once.
The example works if I allow some time delay between lines.
This is might be a relative of the one from a few months ago.
But this message is about invalid permissions.
=
R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book"
Copyright (C) 2021 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.
setwd('/Users/rmh/Rwd/')
library(rgl)
x <- matrix(1:3, 1,3)
plot(1:10, col=7)
open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'invalid permissions'
Traceback:
1: rgl.open(useNULL)
2: open3d()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:
MacBookAir with the M1 chip using the regular intel version of R from CRAN.
Big Sur 11.2.1.
The plot(1:10), col=7) ## went by default to the quartz() device.
I repeated this about 5 times in ESS, and then once in Terminal.
Let me know if you need more information.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] more rgl problems
On 18/02/2021 7:15 a.m., Peter West wrote: I’ve enabled /opt/X11/libexec/launchd_startx for full disk access in Security & Privacy, but it hasn’t fixed the problem. One approach that was fruitful for me: After uninstalling and reinstalling XQuartz 2.7.11, I looked around for related files with older install dates, especially dates around Feb 2, when I had installed 2.8.0beta. The /Library/Launch* files showed up that way. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] more rgl problems
On 18/02/2021 7:15 a.m., Peter West wrote: I’ve enabled /opt/X11/libexec/launchd_startx for full disk access in Security & Privacy, but it hasn’t fixed the problem. In any case, it's a generic XQuartz problem, not related to R or rgl. Duncan ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] more rgl problems
On 18/02/2021 6:14 a.m., Peter West wrote:
Yes, I went through that process. I have no org.xquartz.* files in
/Library Launch* now.
If you run x11(), does it cause the same issue?
What about not starting R at all, and just running some X11 app like
xclock from the terminal?
Duncan Murdoch
On 18 Feb 2021, at 9:08 pm, Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
On 17/02/2021 10:13 p.m., Peter West wrote:
And speaking of M1 Silicon:
My XQuartz version is 2.7.11.
Started R 4.0.4.
Stopped R 4.0.4
Started RStudio
install.packages("rgl")
trying URL
'https://cran.rstudio.com/bin/macosx/contrib/4.0/rgl_0.105.13.tgz
<https://cran.rstudio.com/bin/macosx/contrib/4.0/rgl_0.105.13.tgz>'
Content type 'application/x-gzip' length 6446159 bytes (6.1 MB)
==
downloaded 6.1 MB
The downloaded binary packages are in
/var/folders/jf/mkyz74311796dl4mxx_7tcx8gn/T//RtmpflD1wL/downloaded_packages
library(rgl)
RStudio hangs indefinitely.
My RStudio is at 1.4.1103.
That looks a lot like the issue Rich had last week (which I think is
unrelated to the one posted today). Have you tried the solution I
posted for that? Here's a copy:
This worked for me to apparently fix my system:
Start with a newly rebooted system.
Uninstall XQuartz by dragging it to the trash.
Look in /Library/LaunchAgents/ for filenames related to xquartz. I
had two: a five year old one called
org.macosforge.xquartz.startx.plist, and one from around the time I
installed the XQuartz beta named org.xquartz.startx.plist. I deleted
the latter.
Look in /Library/LaunchDaemons/ for similar files. I deleted one
with the same name, i.e. org.xquartz.startx.plist, and left an older one.
Reboot the system again, and install XQuartz 2.7.11. Relogin, and
things seem fine.
I suspect it would be sufficient to just delete the
/Library/LaunchAgents/org.xquartz.startx.plist and
/Library/LaunchDaemons/org.xquartz.startx.plist files and reboot, but
I haven't tried that.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] more rgl problems
I can reproduce this on a Catalina machine, working in R from the terminal.
This definitely looks similar to the problem that
rgl::setGraphicsDelay() was designed to solve, but even adding a 10
second delay doesn't help. I get a slightly different message than you:
> open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'memory not mapped'
but that might just be a different way of reporting the same underlying
issue.
It's clearly some kind of interaction between the Quartz device and rgl.
I'll see if I can track it down.
Duncan Murdoch
On 17/02/2021 7:36 p.m., Richard M. Heiberger wrote:
This is repeatable when the lines are all pasted in at once.
The example works if I allow some time delay between lines.
This is might be a relative of the one from a few months ago.
But this message is about invalid permissions.
=
R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book"
Copyright (C) 2021 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.
setwd('/Users/rmh/Rwd/')
library(rgl)
x <- matrix(1:3, 1,3)
plot(1:10, col=7)
open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'invalid permissions'
Traceback:
1: rgl.open(useNULL)
2: open3d()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:
MacBookAir with the M1 chip using the regular intel version of R from CRAN.
Big Sur 11.2.1.
The plot(1:10), col=7) ## went by default to the quartz() device.
I repeated this about 5 times in ESS, and then once in Terminal.
Let me know if you need more information.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] more rgl problems
On 17/02/2021 10:13 p.m., Peter West wrote:
And speaking of M1 Silicon:
My XQuartz version is 2.7.11.
Started R 4.0.4.
Stopped R 4.0.4
Started RStudio
install.packages("rgl")
trying URL 'https://cran.rstudio.com/bin/macosx/contrib/4.0/rgl_0.105.13.tgz'
Content type 'application/x-gzip' length 6446159 bytes (6.1 MB)
==
downloaded 6.1 MB
The downloaded binary packages are in
/var/folders/jf/mkyz74311796dl4mxx_7tcx8gn/T//RtmpflD1wL/downloaded_packages
library(rgl)
RStudio hangs indefinitely.
My RStudio is at 1.4.1103.
That looks a lot like the issue Rich had last week (which I think is
unrelated to the one posted today). Have you tried the solution I
posted for that? Here's a copy:
This worked for me to apparently fix my system:
Start with a newly rebooted system.
Uninstall XQuartz by dragging it to the trash.
Look in /Library/LaunchAgents/ for filenames related to xquartz. I had
two: a five year old one called org.macosforge.xquartz.startx.plist,
and one from around the time I installed the XQuartz beta named
org.xquartz.startx.plist. I deleted the latter.
Look in /Library/LaunchDaemons/ for similar files. I deleted one with
the same name, i.e. org.xquartz.startx.plist, and left an older one.
Reboot the system again, and install XQuartz 2.7.11. Relogin, and
things seem fine.
I suspect it would be sufficient to just delete the
/Library/LaunchAgents/org.xquartz.startx.plist and
/Library/LaunchDaemons/org.xquartz.startx.plist files and reboot, but I
haven't tried that.
Duncan Murdoch
___
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: [External] Re: [External] Re: [External] Please test R 4.0.4 RC
On 14/02/2021 2:34 a.m., Peter West wrote: Hi Duncan, When you say ‘fix,’ did that include running the compiled rgl successfully against your R installation? I needed to recompile rgl after the change to 2.7.11, because I had built it to link to files that came with the XQuartz beta. The current CRAN binary (0.104.16) was already compiled for 2.7.11, so it's also fine now. If you install rgl from source after the XQuartz version change, you should be okay. Duncan Murdoch Peter — p...@ehealth.id.au <mailto:p...@ehealth.id.au> Moved with pity, he stretched out his hand and touched him and said to him, “I will; be clean.” On 14 Feb 2021, at 11:42 am, Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote: This worked for me to apparently fix my system: Start with a newly rebooted system. Uninstall XQuartz by dragging it to the trash. Look in /Library/LaunchAgents/ for filenames related to xquartz. I had two: a five year old one called org.macosforge.xquartz.startx.plist, and one from around the time I installed the XQuartz beta named org.xquartz.startx.plist. I deleted the latter. Look in /Library/LaunchDaemons/ for similar files. I deleted one with the same name, i.e. org.xquartz.startx.plist, and left an older one. Reboot the system again, and install XQuartz 2.7.11. Relogin, and things seem fine. Duncan Murdoch ___ 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: [External] Re: [External] Re: [External] Please test R 4.0.4 RC
This worked for me to apparently fix my system:
Start with a newly rebooted system.
Uninstall XQuartz by dragging it to the trash.
Look in /Library/LaunchAgents/ for filenames related to xquartz. I had
two: a five year old one called org.macosforge.xquartz.startx.plist,
and one from around the time I installed the XQuartz beta named
org.xquartz.startx.plist. I deleted the latter.
Look in /Library/LaunchDaemons/ for similar files. I deleted one with
the same name, i.e. org.xquartz.startx.plist, and left an older one.
Reboot the system again, and install XQuartz 2.7.11. Relogin, and
things seem fine.
Duncan Murdoch
On 13/02/2021 7:22 p.m., Richard M. Heiberger wrote:
It is looking for:
missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
This is the entirety of
/Library/Developer/CommandLineTools/usr/share/
/Library/Developer/CommandLineTools/usr/share/man:
total used in directory 40 available 1.3 TiB
drwxr-xr-x 3 root wheel 96 Feb 11 12:34 .
drwxr-xr-x 3 root wheel 96 Feb 11 12:34 ..
-rw-r--r-- 1 root wheel 20198 Jan 27 16:11 whatis
So I will again try
sudo xcode-select --install
It took a few minutes, and now from a new R session
X11()
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, :
unable to start device X11
In addition: Warning message:
In X11() : unable to open connection to X11 display ''
Sys.getenv("DISPLAY")
[1] "/private/tmp/com.apple.launchd.l0xAmiv83n/org.xquartz:0"
Sys.setenv(DISPLAY=":0.0")
Sys.getenv("DISPLAY")
[1] ":0.0"
X11()
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, :
unable to start device X11
In addition: Warning message:
In X11() : unable to open connection to X11 display ''
the xcrun is still not on the machine, and specifically not in
/Library/Developer/CommandLineTools/
From: Dr Eberhard W Lisse
Sent: Saturday, February 13, 2021 6:50 PM
To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re: [External] Re:
[External] Please test R 4.0.4 RC
Remove the directory where xcrun says it is supposed to live and re-install the
command line tools?
el
—
Sent from Dr Lisse’s iPhone
On 14 Feb 2021, 01:41 +0200, Richard M. Heiberger , wrote:
I reported on installing xcode tools in my email
Sat 2/13/2021 3:59 PM
It didn't help.
I did all this R_4.0.4 RC testing after updating to Big Sur 11.2.1.
From: Dr Eberhard W Lisse
Sent: Saturday, February 13, 2021 4:44 PM
To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: [External]
Please test R 4.0.4 RC
the Xcode Command line tools are missing. Install them and see what happens.
Did you recently upgrade MacOS?
el
—
Sent from Dr Lisse’s iPhone
On 13 Feb 2021, 23:21 +0200, Richard M. Heiberger , wrote:
That is next. Again a fresh session.
setwd('/Users/rmh/Rwd/')
Sys.setenv(DISPLAY=":0.0")
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, :
unable to start device X11
In addition: Warning messages:
1: In system2("otool", c("-L", shQuote(DSO)), stdout = TRUE) :
running command ''otool' -L
'/Library/Frameworks/R.framework/Resources/modules/R_X11.so'' had status 1
2: In X11() : unable to open connection to X11 display ''
and the R session is still alive.
This rasies for me a different question. Why should I want X11()?
When X11 was working it was very slow, and didn't allow paging back through
previous images.
In favor of X11, I think it uses the display space better. X11() has better
size and spacing for xlab, ylab, and main than quartz(). But that isn't a
strong enough
reason to use it while develkoping a graph. When I want it to look good,
I go directly to pdf() and get the spacing that I think looks better.
From: Duncan Murdoch
Sent: Saturday, February 13, 2021 4:05 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R
4.0.4 RC
Have you tried the change to DISPLAY, i.e.
Sys.setenv(DISPLAY=":0.0")
before running X11()?
Duncan Murdoch
On 13/02/2021 3:50 p.m., Richard M. Heiberger wrote:
I tried this. It made no difference. Both before and after running
sudo xcode-select —install
I ran (in both cases, in a brand new *R* sessio n)
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
My prior was that the xcode call was irrelevant is that X11() using XQuart
8.0.3beta
worked wit
Re: [R-SIG-Mac] [External] Re: [External] Please test R 4.0.4 RC
On 13/02/2021 5:43 p.m., Simon Urbanek wrote:
Duncan,
not really - this is why the XQuartz betas are such a disaster - they replace
libraries with incompatible versions (under same file name) - and even remove
some libraries, thus breaking anything that was compiled against either
version. If you downgrade, you have to re-compile anything you compiled against
the beta. That is probably one of the lesser evils since you can't expect
anything to be forwards-compatible.
In theory, you could detect the version using otool - that's what X11() is
doing to find whether XQuartz is present, but it only works for users that have
dev tools installed, so not a good idea in general.
Okay, thanks. I already have a no-X11 workaround; I'll just change the
error message if the dyn.load() fails.
Duncan
Cheers,
Simon
On Feb 14, 2021, at 11:32 AM, Duncan Murdoch wrote:
On 13/02/2021 4:54 p.m., Simon Urbanek wrote:
As mentioned earlier, the issue is likely that your X11-auto-launch is not working. You
can start X11 (=XQuartz) yourself and set DISPLAY=:0 as you would on any unix system or
start X11 with X11(":0")
[personally, I hate that auto-launch "feature" since it tries to start XQuartz
even if you don't want it].
Thanks. Here's another datum: I did my last build of rgl with the beta
XQuartz installed. I'm now back to 2.7.11 and I get this when I try to start
rgl:
library(rgl)
Error in dyn.load(dynlib) :
unable to load shared object
'/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so':
dlopen(/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so,
6): Library not loaded: /opt/X11/lib/libX11.6.dylib
Referenced from:
/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so
Reason: Incompatible library version: rgl.so requires version 11.0.0 or
later, but libX11.6.dylib provides version 10.0.0
Error: package or namespace load failed for ‘rgl’:
.onLoad failed in loadNamespace() for 'rgl', details:
call: NULL
error:Loading rgl's DLL failed.
This build of rgl depends on XQuartz, which you can download from
xquartz.org.
So it appears they updated the version of libX11.6.dylib, and rgl is asking for
the wrong one.
Is there some way for me to request a particular version during my build, or at
least detect that the wrong version is installed?
Duncan Murdoch
Cheers,
Simon
On Feb 14, 2021, at 9:50 AM, Richard M. Heiberger wrote:
I tried this. It made no difference. Both before and after running
sudo xcode-select —install
I ran (in both cases, in a brand new *R* sessio n)
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
My prior was that the xcode call was irrelevant is that X11() using XQuart
8.0.3beta
worked with intel R_4.0.3 on the Mac M1.
From: Dr Eberhard W Lisse
Sent: Saturday, February 13, 2021 3:33 AM
To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
that has nothing to do with Xquartz but means you need to install the Command
line tools
sudo xcode-select —install
—
Sent from Dr Lisse’s iPhone
On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote:
Using the intel R_4.0.4RC on the Mac M1.
Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the
8.0.3beta.
X11() now does not work at all.
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
C-c C-c C-c C-c
Force-Killing XQuartz from the Activity Monitor doesn't help.
I have to Force-kill the R process.
From: R-SIG-Mac on behalf of Simon Urbanek
Sent: Friday, February 12, 2021 6:50 PM
To: R-SIG-Mac
Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC
Dear macOS useRs,
please test the latest R 4.0.4 RC builds from
https://mac.r-project.org/
especially if you are running macOS Big Sur. The known issues introduced by Big
Sur have been fixed, but I cannot replicate nor test the spurious touchbar
warning.
Also a reminder to *not* install XQuartz betas even if XQuartz ask you to -
they are betas for a reason (=unstable) and break things.
Cheers,
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
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://
Re: [R-SIG-Mac] [External] Re: [External] Please test R 4.0.4 RC
On 13/02/2021 4:54 p.m., Simon Urbanek wrote:
As mentioned earlier, the issue is likely that your X11-auto-launch is not working. You
can start X11 (=XQuartz) yourself and set DISPLAY=:0 as you would on any unix system or
start X11 with X11(":0")
[personally, I hate that auto-launch "feature" since it tries to start XQuartz
even if you don't want it].
Thanks. Here's another datum: I did my last build of rgl with the beta
XQuartz installed. I'm now back to 2.7.11 and I get this when I try to
start rgl:
> library(rgl)
Error in dyn.load(dynlib) :
unable to load shared object
'/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so':
dlopen(/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so,
6): Library not loaded: /opt/X11/lib/libX11.6.dylib
Referenced from:
/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so
Reason: Incompatible library version: rgl.so requires version 11.0.0
or later, but libX11.6.dylib provides version 10.0.0
Error: package or namespace load failed for ‘rgl’:
.onLoad failed in loadNamespace() for 'rgl', details:
call: NULL
error:Loading rgl's DLL failed.
This build of rgl depends on XQuartz, which you can download from
xquartz.org.
So it appears they updated the version of libX11.6.dylib, and rgl is
asking for the wrong one.
Is there some way for me to request a particular version during my
build, or at least detect that the wrong version is installed?
Duncan Murdoch
Cheers,
Simon
On Feb 14, 2021, at 9:50 AM, Richard M. Heiberger wrote:
I tried this. It made no difference. Both before and after running
sudo xcode-select —install
I ran (in both cases, in a brand new *R* sessio n)
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
My prior was that the xcode call was irrelevant is that X11() using XQuart
8.0.3beta
worked with intel R_4.0.3 on the Mac M1.
From: Dr Eberhard W Lisse
Sent: Saturday, February 13, 2021 3:33 AM
To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
that has nothing to do with Xquartz but means you need to install the Command
line tools
sudo xcode-select —install
—
Sent from Dr Lisse’s iPhone
On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote:
Using the intel R_4.0.4RC on the Mac M1.
Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the
8.0.3beta.
X11() now does not work at all.
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
C-c C-c C-c C-c
Force-Killing XQuartz from the Activity Monitor doesn't help.
I have to Force-kill the R process.
From: R-SIG-Mac on behalf of Simon Urbanek
Sent: Friday, February 12, 2021 6:50 PM
To: R-SIG-Mac
Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC
Dear macOS useRs,
please test the latest R 4.0.4 RC builds from
https://mac.r-project.org/
especially if you are running macOS Big Sur. The known issues introduced by Big
Sur have been fixed, but I cannot replicate nor test the spurious touchbar
warning.
Also a reminder to *not* install XQuartz betas even if XQuartz ask you to -
they are betas for a reason (=unstable) and break things.
Cheers,
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
___
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: [External] Re: [External] Please test R 4.0.4 RC
Thanks for your detailed descriptions! I can now reproduce this, and I
have an ugly workaround. I should be able to get a better workaround soon.
To reproduce:
Install the beta. (I did this when it was pushed to me.) It worked
fine for me.
Install the previous version, 2.7.11. Reboot the system.
Now running x11() in R causes the spinning beach ball.
The workaround:
Start R. The DISPLAY environment variable will show the name something like
[1] "/private/tmp/com.apple.launchd.RuLLnvteCn/org.xquartz:0"
This is a socket, not a regular file.
Delete this, and set DISPLAY to ":0.0":
unlink(Sys.getenv("DISPLAY"))
Sys.setenv(DISPLAY=":0.0")
Now x11() is fine.
This is only a workaround. The unlink() is permanent, but setting the
environment variable only lasts for the length of the R session. You'll
need to enter Sys.setenv(DISPLAY=":0.0") again in future sessions, and I
would guess the socket will be recreated the next time you restart the
system (or maybe on login).
Duncan Murdoch
On 13/02/2021 4:21 p.m., Richard M. Heiberger wrote:
That is next. Again a fresh session.
setwd('/Users/rmh/Rwd/')
Sys.setenv(DISPLAY=":0.0")
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, :
unable to start device X11
In addition: Warning messages:
1: In system2("otool", c("-L", shQuote(DSO)), stdout = TRUE) :
running command ''otool' -L
'/Library/Frameworks/R.framework/Resources/modules/R_X11.so'' had status 1
2: In X11() : unable to open connection to X11 display ''
and the R session is still alive.
This rasies for me a different question. Why should I want X11()?
When X11 was working it was very slow, and didn't allow paging back through
previous images.
In favor of X11, I think it uses the display space better. X11() has better
size and spacing for xlab, ylab, and main than quartz(). But that isn't a
strong enough
reason to use it while develkoping a graph. When I want it to look good,
I go directly to pdf() and get the spacing that I think looks better.
From: Duncan Murdoch
Sent: Saturday, February 13, 2021 4:05 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R
4.0.4 RC
Have you tried the change to DISPLAY, i.e.
Sys.setenv(DISPLAY=":0.0")
before running X11()?
Duncan Murdoch
On 13/02/2021 3:50 p.m., Richard M. Heiberger wrote:
I tried this. It made no difference. Both before and after running
sudo xcode-select —install
I ran (in both cases, in a brand new *R* sessio n)
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
My prior was that the xcode call was irrelevant is that X11() using XQuart
8.0.3beta
worked with intel R_4.0.3 on the Mac M1.
From: Dr Eberhard W Lisse
Sent: Saturday, February 13, 2021 3:33 AM
To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
that has nothing to do with Xquartz but means you need to install the Command
line tools
sudo xcode-select —install
—
Sent from Dr Lisse’s iPhone
On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote:
Using the intel R_4.0.4RC on the Mac M1.
Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the
8.0.3beta.
X11() now does not work at all.
X11()
xcrun: error: invalid active developer path
(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun
C-c C-c C-c C-c
Force-Killing XQuartz from the Activity Monitor doesn't help.
I have to Force-kill the R process.
From: R-SIG-Mac on behalf of Simon Urbanek
Sent: Friday, February 12, 2021 6:50 PM
To: R-SIG-Mac
Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC
Dear macOS useRs,
please test the latest R 4.0.4 RC builds from
https://mac.r-project.org/
especially if you are running macOS Big Sur. The known issues introduced by Big
Sur have been fixed, but I cannot replicate nor test the spurious touchbar
warning.
Also a reminder to *not* install XQuartz betas even if XQuartz ask you to -
they are betas for a reason (=unstable) and break things.
Cheers,
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-SI
Re: [R-SIG-Mac] [External] Re: [External] Please test R 4.0.4 RC
Have you tried the change to DISPLAY, i.e. Sys.setenv(DISPLAY=":0.0") before running X11()? Duncan Murdoch On 13/02/2021 3:50 p.m., Richard M. Heiberger wrote: I tried this. It made no difference. Both before and after running sudo xcode-select —install I ran (in both cases, in a brand new *R* sessio n) X11() xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun My prior was that the xcode call was irrelevant is that X11() using XQuart 8.0.3beta worked with intel R_4.0.3 on the Mac M1. From: Dr Eberhard W Lisse Sent: Saturday, February 13, 2021 3:33 AM To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger Cc: e...@lisse.na Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC that has nothing to do with Xquartz but means you need to install the Command line tools sudo xcode-select —install — Sent from Dr Lisse’s iPhone On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote: Using the intel R_4.0.4RC on the Mac M1. Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the 8.0.3beta. X11() now does not work at all. X11() xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun C-c C-c C-c C-c Force-Killing XQuartz from the Activity Monitor doesn't help. I have to Force-kill the R process. From: R-SIG-Mac on behalf of Simon Urbanek Sent: Friday, February 12, 2021 6:50 PM To: R-SIG-Mac Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC Dear macOS useRs, please test the latest R 4.0.4 RC builds from https://mac.r-project.org/ especially if you are running macOS Big Sur. The known issues introduced by Big Sur have been fixed, but I cannot replicate nor test the spurious touchbar warning. Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - they are betas for a reason (=unstable) and break things. Cheers, 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 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to find the path for a file to be read with read.table() in a Mac
On 13/02/2021 10:42 a.m., Parkhurst, David F. wrote:
I’ve several times to figure this out with no luck. I’ve moved a tab delimited text file
(created from excel) to the desktop to simplify the path. If I click on the file and ask
Get Info, it lists “Where” as iCloud Drive > Desktop. If I copy that to the clipboard
and paste that into a read.table command in the R console, it comes up as
/Users/DFP/Desktop. But if I try
read.table("\\Users\\DFP\\Desktop\\moabsitechem"), I get No such file or
directory. How can I get that file into a data frame?
Is there some place in my Mac that I can put the file so I could enter just the
file name, and not the whole path?
Sorry, forget to answer your actual question:
You can use getwd() to find the working directory. If you put the file
there, you won't need to specify the path.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to find the path for a file to be read with read.table() in a Mac
On 13/02/2021 10:42 a.m., Parkhurst, David F. wrote:
I’ve several times to figure this out with no luck. I’ve moved a tab delimited text file
(created from excel) to the desktop to simplify the path. If I click on the file and ask
Get Info, it lists “Where” as iCloud Drive > Desktop. If I copy that to the clipboard
and paste that into a read.table command in the R console, it comes up as
/Users/DFP/Desktop. But if I try
read.table("\\Users\\DFP\\Desktop\\moabsitechem"), I get No such file or
directory. How can I get that file into a data frame?
Is there some place in my Mac that I can put the file so I could enter just the
file name, and not the whole path?
It doesn't make sense to use backslashes in the path: macOS will see
those as part of the name, not as path separators. Just use
read.table("/Users/DFP/Desktop/moabsitechm") if that's the filename.
Duncan Murdoch
___
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] Please test R 4.0.4 RC
On 12/02/2021 11:12 p.m., Richard M. Heiberger wrote: Using the intel R_4.0.4RC on the Mac M1. Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the 8.0.3beta. X11() now does not work at all. X11() xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun C-c C-c C-c C-c Force-Killing XQuartz from the Activity Monitor doesn't help. I have to Force-kill the R process. I've received reports about this related to rgl. Some unconfirmed reports suggest that setting Sys.setenv(DISPLAY=":0.0") fixes it. Others say that didn't work. I'm still running the beta, and haven't seen any issues. Maybe I'll try going back to 2.7.11 to see if I can trigger things. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] rgl and x11 failures on MacOS
I have heard a few reports recently that attempting to load rgl causes R
to freeze up. This is related to recent problems with MacOS updates or
XQuartz updates: people who now can't load rgl also can't run x11() in R.
I haven't experienced the issue myself, but have heard of two possible
solutions and have one or two workarounds:
Deleting everything from /opt/X11 (and maybe some other related files),
rebooting the Mac, and reinstalling XQuartz 2.7.11 worked in one case:
https://github.com/dmurdoch/rgl/issues/11#issuecomment-775595356 .
Explicitly setting the DISPLAY environment variable to :0.0 fixed a
problem that might be related:
https://github.com/XQuartz/XQuartz/issues/66#issue-803786687 .
Installing rgl from source using
install.packages("rgl", configure.args = "--disable-opengl", type =
"source")
is a workaround, but it loses the ability to display rgl output in an
X11 window from R. You need to use rglwidget() to do the display in a
browser, e.g. the one built in to RStudio. I don't think the browser
built in to R.app has WebGL support, so it probably won't work.
I'm currently working on changes to the build process so that in the
future the CRAN binary will be able to run the no-X11 version based on
setting options(rgl.useNULL = TRUE).
I'd appreciate hearing from anyone who can confirm that setting the
DISPLAY variable fixes the issue, or more specific detail about what
needs to be deleted so that the XQuartz install will work.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Missing R and RScript on /usr/bin/ on Big Sur
On 17/01/2021 5:15 p.m., Luis Puerto wrote: Hey! I just installed the binary from cran for R-4.0.3 and for some reason I'm missing the R and RScript commands on terminal. I'm on Big Sur 11.1 and when I check if there are symbol links on /usr/bin/ related to R I find none. I'm not the only one https://stackoverflow.com/a/64920581/6888648 <https://stackoverflow.com/a/64920581/6888648> Does anyone experience this behavior too? If you have updated perhaps you still have those from previous releases, but in case this was a clean install since I decided to change from homebrew to the binary form cran. I'm not on Big Sur, but I see this: $ which R /usr/local/bin/R So maybe you're looking in the wrong place? Duncan Murdoch ___ 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 for macOS Big Sur
On 14/01/2021 1:06 p.m., Gregory Coats via R-SIG-Mac wrote: macOS Big Sur has shipped with all Apple Mac computers since Thu 2020-11-12. The web site https://mac.r-project.org/ shows that as of Thu 2021-01-14 00:56 1. R compiled for Big Sur for Macs with the Intel CISC x86_64 chip is not available. 2. R compiled for Big Sur for Macs with the Apple M1 RISC chip (=ARM64) FAILED to compile. So, R is not available to any of us who have bought Apple Mac computers in the past 2 months. A note posted to R-SIG-Mac on Thu 2021-01-14 by Brian Ripley says "The goal remains to release a native binary distribution with R 4.1.0 about April 2021." A similar note posted on Fri 2021-01-08 said "We hope this will be solved by the end of January 2021." Waiting until April 2021 to run an application on a computer purchased in Nov 2020 seems like a very long wait. I suggest a goal of releasing R compiled for Big Sur for Macs with the Intel CISC x86_64 chip before the end of January 2021. Greg Coats You are being quite rude, repeating the same incorrect information. Prof Ripley's notes were not about your system, they were about the M1 Macs. For your system, https://cran.r-project.org/bin/macosx/ contains a build of R 4.0.3 that is "for macOS 10.13 (High Sierra) and higher". That's what Jean Thiolouse was referring to. It's possible that the package on CRAN doesn't work on your system, but it doesn't sound as if you've tried it. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] CRAN package checks on M1 Mac
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 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
Re: [R-SIG-Mac] Recommended version of Xcode?
Thanks for pointing that out. Which version are you using?
Duncan Murdoch
On 03/11/2020 2:08 a.m., Adrian Dușa wrote:
For some reason, I was recently unable to update my Xcode and digged a
little bit.
One solution was to completely uninstall it and do a fresh install, a
process in which I found that:
- Xcode take more than 10GB of my harddrive
- not sure about building R, but I was able to build packages _without_
Xcode altogether, since it is possible to download and install only the
Command Line Tools.
Since the CLT takes about 500MB, I thought this might be worth sharing.
Adrian
On Tue, Nov 3, 2020 at 3:08 AM Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
The https://mac.r-project.org/ page says that R is now built with Xcode
11.4. Is this still correct? There are several newer versions
available (11.5, 11.6, 11.7, 12, 12.0.1, 12.1).
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org>
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Recommended version of Xcode?
The https://mac.r-project.org/ page says that R is now built with Xcode 11.4. Is this still correct? There are several newer versions available (11.5, 11.6, 11.7, 12, 12.0.1, 12.1). Duncan Murdoch ___ 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.2 GUI does not terminate with Cmd+Q
On 29/10/2020 6:30 a.m., Petar Milin wrote: I am experiencing some unexpected behaviour of R for R 4.0.2 GUI 1.72 Catalina build (7847): It does not quit properly when I am using Cmd+Q but instead halts and starts overheating my machine. I need to kill the process in Activity Monitor. However, if I type the command q() it seems it's doing the expected thing. Any advice? I'm not seeing that with the current release, 4.0.3 R.app GUI 1.73 (7892) x86_64-apple-darwin17.0. So I'd suggest updating. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] plot window not showing most recent plot?
Which front end are you using? The cmd-] and cmd-[ don't do anything in the ones I'm using. Duncan Murdoch On 05/09/2020 8:23 a.m., Timothy Bates wrote: In R version: R version 4.0.2 (2020-06-22), I’m seeing the plot window not advance when a new ggplot is drawn. calls to plot() advance the quartz window to the newest “frame”, but calls to ggplot2::qplot() show the graph only the first time the function is called in the quartz window’s history. For subsequent qplots, the pane does not advance to show the new plot, instead staying on which ever “frame’ in the plot history it was at. repro plot(wt ~ mpg, data=mtcars) # displays ggplot2::qplot(mpg, wt, data=mtcars) # doesn't display close quartz window qplot(mpg, wt, data=mtcars) # displays plot(wt ~ mpg, data=mtcars) # displays qplot(mpg, wt, data=mtcars) # doesn't display try cmd-] to advance forward into current history… nothing happens (newest plot is not in the (forward) history try cmd-[ to go back, then cmd-] cmd-] to go forward into current history… newest plot displays as it should have the first time ___ 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] bzip2 configure error
I seem to have got past this error by reinstalling Xcode. I'm not sure what went wrong with the old install; I'm pretty sure I did an R-devel build since installing Catalina. Duncan Murdoch On 28/08/2020 10:41 a.m., Duncan Murdoch wrote: I'm trying to build R-devel in Catalina for the first time in a few weeks, and configure is dying with this error: checking whether bzip2 support suffices... configure: error: bzip2 library and headers are required I tried a Homebrew install of bzip2, and it didn't help. When I look in config.log, I see this: configure:45424: checking if bzip2 version >= 1.0.6 configure:45452: gcc -o conftest -g -O2 -I/usr/local/opt/libffi/include -L/usr/local/opt/libffi/lib conftest.c -lbz2 -lz -licucore -ldl -lm -liconv >&5 conftest.c:250:11: warning: initializing 'char *' with an expression of type 'const char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] char *ver = BZ2_bzlibVersion(); ^ ~~ conftest.c:251:5: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration] exit(strcmp(ver, "1.0.6") < 0); ^ conftest.c:251:5: note: include the header or explicitly provide a declaration for 'exit' conftest.c:251:10: error: implicitly declaring library function 'strcmp' with type 'int (const char *, const char *)' [-Werror,-Wimplicit-function-declaration] exit(strcmp(ver, "1.0.6") < 0); ^ conftest.c:251:10: note: include the header or explicitly provide a declaration for 'strcmp' 1 warning and 2 errors generated. Suggestions for fixing this? Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] bzip2 configure error
I'm trying to build R-devel in Catalina for the first time in a few weeks, and configure is dying with this error: checking whether bzip2 support suffices... configure: error: bzip2 library and headers are required I tried a Homebrew install of bzip2, and it didn't help. When I look in config.log, I see this: configure:45424: checking if bzip2 version >= 1.0.6 configure:45452: gcc -o conftest -g -O2 -I/usr/local/opt/libffi/include -L/usr/local/opt/libffi/lib conftest.c -lbz2 -lz -licucore -ldl -lm -liconv >&5 conftest.c:250:11: warning: initializing 'char *' with an expression of type 'const char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] char *ver = BZ2_bzlibVersion(); ^ ~~ conftest.c:251:5: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration] exit(strcmp(ver, "1.0.6") < 0); ^ conftest.c:251:5: note: include the header or explicitly provide a declaration for 'exit' conftest.c:251:10: error: implicitly declaring library function 'strcmp' with type 'int (const char *, const char *)' [-Werror,-Wimplicit-function-declaration] exit(strcmp(ver, "1.0.6") < 0); ^ conftest.c:251:10: note: include the header or explicitly provide a declaration for 'strcmp' 1 warning and 2 errors generated. Suggestions for fixing this? Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Running R with lldb
Thanks, attaching to the process seemed simplest. For others: the manual talks about doing it with gdb, but the same syntax works with lldb. Here's an example: Start R, then open a new terminal window: murdoch@djmair3 ~ $ ps PID TTY TIME CMD 11293 ttys0000:00.08 -bash 13829 ttys0000:00.31 /Users/murdoch/R/R-devel/bin/exec/R 13804 ttys0010:00.03 -bash murdoch@djmair3 ~ $ lldb -p 13829 (lldb) process attach --pid 13829 Process 13829 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x7fff70eb10fe libsystem_kernel.dylib`__select + 10 libsystem_kernel.dylib`__select: -> 0x7fff70eb10fe <+10>: jae0x7fff70eb1108; <+20> 0x7fff70eb1100 <+12>: movq %rax, %rdi 0x7fff70eb1103 <+15>: jmp0x7fff70eaa22d; cerror 0x7fff70eb1108 <+20>: retq Target 0: (R) stopped. Duncan Murdoch On 05/08/2020 10:16 a.m., Prof Brian Ripley wrote: One of the suggestions in https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Debugging-on-macOS should help. Both worked for my build of R-devel yesterday .... On 05/08/2020 14:25, Duncan Murdoch wrote: I'm now successfully building R-devel in /Users/murdoch/R/R-devel. If I run it from that directory using bin/R -d lldb it starts, but "run" gives this error: Process 11165 launched: '/Users/murdoch/R/R-devel/bin/exec/R' (x86_64) dyld: Library not loaded: libRblas.dylib Referenced from: /Users/murdoch/R/R-devel/bin/exec/R Reason: image not found Process 11165 stopped * thread #1, stop reason = signal SIGABRT frame #0: 0x0001004c7ede dyld`__abort_with_payload + 10 dyld`__abort_with_payload: -> 0x1004c7ede <+10>: jae 0x1004c7ee8 ; <+20> 0x1004c7ee0 <+12>: movq %rax, %rdi 0x1004c7ee3 <+15>: jmp 0x1004c6408 ; cerror_nocancel 0x1004c7ee8 <+20>: retq Target 0: (R) stopped. I can start it from the /Users/murdoch/R/R-devel/lib directory where libRblas.dylib lives. Setting DYLD_LIBRARY_PATH or LD_LIBRARY_PATH to point there doesn't help (either on the bin/R command line or exported). Is there some other way to run it from whatever directory I happen to be in? Duncan Murdoch On 02/05/2020 11:26 p.m., Simon Urbanek wrote: Vince, Apple no longer allows debugging of distributed apps - see R for Mac FAQ 10.17: http://mac.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R Another (not recommended) work-around is to disable SIP. Cheers, Simon On 3/05/2020, at 10:42 AM, Vincent Carey wrote: I'd like to make use of material in https://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/ But with R 4.0 I get %vjcair> R -d lldb (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R" Current executable set to '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64). (lldb) run error: process exited with status -1 (Error 1) (lldb) quit %vjcair> which lldb /usr/bin/lldb %vjcair> lldb --version lldb-1100.0.30.12 Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15) with gdb, there is a little more info -- and a peculiar warning that mentions /Volumes/Builds/Simon/R4/h ... %vjcair> R -d gdb GNU gdb (GDB) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin16.7.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /Library/Frameworks/R.framework/Resources/bin/exec/R... warning: `/Volumes/Builds/Simon/R4/high-sierra-x86_64/R-4.0-branch/src/main/Rmain.o': can't open to read symbols: No such file or directory. (no debugging symbols found)...done. (gdb) run Starting program: /Library/Frameworks/R.framework/Versions/4.0/Resources/bin/exec/R Unable to find Mach task port for process-id 59032: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8)) sessionInfo() R version 4.0.0 Patched (2020-04-27 r78309) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Mojave 10.14.6 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.
[R-SIG-Mac] Running R with lldb
I'm now successfully building R-devel in /Users/murdoch/R/R-devel. If I
run it from that directory using
bin/R -d lldb
it starts, but "run" gives this error:
Process 11165 launched: '/Users/murdoch/R/R-devel/bin/exec/R' (x86_64)
dyld: Library not loaded: libRblas.dylib
Referenced from: /Users/murdoch/R/R-devel/bin/exec/R
Reason: image not found
Process 11165 stopped
* thread #1, stop reason = signal SIGABRT
frame #0: 0x0001004c7ede dyld`__abort_with_payload + 10
dyld`__abort_with_payload:
-> 0x1004c7ede <+10>: jae0x1004c7ee8 ; <+20>
0x1004c7ee0 <+12>: movq %rax, %rdi
0x1004c7ee3 <+15>: jmp0x1004c6408 ; cerror_nocancel
0x1004c7ee8 <+20>: retq
Target 0: (R) stopped.
I can start it from the /Users/murdoch/R/R-devel/lib directory where
libRblas.dylib lives. Setting DYLD_LIBRARY_PATH or LD_LIBRARY_PATH to
point there doesn't help (either on the bin/R command line or exported).
Is there some other way to run it from whatever directory I happen to
be in?
Duncan Murdoch
On 02/05/2020 11:26 p.m., Simon Urbanek wrote:
Vince,
Apple no longer allows debugging of distributed apps - see R for Mac FAQ 10.17:
http://mac.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R
Another (not recommended) work-around is to disable SIP.
Cheers,
Simon
On 3/05/2020, at 10:42 AM, Vincent Carey wrote:
I'd like to make use of material in
https://kevinushey.github.io/blog/2015/04/13/debugging-with-lldb/
But with R 4.0 I get
%vjcair> R -d lldb
(lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
Current executable set to
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
(lldb) run
error: process exited with status -1 (Error 1)
(lldb) quit
%vjcair> which lldb
/usr/bin/lldb
%vjcair> lldb --version
lldb-1100.0.30.12
Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15)
with gdb, there is a little more info -- and a peculiar warning that
mentions /Volumes/Builds/Simon/R4/h ...
%vjcair> R -d gdb
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin16.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /Library/Frameworks/R.framework/Resources/bin/exec/R...
warning:
`/Volumes/Builds/Simon/R4/high-sierra-x86_64/R-4.0-branch/src/main/Rmain.o':
can't open to read symbols: No such file or directory.
(no debugging symbols found)...done.
(gdb) run
Starting program:
/Library/Frameworks/R.framework/Versions/4.0/Resources/bin/exec/R
Unable to find Mach task port for process-id 59032: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
sessionInfo()
R version 4.0.0 Patched (2020-04-27 r78309)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Mojave 10.14.6
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
--
The information in this e-mail is intended only for t...{{dropped:8}}
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Workaround for crash due to rgl and base graphics conflict
On 04/08/2020 8:02 p.m., Simon Urbanek wrote:
Duncan,
how is quartz() related to rgl? I thought that now you only supported X11 which
wouldn't involve quartz. In general, Cocoa windows are asynchronous, i.e. when
the quartz device is created the window may not exist yet, but I'm not sure why
that would affect rgl (quartz device draws to off-screen buffer so it doesn't
mind if the windows doesn't exist yet). For the X11 device there could be
significant delay with X11 (not related to quartz) if you don't have X11
running yet as users have typically DISPLAY set to a socket which will first
start XQuartz if it's not up yet.
The only connections I know between rgl and quartz() are this bug, and
the fact that XQuartz uses Quartz.
When I see the crash, what happens is that the library(rgl) starts
XQuartz. Running quartz() at this point opens a window with no crash
(but it's a little slower than I'd expect). Running plot(1:10) after
that causes no problems.
However, if I skip calling quartz() explicitly as in the demo code
below, the plot(1:10) call will call it and plot immediately, and that
usually causes the crash.
Duncan
Cheers,
Simon
On 5/08/2020, at 8:51 AM, Duncan Murdoch wrote:
I seem to have a workaround for the rgl-related crash. If I insert a one
second delay after the first quartz() device is opened but before anything is
plotted, then I don't see the crash. This script does that if the RGL_SLOW_DEV
environment variable is non-empty:
if (nchar(Sys.getenv("RGL_SLOW_DEV")))
options(device = local({
olddev <- getOption("device")
function(...) {
olddev(...)
Sys.sleep(1)
options(device = olddev)
}
}))
library(rgl)
plot(1:10)
The last two lines are the code to trigger a crash. I'm seeing pretty regular
crashes if I source this without RGL_SLOW_DEV being set, but setting it seems
to make things work. I tried reducing the delay to 0.1 seconds and it didn't
work.
I'd hypothesize that what's happening is that some part of the initialization
of the quartz() window is asynchronous with the main R thread, and in Catalina
something about rgl makes it so slow that the window isn't ready when R starts
plotting there. But I don't know the quartz() device code, so this might not
be right at all.
Duncan Murdoch
___
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] Workaround for crash due to rgl and base graphics conflict
I seem to have a workaround for the rgl-related crash. If I insert a
one second delay after the first quartz() device is opened but before
anything is plotted, then I don't see the crash. This script does that
if the RGL_SLOW_DEV environment variable is non-empty:
if (nchar(Sys.getenv("RGL_SLOW_DEV")))
options(device = local({
olddev <- getOption("device")
function(...) {
olddev(...)
Sys.sleep(1)
options(device = olddev)
}
}))
library(rgl)
plot(1:10)
The last two lines are the code to trigger a crash. I'm seeing pretty
regular crashes if I source this without RGL_SLOW_DEV being set, but
setting it seems to make things work. I tried reducing the delay to 0.1
seconds and it didn't work.
I'd hypothesize that what's happening is that some part of the
initialization of the quartz() window is asynchronous with the main R
thread, and in Catalina something about rgl makes it so slow that the
window isn't ready when R starts plotting there. But I don't know the
quartz() device code, so this might not be right at all.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] "cannot run mixed C/Fortran code"
I found the problem. /usr/local/lib had old copies of libgfortran* and libquadmath* from 2015, and removing these allowed things to proceed. The current copies are in /usr/local/gfortran/lib. That directory contains a lot of old junk; I'll probably find more needs to go too. Duncan Murdoch On 04/08/2020 9:58 a.m., Duncan Murdoch wrote: After updating to Catalina, I've installed the Xcode command line tools version 11.4.1, and gfortran 8.2. When trying to build R, configure dies: checking whether gfortran appends underscores to external names... yes checking whether gfortran appends extra underscores to external names... no checking whether mixed C/Fortran code can be run... configure: WARNING: cannot run mixed C/Fortran code configure: error: Maybe check LDFLAGS for paths to Fortran libraries? I don't have LDFLAGS set. I'm not certain I'm running the right compilers (I might have old ones that have precedence on the path). Are these the versions I should be seeing? $ clang --version Apple clang version 11.0.3 (clang-1103.0.32.59) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin $ gfortran --version GNU Fortran (GCC) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If those are the right versions, any other suggestions on how to fix the configure problem? Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] "cannot run mixed C/Fortran code"
After updating to Catalina, I've installed the Xcode command line tools version 11.4.1, and gfortran 8.2. When trying to build R, configure dies: checking whether gfortran appends underscores to external names... yes checking whether gfortran appends extra underscores to external names... no checking whether mixed C/Fortran code can be run... configure: WARNING: cannot run mixed C/Fortran code configure: error: Maybe check LDFLAGS for paths to Fortran libraries? I don't have LDFLAGS set. I'm not certain I'm running the right compilers (I might have old ones that have precedence on the path). Are these the versions I should be seeing? $ clang --version Apple clang version 11.0.3 (clang-1103.0.32.59) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin $ gfortran --version GNU Fortran (GCC) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If those are the right versions, any other suggestions on how to fix the configure problem? Duncan Murdoch ___ 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
I dropped the native Apple GL support a few years ago. Currently the only options are X11, WGL (for Windows), and null, which means you need to produce WebGL to view in a browser. I suppose I could resurrect the native display. OpenGL has been deprecated on MacOS since Mojave, but maybe it will be supported for a few more years. Right now I don't even have svn running (the Catalina update broke it), but eventually things should get back to normal here. Duncan Murdoch On 03/08/2020 4:34 p.m., Simon Urbanek wrote: Duncan, I have seen crashes in rgl with X11 before, in fact I have an e-mail in my draft folder to you with that crash and backtrace (see below). However, I also recall that I have fixed the issue with some trivial step (which I can't remember - I think I may have messed with /opt and/or restart X11 or something like that) and I felt silly not doing it so I didn't end up sending the report. The crash comes likely from https://github.com/XQuartz/AppleSGLX/blob/master/apple_visual.c#L142 which means that CGLChoosePixelFormat() fails, but no idea why since it is in principle independent of X11 - there should be also an error on stderr. The libGL code is more than 10 years old, so I wouldn't expect any changes anytime soon. Cheers, Simon Begin forwarded message: From: Simon Urbanek Subject: rgl Date: April 1, 2020 at 13:05:20 GMT+13 To: Duncan Murdoch Duncan, I'm preparing packages for R 4.0.0 release and rgl is segfaulting on load when DISPLAY is set (i.e. when X11 is available). Do you have any idea? (rgl 0.100.50) I remember something about a way to use native GL instead of X11, but I can't recall how to activate that. If DISPLAY is not set, it uses a NULL device which doesn't segfault (obviously). Thanks, Simon library(rgl) Process 54673 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x7fff5a145b66 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fff5a145b66 <+10>: jae0x7fff5a145b70; <+20> 0x7fff5a145b68 <+12>: movq %rax, %rdi 0x7fff5a145b6b <+15>: jmp0x7fff5a13cae5; cerror_nocancel 0x7fff5a145b70 <+20>: retq Target 0: (R) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x7fff5a145b66 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x7fff5a310080 libsystem_pthread.dylib`pthread_kill + 333 frame #2: 0x7fff5a0a11ae libsystem_c.dylib`abort + 127 frame #3: 0x0001086e6aed libGL.1.dylib`apple_visual_create_pfobj + 1010 frame #4: 0x0001086e457b libGL.1.dylib`apple_glx_create_context + 204 frame #5: 0x0001086e15b9 libGL.1.dylib`applegl_create_context + 182 frame #6: 0x0001086c1377 libGL.1.dylib`CreateContext + 126 frame #7: 0x0001086c1288 libGL.1.dylib`glXCreateContext + 199 frame #8: 0x0001084e5b23 rgl.so`rgl::X11WindowImpl::X11WindowImpl(rgl::Window*, rgl::X11GUIFactory*, unsigned long, XVisualInfo*) [inlined] rgl::X11WindowImpl::initGL(this=0x00010584fc00) at x11gui.cpp:335 [opt] frame #9: 0x0001084e5b10 rgl.so`rgl::X11WindowImpl::X11WindowImpl(rgl::Window*, rgl::X11GUIFactory*, unsigned long, XVisualInfo*) [inlined] rgl::X11WindowImpl::on_init(this=0x00010584fc00) at x11gui.cpp:411 [opt] frame #10: 0x0001084e5b10 rgl.so`rgl::X11WindowImpl::X11WindowImpl(this=0x00010584fc00, w=, f=0x00010262c9b0, in_xwindow=10485763, invisualinfo=0x000100a6f560) at x11gui.cpp:78 [opt] frame #11: 0x0001084e7610 rgl.so`rgl::X11GUIFactory::createWindowImpl(rgl::Window*) [inlined] rgl::X11WindowImpl::X11WindowImpl(this=, w=, f=, in_xwindow=, invisualinfo=) at x11gui.cpp:77 [opt] frame #12: 0x0001084e75fa rgl.so`rgl::X11GUIFactory::createWindowImpl(this=, window=0x000100b33ba0) at x11gui.cpp:694 [opt] frame #13: 0x0001084d9401 rgl.so`rgl::Window::Window(this=0x000100b33ba0, in_child=, factory=) at gui.cpp:147 [opt] frame #14: 0x0001084c1dea rgl.so`rgl::Device::Device(this=0x000100b2d4c0, id=, useNULL=) at device.cpp:16 [opt] frame #15: 0x0001084c28c5 rgl.so`rgl::DeviceManager::createTestWindow(this=0x000100b34880) at devicemanager.cpp:167 [opt] frame #16: 0x0001084d9a9a rgl.so`::rgl_init(initValue=, useNULL=, in_namespace=, debug=) at init.cpp:94 [opt] frame #17: 0x00010012b4cb libR.dylib`R_doDotCall(ofun=, nargs=, cargs=0x7ffeefbef4e0, call=0x000101cc1618) at dotcode.c:607 [opt] frame #18: 0x00010017738a libR.dylib`bcEval(body=0x000101cc1650, rho=0x000101cc1228, useCache=) at eval.c:7646 [opt] frame #19: 0x00010015d141 libR.dylib`Rf_eval(e=, rho=) at eval.c:723 [opt] frame #20: 0x00010017d601 libR.dylib`R_execClosure(call=0x0001019f12b0, newrho=, sysparent=, rho=0x0001019df6b8,
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
It didn't stay fixed. I get crashes about half the time now. I'll see if I can figure out what's going wrong. My guess would be that rather than an rgl bug this is an Xquartz bug, but maybe I can find a way to prevent it. Duncan Murdoch On 03/08/2020 12:54 p.m., Duncan Murdoch wrote: With great trepidation, I installed Catalina. I saw the same crash as reported. Then I reinstalled Xquartz, shut down the Xquartz that was still running (should have done that in the other order!), and tried again: no crash. Hope it stays fixed! Duncan Murdoch On 03/08/2020 9:25 a.m., Duncan Murdoch wrote: Thanks. Looks like I should update. I'm looking forward to the crashes... Duncan Murdoch On 03/08/2020 9:21 a.m., Marc Schwartz 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-1
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
With great trepidation, I installed Catalina. I saw the same crash as reported. Then I reinstalled Xquartz, shut down the Xquartz that was still running (should have done that in the other order!), and tried again: no crash. Hope it stays fixed! Duncan Murdoch On 03/08/2020 9:25 a.m., Duncan Murdoch wrote: Thanks. Looks like I should update. I'm looking forward to the crashes... Duncan Murdoch On 03/08/2020 9:21 a.m., Marc Schwartz 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 Core
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
Thanks. Looks like I should update. I'm looking forward to the crashes... Duncan Murdoch On 03/08/2020 9:21 a.m., Marc Schwartz 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 0x7f
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
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 0x7fff398de456 -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 166 4 AppKit 0x7fff34503083 +[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] + 361 5 AppKit 0x7fff34e4bda8 _NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243 6 AppKit 0x7fff34502c85 -[NSApplication(ScreenHandling) _reactToDockChanged] + 144 7 AppKit 0x7fff345024dc _NSCGSDockMessageReceive + 268 8 HIToolbox 0x7fff35d34a3c _ZL12DockCallbackjjPvS_ + 1987 9
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
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 0x7fff398de456 -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 166 4 AppKit 0x7fff34503083 +[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] + 361 5 AppKit 0x7fff34e4bda8 _NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243 6 AppKit 0x7fff34502c85 -[NSApplication(ScreenHandling) _reactToDockChanged] + 144 7 AppKit 0x7fff345024dc _NSCGSDockMessageReceive + 268 8 HIToolbox 0x7fff35d34a3c _ZL12DockCallbackjjPvS_ + 1987 9 HIServices 0x7fff3539c8ec dockClientNotificationProc + 217 10 SkyLight0x7fff6626f174 _ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ + 1002 11 SkyLight0x7fff6626de71 CGSSnarfAndDispatchDatagrams + 1671 12 SkyLight0x7fff6649d5a5 SLSGetNextEventRecordInternal + 83 13 SkyLight0x7fff6633bfbe SLEventCreateNextEvent + 136 14 libXplugin.1.dylib 0x00010686df0c ___xp_init_service_cg_event_port_bl
Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict
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 0x7fff398de456 -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 166 4 AppKit 0x7fff34503083 +[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] + 361 5 AppKit 0x7fff34e4bda8 _NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243 6 AppKit 0x7fff34502c85 -[NSApplication(ScreenHandling) _reactToDockChanged] + 144 7 AppKit 0x7fff345024dc _NSCGSDockMessageReceive + 268 8 HIToolbox 0x7fff35d34a3c _ZL12DockCallbackjjPvS_ + 1987 9 HIServices 0x7fff3539c8ec dockClientNotificationProc + 217 10 SkyLight0x7fff6626f174 _ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ + 1002 11 SkyLight0x7fff6626de71 CGSSnarfAndDispatchDatagrams + 1671 12 SkyLight0x7fff6649d5a5 SLSGetNextEventRecordInternal + 83 13 SkyLight0x7fff6633bfbe SLEventCreateNextEvent + 136 14 libXplugin.1.dylib 0x00010686df0c ___xp_init_service_cg_event_port_block_invoke + 104 15 libdispatch.dylib 0x7fff7108d658 _dispatch_client_callout + 8 16 libdispatch.dylib 0x7fff7108f818 _dispatch_continuation_pop + 414 17 libdispatch.dylib 0x7fff7109f4be _dispatch_source_invoke + 2084 18 libdispatch.dylib 0x7fff71092af6 _dispatch_lane_serial_drain + 263 19 libdispatch.dylib 0x7fff710935d6 _dispatch_lane_invoke + 363 20 libdispatch.dylib 0x7fff7109cc09 _dispatch_workloop_worker_thread + 596 21 libsystem_pthread.dylib 0x7fff712eba3d _pthread_wqthread + 290 22 libsystem_pthread.dylib 0x7fff712eab77 start_wqthread + 15 ) libc++abi.dylib: terminating with uncaught exception of type NSException zsh: abort R rmh@rmhs-Air ~ % On Fri, May 29, 2020 at 12:16 PM Duncan Murdoch wrote: I'm not seeing that with R-patched r78557, run from the console. I'm not sure I have the same MacOS version as you (R prints the same thing, Apple says High Sierra 10.13.6). I tried with the CRAN binary of rgl 0.100.54. I'd guess the version of XQuartz may be important: I'm not seeing rgl in the call stack, but libXplugin is there. Mine is "XQuartz 2.7.11 (xorg-server 1.18.4)". Duncan Murdoch On 29/05/2020 1
Re: [R-SIG-Mac] crash due to rgl and base graphics conflict
I'm not seeing that with R-patched r78557, run from the console. I'm
not sure I have the same MacOS version as you (R prints the same thing,
Apple says High Sierra 10.13.6). I tried with the CRAN binary of rgl
0.100.54. I'd guess the version of XQuartz may be important: I'm not
seeing rgl in the call stack, but libXplugin is there. Mine is "XQuartz
2.7.11 (xorg-server 1.18.4)".
Duncan Murdoch
On 29/05/2020 11:44 a.m., Richard M. Heiberger wrote:
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.
if(identical(getOption('pager'), file.path(R.home('bin'), 'pager')))
options(pager='cat') # rather take the ESS one
options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient',
show.error.locations=TRUE)
version
_
platform x86_64-apple-darwin17.0
arch x86_64
os darwin17.0
system x86_64, darwin17.0
status
major 4
minor 0.0
year 2020
month 04
day24
svn rev78286
language R
version.string R version 4.0.0 (2020-04-24)
nickname Arbor Day
library(rgl)
plot(1:10)
Process R abort trap: 6 at Fri May 29 11:32:59 2020
2020-05-29 11:32:59.542 R[24448:3255600] *** 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 11:32:59.560 R[24448:3255600] *** 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 0x7fff398de456
-[NSAssertionHandler
handleFailureInFunction:file:lineNumber:description:] + 166
4 AppKit 0x7fff34503083
+[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] +
361
5 AppKit 0x7fff34e4bda8
_NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243
6 AppKit 0x7fff34502c85
-[NSApplication(ScreenHandling) _reactToDockChanged] + 144
7 AppKit 0x7fff345024dc
_NSCGSDockMessageReceive + 268
8 HIToolbox 0x7fff35d34a3c
_ZL12DockCallbackjjPvS_ + 1987
9 HIServices 0x7fff3539c8ec
dockClientNotificationProc + 217
10 SkyLight0x7fff6626f174
_ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ +
1002
11 SkyLight0x7fff6626de71
CGSSnarfAndDispatchDatagrams + 1671
12 SkyLight0x7fff6649d5a5
SLSGetNextEventRecordInternal + 83
13 SkyLight0x7fff6633bfbe
SLEventCreateNextEvent + 136
14 libXplugin.1.dylib 0x00010ffa5f0c
___xp_init_service_cg_event_port_block_invoke + 104
15 libdispatch.dylib 0x7fff7108d658
_dispatch_client_callout + 8
16 libdispatch.dylib 0x7fff7108f818
_dispatch_continuation_pop + 414
17 libdispatch.dylib 0x7fff7109f4be
_dispatch_source_invoke + 2084
18 libdispatch.dylib 0x7fff71092af6
_dispatch_lane_serial_drain + 263
19 libdispatch.dylib 0x7fff710935d6
_dispatch_lane_invoke + 363
20 libdispatch.dylib 0x7fff7109cc09
_dispatch_workloop_worker_thread + 596
21 libsystem_pthread.dylib 0x7fff712eba3d
_pthread_wqthread + 290
22 libsystem_pthread.dylib 0x7fff712eab77 start_wqthread + 15
)
libc++abi.dylib: terminating with uncaught exception of type NSException
___
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] obsolete LaTeX software in "R CMD check" on Mac?
On 12/05/2020 6:17 p.m., Spencer Graves wrote:
Hello, All:
Might "R CMD check" on Mac use obsolete LaTeX software?
I ask, because "R CMD check" on my Mac started reporting LaTeX
errors on *.Rd files that previously passed "R CMD check" without
problems. Dirk Eddelbuettel recommended I ask tex.stackexchange about
that. I did that and got the following:
If I understand correctly, this error is showing up on *your* Mac. So
isn't it easy for you to check if LaTeX is up to date?
The \textasciigrave macro has been used by Rd.sty and Sweave.sty since
2013, so it's nothing new on R's end.
Duncan Murdoch
* "In a current tex system \textasciigrave should work with
your families - they don't have the glyph but latex will fall back
without error. In older systems it could give an error."
See:
https://tex.stackexchange.com/questions/543783/package-textcomp-error-symbol-textasciigrave-not-provided
Comments?
Thanks,
Spencer Graves
p.s. An earlier post on this issue to r-pkg-devel is copied below.
Forwarded Message
Subject:[R-pkg-devel] Error: Symbol \textasciigrave not provided by
(textcomp)
Date: Sun, 16 Feb 2020 14:21:17 -0600
From: Spencer Graves
To: r-package-de...@r-project.org
Hello, All:
"R CMD check Ecfun_0.2-4.tar.gz" ends with 8 repetitions of the
following:
! Package textcomp Error: Symbol \textasciigrave not provided by
(textcomp) font family zi4 in TS1 encoding.
(textcomp) Default family used instead.
See the textcomp package documentation for explanation.
* checking PDF version of manual without hyperrefs or index ... ERROR
* DONE
This is using R 3.6.2 under macOS 10.15.3 applied to the current
development version of "https://github.com/sbgraves237/Ecfun". Travis
CI reported that the build passed; see
"https://travis-ci.org/sbgraves237/Ecfun/builds/650505913?utm_medium=notification_source=email;.
This looks to me like it's complaining about the use of the back
tick character ("`", below "~" on the top left key on a standard
American English keyboard), which I assume is equivalent to
"\textasciigrave" in certain contexts.
Six out of those 8 repetitions occur in the examples sections of
files "grepNonStandardCharacters.Rd", "subNonStandardCharacters.Rd", and
"subNonStandardNames.Rd". Those functions were written to fix parsing
errors with names like "Raúl" that had been mangled by different
software before I could get it into R.
After a day's work failed to produce a work around, I decided to
ask this group.
What do you suggest?
Thanks,
Spencer Graves
__
r-package-de...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[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
[R-SIG-Mac] R CMD check warning in 4.0.0 RC
I've just installed R version 4.0.0 RC (2020-04-18 r78249) and am checking a package on MacOS High Sierra (10.13.6). I can't install the recommended version of Xcode on this MacOS version. I'm currently using Xcode 9.2. (I think Xcode 10.x is supposed to work on High Sierra, but it isn't obvious how to update.) My package has a small amount of C code, and R CMD check is clean, but R CMD check --as-cran gives this NOTE: * checking compilation flags used ... NOTE Compilation used the following non-portable flag(s): ‘-mmacosx-version-min=10.13’ I didn't supply that, it's the default, so probably this note should not appear (even though the message is true). Duncan Murdoch ___ 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-SIG-Mac Digest, Vol 205, Issue 13
That lists "base" as a package, as well as the other base and
recommended packages. That's not what Dr. Lisse was looking for: he
wanted "all user installed (additional) packages, ie not the ones that
come with R?".
Duncan Murdoch
On 02/04/2020 10:47 a.m., Colin A. Smith wrote:
This will do it as well:
package_list <- tapply(rownames(installed.packages()),
installed.packages()[,"LibPath"], c)
Bonus to find out which library directories are writable by the user:
file.access(names(package_list), mode=2) == 0
Cheers,
Colin
On Apr 2, 2020, at 10:36, Michael Hall wrote:
On Apr 2, 2020, at 6:10 AM, r-sig-mac-requ...@r-project.org wrote:
Is there a way of (only) listing all user installed (additional)
packages, ie not the ones that come with R?
https://www.r-bloggers.com/list-of-user-installed-r-packages-and-their-versions/
<https://www.r-bloggers.com/list-of-user-installed-r-packages-and-their-versions/>
Sys.getenv()
…
R_LIBS_USER ~/Library/R/3.6/library
…
list.files('~/Library/R/3.6/library')
[1] "alphavantager" "BBmisc""brew" "C50"
[5] "checkmate" "clisymbols""coda" "commonmark”
...
___
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] Homebrew
On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:
New thread :-)-O
I am wondering if I should not try to figure out how automate this.
Is there a way of (only) listing all user installed (additional)
packages, ie not the ones that come with R?
Look at the "Priority" column in installed.packages(). "base" is part
of R, "recommended" is normally distributed with R. "recommended"
packages can be updated after R is installed, "base" packages can't.
If you just copy all the packages to the new library that aren't already
there, and run update.packages(checkBuilt = TRUE) R will re-install
everything that was originally installed under an earlier version.
Duncan Murdoch
I could then construct the below file automagically, and if I was
really bothered and bored find out how to make Homebrew pre/post
install scripts to automate this :-)-O
And, for the record, other than that, I can only recall one serious
issue, when the openblas library got lost recently which was however
fixed quite quickly.
greetings, el
On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:
I do same, including Rstudio (Cask).
Once in a while after major updates I need to reinstall all my extra
packages, so I have written me a little script along the lines of
#!/usr/local/bin/Rscript
local({
r <- getOption("repos")
r["CRAN"] <- "https://cloud.r-project.org/;
options(repos = r)
})
install.packages(c(
"RMariaDB", "rstudioapi"
))
made it 0755 and can run it from the command line. Put it in my
handbook so I don't forget and never looked back.
greetings, el
On 02/04/2020 10:03 am, Rainer M Krug wrote:
I am using Homebrew on a Mac (two Macs - one at home, one at work)
instead of the official R package, and I did not have any problems
after upgrades - maybe I am lucky, maybe not as picky in defining
“problem”, but my suggestion would be to try R from homebrew to
install R.
OK - no support from here - I know.
And homebrew has also binary versions. What is missing, is a hombrew
R package repository. Maybe an idea to create one?
Cheers,
Rainer
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Transitioning from Mac to LInux?
On 01/04/2020 2:48 p.m., Carl Witthoft wrote: If I should ask over at r-sig-debian instead of here, please tell me. I don't wish to clog r-sig-mac with off-topic stuff. I've been watching the massive headaches people are dealing with trying to keep R fully compatible with each MacOS X upgrade, I'm wondering whether replacing my iMac (2009) with a new Mac really makes sense from an R - user point of view, as opposed to getting some inexpensive desktop and installing Linux. I know I can run R and RStudio under Linux, for example, but don't know what limitations, if any there are when it comes to building packages from source, getting compatible compilers, and so on. What have some of you 'power R users' discovered when/if you tried to build , or incorporate Bioconductor or other repository's packages under Linux? If your iMac is still working, try installing Ubuntu or some other Linux on it. I think at that age Apple is no longer providing upgrades, but I just put Ubuntu on a 2008 iMac, and it works well. (I needed to upgrade the memory, but that just cost $40 for 4 GB.) So I got a $40 desktop, with a nice screen. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to add variables to a vector
On 28/03/2020 4:17 p.m., David wrote: If I have a vector created like x <- c(5,1,9,3), how can I add values to it later? That seems simple, but I don't find the answer in either of my Dalgaard or Crawley books, or in the help functions. Thanks. This question belongs on R-help: nothing to do with MacOS. But the answer is to use c(), or just assign to a nonexistent location. For example, x <- c(5,1,9,3) x <- c(x, 10) x[10] <- 20 This will result in x printing as [1] 5 1 9 3 10 NA NA NA NA 20 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] damned Catalina
On 18/12/2019 8:43 a.m., bruno apolloni wrote:
Do you mean that it does not work locally on my computer, but only in the cloud?
I think he meant
install.packages("regtools", repo = "https://cloud.r-project.org;)
which works for me (but I'm not on Catalina, I'm still on High Sierra).
Duncan Murdoch
Thanks for the collaboration
Bruno
Il giorno 18 dic 2019, alle ore 14:37, Rainer M Krug ha
scritto:
Just works out of the box, i.e. the cloud repo.
PS: please CC the list in - thanks
On 18 Dec 2019, at 14:34, bruno apolloni mailto:apoll...@di.unimi.it>> wrote:
I tried from many repo:
https://cran.r-project.org <https://cran.r-project.org/>
https://pbil.univ-lyon1.fr/CRAN/ <https://pbil.univ-lyon1.fr/CRAN/>
https://cran.stat.unipd.it <https://cran.stat.unipd.it/>
http://cran.mirror.garr.it/mirrors/CRAN/
<http://cran.mirror.garr.it/mirrors/CRAN/>
always with the same answer:
package ‘regtools’ is not available (for R version 3.6.2) .
Which URL you refer to? The above links are opened in Safari.
Thanks for your cooperation
Bruno
Il giorno 18 dic 2019, alle ore 13:41, Rainer M Krug mailto:rai...@krugs.de>> ha scritto:
Also on Catalena: I can install without problems. Try a different repo? Can you
open the URL in Safari?
Cheers,
Rainer
On 18 Dec 2019, at 13:32, bruno apolloni mailto:apoll...@di.unimi.it>> wrote:
Any help after the Ken answer?
Thanks a lot
Bruno
Inizio messaggio inoltrato:
Da: bruno apolloni mailto:apoll...@di.unimi.it>>
Oggetto: Re: [R-SIG-Mac] damned Catalina
Data: 18 dicembre 2019 13:30:54 CET
A: Ken Beath mailto:k...@kjbeath.com.au>>
Actually, in https://cran.r-project.org/bin/macosx/
<https://cran.r-project.org/bin/macosx/> <https://cran.r-project.org/bin/macosx/
<https://cran.r-project.org/bin/macosx/>> I read;
For discussion of Mac-related topics and reporting Mac-specific bugs, please use the
R-SIG-Mac <https://stat.ethz.ch/mailman/listinfo/r-sig-mac
<https://stat.ethz.ch/mailman/listinfo/r-sig-mac>> mailing list.
Did something went wrong? Should I remove the first line of my mail? Actually,
what I need is to run “regtools” on Cran R insalled on my computer. Thanks for
your unsderstanding, all the best
Bruno
Bruno Apolloni
(Full Professor )
Dipartimento di Informatica
University of Milano
Via Comelico 39
20135 Milano (Italy)
Tel. +39(0)2-50316284
Fax. +39(0)2-50316228
Mobile +39 333 7469878
e-mail: apoll...@di.unimi.it <mailto:apoll...@di.unimi.it> <mailto:apoll...@di.unimi.it
<mailto:apoll...@di.unimi.it>>
http://homes.di.unimi.it/apolloni <http://homes.di.unimi.it/apolloni>
<http://homes.di.unimi.it/apolloni <http://homes.di.unimi.it/apolloni>>
Il giorno 18 dic 2019, alle ore 13:08, Ken Beath mailto:k...@kjbeath.com.au> <mailto:k...@kjbeath.com.au
<mailto:k...@kjbeath.com.au>>> ha scritto:
Try another repository. It works fine with the main CRAN and teh RStudio
repositories.
Ken
On 18 Dec 2019, at 10:50 pm, bruno apolloni mailto:apoll...@di.unimi.it> <mailto:apoll...@di.unimi.it
<mailto:apoll...@di.unimi.it>>> wrote:
Dear All
among disasters of the new operating system Catalina, this one concerns R.
Trying to install “regtools" the answer by Crane R consolle is
unable to access index for repository https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6>
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6>>
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6>
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6
<https://cran.stat.unipd.it/bin/macosx/el-capitan/contrib/3.6>>>
The same for “devtools”. This happens on my Mac with Catalina OS. The same
installation on same Crane R but on a laptop of colleauge of mine endowed with
previous OS (el captain) succeeds without any problem.
Any remedy to suggest?
Thanks a lot
Bruno
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org> <mailto:R-SIG-Mac@r-project.org
<mailto:R-SIG-Mac@r-project.org>>
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
<https://stat.ethz.ch/mailman/listinfo/r-sig-mac>
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org>
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
<https://stat.ethz.ch/mailman/listinfo/r-sig-mac>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys
Re: [R-SIG-Mac] segfault with raster package
On 16/12/2019 4:34 p.m., Marc Girondot via R-SIG-Mac wrote:
When I load the last version of raster package in MacOS, I get a segfault:
This is similar to the problem described here:
https://r.789695.n4.nabble.com/Raster-package-crash-with-segmentation-fault-td4759487.html
or here
https://github.com/rspatial/raster/issues/63
The last working version for me is the 2.5-8 installed with:
require(devtools)
install_version("raster", version = "2.5-8", repos
="http://cran.us.r-project.org;)
I would like know if the problem with the raster package is common in
macOSX or if there is something special for me.
library(raster) works fine for me. This loads 3.0-7. I'm on MacOS
10.13.6, likely older than whatever you are using.
Duncan Murdoch
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How can I find the "sh" application used by "R CMD check" on a Mac?
On 19/02/2019 5:39 p.m., Spencer Graves wrote: How can I find the "sh" application used by "R CMD check" on a Mac? I need to know to be able to add it to the "Application Access" list maintained by the "Anti-Ransomware" feature of my Bitdefender Antivirus for Mac. With that feature on, "R CMD check Ecfun" stopped with the following: checking whether package ‘Ecfun’ can be installed ...sh: ... Permission denied When I saw that, I also got a popup from Bitdefender that would only allow me to allow this once but not permanently. To allow it permanently, I need to know where it is on my hard drive. From a console, run "which sh". I get "/bin/sh". Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] legend function and Inf warnings
On 20/10/2018 11:23 AM, Ossenbruggen, Paul wrote:
I receive warnings() that make debugging difficult. I have two
questions:
I think you've posted this to the wrong list. Maybe R-help instead?
1. In this part of my script, I want my script to return “Inf”. I receive the
following warning.
In min(df12.[df12.[, 7] <= 0, 1]) :
no non-missing arguments to min; returning Inf
Is there are command to eliminate the warning message?
You can add another value and suppress the message:
min(c()) gives the warning, min(c(), 2) will give 2. You'll need to
find some value that you can distinguish from a real minimum...
Sorry, no comment on your other question.
Duncan Murdoch
2. I use the following legend that returns a plot that I am happy with and no
errors:
legend("topright",
title = "",
legend = c(
expression("Predictions:"),
bquote(bar(u)[A] == .(u.a)),
bquote(bar(u)[D] == .(u.d))
),
cex = c(0.75,0.75,0.75)
)
At the same time, I receive the following warnings:
warnings()
Warning messages:
1: In if (xc < 0) text.width <- -text.width :
the condition has length > 1 and only the first element will be used
2: In strheight(legend, units = "user", cex = cex)/yc :
longer object length is not a multiple of shorter object length
3: In w0 * rep.int(0:(ncol - 1), rep.int(n.legpercol, ncol)) :
longer object length is not a multiple of shorter object length
4: In left + xchar + xextra + (w0 * rep.int(0:(ncol - 1), ... :
longer object length is not a multiple of shorter object length
5: In (rep.int(1L:n.legpercol, ncol)[1L:n.leg] - 1 + !is.null(title)) * ... :
longer object length is not a multiple of shorter object length
6: In top - 0.5 * yextra - ymax - (rep.int(1L:n.legpercol, ... :
longer object length is not a multiple of shorter object length
7: In xt + x.intersp * xchar :
longer object length is not a multiple of shorter object length
8: In if (xc < 0) text.width <- -text.width :
the condition has length > 1 and only the first element will be used
9: In if (xc < 0) text.width <- -text.width :
the condition has length > 1 and only the first element will be used
If I remove “bquote” from “legend,” no warnings are produced.
By the way, “xc,” “yextra”, and other variable listed are not part of my
script. I have no idea what to do with the warning information.
Is there a better way to write my “legend” code?
Thanks,
Paul
___
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] Blank help window
On 18/10/2018 5:09 PM, Ben Tupper wrote:
Hi,
In a fresh R.app session
> debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
> help('help')
starting httpd help server ... done
debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
debug: {
x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
.Call("aqua.custom.print", "help-files", x)
invisible(x)
}
Browse[2]> n
debug: x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
Browse[2]> n
debug: .Call("aqua.custom.print", "help-files", x)
Browse[2]> browseURL(x)
opens the external browser
http://localhost:28450/library/utils/html/help.html
but the browser says...
"Hmm. We’re having trouble finding that site.
We can’t connect to the server at localhost.
If that address is correct, here are three other things you can try:
Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has
permission to access the Web."
And...
Browse[2]> c
exiting from: browser(if (encodeIfNeeded) URLencode(url) else url)
... opens the blank help window.
That's the issue then. Your system doesn't support "localhost", and
R.app assumes it will.
I don't know enough about MacOS to guess a cause or a remedy, but that's
what you need to fix.
Duncan Murdoch
Finally, following up on Marc's suggestion that I invoke R without
--vanilla...
ben@gale ~ $ diff R-app-options R-options
81c81
<
---
>
108,110d107
< $help_type
< [1] "html"
<
184,185c181,182
< CRAN
< "http://cran.utstat.utoronto.ca;
---
> CRAN
> "@CRAN@"
247c244
< [1] 168
---
> [1] 80
On Oct 18, 2018, at 4:49 PM, Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
On 18/10/2018 8:50 AM, Ben Tupper wrote:
I also have no firewall running on the platform. I do have
anti-virus/malware and have turned it off. The help window still
renders with a blank page and there is no text captured with a
copy-paste.
I tried debug() as Duncan suggested and get the following in a fresh
R.app session...
Okay, that wasn't as informative as I had hoped. Could you try the
following:
debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
then ask for help on something. You should stop in the debugger
seeing something like
debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
debug: {
x <- gsub("http://127.0.0.1 <http://127.0.0.1/>", "http://localhost
<http://localhost/>", x, fixed = TRUE)
.Call("aqua.custom.print", "help-files", x)
invisible(x)
}
At the prompt, type "n" (without the quotes, followed by return)
twice, until you are at the .Call line. Then type
browseURL(x)
This should open your external browser. It will either show a blank
page, or the help page: that will indicate whether the problem is in
the internal browser or in the server.
Then go back to R.app, and type "c". This should open the same help
page in the internal browser. It might show a blank page, or the
regular help page: either one would tell us something.
Duncan Murdoch
debug(utils:::print.help_files_with_topic)
help("help")
debugging in: print.help_files_with_topic(x)
debug: {
browser <- getOption("browser")
topic <- attr(x, "topic")
type <- attr(x, "type")
if (.Platform$GUI == "AQUA" && type == "html")
browser <- get("aqua.browser", envir =
as.environment("tools:RGUI"))
paths <- as.character(x)
if (!length(paths)) {
writeLines(c(gettextf("No documentation for %s in specified
packages and libraries:",
sQuote(topic)), gettextf("you could try %s",
sQuote(paste0("??",
topic)
return(invisible(x))
}
port <- if (type == "html")
tools::startDynamicHelp(NA)
else NULL
if (attr(x, "tried_all_packages")) {
paths <- unique(dirname(dirname(paths)))
msg <- gettextf("Help for topic %s is not in any loaded
package but can be found in the following packages:",
sQuote(topic))
if (type == "html" && port > 0L) {
path <- file.path(tempdir(), ".R/doc/html")
dir.create(path, recursive = TRUE, showWarnings = FALSE)
out <- paste0("4.01 Transitional//EN\">\n",
"R: help\n", "http-equiv=\"Content-Type\" content=\"text/html; charset=\"UTF-8\">\n",
&q
Re: [R-SIG-Mac] Blank help window
On 18/10/2018 8:50 AM, Ben Tupper wrote:
I also have no firewall running on the platform. I do have anti-virus/malware
and have turned it off. The help window still renders with a blank page and
there is no text captured with a copy-paste.
I tried debug() as Duncan suggested and get the following in a fresh R.app
session...
Okay, that wasn't as informative as I had hoped. Could you try the
following:
debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
then ask for help on something. You should stop in the debugger seeing
something like
debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
debug: {
x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
.Call("aqua.custom.print", "help-files", x)
invisible(x)
}
At the prompt, type "n" (without the quotes, followed by return) twice,
until you are at the .Call line. Then type
browseURL(x)
This should open your external browser. It will either show a blank
page, or the help page: that will indicate whether the problem is in
the internal browser or in the server.
Then go back to R.app, and type "c". This should open the same help
page in the internal browser. It might show a blank page, or the
regular help page: either one would tell us something.
Duncan Murdoch
debug(utils:::print.help_files_with_topic)
help("help")
debugging in: print.help_files_with_topic(x)
debug: {
browser <- getOption("browser")
topic <- attr(x, "topic")
type <- attr(x, "type")
if (.Platform$GUI == "AQUA" && type == "html")
browser <- get("aqua.browser", envir = as.environment("tools:RGUI"))
paths <- as.character(x)
if (!length(paths)) {
writeLines(c(gettextf("No documentation for %s in specified packages and
libraries:",
sQuote(topic)), gettextf("you could try %s", sQuote(paste0("??",
topic)
return(invisible(x))
}
port <- if (type == "html")
tools::startDynamicHelp(NA)
else NULL
if (attr(x, "tried_all_packages")) {
paths <- unique(dirname(dirname(paths)))
msg <- gettextf("Help for topic %s is not in any loaded package but can be
found in the following packages:",
sQuote(topic))
if (type == "html" && port > 0L) {
path <- file.path(tempdir(), ".R/doc/html")
dir.create(path, recursive = TRUE, showWarnings = FALSE)
out <- paste0("\n",
"R: help\n", "\n",
"\n",
"\n\n\n")
out <- c(out, "", msg, "")
out <- c(out, "\n",
"\n", "PackageLibrary\n")
pkgs <- basename(paths)
links <- paste0("http://127.0.0.1:;, port,
"/library/", pkgs, "/help/", topic, "\">", pkgs,
"")
out <- c(out, paste0("\n",
"", links, "", dirname(paths), "\n"))
out <- c(out, "\n\n\n")
writeLines(out, file.path(path, "all.available.html"))
browseURL(paste0("http://127.0.0.1:;, port,
"/doc/html/all.available.html"),
browser)
}
else {
writeLines(c(strwrap(msg), "", paste0(" ",
formatDL(c(gettext("Package"),
basename(paths)), c(gettext("Library"), dirname(paths)),
indent = 22
}
}
else {
if (length(paths) > 1L) {
if (type == "html" && port > 0L) {
browseURL(paste0("http://127.0.0.1:;, port,
"/library/NULL/help/",
URLencode(topic, reserved = TRUE)), browser)
return(invisible(x))
}
file <- paths[1L]
p <- paths
msg <- gettextf("Help on topic %s was found in the following
packages:",
sQuote(topic))
paths <- dirname(dirname(paths))
txt <- formatDL(c("Package", basename(paths)), c("Library",
dirname(paths)), indent = 22L)
writeLines(c(strwrap(msg), "", paste0(" ", txt),
""))
if (interactive()) {
fp <- file.path(paths, "Meta", "Rd.rds")
tp <- basename(p)
t
Re: [R-SIG-Mac] Blank help window
On 17/10/2018 8:06 PM, Ben Tupper wrote:
Darn. No joy from a complete clean-and-reinstall with a reinstall of XQuartz
as Marc suggested. It is still a blank help page.
Below is everything I can think of from the new session.
You can try
debug(utils:::print.help_files_with_topic)
to see what is going on on your system. On mine (High Sierra with help
working), it retrieves as.environment("tools:RGUI")$aqua.browser which
looks like
function (x, ...)
{
x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
.Call("aqua.custom.print", "help-files", x)
invisible(x)
}
If I debug this and try browseURL(x) after x is modified, I see help in
my usual browser. If I continue to the .Call(), it appears in the usual
R.app browser.
Do you see something similar?
Duncan Murdoch
R version 3.5.1 (2018-07-02) -- "Feather Spray"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.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.
[R.app GUI 1.70 (7543) x86_64-apple-darwin15.6.0]
?data.frame
starting httpd help server ... done
sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.6
Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.5.1 tools_3.5.1
capabilities()
jpeg pngtiff tcltk X11aqua
http/ftp sockets libxmlfifo
TRUETRUETRUETRUETRUETRUE
TRUETRUETRUETRUE
cledit iconv NLS profmem cairo ICU
long.double libcurl
TRUETRUETRUETRUETRUETRUE
TRUETRUE
And from shell...
ben@gale ~ $ ll /usr | grep X11
lrwxr-xr-x 1 root wheel 8B Oct 17 19:35 X11 -> /opt/X11
lrwxr-xr-x 1 root wheel 8B Oct 17 19:35 X11R6 -> /opt/X11
On Oct 17, 2018, at 7:20 PM, Ben Tupper wrote:
Ahoy!
?data.frame
starting httpd help server ... done
(tools::startDynamicHelp(NA))
[1] 31048
Connecting to http://127.0.0.1:31048/NEWS <http://127.0.0.1:31048/NEWS> brings
up NEWS as expected.
If I understand the MacOS preferences the firewall is OFF.
I'll try the clean-then-reinstall that Marc suggests and report back.
Ben
On Oct 17, 2018, at 5:42 PM, Peter Dalgaard mailto:pda...@gmail.com>> wrote:
Hmm, when trying from R.app, do you see the following?
?data.frame
starting httpd help server ... done
(tools::startDynamicHelp(NA))
[1] 26163
(The last bit is the port number of the HTTP server and will differ between
invokations. I think you get 0 if the server isn't running and -1 if it failed
to start.)
If the server is there, you could try connecting from your favourite browser at (say)
http://127.0.0.1:26163/NEWS <http://127.0.0.1:26163/NEWS>
If the server is there, but you cannot talk to it, then I suspect that a
firewall is getting in the way.
-pd
On 17 Oct 2018, at 20:53 , Ben Tupper mailto:btup...@bigelow.org>> wrote:
Hi,
The behavior I see is identical to what you describe regardless of the function
(I used ?data.frame as an example). The help commands
?
and
help("something")
both bring up a blank help window. All of the other steps you have taken yield
the same result on my system.
R version 3.5.1 (2018-07-02) -- "Feather Spray"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.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 in
Re: [R-SIG-Mac] R 3.4.4 and 3.5 (Mac) crash when loading a .R file
On 05/07/2018 12:28 PM, Felipe Pérez-Jvostov wrote: Hi, I'm not sure where to get help regarding this, but I haven't been able to load any .R files on RGui 3.4.4 or 3.5 on Mac OS High Sierra 10.13.5. I've re-installed R and still have this problem. If I use the "open in editor" or "Open recent", R will hang. If I use load(file.choose()), it shows this error: Error in load(file.choose()) : bad restore file magic number (file may be corrupted) -- no data loaded In addition: Warning message: file ‘R_data_Sci.R’ has magic number 'ggp' Use of save versions prior to 2 is deprecated objc[49397]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fffa24a9c90) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x110ca5cd8). One of the two will be used. Which one is undefined. Any ideas what it could be? You shouldn't try to load() a .R file. It is a source file; you would use source() to read and execute it. load() is for binary images of workspaces, typically called something like .RData. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Updating some packages fails
On 15/01/2018 6:03 PM, Manuel Spínola wrote:
Thank you very much Ben.
But I am trying to make an update, not a first time installation. The
older sf version is running fine.
Building from source needs more from your system than installing a
prebuilt binary. If you aren't willing or able to follow Ben's
instructions, you'll just have to wait until Simon's binary build makes
it onto CRAN.
Duncan Murdoch
Manuel
2018-01-15 10:40 GMT-06:00 Ben Tupper <btup...@bigelow.org>:
Hi,
sf (and many other spatial packages) depend upon gdal (
http://www.gdal.org/) being installed on your platform. Your message
says it can't find the gdal-config utility, "checking for gdal-config...
no". You can install it following these instructions...
https://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries
I'm not sure about the other packages you list.
Cheers,
Ben
On Jan 15, 2018, at 11:25 AM, Manuel Spínola <mspinol...@gmail.com> wrote:
I am still having problems updating some packages, for example,
sf
Hmisc
rms
mgcv
RcmdrMisc
Same messages that I showed in my first email.
Manuel
2018-01-11 12:17 GMT-06:00 Simon Urbanek <simon.urba...@r-project.org>:
Manuel,
the archiving on CRAN has changed recently which broke the updates so
recently the update for macOS packages have been suspended. Hence some most
recent binaries is not available yet - it should be up by tomorrow.
Cheers,
Simon
On Jan 11, 2018, at 12:26 PM, Manuel Spínola <mspinol...@gmail.com>
wrote:
Dear list members,
When trying updating some packages in MacOS High Sierra 10.13 (R 3.4.2)
some packages, as "sf", fails:
install.packages("sf")
There is a binary version available but the source version is later:
binary source needs_compilation
sf 0.5-5 0.6-0 TRUE
Do you want to install from sources the package which needs compilation?
y/n: y
installing the source package ‘sf’
trying URL 'https://cran.rstudio.com/src/contrib/sf_0.6-0.tar.gz'
Content type 'application/x-gzip' length 7399611 bytes (7.1 MB)
==
downloaded 7.1 MB
Warning in strptime(xx, f <- "%Y-%m-%d %H:%M:%OS", tz = tz) :
unknown timezone 'default/America/Costa_Rica'
* installing *source* package ‘sf’ ...
** package ‘sf’ successfully unpacked and MD5 sums checked
configure: CC: clang
configure: CXX: clang++
checking for gdal-config... no
no
configure: error: gdal-config not found or not executable.
ERROR: configuration failed for package ‘sf’
* removing
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/sf’
* restoring previous
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/sf’
Warning in install.packages :
installation of package ‘sf’ had non-zero exit status
The downloaded source packages are in
‘/private/var/folders/gf/vwlbzml90wv7cs2r4v00wg_mgn/T/RtmpbmvcCh/
downloaded_packages’
Any solution to this problem?
Manuel
--
*Manuel Spínola, Ph.D.*
Instituto Internacional en Conservación y Manejo de Vida Silvestre
Universidad Nacional
Apartado 1350-3000
Heredia
COSTA RICA
mspin...@una.cr <mspin...@una.ac.cr>
mspinol...@gmail.com
Teléfono: (506) 8706 - 4662
Personal website: Lobito de río <https://sites.google.com/
site/lobitoderio/>
Institutional website: ICOMVIS <http://www.icomvis.una.ac.cr/>
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
*Manuel Spínola, Ph.D.*
Instituto Internacional en Conservación y Manejo de Vida Silvestre
Universidad Nacional
Apartado 1350-3000
Heredia
COSTA RICA
mspin...@una.cr <mspin...@una.ac.cr>
mspinol...@gmail.com
Teléfono: (506) 8706 - 4662
Personal website: Lobito de río <https://sites.google.com/
site/lobitoderio/>
Institutional website: ICOMVIS <http://www.icomvis.una.ac.cr/>
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Ben Tupper
Bigelow Laboratory for Ocean Sciences
60 Bigelow Drive
<https://maps.google.com/?q=60+Bigelow+Drive=gmail=g>, P.O.
Box 380
East Boothbay, Maine 04544
http://www.bigelow.org
Ecocast Reports: http://seascapemodeling.org/ecocast.html
Tick Reports: https://report.bigelow.org/tick/
Jellyfish Reports: https://jellyfish.bigelow.org/jellyfish/
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] package or namespace load failed for ‘ks’
On 13/11/2017 4:20 AM, 王宙翔 wrote: Hi，Friends： I have installed ks package successfully using R version 3.4.2 on Mac 10.12.6. But when I library it , I have the following problem. error: package or namespace load failed for ‘ks’: onLoad fails when'rgl'is calculated in loadNamespace (): Call: dyn.load(file, DLLpath = DLLpath, ...) Error: unable to load shared target object:‘/Users/sanyu/Library/R/3.4/library/rgl/libs/rgl.so’：: dlopen(/Users/sanyu/Library/R/3.4/library/rgl/libs/rgl.so, 6): Library not loaded: /opt/X11/lib/libGLU.1.dylib Referenced from: /Users/sanyu/Library/R/3.4/library/rgl/libs/rgl.so Reason: image not found This is the first time I write emails to foreign friends , I hope I can get this helps. Wang The problem here is with the rgl package. It requires that you have XQuartz installed. That's not an R package, it's available from xquartz.org. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] ifelse script
On 25/10/2017 1:18 PM, Jose G Conde Santiago via R-SIG-Mac wrote: Hello. I got one new variable computed using ifelse through R Commander. The variable was created without a problem. This was the expression to compute: ifelse(icdfrrcond1 == 1 | icdfrrcond2 == 1 | icdfrrcond3 == 1 | icdfrrcond4 == 1 | icdfrrcond5 == 1 | icdfrrcond6 == 1 | icdfrrcond7 == 1 | icdfrrcond8 == 1 | icdfrrcond9 == 1 | icdfrrcond10 == 1 | icdfrrcond11 == 1 | icdfrrcond12 == 1 | icdfrrcond13 == 1 | icdfrrcond14 == 1 | icdfrrcond15 == 1 | icdfrrcond16 == 1 | icdfrrcond17 == 1 | icdfrrcond18 == 1 | icdfrrcond19 == 1 | icdfrrcond20 == 1, icdfrischhrtdis <- 1, icdfrischhrtdis <- 0) That's not the way to use ifelse(): it's not a control sequence like "if (cond) ... else ...", it's a function. You should write it as icdfrischhrtdis <- ifelse(icdfrrcond1 == 1 | icdfrrcond2 == 1 | icdfrrcond3 == 1 | icdfrrcond4 == 1 | icdfrrcond5 == 1 | icdfrrcond6 == 1 | icdfrrcond7 == 1 | icdfrrcond8 == 1 | icdfrrcond9 == 1 | icdfrrcond10 == 1 | icdfrrcond11 == 1 | icdfrrcond12 == 1 | icdfrrcond13 == 1 | icdfrrcond14 == 1 | icdfrrcond15 == 1 | icdfrrcond16 == 1 | icdfrrcond17 == 1 | icdfrrcond18 == 1 | icdfrrcond19 == 1 | icdfrrcond20 == 1, 1, 0) Duncan Murdoch This is the script generated by R Commander: mortprres0515sle$icdfrischhrtdis <- with(mortprres0515sle, ifelse(icdfrrcond1 == 1 | icdfrrcond2 == 1 | icdfrrcond3 == 1 | icdfrrcond4 == 1 | icdfrrcond5 == 1 | icdfrrcond6 == 1 | icdfrrcond7 == 1 | icdfrrcond8 == 1 | icdfrrcond9 == 1 | icdfrrcond10 == 1 | icdfrrcond11 == 1 | icdfrrcond12 == 1 | icdfrrcond13 == 1 | icdfrrcond14 == 1 | icdfrrcond15 == 1 | icdfrrcond16 == 1 | icdfrrcond17== 1 | icdfrrcond18 == 1 | icdfrrcond19 == 1 | icdfrrcond20 == 1, icdfrischhrtdis <- 1, icdfrischhrtdis <- 0)) When I try to run this same script from RStudio or the R console, the script is read, but the variable is not created. Even if I highlight the script in R Commander and “Submit” it, I get the same problem. What I would like to do is to copy the script and modify it, so I can create 10 additional variables using just one script that I can run directly in R or RStudio. Thanks. José José G. Conde, MD, MPH Professor, School of Medicine Director, CentIT2 UPR Medical Sciences Campus Tel (787) 763-9401 Fax (787) 758-5206 Email: jose.con...@upr.edu URL: http://rcmi.rcm.upr.edu ___ 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] segfault on R v. 3.4.1
On 14/09/2017 12:13 PM, James Plante wrote:
If I knew what a segfault was, I might be able to be more helpful.
In your case, it means that some part of the code is trying to refer to
a nonexistent memory address. This is certainly a bug somewhere or other.
From the traceback you posted, this appears to happen when R is trying
to load the compiled library of some package. I don't see information
on what package that is.
If it is a contributed package, the bug likely lies there. You might be
able to see this by going into the console and running
R --vanilla
which will load R with reduced startup code -- an old workspace won't be
loaded, etc. If that works, then you can gradually add back the things
you usually use (see ?Startup for the startup process) until you find
what triggers the problem.
If that fails, then the problem is likely with R, or some basic part of
your system. Four years old doesn't seem old, but it's long enough for
hardware problems to develop.
Duncan Murdoch
Do any of you folks know what might’ve happened? I’ve d/l’d and installed the
3.4.1. Mac binary from CRAN three times, and each time I get the text below.
Any help will be appreciated; let me know if I can include anything else. A
sysinfo() is out of the question, since my owly option is how I want to quit R.
The only guess I have is that I don’t have enough memory installed.
Main system info:
MacOS Sierra v. 10.12.8; 27” iMac, late 2013; 3.4GHz Core i%; 8GB 1600MHz DDR3
Thanks in advance,
Jim
R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.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.
*** caught segfault ***
address 0x1310, cause 'memory not mapped'
Traceback:
1: dyn.load(file, DLLpath = DLLpath, ...)
2: library.dynam(lib, package, package.lib)
3: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]])
4: asNamespace(ns)
5: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc,
.libPaths()), versionCheck = vI[[j]]),
i[[2L]], from = package)
6: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]])
7: asNamespace(ns)
8: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc,
i[[2L]], from = package)
.libPaths()), versionCheck = vI[[j]]),
9: loadNamespace(package, lib.loc)
10: doTryCatch(return(expr), name, parentenv, handler)
11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
12: tryCatchList(expr, classes, parentenv, handlers)
13: tryCatch({attr(package, "LibPath") <- which.lib.loc
<- attachNamespace(ns, pos = pos, deps)}, error = function(e) {
paste(" in", deparse(cc)[1L])else ""msg <- gettextf("package or
namespace load failed for %s%s:\n
%s", sQuote(package), P, conditionMessage(e))if (logical.return)
msg), domain = NA)else stop(msg, call. = FALSE, domain = NA)})
14: library(package, lib.loc = lib.loc, character.only = TRUE, logical.return =
TRUE,
warn.conflicts, quietly = quietly)
15: doTryCatch(return(expr), name, parentenv, handler)
16: tryCatchOne(expr, names, parentenv, handlers[[1L]])
17: tryCatchList(expr, classes, parentenv, handlers)
18: tryCatch(library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE,
warn.conflicts = warn.conflicts, quietly = quietly), error = function(e) e)
19: require(pkg, quietly = TRUE, warn.conflicts = FALSE, character.only = TRUE)
20: .First.sys()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
2017-09-14 08:14:57.208 R[11081:2277811] IMKClient Stall detected, *please
Report* your user scenario
attaching a spindump (or sysdiagnose) that captures the problem -
(imkxpc_attributesForCharacterIndex:reply:)
block performed very slowly (1.16 secs).
Selection:
[[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
Re: [R-SIG-Mac] Permanently fix R to open Help page in html
On 10/07/2017 5:02 PM, Christofer Bogaso wrote: Hi, I wanted R to open any Help page in html permanently. So 1st I created .Rprofile file with below code in terminal: touch ~/.Rprofile open -a Textedit ~/.Rprofile And then in the .Rprofile file, I wrote below code : options(help_type = ‘html’) However after that when I start R (from Terminal) I get below error on loading R Error: 1:20: unexpected input 1: options(help_type = ? ^ Those don't look like ASCII quotes. Use the R.app editor, not Textedit, and it won't put in funny "smart quotes". Duncan Murdoch [Previously saved workspace restored] Can someone please point me on where I made mistake. Thanks for your time. ___ 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] istate CRAN mirror not working - unable to use .Rprofile to change
On 08/06/2017 5:50 PM, Michael Hall wrote: On Jun 8, 2017, at 5:53 AM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: If you are using R.app, you can also set the mirror in the Preferences menu. Perhaps this setting overrides the .Rprofile setting. I was using the app and wasn’t aware of the preference, so thanks. There was no .Rprofile before I added one. I wasn’t sure what the app was basing this on. I didn’t see a Rprofile. <http://rprofile.info/>site anywhere in the framework either. Just a csv file that seemed to include all the mirrors turned up in a search. Whether or not being unable to do this with .Rprofile is a concern I don’t know. Looking again at help(Startup) it shows doing this as an example for Rprofile.site and not .Rprofile. I haven’t tried with .Rprofile.site. But I can’t exactly say it is documented that this should work. Although you might assume that you should be able to do in .Rprofile whatever might be done in Rprofile.site. The documentation about .Rprofile is documentation about R. R.app is a separate project that acts as a front end to R. Front ends can change things that R does. R.app uses its own Mac OS ways of storing persistent configuration information. But again, for my purposes yes, the preference is fine to change the default mirror and get me working normally. Thanks again. I am still a little curious if there are any thoughts on why the iastate mirror stopped working? You would likely have to figure out who was running it, and ask them. Mirrors are coordinated by CRAN, but are run by the local people who run them. Duncan Murdoch ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
