Re: [R-SIG-Mac] sessionInfo on Monterey

[Bob Rudis]

arm64:

R version 4.1.1 Patched (2021-08-13 r80752)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.0


x86_64:

R version 4.1.1 Patched (2021-08-10 r80733)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 10.16

On Fri, Aug 27, 2021 at 3:42 AM Prof Brian Ripley  wrote:
>
> One oddity is that the CRAN Intel binary build of R (or any other built
> under 10.x) when run on Big Sur reports
>
>  > sessionInfo()
> R version 4.1.1 (2021-08-10)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Big Sur 10.16
> ...
>
> because the system call used reports '10.16'.
>
> If anyone running a beta of Monterey has the CRAN binary installed, for
> completeness I would appreciate seeing what is reported.
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> ___
> 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] Issue installing gdal, sf, rgeos on R 4.1

[Bob Rudis]

Did you install these "Optional Libraries, Frameworks and Applications
for macOS (arm64)" — https://mac.r-project.org/libs-arm64/ — and
/opt/R/arm64/bin to PATH?

On Fri, Jul 23, 2021 at 8:54 AM Stephen Wild
 wrote:
>
> Hello,
>
> I am trying to install rgdal, sf, and rgeos on R 4.1 using Apple Silicon
> with native arm support. An old email
> 
> to the R help email list suggested emailing here given the error messages I
> am receiving.
>
> When I try to install `rgeos` or `sf` I get the following error:
>
> > configure: error: geos-config not found or not executable.
>
>
> Full error messages are at the end of the email.
>
> I have followed the instructions here
>  to
> install gdal using homebrew. Installation is successful, and running
> `gdalinfo --version` show I am running
>
> > GDAL 3.3.1, released 2021/06/28
>
>
> I have tried uninstalling gdal, reinstalling it, building from source, and
> changing the PATH (`export PATH=$PATH:/usr/local/opt/gdal-33/bin`). So far,
> no luck. Any help would be appreciated.
>
>
> Thanks.
>
> Steve
>
> Full error messages:
> rgeos
>
> > * installing *source* package ‘rgeos’ ...
> > ** using staged installation
> > configure: CC: clang -arch arm64
> > configure: CXX: clang++ -arch arm64 -std=gnu++14
> > configure: rgeos: 0.5-7
> > checking for /usr/bin/svnversion... no
> > cat: inst/SVN_VERSION: No such file or directory
> > configure: svn revision:
> > checking for geos-config... no
> > no
> > configure: error: geos-config not found or not executable.
> > ERROR: configuration failed for package ‘rgeos’
> > * removing
> > ‘/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgeos’
> > Warning in install.packages :
> >   installation of package ‘rgeos’ had non-zero exit status
>
>
> The downloaded source packages are in
> >
> > ‘/private/var/folders/r1/t2s9jjkj4k56jy6_29_s3svmgn/T/Rtmp6w846p/downloaded_packages’
>
>
>
>
> sf
>
> > * installing *source* package ‘sf’ ...
> > ** using staged installation
> > configure: CC: clang -arch arm64
> > configure: CXX: clang++ -arch arm64 -std=gnu++11
> > 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/4.1-arm64/Resources/library/sf’
> > Warning message:
> > In i.p(...) :
> >   installation of package
> > ‘/var/folders/r1/t2s9jjkj4k56jy6_29_s3svmgn/T//Rtmp6w846p/file23001676a067/sf_1.0-2.tar.gz’
> > had non-zero exit status
>
> [[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] Mac M1 emacs

[Bob Rudis]

you should likely re-post to the list or double check the download as
there are no x86_64 + amd64 universal binaries in there:

$ find  /Volumes/Emacs/Emacs.app/Contents/MacOS -type f -exec file {} \;
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ctags:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ebrowse:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/emacsclient:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/etags:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ctags:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ebrowse:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/emacsclient:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/etags:
Mach-O 64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs: Ruby script text,
UTF-8 Unicode text
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_10: Mach-O
64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_10.pdmp: data
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14: Mach-O
64-bit executable x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14.pdmp: data
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs.pdmp: data

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libffi.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libgmp.10.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libgnutls.30.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libhogweed.4.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libjansson.4.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libnettle.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libp11-kit.0.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libtasn1.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libunistring.2.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libffi.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libgmp.10.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libgnutls.30.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libhogweed.4.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libjansson.4.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libnettle.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libp11-kit.0.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libtasn1.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64

/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libunistring.2.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libffi.7.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libgmp.10.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libgnutls.30.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libhogweed.6.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libidn2.0.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libintl.8.dylib:
Mach-O 64-bit dynamically linked shared library x86_64
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libjansson.4.dylib:
Mach-O 

[R-SIG-Mac] XQuartz now supports Apple Silicon

[Bob Rudis]

Announcement and d/l links:

— https://www.mail-archive.com/xquartz-dev@lists.macosforge.org/msg01027.html
— https://www.xquartz.org/releases/XQuartz-2.8.0_beta1.html

Folks who use it should get prompted to install it next time you open it.

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Swift + embedded R

[Bob Rudis]

Hey folks,

In case there's any interest in using embedded R with Swift/SwiftUI,
I've started a blogdown series on that very thing.

Updates will be over at https://rud.is/books/swiftr/ & the associated
repo is at hrbrmstr/swiftr-book-examples

The book and repo are leading up to an eventual release of two
(Swift/C) packages that will make the bridge easier to integrate into
macOS Xcode Swift projects.

That library will have two modes. One will be the traditional way
embedded R works now with C code (Rf_…, SEXPs, etc).

The other uses a new/recent capability of Swift that makes the
language a bit more dynamic (at the cost of some type safety which is
sad but useful enough to make it cool).

That second mode will make Swift code like this possible:

_  = try R.evalParse("options(tidyverse.quiet = TRUE )")

// in practice this wld be called once in a model
try R.library("ggplot2")
try R.library("hrbrthemes")
try R.library("magick")

// can mix initialization of an R list with Swift and R objects
let mvals: RObject = [
  "month": [ "Jan", "Feb", "Mar", "Apr", "May", "Jun" ],
  "value": try R.sample(100, 6)
]

// ggplot2 ex. `mvals` is above, `col.hexValue` comes from the color picker
// can't do R.as.data.frame b/c "dots" so this is a deliberately
exposed alternate call
let gg = try R.ggplot(R.as_data_frame(mvals)) +
  R.geom_col(R.aes_string("month", "value"), fill: col.hexValue) +
// supports both [un]named
  R.scale_y_comma() +
  R.labs(
x: rNULL, y: "# things",
title: "Monthly Bars"
  ) +
  R.theme_ipsum_gs(grid: "Y")

// an alternative to {magick} could be getting raw SVG from {svglite} device
// we get Image view width/height and pass that to {magick}
// either beats disk/ssd round-trip
let fig = try R.image_graph(
  width: Double(imageRect.width),
  height: Double(imageRect.height),
  res: 144
)

try R.print(gg)
_ = R.dev_off() // can't do R.dev.off b/c "dots" so this is a
deliberately exposed alternate call

let res = try R.image_write(fig, path: rNULL, format: "png")

imgData = Data(res) // "imgData" is a reactive SwiftUI bound
object; when it changes Image does too

All of the "R.…" calls are dynamically looked up in the embedded R session.

It's a WIP (~70% feature complete) and will be introduced in the
bookdown series and repo in a couple weeks.

It likely isn't super useful to a general audience (or perhaps only
useful to me :-) but the latest Swift 5 update made working with R
directly from Swift much, much easier than previously possible.

https://twitter.com/hrbrmstr/status/1344036731855769600?ref_src=twsrc%5Etfw
has a running example of the above code.

Cheers…

-boB

___
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 with R and Big Sur

[Bob Rudis]

 After a bit of git and google poking it seems this is happening to users
of MacVim (https://github.com/macvim-dev/macvim/issues/1114) and a few
other FOSS projects.

In various GH issues (like that one) the issue claims to be resolved by
using the latest Xcode & SDK but that’s not likely to be a solution for R
GUI (which I’m assuming you're using and where this error is coming up).

Some of the threads I saw made it seem like it was happening especially on
Touch Bar-equipped MacBook Pros (but that’s not confirmed).

When I try R GUI on Big Sur (on the new M1 Mini) — either just plain R
scripts or plotting — I do not see this, nor do I see this on my Intel
MacBook Pro (both are on the latest Big Sur beta and R 4.0.3).

On Dec 2, 2020 at 7:53:26 AM, Spencer Graves 
wrote:

>  I didn't get this with R 4.0.3 under macOS Big Sur 11.0.1 with "time
> R CMD build" / check.  I have not tried it under RStudio.
>
>
>  sg
>
>
> On 2020-12-02 05:01, Dr Eberhard W Lisse wrote:
>
> I don't get this in 4.0.3 (using the command line version of R) and I
>
> don't get this in RStudio 1.3.1093 either.  I use the homebrew versions
>
> without the R GUI even installed.
>
>
> I am sure more detail will be helpful to the developers.
>
>
> el
>
>
> On 02/12/2020 11:09, Maria-Angeles Casares-de-Cal via R-SIG-Mac wrote:
>
> > To those in charge of R for Mac OS X:
>
> >
>
> > I have installed the new Big Sur operating system and now I always get
>
> > a warning similar to:
>
> >
>
> > 2020-12-02 09:52:00.647 R[703:11786] Warning: Expected min height of
>
> > view: () to be less than
>
> > or equal to 30 but got a height of 32.00.  This error will be
>
> > logged once per view in violation.
>
> >
>
> > and the computer becomes very slow.
>
> >
>
> > Can I do something to fix it, or will we have to wait for an R update?
>
> >
>
> > Thank you very much for your attention.
>
> >
>
> > Sincerely,
>
> >
>
> > María-Ángeles Casares-de-Cal
>
> [...]
>
>
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] svn tarball

[Bob Rudis]

As an alternative, this:

https://github.com/r-devel/r-svn

is also kept current and has another advantage of being usable with git and 
running CI tests on PRs.

-boB

> On Aug 26, 2020, at 13:00, peter dalgaard  wrote:
> 
> Not dumb. 
> 
> Simon's usual style is that tarballs are installed at / and things end up 
> under /usr/local, using the procedure outlined at the bottom of
> 
> https://mac.r-project.org/libs/
> 
> but you should probably check with "tar tvfz" first. 
> 
> -pd
> 
> 
> 
>> On 26 Aug 2020, at 18:43 , Carl Witthoft  wrote:
>> 
>> Dumb question from someone who hasn't done any building in quite a while: 
>> recommended director to place the svn executable?
>> thanks
>> Carl
>> 
>> On 8/26/20 6:00 AM, r-sig-mac-requ...@r-project.org wrote:
>> 
>>>   1.  svn now available from the tools (Simon Urbanek)
>>> ntent-Type: text/plain; charset="us-ascii"
>>> If you want to build R from the svn repository you need svn (subversion). 
>>> Xcode 10 has removed svn so it is no loner available from Apple, we are 
>>> providing a binary (cmopatible with OS X 10.11 and higher) in
>>> https://mac.r-project.org/tools/
>>> (in "optional tools and libraries" at the bottom), direct link:
>>> https://mac.r-project.org/tools/subversion-1.14.0-darwin15.6.tar.gz
>>> It is a single-file signed, static build so has no dependencies and can be 
>>> run from anywhere.
>>> Cheers,
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> ___
> 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] Error compiling C++ code in R 4.0 on Mac OS X Catalina

[Bob Rudis]

Something is causing Rcpp to be unable to detect the presence of 
{RcppArmadillo}, which can be seen in the lack of the include for it in the 
snippet you posted on SO (FWIW that site has multiple trackers and I'm not 
really a fan of being made a product to try to answer a question):

clang++ 
  -mmacosx-version-min=10.13 \
  -std=gnu++11 \
  -I"/Library/Frameworks/R.framework/Resources/include" \
  -DNDEBUG \
  -I"/Library/Frameworks/R.framework/Packages/Rcpp/include" \
  -I"/Users/itpetersen/Desktop" \
  -I/usr/local/include \
  -fPIC -Wall -g -O2  -c helloworld.cpp -o helloworld.o


Can you re-run the sourceRcpp() call with `verbose = TRUE` and paste the output 
here?

Also, have you tried:

remove.packages(c("Rcpp", "RcppArmadillo"))
install.packages(c("Rcpp", "RcppArmadillo"))

and trying everything again in a `--vanilla` R session?

> On Aug 10, 2020, at 18:33, Isaac Petersen  wrote:
> 
> I'm trying to compile C++ code in R so I can install packages from source.
> I’m running R 4.0.2 on Mac OS X Catalina (10.15.6).  I receive an error
> when trying to compile C++ code in R.  I posted the full details of my
> problem on Stack Overflow here:
> https://stackoverflow.com/questions/63276265/error-compiling-c-code-in-r-4-0-on-mac-os-x-catalina?noredirect=1#comment112012438_63276265.
> The question was unfortunately marked as a duplicate because it is similar
> to another question, even though the answers to the "similar" question did
> not solve my problem.  One responder noted that
> "/usr/local/include/RcppArmadillo.h" was missing (even though I
> successfully installed the RcppArmadillo package).  Any help would be
> greatly appreciated.
> 
> Thanks very much in advance.
> -Isaac
> 
> ---
> Isaac T. Petersen, Ph.D.
> Assistant Professor
> Department of Psychological and Brain Sciences
> University of Iowa
> 175 Psychological and Brain Sciences Building
> Iowa City, IA 52242
> p: (319) 467-1014
> isaac-t-peter...@uiowa.edu
> https://psychology.uiowa.edu/developmental-psychopathology-lab
> 
>   [[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] No labels in plots - none of the solutions that I've come across have worked

[Bob Rudis]

What does the output of:

extrafont::font_import()
subset(extrafont::fonttable(), grepl("Arial", FontName))

say about Arial? (you may need to install.packages("extrafont"))

On Wed, Jun 17, 2020 at 2:00 AM J Greenbaum  wrote:
>
> Hi all,
>
> I'm having what appears to be a relatively common problem in R under macOS
> in that text is not displaying in my plots.  This used to work just fine
> for me, and still does on my other machines, except for my laptop (MBP
> 16).  The issue seemed to coincide with my upgrade to 10.15.5.
>
> When plotting, I get warnings similar to:
>
> no font could be found for family "Arial"
>
> I've tried every solution that I've come across on this issue including
> finding duplicate fonts in 'Font Book', ensuring they all validate
> properly, and I've even gone nuclear and completely reinstalled my OS!
> I've tried installing the official R package as well as the homebrew R
> package.  I've also validated it's not my user account by reproducing the
> issue under different accounts. Nothing works.
>
> I would love some help in tracking this issue down.  Any insight would be
> much appreciated.
>
> Thank you!
>
> -J
>
> [[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] Can't open files in 4.0 or 4.01

[Bob Rudis]

Are there any entries in Console.app that might help triage?

Have you tried creating a new user on your Mac and seeing if that account has 
issues performing the same tasks your user account is having?

Having said that, I just grabbed "Mac OS X GUI rev. 7843 for R 4.0.x" from 
mac.r-project.org (I never use R.app nor do I keep it installed unless testing 
something) and am running R 4.0.1 on latest Catalina beta — 10.15.6 Beta 
(19G36e) — and it crashes every time I try to open a .R file (crashlog 
https://paste.sr.ht/~hrbrmstr/9899f3a7f3c1724cc952b935c3fc39a47cac88ac)

> On Jun 7, 2020, at 16:22, Carl Witthoft  wrote:
> 
> 
> 
> 
> Hi,
> 2 weeks ago I installed R 4.0 on my new Catalina machine. Things seemed to be 
> working fine.
> Today I installed R 4.01, and now I can't open any FILE.r - no matter what 
> way I try, i.e. double-click the file, drag/drop, or open from the R GUI 
> menu,  R hangs with the beachball.
> I tried giving R full disk access and other privileges via Security settings; 
> no help.
> 
> So I deleted R 4.01 and reinstalled R 4.0, and dang if I no longer can open 
> files any more!  I've tried all the suggestions in the previous thread in 
> this mailing group; no help.
> 
> What else can I do, or delete, or uninstall, to at least get back to where I 
> was? Right now I'm basically DIW.
> -- 
> Carl Witthoft
> c...@witthoft.com
> resume: https://app.box.com/file/498153801347
> 
> ___
> 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] Problem with CHECK --as-cran on Catalina

[Bob Rudis]

Does it still do it if you build a tar.tgz archive and run it on that?

I could not dup your problem, but when I tried to run it on a couple
of my packages that work fine with tar.gz (I use Authors@R) in dir (`R
CMD check --as-cran .` or parent dir and specify the pkg dir) I get:

Required field missing or empty:
  ‘Author’

(running last R 4.0.1 beta before the release of R 4.0.1, latest
Catalina beta AND R 4.0.0 on ubuntu)

So, def something strange going on.

On Sat, Jun 6, 2020 at 12:47 PM Carl Witthoft  wrote:
>
> Hi,
> I recently upgraded to a new iMac w/ Catalina.  Something really strange
> is happening when I try to run "R CMD CHECK --as-cran  " .
> If I run it on various older packages that have previously passed the
> check, all is well.
>
> I am writing a new package, and here's the response I get:
>
>
> * using log directory ‘/Users/cgw/Rgames/fitConic.Rcheck’
> * using R version 4.0.0 (2020-04-24)
> * using platform: x86_64-apple-darwin17.0 (64-bit)
> * using session charset: UTF-8
> * using option ‘--as-cran’
> * checking for file ‘fitConic/DESCRIPTION’ ... OK
> * this is package ‘fitConic’ version ‘1.0’
> * checking CRAN incoming feasibility ...Error:  file './DESCRIPTION'
> does not exist
> Execution halted
>
>
> This happens whether I run R CMD CHECK  from the parent dirctory
> /Users/cgw/Rgames  or from the source directory /Users/cgw/Rgames/fitConic .
>
> I verified I can edit the DESCRIPTION file in my previous packages &
> still pass the check.  I even took one of those old DESCRIPTION files
> and put it into the fitConic directory, and changed only the "Package: "
> line  .
>
> I'm guessing that last error message is not telling me what actually
> went wrong, but I'm at a loss as to why this new package fails.  I've
> created a new directory and moved all my files (DESCRIPTION, NAMESPACE,
> and the R & man folders) over. No luck.
>
> Is this a hangup somewhere in R 4.0 for OSX, or is there something else
> going on?   (do I need, for example to do something to give XQuartz more
> permissions, or some other called app? )
>
> thanks
> --
> Carl Witthoft
> c...@witthoft.com
> resume: https://app.box.com/file/498153801347
>
> ___
> 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] Catalina Crashes R

[Bob Rudis]

On 10.15.5 Beta (the one after the GA folks might have),

   scatter3d(prestige ~ income + education, data=Duncan, id=list(n=3))

(the example)

works perfectly.

Did you reinstall XQuartz? Unfortunately, that is kind of "a thing"
one has to do after every x.y.z release of macOS if you care at all
abt stability these days.

On Mon, Jun 1, 2020 at 8:13 PM Spencer Graves
 wrote:
>
>I have 10.15.4, and I don't notice any serious problems.  I just
> did "install.packages('KernSmooth')" and "help(pac='KernSmooth')" to
> look at the DESCRIPTION file, without a problem.
>
>
>Spencer Graves
>
>
> On 2020-05-21 09:49, Joseph Vanterpool wrote:
> > Hello,
> >
> > Yesterday, I started using the John Hopkins course that includes R 
> > training. I currently have a Mac with Catalina (Version 10.15.4).
> >
> > For simple examples, they have you install and load KernSmooth to view the 
> > copyright date. The first time I tried this, the installation was fine, but 
> > loading didn’t work. I tried a second time and it worked.
> >
> > I noticed on the forum that other people had similar problems, though were 
> > further along in their use of R. Have these problems been resolved?
> >
> > Thanks,
> >
> > Joseph
> > ___
> > 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] R.app GUI 1.71 (7827) crashes on Catalina

[Bob Rudis]

Aye, I should have noted that Apple's `tccd` and entire TCC (privacy)
subsystem is super buggy/noisy. Enough of them that there are a fw
third-party apps like Taccy
(https://eclecticlight.co/taccy-signet-precize-alifix-utiutility-alisma/)
to help privacy-perms issues. The GUI code does not try to do things
`tccd` would balk at, and this particular sandbox error shows up in
many general apps/FOSS projects outside of R GUI.

On Mon, May 4, 2020 at 8:13 AM Hiroshi Hakoyama
 wrote:
>
> The sandbox error also happened for test2.R that can open without trouble.
> So, this might not be the critical error.
>
> I uploaded the two devices logs for test.R and test2.R:
>
> https://hako.space/R/devices_log_for_test_R.txt
> https://hako.space/R/devices_log_for_test2_R.txt
>
> Best regards,
>
> Hiroshi
>
>
>
>
> > 2020/05/04 20:29、Hiroshi Hakoyama のメール:
> >
> > Thank you for responses.
> >
> > I installed the debug build R.app GUI 1.71 (7834) to MacBook Air (2012, 4G 
> > RAM, Catalina 10.15.4), and double-clicked test.R. The result is the same 
> > GUI hang. The following is a part of the device log:
> >
> > ...
> > default   19:56:06.123133+0900R- 1 documents to open
> > default   19:56:06.123188+0900R- 
> > application:openFile:/Users/hako/Desktop/test.R called
> > default   19:56:06.123316+0900R- intial start, changing wd 
> > to pathname whic is /Users/hako/Desktop/
> > error 19:56:06.126663+0900tccd{ID: com.apple.sandboxd, PID[155], 
> > auid: 0, euid: 0, binary path: '/usr/libexec/sandboxd'} attempted to call 
> > TCCAccessRequest without the 
> > com.apple.private.tcc.manager.check-by-audit-token entitlement
> > default   19:56:06.127340+0900tccdPID[155] is checking access 
> > for target PID[655]
> > default   19:56:06.136847+0900tccd-[TCCDAccessIdentity 
> > staticCode]: static code for: identifier org.R-project.R, type: 0: 
> > 0x7fa62ad38b10 at /Applications/R.app
> > ...
> >
> > The error line seems to be similar with Brandon's cases.
> >
> >
> > Best regards,
> >
> >
> > Hiroshi
> >
> >
> >
> >
> >> 2020/05/02 11:18、Brandon Hurr のメール:
> >>
> >> I have a mac mini as well that does not show this crash. It's much
> >> beefier (6-core i7, 32 GB RAM probably not relevant).
> >> Here is the same boot up log with the same file and it does not crash R.
> >>
> >> https://gist.github.com/bhive01/2a48fa3e6fd70ae1b974184ad7b947ba#file-r-gui_pid4422_working_console-log
> >>
> >> I look at the transition where the two differ and the crash happens
> >> and the one that works is much shorter. At line 319 in the non-working
> >> MBA (PID 889) it "makes presenter" and then stops. Making presenter
> >> doesn't happen until line 4261 in the working file. Lots of parsing of
> >> the file is missing (4000 lines of it).
> >>
> >> B
> >>
> >> On Fri, May 1, 2020 at 6:48 PM Brandon Hurr  wrote:
> >>>
> >>> Thanks Bob.
> >>>
> >>> I did this and it did not fix it sadly.
> >>> I downloaded the Debug version of R-GUI and captured the following
> >>> after clicking on the same file (which did cause it to crash again)
> >>> Here is the console log for the R PID (889 in this instance) from
> >>> loading R to then clicking to load the same file (which froze my
> >>> system again):
> >>> https://gist.github.com/bhive01/5efa02237085c7a3ccf6d137e04f7c45
> >>> Here is the full Apple Crash Log that came up after I force quit R:
> >>> https://gist.github.com/bhive01/0eeb32d0a666f875e83440268b69aefd
> >>>
> >>> I hope this is helpful. Please let me know if I need to dig more and
> >>> recommendations for doing so.
> >>>
> >>> Thanks,
> >>> B
> >>>
> >>> On Fri, May 1, 2020 at 5:54 PM Bob Rudis  wrote:
> >>>>
> >>>> Suggestion: try adding R.app to "Full Disk Access" in the Privacy tab
> >>>> under Security & Privacy system preferences.
> >>>>
> >>>> I'm not experiencing these issues (just now when I tried it; I
> >>>> generally don't use R.app)
> >>>>
> >>>> On Fri, May 1, 2020 at 4:54 PM Brandon Hurr  
> >>>> wrote:
> >>>>>
> >>>>> I'm going to add to the pile on this one. It's hard to nail down
> >>>>> thou

Re: [R-SIG-Mac] R.app GUI 1.71 (7827) crashes on Catalina

[Bob Rudis]

I'll try to scrounge time today (but def have some Tue) to setup fresh
Catalina VM with 4GB memory and see if I can reproduce there and
capture some more logs.

On Mon, May 4, 2020 at 7:29 AM Hiroshi Hakoyama
 wrote:
>
> Thank you for responses.
>
> I installed the debug build R.app GUI 1.71 (7834) to MacBook Air (2012, 4G 
> RAM, Catalina 10.15.4), and double-clicked test.R. The result is the same GUI 
> hang. The following is a part of the device log:
>
> ...
> default 19:56:06.123133+0900R- 1 documents to open
> default 19:56:06.123188+0900R- 
> application:openFile:/Users/hako/Desktop/test.R called
> default 19:56:06.123316+0900R- intial start, changing wd to 
> pathname whic is /Users/hako/Desktop/
> error   19:56:06.126663+0900tccd{ID: com.apple.sandboxd, PID[155], 
> auid: 0, euid: 0, binary path: '/usr/libexec/sandboxd'} attempted to call 
> TCCAccessRequest without the 
> com.apple.private.tcc.manager.check-by-audit-token entitlement
> default 19:56:06.127340+0900tccdPID[155] is checking access for 
> target PID[655]
> default 19:56:06.136847+0900tccd-[TCCDAccessIdentity staticCode]: 
> static code for: identifier org.R-project.R, type: 0: 0x7fa62ad38b10 at 
> /Applications/R.app
> ...
>
> The error line seems to be similar with Brandon's cases.
>
>
> Best regards,
>
>
> Hiroshi
>
>
>
>
> > 2020/05/02 11:18、Brandon Hurr のメール:
> >
> > I have a mac mini as well that does not show this crash. It's much
> > beefier (6-core i7, 32 GB RAM probably not relevant).
> > Here is the same boot up log with the same file and it does not crash R.
> >
> > https://gist.github.com/bhive01/2a48fa3e6fd70ae1b974184ad7b947ba#file-r-gui_pid4422_working_console-log
> >
> > I look at the transition where the two differ and the crash happens
> > and the one that works is much shorter. At line 319 in the non-working
> > MBA (PID 889) it "makes presenter" and then stops. Making presenter
> > doesn't happen until line 4261 in the working file. Lots of parsing of
> > the file is missing (4000 lines of it).
> >
> > B
> >
> > On Fri, May 1, 2020 at 6:48 PM Brandon Hurr  wrote:
> >>
> >> Thanks Bob.
> >>
> >> I did this and it did not fix it sadly.
> >> I downloaded the Debug version of R-GUI and captured the following
> >> after clicking on the same file (which did cause it to crash again)
> >> Here is the console log for the R PID (889 in this instance) from
> >> loading R to then clicking to load the same file (which froze my
> >> system again):
> >> https://gist.github.com/bhive01/5efa02237085c7a3ccf6d137e04f7c45
> >> Here is the full Apple Crash Log that came up after I force quit R:
> >> https://gist.github.com/bhive01/0eeb32d0a666f875e83440268b69aefd
> >>
> >> I hope this is helpful. Please let me know if I need to dig more and
> >> recommendations for doing so.
> >>
> >> Thanks,
> >> B
> >>
> >> On Fri, May 1, 2020 at 5:54 PM Bob Rudis  wrote:
> >>>
> >>> Suggestion: try adding R.app to "Full Disk Access" in the Privacy tab
> >>> under Security & Privacy system preferences.
> >>>
> >>> I'm not experiencing these issues (just now when I tried it; I
> >>> generally don't use R.app)
> >>>
> >>> On Fri, May 1, 2020 at 4:54 PM Brandon Hurr  
> >>> wrote:
> >>>>
> >>>> I'm going to add to the pile on this one. It's hard to nail down
> >>>> though. I was able to load Hiroshi's test.R script after loading up
> >>>> R-GUI 7827 and just now 7832. I loaded it from multiple directories by
> >>>> clicking on it.
> >>>> That said, I've been having many issues locking up R-GUI on my 2019
> >>>> MBAir since upgrading to R4.0.0. I can click and load R-GUI with a
> >>>> script file, but if I want to load another script it gives me the
> >>>> colored pinwheel of death. Sometimes it will load up R-GUI, but then
> >>>> pinwheel of death on loading a lengthy script. I'm not sure the length
> >>>> is the issue.
> >>>>
> >>>> I played around with the console a bit and noticed these messages pop
> >>>> up when it locks up R:
> >>>> error13:49:54.173449-0700kernelSandbox: garcon(763)
> >>>> deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> >>>> standardisation/Database Converts/Conversion scr

Re: [R-SIG-Mac] incompatible lldb on mojave?

[Bob Rudis]

Can you provide a bit more info on the setup?

I ask b/c: (more below the snippet)

$ 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
Process 3834 launched:
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)

R version 4.0.0 RC (2020-04-21 r78267) -- "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.

> str(mtcars)
'data.frame':   32 obs. of  11 variables:
 $ mpg : num  21 21 22.8 21.4 18.7 18.1 14.3 24.4 22.8 19.2 ...
 $ cyl : num  6 6 4 6 8 6 8 4 4 6 ...
 $ disp: num  160 160 108 258 360 ...
 $ hp  : num  110 110 93 110 175 105 245 62 95 123 ...
 $ drat: num  3.9 3.9 3.85 3.08 3.15 2.76 3.21 3.69 3.92 3.92 ...
 $ wt  : num  2.62 2.88 2.32 3.21 3.44 ...
 $ qsec: num  16.5 17 18.6 19.4 17 ...
 $ vs  : num  0 0 1 1 0 1 0 1 1 1 ...
 $ am  : num  1 1 1 0 0 0 0 0 0 0 ...
 $ gear: num  4 4 4 3 3 3 3 4 4 4 ...
 $ carb: num  4 4 1 1 2 1 4 2 2 4 ...
>

I have full Xcode installed and updated to latest (I'm on developer betas).

$ lldb --version
lldb-1103.0.17
Apple Swift version 5.2 (swiftlang-1103.0.22 clang-1103.0.22)

I'm also on a more restrictive OS (Catalina).

Of note: macOS prompted me for permission to use lldb.

-boB

On Sat, May 2, 2020 at 11:26 PM 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  >>
> >
> > 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:
> >
> > .
> >
> > Find the GDB manual and other documentation resources online at:
> >
> > .
> >
> > 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
> >
> > --
> > 

Re: [R-SIG-Mac] R.app GUI 1.71 (7827) crashes on Catalina

[Bob Rudis]

Also, can you try running with the Debug build and poke around for
contextual errors if you still get errors?

On Fri, May 1, 2020 at 8:54 PM Bob Rudis  wrote:
>
> Suggestion: try adding R.app to "Full Disk Access" in the Privacy tab
> under Security & Privacy system preferences.
>
> I'm not experiencing these issues (just now when I tried it; I
> generally don't use R.app)
>
> On Fri, May 1, 2020 at 4:54 PM Brandon Hurr  wrote:
> >
> > I'm going to add to the pile on this one. It's hard to nail down
> > though. I was able to load Hiroshi's test.R script after loading up
> > R-GUI 7827 and just now 7832. I loaded it from multiple directories by
> > clicking on it.
> > That said, I've been having many issues locking up R-GUI on my 2019
> > MBAir since upgrading to R4.0.0. I can click and load R-GUI with a
> > script file, but if I want to load another script it gives me the
> > colored pinwheel of death. Sometimes it will load up R-GUI, but then
> > pinwheel of death on loading a lengthy script. I'm not sure the length
> > is the issue.
> >
> > I played around with the console a bit and noticed these messages pop
> > up when it locks up R:
> > error13:49:54.173449-0700kernelSandbox: garcon(763)
> > deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> > standardisation/Database Converts/Conversion script DEV.R
> > error13:49:54.243397-0700kernelSandbox: garcon(763)
> > deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> > standardisation/Database Converts
> > error13:49:54.312989-0700kernelSandbox: garcon(763)
> > deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> > standardisation
> > error13:49:54.344345-0700kernelSandbox: garcon(763)
> > deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)
> >
> > A rough guess here is that the sandboxing isn't working right (or is?)
> > and is blocking access of R-GUI to the file which then locks up
> > because it's waiting for data?
> >
> > Anyone else seeing this behavior and have a better idea how to pin it down?
> >
> > Thanks,
> > B
> >
> >
> > On Thu, Apr 30, 2020 at 6:07 AM Hiroshi Hakoyama
> >  wrote:
> > >
> > > Dear All,
> > >
> > > Environment:
> > > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> > > [R.app GUI 1.71 (7827) x86_64-apple-darwin17.0]
> > > macOS: Mojave and Catalina
> > > Removed file for the test: .Rapp.history
> > >
> > > Description:
> > > R.app crashes when a large file (e.g., test.R) is double-clicked on 
> > > Mojave and Catalina. The crash does not occur on High Sierra. Small 
> > > source files (e.g., test2.R) do not cause the crash on Mojave and 
> > > Catalina.
> > >
> > > How-To-Repeat:
> > > Double-click test.R (or open test.R using R.app) on Catalina or Mojave.
> > >
> > > Fix:
> > > unknown
> > >
> > > Crash Report is too large to paste to the email.
> > >
> > >
> > > Best regards,
> > >
> > > Hiroshi Hakoyama
> > > Nagano University
> > >
> > > test.R
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ###
> > > ##

Re: [R-SIG-Mac] R.app GUI 1.71 (7827) crashes on Catalina

[Bob Rudis]

Suggestion: try adding R.app to "Full Disk Access" in the Privacy tab
under Security & Privacy system preferences.

I'm not experiencing these issues (just now when I tried it; I
generally don't use R.app)

On Fri, May 1, 2020 at 4:54 PM Brandon Hurr  wrote:
>
> I'm going to add to the pile on this one. It's hard to nail down
> though. I was able to load Hiroshi's test.R script after loading up
> R-GUI 7827 and just now 7832. I loaded it from multiple directories by
> clicking on it.
> That said, I've been having many issues locking up R-GUI on my 2019
> MBAir since upgrading to R4.0.0. I can click and load R-GUI with a
> script file, but if I want to load another script it gives me the
> colored pinwheel of death. Sometimes it will load up R-GUI, but then
> pinwheel of death on loading a lengthy script. I'm not sure the length
> is the issue.
>
> I played around with the console a bit and noticed these messages pop
> up when it locks up R:
> error13:49:54.173449-0700kernelSandbox: garcon(763)
> deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> standardisation/Database Converts/Conversion script DEV.R
> error13:49:54.243397-0700kernelSandbox: garcon(763)
> deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> standardisation/Database Converts
> error13:49:54.312989-0700kernelSandbox: garcon(763)
> deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)/Data
> standardisation
> error13:49:54.344345-0700kernelSandbox: garcon(763)
> deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)
>
> A rough guess here is that the sandboxing isn't working right (or is?)
> and is blocking access of R-GUI to the file which then locks up
> because it's waiting for data?
>
> Anyone else seeing this behavior and have a better idea how to pin it down?
>
> Thanks,
> B
>
>
> On Thu, Apr 30, 2020 at 6:07 AM Hiroshi Hakoyama
>  wrote:
> >
> > Dear All,
> >
> > Environment:
> > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> > [R.app GUI 1.71 (7827) x86_64-apple-darwin17.0]
> > macOS: Mojave and Catalina
> > Removed file for the test: .Rapp.history
> >
> > Description:
> > R.app crashes when a large file (e.g., test.R) is double-clicked on Mojave 
> > and Catalina. The crash does not occur on High Sierra. Small source files 
> > (e.g., test2.R) do not cause the crash on Mojave and Catalina.
> >
> > How-To-Repeat:
> > Double-click test.R (or open test.R using R.app) on Catalina or Mojave.
> >
> > Fix:
> > unknown
> >
> > Crash Report is too large to paste to the email.
> >
> >
> > Best regards,
> >
> > Hiroshi Hakoyama
> > Nagano University
> >
> > test.R
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > ###
> > x <- rnorm(10)
> > y <- rnorm(10)
> > hist(x)
> > hist(y)
> >
> > test2.R
> > x <- rnorm(10)
> > y <- rnorm(10)
> > hist(x)
> > hist(y)
> >
> > system.log
> > Apr 30 20:54:40 ec7 R[1147]: assertion failed: 19E287: libxpc.dylib + 92807 
> > [32B0E31E-9DA3-328B-A962-BC9591B93537]: 0x89
> > ___
> > 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] Strange library problem with 4.0

[Bob Rudis]

Can you try it with the "tar" method and see if it has the same behavior?

I use the gzip'd tar files and have multiple versions running on
multiple Macs and .libPaths() is not exhibiting that behavior.

On Sat, Apr 25, 2020 at 5:47 AM Erich Subscriptions
 wrote:
>
> I installed R 4.0 on 2 machines, an iMac and a Macbook Pro.
> Before that, I installed RSwitch and did what the site tells to do:
> sudo pkgutil --forget org.r-project.R.el-capitan.fw.pkg \
>  --forget org.r-project.x86_64.tcltk.x11 \
>  --forget org.r-project.x86_64.texinfo \
>  --forget org.r-project.R.el-capitan.GUI.pkg
> so that the 3.6 and 4.0 can coexist.
>
> I always keep the additionally installed packages in
> ~/Library/R
>
> After installing R 4.0 I therefore have
> ~/Library/R/3.6/library and ~/Library/R/4.0/library
>
> On the iMac, I can switch between the two versions and R will put the 
> appropriate folder
> in .libPaths()
>
> On the Macbook, however, when I run R 4.0
> both these folders are in .libPaths().
> This does not happen when I run R 3.6.
>
> How can this problem be solved?
>
> Erich
>
> ___
> 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] Please test R 4.0.0 pre-releases!

[Bob Rudis]

Hey Simon!

At the bottom of https://mac.r-project.org/libs-4/ is:

curl -O 
http://mac.R_project.org/libs-4/pkgconfig-0.28-darwin.17-x86_64.tar.gz

While most folks will figure it out, it should be:

curl -O 
http://mac.R-project.org/libs-4/pkgconfig-0.28-darwin.17-x86_64.tar.gz

(dash instead of underline).

-boB


> On Apr 1, 2020, at 09:30, Balamuta, James Joseph  
> wrote:
> 
> Simon,
> 
> Thanks for the overview! A few quick questions:
> 
> 1. Compiler-wise, the external clang compiler requirement was removed and, 
> so, there is no guarantee of OpenMP on macOS again? 
> 2. Why was 10.13 chosen as the oldest system instead of 10.14 given the new 
> push for increased security by Apple?
> 3. How likely is the oldest system requirement to be bumped in a patch 
> release? 
> 
> Also, if you need help with mac-builder, Travis, or GitHub Actions, I'm more 
> than happy to help! 
> 
> Best,
> 
> JJB
> 
> On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of Simon Urbanek" 
>  
> wrote:
> 
>Dear Mac users,
> 
>R 4.0.0 will be using an entirely new toolchain, entirely new build system 
> on entirely new macOS version and hardware. Therefore I would like to ask you 
> kindly to test the binaries from
> 
>https://mac.R-project.org
> 
>before the release as much as you can. Raising any issues after the 
> release is too late! So please, please, test the pre-releases. Report any 
> issues either directly to me or this mailing list.
> 
>The nightly builds are signed, but not necessarily notarized. However, the 
> build fulfils Apple's conditions and is known to pass notarization (in fact 
> the the package available for download today is actually notarized) so it 
> should be a good test for the release which will be notarized and should work 
> on Catalina.
> 
>For those that want to replicate our setup - technical details: we are now 
> building with macOS 10.13 (High Sierra) as target (i.e. the oldest supported 
> system), regular Apple Xcode/command line tools and GNU Fortran 8.2. R builds 
> are running on macOS 10.15 (Catalina) with Xcode 11.4 using macOS 10.13 
> target. Packages are built on macOS 10.13 VMs with just Apple command line 
> tools (this should make it easy to replicate the setup using Travis, for 
> example). All 3rd party libraries that CRAN uses are available in 
> http://mac.r-project.org/libs-4/
> 
>The new R build system is in
>https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4
>Packages build system has not changed and is in
>https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages
> 
>We also plan to have a mac-builder available with similar function as the 
> win-builder where pre-submission tests can be performed and potentially a 
> Travis template.
> 
>Please test R pre-releases and provide feedback!
> 
>Thanks,
>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

Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!

[Bob Rudis]

I shall pile on with an additional offer of assistance, Simon and a huge #ty 
for this and all the work you do.

> On Apr 1, 2020, at 09:30, Balamuta, James Joseph  
> wrote:
> 
> Simon,
> 
> Thanks for the overview! A few quick questions:
> 
> 1. Compiler-wise, the external clang compiler requirement was removed and, 
> so, there is no guarantee of OpenMP on macOS again? 
> 2. Why was 10.13 chosen as the oldest system instead of 10.14 given the new 
> push for increased security by Apple?
> 3. How likely is the oldest system requirement to be bumped in a patch 
> release? 
> 
> Also, if you need help with mac-builder, Travis, or GitHub Actions, I'm more 
> than happy to help! 
> 
> Best,
> 
> JJB
> 
> On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of Simon Urbanek" 
>  
> wrote:
> 
>Dear Mac users,
> 
>R 4.0.0 will be using an entirely new toolchain, entirely new build system 
> on entirely new macOS version and hardware. Therefore I would like to ask you 
> kindly to test the binaries from
> 
>https://mac.R-project.org
> 
>before the release as much as you can. Raising any issues after the 
> release is too late! So please, please, test the pre-releases. Report any 
> issues either directly to me or this mailing list.
> 
>The nightly builds are signed, but not necessarily notarized. However, the 
> build fulfils Apple's conditions and is known to pass notarization (in fact 
> the the package available for download today is actually notarized) so it 
> should be a good test for the release which will be notarized and should work 
> on Catalina.
> 
>For those that want to replicate our setup - technical details: we are now 
> building with macOS 10.13 (High Sierra) as target (i.e. the oldest supported 
> system), regular Apple Xcode/command line tools and GNU Fortran 8.2. R builds 
> are running on macOS 10.15 (Catalina) with Xcode 11.4 using macOS 10.13 
> target. Packages are built on macOS 10.13 VMs with just Apple command line 
> tools (this should make it easy to replicate the setup using Travis, for 
> example). All 3rd party libraries that CRAN uses are available in 
> http://mac.r-project.org/libs-4/
> 
>The new R build system is in
>https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4
>Packages build system has not changed and is in
>https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages
> 
>We also plan to have a mac-builder available with similar function as the 
> win-builder where pre-submission tests can be performed and potentially a 
> Travis template.
> 
>Please test R pre-releases and provide feedback!
> 
>Thanks,
>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] contrib/3.5 and contrib/3.6 empty

[Bob Rudis]

Simon (et al),

FYI Ref: https://twitter.com/bearloga/status/1243159479492972545?s=20

and also my confirmation that bin/macosx/el-capitan/contrib/3.4 is the only 3.x 
with binaries in it after checking home CRAN mirror.

-BoB
___
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-latest.pkg link returning a 403 Forbidden error

[Bob Rudis]

Just a list FYI I'm keeping the status site up 
(https://rud.is/mac-r-project-links/) but since the current, remaining broken 
links aren't getting fixed I'm disabling Pushover notifications to me so I 
won't be able to proactively notify here if more links go bad.

> On Feb 21, 2020, at 11:02, Bob Rudis  wrote:
> 
> Hey Simon (et al),
> 
> I setup a 2x daily link checker job for mac.r-project.org. It outputs tabular 
> results to https://rud.is/mac-r-project-links/ (timestamp at top is when the 
> job ran). One table is for HTTP HEAD results and the other is for HTTPS HEAD 
> results since the server doesn't auto-upgrade HTTP to HTTPS which could mean 
> different status codes depending the underlying config.
> 
> It's also configured to send me a pushover notification for anything but 200 
> return status code an I'll post here or privately when you give me the 
> go-ahead to do that (since it cld take a bit to fix the below :-).
> 
> Right now, the following links have non-200 status codes:
> 
> - 404 
> http://mac.r-project.org/mavericks/R-3.4-branch/R-3.4-branch-mavericks-signed.pkg
> - 404 http://mac.r-project.org/RSwitch-1.1.dmg
> - 404 http://mac.r-project.org/RSwitch-1.2.tar.gz
> - 404 http://mac.r-project.org/RSwitch-1.1.tar.gz
> - 403 
> http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
> 
> Lemme know if I can do any more monitoring/alerting for the site.
> 
> -boB
> 
>> On Feb 21, 2020, at 09:12, Patrick Schratz  wrote:
>> 
>> Simon, sorry I was wrong with the version.
>> In fact, I am getting a 403 with the R-3.6 branch. Other branches work fine.
>> 
>> curl -Osv 
>> http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
>>   I
>> * Trying 184.172.231.50...
>> * TCP_NODELAY set
>> * Connected to mac.r-project.org (184.172.231.50) port 80 (#0)
>>> GET /el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz 
>>> HTTP/1.1
>>> Host: mac.r-project.org
>>> User-Agent: curl/7.64.1
>>> Accept: */*
>>> 
>> < HTTP/1.1 403 Forbidden
>> < Date: Fri, 21 Feb 2020 14:08:51 GMT
>> < Server: Apache
>> < Content-Length: 266
>> < Content-Type: text/html; charset=iso-8859-1
>> <
>> { [266 bytes data]
>> * Connection #0 to host mac.r-project.org left intact
>> * Closing connection 0
>> 
>> Can anyone reproduce this or is this really on my side? If you, any hints on 
>> resolving this?
>> On 20. Feb 2020, 20:36 +0100, Simon Urbanek , 
>> wrote:
>>> Patrick,
>>> 
>>> it works just fine for me:
>>> 
>>> $ curl -s -v -o /dev/null https://mac.r-project.org/bin/macosx/R-latest.pkg
>>> * Trying 184.172.231.50...
>>> * TCP_NODELAY set
>>> * Connected to mac.r-project.org (184.172.231.50) port 443 (#0)
>>> * ALPN, offering h2
>>> * ALPN, offering http/1.1
>>> * Cipher selection: 
>>> ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
>>> * successfully set certificate verify locations:
>>> [...]
>>> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
>>> * ALPN, server accepted to use http/1.1
>>> * Server certificate:
>>> * subject: CN=mac.r-project.org
>>> * start date: Jan 26 18:55:18 2020 GMT
>>> * expire date: Apr 25 18:55:18 2020 GMT
>>> * subjectAltName: host "mac.r-project.org" matched cert's 
>>> "mac.r-project.org"
>>> * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
>>> * SSL certificate verify ok.
>>>> GET /bin/macosx/R-latest.pkg HTTP/1.1
>>>> Host: mac.r-project.org
>>>> User-Agent: curl/7.54.0
>>>> Accept: */*
>>>> 
>>> < HTTP/1.1 200 OK
>>> < Date: Thu, 20 Feb 2020 19:31:51 GMT
>>> < Server: Apache
>>> < Last-Modified: Sun, 15 Dec 2019 14:09:32 GMT
>>> < ETag: "4d4a72f-599bea4d7df00"
>>> < Accept-Ranges: bytes
>>> < Content-Length: 81045295
>>> <
>>> 
>>> Please make sure you clear your caches and try directly without proxies.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
>>> 
>>>> On 20/02/2020, at 9:41 PM, Patrick Schratz  
>>>> wrote:
>>>> 
>>>> @Simon
>>>> 
>>>> As of today the link still returns a 403 - other R versions work.
>>>> Could you have a look? Especially because the Travis CI runner by Jim 
>>>> relies on it, this is som

Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error

[Bob Rudis]

Hey Simon (et al),

I setup a 2x daily link checker job for mac.r-project.org. It outputs tabular 
results to https://rud.is/mac-r-project-links/ (timestamp at top is when the 
job ran). One table is for HTTP HEAD results and the other is for HTTPS HEAD 
results since the server doesn't auto-upgrade HTTP to HTTPS which could mean 
different status codes depending the underlying config.

It's also configured to send me a pushover notification for anything but 200 
return status code an I'll post here or privately when you give me the go-ahead 
to do that (since it cld take a bit to fix the below :-).

Right now, the following links have non-200 status codes:

- 404 
http://mac.r-project.org/mavericks/R-3.4-branch/R-3.4-branch-mavericks-signed.pkg
- 404 http://mac.r-project.org/RSwitch-1.1.dmg
- 404 http://mac.r-project.org/RSwitch-1.2.tar.gz
- 404 http://mac.r-project.org/RSwitch-1.1.tar.gz
- 403 
http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz

Lemme know if I can do any more monitoring/alerting for the site.

-boB

> On Feb 21, 2020, at 09:12, Patrick Schratz  wrote:
> 
> Simon, sorry I was wrong with the version.
> In fact, I am getting a 403 with the R-3.6 branch. Other branches work fine.
> 
> curl -Osv 
> http://mac.r-project.org/el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz
>   I
> * Trying 184.172.231.50...
> * TCP_NODELAY set
> * Connected to mac.r-project.org (184.172.231.50) port 80 (#0)
>> GET /el-capitan/R-3.6-branch/R-3.6-branch-el-capitan-sa-x86_64.tar.gz 
>> HTTP/1.1
>> Host: mac.r-project.org
>> User-Agent: curl/7.64.1
>> Accept: */*
>> 
> < HTTP/1.1 403 Forbidden
> < Date: Fri, 21 Feb 2020 14:08:51 GMT
> < Server: Apache
> < Content-Length: 266
> < Content-Type: text/html; charset=iso-8859-1
> <
> { [266 bytes data]
> * Connection #0 to host mac.r-project.org left intact
> * Closing connection 0
> 
> Can anyone reproduce this or is this really on my side? If you, any hints on 
> resolving this?
> On 20. Feb 2020, 20:36 +0100, Simon Urbanek , 
> wrote:
>> Patrick,
>> 
>> it works just fine for me:
>> 
>> $ curl -s -v -o /dev/null https://mac.r-project.org/bin/macosx/R-latest.pkg
>> * Trying 184.172.231.50...
>> * TCP_NODELAY set
>> * Connected to mac.r-project.org (184.172.231.50) port 443 (#0)
>> * ALPN, offering h2
>> * ALPN, offering http/1.1
>> * Cipher selection: 
>> ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
>> * successfully set certificate verify locations:
>> [...]
>> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
>> * ALPN, server accepted to use http/1.1
>> * Server certificate:
>> * subject: CN=mac.r-project.org
>> * start date: Jan 26 18:55:18 2020 GMT
>> * expire date: Apr 25 18:55:18 2020 GMT
>> * subjectAltName: host "mac.r-project.org" matched cert's "mac.r-project.org"
>> * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
>> * SSL certificate verify ok.
>>> GET /bin/macosx/R-latest.pkg HTTP/1.1
>>> Host: mac.r-project.org
>>> User-Agent: curl/7.54.0
>>> Accept: */*
>>> 
>> < HTTP/1.1 200 OK
>> < Date: Thu, 20 Feb 2020 19:31:51 GMT
>> < Server: Apache
>> < Last-Modified: Sun, 15 Dec 2019 14:09:32 GMT
>> < ETag: "4d4a72f-599bea4d7df00"
>> < Accept-Ranges: bytes
>> < Content-Length: 81045295
>> <
>> 
>> Please make sure you clear your caches and try directly without proxies.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> On 20/02/2020, at 9:41 PM, Patrick Schratz  
>>> wrote:
>>> 
>>> @Simon
>>> 
>>> As of today the link still returns a 403 - other R versions work.
>>> Could you have a look? Especially because the Travis CI runner by Jim 
>>> relies on it, this is somewhat pressing.
>>> 
>>> Thanks.
>>> On 18. Feb 2020, 07:43 +0100, Matthias Krawutschke 
>>> , wrote:
 Dear Simon,
 
 thank you so much.
 If I want to download the latest R-package with this link - i´ve got the 
 cryptic signs in the window, but not the file ☹
 
 Best regars….
 
 
 
 Matthias Krawutschke, Dipl. Inf.
 
 Universität Potsdam
 ZIM - Zentrum für Informationstechnologie und Medienmanagement
 Team High-Performance-Computing on Cluster - Environment
 
 Campus Am Neuen Palais: Am Neuen Palais 10 | 14469 Potsdam
 Tel: +49 331 977-, Fax: +49 331 977-1750
 
 Internet: https://www.uni-potsdam.de/de/zim/angebote-loesungen/hpc.html
 
 
 -Ursprüngliche Nachricht-
 Von: R-SIG-Mac  Im Auftrag von Simon 
 Urbanek
 Gesendet: Freitag, 14. Februar 2020 19:15
 An: Jim Hester 
 Cc: r-sig-mac@r-project.org
 Betreff: Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
 
 Thanks, should be fixed now (adding index removed symlink following 
 permission).
 Simon
 
 
> On Feb 15, 2020, at 4:50 AM, Jim Hester  wrote:
> 
> The link https://mac.r-project.org/bin/macosx/R-latest.pkg which
> previously served the latest version of R is now returning a 403. 

Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error

[Bob Rudis]

Aye. It's working fine from more than a few vantage points I've tested
it from via personal internet endpoints and work systems.

I've setup a daily 0500 ET cron job to do a HEAD of said URL and
output a slice of the {httr} response object as JSON to:
https://rud.is/dl/r-latest.json in the event other folks have issues
and need a validation point from a third party.

I've also got a local (not internet-facing) script that monitors the
mirror status (separate from what CRAN does as it's just looking for
last-modified date of src/contrib/PACKAGES,
bin/windows/contrib/3.6/PACKAGES, and
bin/macosx/el-capitan/contrib/3.6/PACKAGES on all HTTPS CRAN mirrors).
It's not internet-facing since I use it to check my own internal CRAN
mirror but I can also make a public JSON endpoint for it as well if
that wld be helpful for folks.

-Bob

On Thu, Feb 20, 2020 at 2:36 PM Simon Urbanek
 wrote:
>
> Patrick,
>
> it works just fine for me:
>
> $ curl -s -v -o /dev/null https://mac.r-project.org/bin/macosx/R-latest.pkg
> *   Trying 184.172.231.50...
> * TCP_NODELAY set
> * Connected to mac.r-project.org (184.172.231.50) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> * successfully set certificate verify locations:
> [...]
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> * ALPN, server accepted to use http/1.1
> * Server certificate:
> *  subject: CN=mac.r-project.org
> *  start date: Jan 26 18:55:18 2020 GMT
> *  expire date: Apr 25 18:55:18 2020 GMT
> *  subjectAltName: host "mac.r-project.org" matched cert's "mac.r-project.org"
> *  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
> *  SSL certificate verify ok.
> > GET /bin/macosx/R-latest.pkg HTTP/1.1
> > Host: mac.r-project.org
> > User-Agent: curl/7.54.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Thu, 20 Feb 2020 19:31:51 GMT
> < Server: Apache
> < Last-Modified: Sun, 15 Dec 2019 14:09:32 GMT
> < ETag: "4d4a72f-599bea4d7df00"
> < Accept-Ranges: bytes
> < Content-Length: 81045295
> <
>
> Please make sure you clear your caches and try directly without proxies.
>
> Cheers,
> Simon
>
>
>
> > On 20/02/2020, at 9:41 PM, Patrick Schratz  
> > wrote:
> >
> > @Simon
> >
> > As of today the link still returns a 403 - other R versions work.
> > Could you have a look? Especially because the Travis CI runner by Jim 
> > relies on it, this is somewhat pressing.
> >
> > Thanks.
> > On 18. Feb 2020, 07:43 +0100, Matthias Krawutschke 
> > , wrote:
> >> Dear Simon,
> >>
> >> thank you so much.
> >> If I want to download the latest R-package with this link - i´ve got the 
> >> cryptic signs in the window, but not the file ☹
> >>
> >> Best regars….
> >>
> >>
> >>
> >> Matthias Krawutschke, Dipl. Inf.
> >>
> >> Universität Potsdam
> >> ZIM - Zentrum für Informationstechnologie und Medienmanagement
> >> Team High-Performance-Computing on Cluster - Environment
> >>
> >> Campus Am Neuen Palais: Am Neuen Palais 10 | 14469 Potsdam
> >> Tel: +49 331 977-, Fax: +49 331 977-1750
> >>
> >> Internet: https://www.uni-potsdam.de/de/zim/angebote-loesungen/hpc.html
> >>
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: R-SIG-Mac  Im Auftrag von Simon 
> >> Urbanek
> >> Gesendet: Freitag, 14. Februar 2020 19:15
> >> An: Jim Hester 
> >> Cc: r-sig-mac@r-project.org
> >> Betreff: Re: [R-SIG-Mac] R-latest.pkg link returning a 403 Forbidden error
> >>
> >> Thanks, should be fixed now (adding index removed symlink following 
> >> permission).
> >> Simon
> >>
> >>
> >>> On Feb 15, 2020, at 4:50 AM, Jim Hester  wrote:
> >>>
> >>> The link https://mac.r-project.org/bin/macosx/R-latest.pkg which
> >>> previously served the latest version of R is now returning a 403. Is
> >>> this an intentional change, or is it an unintentional? This link is
> >>> used by the Travis-CI build scripts for macOS, so if the link is no
> >>> longer valid we will need to update the script.
> >>>
> >>> Thanks,
> >>>
> >>> Jim
> >>>
> >>
> >> ___
> >> 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
> >
> >   [[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] mac.r-project.org links are broken

[Bob Rudis]

ARGH. It also looks like a standard wget mirroring + rewrite command
isn't dealing with everything, but /src/ and /libs/ are both intact.
I'll tweak the process this week so everything gets covered.

On Sun, Jan 26, 2020 at 8:10 PM Bob Rudis  wrote:
>
> FWIW I've started a daily mirror process (mirror URL =
> https://rud.is/rmac/mac.r-project.org/) and also setup certificate &
> uptime monitoring for the main site so there'll be a bit more advance
> notice in the future.
>
> I need to add a couple checks for this particular situation (to the
> mirroring to avoid it clobberin the mirror) but it'll be a backup in a
> pinch.
>
> -boB
>
> On Sun, Jan 26, 2020 at 3:12 PM David Winsemius  
> wrote:
> >
> >
> > On 1/25/20 2:05 PM, Jonathon Love wrote:
> > > in the interim - does anyone know if this content is mirrored somewhere?
> >
> >
> > They appear functional. Have you checked recently?
> >
> >
> > --
> >
> > David
> >
> > >
> > > with thanks
> > >
> > >
> > > On 26/1/20 05:31, peter dalgaard wrote:
> > >> Yes, they are on a plane to New Zealand... (more or less, anyway)
> > >>
> > >> Expect things to get tidied up during next week.
> > >>
> > >> -pd
> > >>
> > >>> On 25 Jan 2020, at 12:08 , Jonathon Love  wrote:
> > >>>
> > >>> hi,
> > >>>
> > >>> in case no-one had noticed yet, the following links are broken:
> > >>>
> > >>> http://mac.r-project.org/src/
> > >>>
> > >>> http://mac.r-project.org/libs/
> > >>>
> > >>> as linked from:
> > >>>
> > >>> https://cran.r-project.org/bin/macosx/tools/
> > >>>
> > >>> earlier today, the SSL on mac.r-project.org was broken too, but that
> > >>> appears to be working now.
> > >>>
> > >>> cheers
> > >>>
> > >>> jonathon
> > >>>
> > >>> ___
> > >>> 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] mac.r-project.org links are broken

[Bob Rudis]

FWIW I've started a daily mirror process (mirror URL =
https://rud.is/rmac/mac.r-project.org/) and also setup certificate &
uptime monitoring for the main site so there'll be a bit more advance
notice in the future.

I need to add a couple checks for this particular situation (to the
mirroring to avoid it clobberin the mirror) but it'll be a backup in a
pinch.

-boB

On Sun, Jan 26, 2020 at 3:12 PM David Winsemius  wrote:
>
>
> On 1/25/20 2:05 PM, Jonathon Love wrote:
> > in the interim - does anyone know if this content is mirrored somewhere?
>
>
> They appear functional. Have you checked recently?
>
>
> --
>
> David
>
> >
> > with thanks
> >
> >
> > On 26/1/20 05:31, peter dalgaard wrote:
> >> Yes, they are on a plane to New Zealand... (more or less, anyway)
> >>
> >> Expect things to get tidied up during next week.
> >>
> >> -pd
> >>
> >>> On 25 Jan 2020, at 12:08 , Jonathon Love  wrote:
> >>>
> >>> hi,
> >>>
> >>> in case no-one had noticed yet, the following links are broken:
> >>>
> >>> http://mac.r-project.org/src/
> >>>
> >>> http://mac.r-project.org/libs/
> >>>
> >>> as linked from:
> >>>
> >>> https://cran.r-project.org/bin/macosx/tools/
> >>>
> >>> earlier today, the SSL on mac.r-project.org was broken too, but that
> >>> appears to be working now.
> >>>
> >>> cheers
> >>>
> >>> jonathon
> >>>
> >>> ___
> >>> 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] Finding "bash" and "mv" on my hard drive?

[Bob Rudis]

R does not ship bash or bin with the program distribution on macOS. It
uses the ones that come along for the ride with the system (which will
be interesting when Apple removes bash completely in 10.16).

If you've used MacPorts or Homebrew, you may have installed version of
those shells/tools there which R is picking up.

This:

sapply(c("bash", "mv"), Sys.which)

should tell you where R is picking up those binaries.

-boB

On Fri, Jan 17, 2020 at 6:01 PM Spencer Graves
 wrote:
>
> Hello:
>
>
>How can I find the version of "bash" and "mv" that are used by "R
> CMD check" under macOS 10.15.2 Catalina?
>
>
>I ask, because my "Bitdefender for Mac" has been interrupting "R
> CMD check" for a couple of years now, saying, "Bitdefender Safe Files
> blocked a new process, bash, from accessing your protected files."  Each
> time it happens, Bitdefender allows me to tell it to "Remember this
> action:  For 5 minutes" or "For this time only" or to "Keep blocking".
> Their "Safe Files" feature allows me to give access to certain
> applications.  I've already "allowed" 36 different applications using
> that feature, including "/bin/bash", "/bin/mv",
> "/Library/Frameworks/R.framework/Versions/3.6/Resources/exec/R", and two
> different versions of "git".  I'm not sure, but I believe that "R CMD
> check" uses versions of "bash" and "mv" different from "/bin/bash" and
> "/bin/mv".
>
>
>Thanks,
>Spencer Graves
>
> ___
> 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] damned Catalina

[Bob Rudis]

Something else changed on your system as Catalina does no domain/IP/URL 
blocking without user-intervention and those repo URLs work fine on all my 
(many) Catalina systems.

What else changed after you did the Catalina install?

There's a great deal wrong with Catalina, this is not one of those things.

> On Dec 18, 2019, at 10:43, peter dalgaard  wrote:
> 
> Hmm, my best guess is that file downloads are failing somehow. It's not like, 
> e.g.,
> 
> https://cloud.r-project.org/bin/macosx/el-capitan/contrib/3.6/PACKAGES.gz
> 
> is not on the website. 
> 
> Time to get scientific: Try putting a debug(download.file) and/or 
> debug(available.packages), retry the install (or maybe just do 
> available.packages(repos=)), and single-step through the call to see 
> where it goes wrong. One possibility is that you don't have write permission 
> for the directory that it wants to download into, so figure out what the 
> exact target is.
> 
> -pd
> 
> 
>> On 18 Dec 2019, at 16:05 , bruno apolloni  wrote:
>> 
>> Thanks for the clarification. I did it, but with the same result
>> 
>>> install.packages("regtools", repo = "https://cloud.r-project.org;)
>> Installing package into ‘/Users/blapo_nuovo/Library/R/3.6/library’
>> Warning: unable to access index for repository 
>> https://cloud.r-project.org/src/contrib:
>> Warning: unable to access index for repository 
>> https://cloud.r-project.org/bin/macosx/el-capitan/contrib/3.6:
>> Warning message:
>> package ‘regtools’ is not available (for R version 3.6.2) 
>> 
>> Cave Catalina!  Me too have no problem with el-captain.
>> 
>> Bruno
>> 
>>> Il giorno 18 dic 2019, alle ore 15:52, Duncan Murdoch 
>>>  ha scritto:
>>> 
>>> 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 > > wrote:
>> 
>> I tried from many repo:
>> 
>> https://cran.r-project.org 
>> https://pbil.univ-lyon1.fr/CRAN/ 
>> https://cran.stat.unipd.it 
>> 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 >> > 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 >>> > wrote:
 
 Any help after the Ken answer?
 
 Thanks a lot
 Bruno
 
> Inizio messaggio inoltrato:
> 
> Da: bruno apolloni  >
> 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/ 
>  
>  > I read;
> 
> For discussion of Mac-related topics and reporting Mac-specific bugs, 
> please use the 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  
> >
> 

Re: [R-SIG-Mac] R 3.6.2 installer / Catalina / Notarization

[Bob Rudis]

It's definitely showing for me on https://cran.r-project.org/bin/macosx/

> On Dec 13, 2019, at 12:53, Roy Mendelssohn - NOAA Federal 
>  wrote:
> 
> Yes but I don't see the installer on the CRAN site, I only see the installer 
> for 3.6.1.  Am I missing something?  Not a complaint,  just don't see it?  I 
> did clear my caches.
> 
> Thanks,
> 
> -Roy
> 
> 
>> On Dec 13, 2019, at 9:51 AM, Bob Rudis  wrote:
>> 
>> 3.6.2 was released on the 12th and it's been on all the CRAN mirrors I, er, 
>> "monitor", including the cran.r-project.org site 
>> (https://cran.r-project.org/bin/macosx/R-3.6.2.pkg).
>> 
>>> On Dec 13, 2019, at 12:49, rmendelss gmail  wrote:
>>> 
>>> Is this on the CRAN page?  Am I missing something?
>>> 
>>> Thanks,
>>> 
>>> -Roy
>>> 
>>> 
>>>> On Dec 13, 2019, at 9:39 AM, Simon Urbanek  
>>>> wrote:
>>>> 
>>>> Bob,
>>>> 
>>>> thanks - oddly, it didn't show when I tested it on Catalina, there must be 
>>>> a flag somewhere. As discussed before we cannot notarize any version of R 
>>>> before 4.0.0 so Catalina users have to either stick to 3.5.1 (since Apple 
>>>> has grand-fathered installers create before Catalina) or use the 
>>>> Ctrl+click way to install R 3.6.2.
>>>> 
>>>> Cheers,
>>>> Simon
>>>> 
>>>> 
>>>>> On Dec 13, 2019, at 12:30 PM, Bob Rudis  wrote:
>>>>> 
>>>>> While easily remedied via right-click + open, out-of-the-box installer 
>>>>> gives the Apple daft (and technically incorrect since Apple could most 
>>>>> certainly check it for malicious software):
>>>>> 
>>>>> “R-3.6.2.pkg” can’t be opened because Apple cannot check it for malicious 
>>>>> software.
>>>>> 
>>>>> message.
>>>>> 
>>>>> 
>>>>> Here's what spctl returns:
>>>>> 
>>>>> $ spctl -a -vv -t install R-3.6.2.pkg
>>>>> R-3.6.2.pkg: rejected
>>>>> source=Unnotarized Developer ID
>>>>> origin=Developer ID Installer: Simon Urbanek (VZLD955F6P)
>>>>> 
>>>>> 
>>>>> NOTE: R & R.app work fine once installed.
>>>>> 
>>>>> Not sure if this is going to cause consternation in "corporate" 
>>>>> environments.
>>>>> 
>>>>> -boB
>>>>> ___
>>>>> 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
>>> 
>> 
> 
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
> 
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected" 
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
> 

___
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 3.6.2 installer / Catalina / Notarization

[Bob Rudis]

3.6.2 was released on the 12th and it's been on all the CRAN mirrors I, er, 
"monitor", including the cran.r-project.org site 
(https://cran.r-project.org/bin/macosx/R-3.6.2.pkg).

> On Dec 13, 2019, at 12:49, rmendelss gmail  wrote:
> 
> Is this on the CRAN page?  Am I missing something?
> 
> Thanks,
> 
> -Roy
> 
> 
>> On Dec 13, 2019, at 9:39 AM, Simon Urbanek  
>> wrote:
>> 
>> Bob,
>> 
>> thanks - oddly, it didn't show when I tested it on Catalina, there must be a 
>> flag somewhere. As discussed before we cannot notarize any version of R 
>> before 4.0.0 so Catalina users have to either stick to 3.5.1 (since Apple 
>> has grand-fathered installers create before Catalina) or use the Ctrl+click 
>> way to install R 3.6.2.
>> 
>> Cheers,
>> Simon
>> 
>> 
>>> On Dec 13, 2019, at 12:30 PM, Bob Rudis  wrote:
>>> 
>>> While easily remedied via right-click + open, out-of-the-box installer 
>>> gives the Apple daft (and technically incorrect since Apple could most 
>>> certainly check it for malicious software):
>>> 
>>>  “R-3.6.2.pkg” can’t be opened because Apple cannot check it for malicious 
>>> software.
>>> 
>>> message.
>>> 
>>> 
>>> Here's what spctl returns:
>>> 
>>>  $ spctl -a -vv -t install R-3.6.2.pkg
>>>  R-3.6.2.pkg: rejected
>>>  source=Unnotarized Developer ID
>>>  origin=Developer ID Installer: Simon Urbanek (VZLD955F6P)
>>> 
>>> 
>>> NOTE: R & R.app work fine once installed.
>>> 
>>> Not sure if this is going to cause consternation in "corporate" 
>>> environments.
>>> 
>>> -boB
>>> ___
>>> 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] R 3.6.2 installer / Catalina / Notarization

[Bob Rudis]

While easily remedied via right-click + open, out-of-the-box installer gives 
the Apple daft (and technically incorrect since Apple could most certainly 
check it for malicious software):

“R-3.6.2.pkg” can’t be opened because Apple cannot check it for malicious 
software.

message.


Here's what spctl returns:

$ spctl -a -vv -t install R-3.6.2.pkg
R-3.6.2.pkg: rejected
source=Unnotarized Developer ID
origin=Developer ID Installer: Simon Urbanek (VZLD955F6P)


NOTE: R & R.app work fine once installed.

Not sure if this is going to cause consternation in "corporate" environments.

-boB
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Apparent interaction between XQuartz and the Catalina (10.15) macOS upgrade

[Bob Rudis]

I've been running Catalina since the first beta and upgraded to GM the day of 
release. Apart from having to stick R things into Full Disk Access I've had no 
issues with R nor XQuartz.

I read through the links provided and, while I do have said symlink in the 
relocated items folder Apple creates (this is new behavior for the GM), it gets 
re-created fine for me & XQuartz works fine (and the minor pkg deps I have 
installed that use it also work fine.

This would appear to be a YMMV situation.

-Bob

> On Oct 8, 2019, at 4:19 PM, Luis Puerto  wrote:
> 
> Thanks a lot for the heads up! 
> 
> Cheers!
> Luis
> 
>> On 8 Oct 2019, at 22:49, Marc Schwartz via R-SIG-Mac 
>>  wrote:
>> 
>> Hi All,
>> 
>> Perhaps I missed something relevant along the way someplace, but I ran the 
>> upgrade to Catalina (10.15) last night. I wanted to give folks a heads up on 
>> an issue that you may face, especially if you have XQuartz installed 
>> alongside R.
>> 
>> One of the sequelae of the upgrade is that some files may get relocated 
>> during the upgrade, likely in part due to the macOS SIP.
>> 
>> In my case, this involved the symlink for XQuartz, 'usr/X11R6', which gets 
>> placed into a "Relocated Items" folder on the Desktop. That folder, which is 
>> actually an alias to /Users/Shared, contains a folder tree with: 
>> Security/usr/X11R6. Naively, after seeing this, I elected to move the entire 
>> folder to the Trash.
>> 
>> That led me into a cycle of trying to figure out how to then delete that 
>> folder tree from the Trash, as I would get various OS errors in the course 
>> of doing so.
>> 
>> That led me to some Google searches, with incremental attempts at solutions, 
>> but eventually landing on the following thread in the Apple Community forums:
>> 
>> https://discussions.apple.com/thread/250712783
>> 
>> After the first review of the thread there, and before user 'faikbey' posted 
>> a possible solution using Recovery Mode, I filed an Issue on the XQuartz 
>> github repo here:
>> 
>> https://github.com/XQuartz/XQuartz/issues/1
>> 
>> It would seem that, at some level, one workaround would be to uninstall 
>> XQuartz fully before the Catalina upgrade, but there is no uninstall program 
>> provided by them. There is a series of CLI commands in a github gist here:
>> 
>> https://gist.github.com/pwnsdx/d127873e24cef159d4d603accaf37ee4#file-gistfile1-txt
>> 
>> which appears to work, but would likely be best used prior to the Catalina 
>> upgrade, and then re-install XQuartz after the upgrade is complete.
>> 
>> The solution to the problem posted by 'faikbey' in the Apple forum appears 
>> to work in the original scenario, albeit, as I noted in my reply in that 
>> thread, I needed to first mount the user volume in Recovery Mode using Disk 
>> Utility, before I could proceed with the additional steps of deleting the 
>> files from the Trash, then rebooting into normal mode. 
>> 
>> If anyone else has experienced this and knows of an alternative/better 
>> solution, let us know.
>> 
>> Otherwise, let's see what the XQuartz folks might come up with on this, as 
>> this was not an issue with prior macOS upgrades.
>> 
>> Regards,
>> 
>> Marc Schwartz
>> 
>> ___
>> 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] code-signing for builds of R from the developer page?

[Bob Rudis]

(apologies for a second spam addendum, I hit "send" too quickly)

In theory, once the latest Xcode is truly stable (the Xcode 11 GM is broken in 
some places so there's going to be another release before Apple release macOS 
Vista in October) the notarization "API" (that's way too kind of a word for it) 
should be fully baked and can be added to any build pipeline. That will require 
some other things for command line binaries (e.g. an Info.plist and 
entitlements file just for the notarization) to get ask for, receive, and then 
staple a ticket to a command line app.

R.app will likely "need" said stapling come January 2020 (to avoid the "this 
app is malware" message from Apple).

For the previous mail, you should be able to also use `productsign` to sign the 
installer the same way.

-boB

> On Sep 22, 2019, at 1:23 PM, Bob Rudis  wrote:
> 
> Something like:
> 
>
> "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
>
>
> 
>  Label
>  is.rud.buildr
> 
>  ProgramArguments
>  
>sh
>-c
>/Users/bob/Development/R-3.6.1/build-and-sign.sh
>  
> 
>  StartCalendarInterval
>  
>Hour
>13
>  
> 
>  UserName
>  bob
> 
>  SessionCreate
>  
> 
>  WorkingDirectory
>  /Users/bob/Development/R-3.6.1
> 
>  StandardOutPath
>  /Users/bob/tmp/buildr-stdout.log
> 
>  StandardErrorPath
>  /Users/bob/tmp/buildr-sterr.log
> 
>
>
> 
> put into ~/Library/LaunchAgents/whatever.you.want.plist
> 
> then:
> 
>$ launchctl load -w ~/Library/LaunchAgents/whatever.you.want.plist
> 
> will run the build-and-sign.sh script at 1300 daily (made that up b/c it just 
> turned 1300 here as I was typing) with std[out|err] logs preserved.
> 
> The key elements of the plist to enable access to the cert are:
> 
>  UserName
>  bob
> 
> and:
> 
>  SessionCreate
>  
> 
> That should work on any recent/supported macOS.
> 
> Use:
> 
>  $ launchctl unload -w ~/Library/LaunchAgents/whatever.you.want.plist 
> 
> to unload any active launchd agent so you can reload.
> 
> To get verbose output from the code signing in the logs do:
> 
>codesign -vs "Developer-id-stirng-from-keychain" file
> 
> I belive only:
> 
>Resources/bin/exec/R
> 
> and any dylibs in:
> 
>Resources/lib/
> 
> [need to|should be] be signed.
> 
> While the script name I used is "build and sign" there's no reason you 
> couldn't just have a launchd process for the code signing and keep the R 
> build in cron.
> 
> There are (or used to be, at least) quite a few google-able solutions to 
> other scenarios for this, the most common of which has the use of Jenkins (or 
> other build pipeline managers) to manage build pipelines for macOS and iOS 
> apps. I did a quick "jenkins macos code sign" and they all still seem to be 
> there (just looked at the list, didn't dig into the URLs to see if they're 
> alive).
> 
> -boB
> 
>> On Sep 21, 2019, at 4:16 PM, Balamuta, James Joseph  
>> wrote:
>> 
>> Greetings and Salutations All, 
>> 
>> I think `launchd` jobs would properly sign the installer. `launchd` is 
>> Apple's re-envisioning of `cron`.
>> 
>> So, would it be possible to port over the cron job to `launchd`?
>> 
>> Sincerely,
>> 
>> JJB
>> 
>> On 9/20/19, 11:06 PM, "R-SIG-Mac on behalf of Simon Urbanek" 
>>  
>> wrote:
>> 
>>   For some reason signing doesn't work in cron jobs even if the keychain is 
>> unlocked. Hence only runs that I run from the shell are successfully signed 
>> (like releases). If anyone has a solution, I'd like to hear it.
>> 
>>   Cheers,
>>   Simon
>> 
>> 
>>> On Sep 19, 2019, at 12:55 PM, Kevin Ushey  wrote:
>>> 
>>> Hi,
>>> 
>>> It looks like the builds of R from http://mac.r-project.org/ are typically
>>> not code-signed, and so one normally gets a Gatekeeper warning when trying
>>> to install them. E.g. I see (on macOS 10.14.6):
>>> 
>>> “R-3.6-branch-el-capitan.pkg” can’t be opened because it is from an
>>> unidentified developer.
>>> 
>>> Your security preferences allow installation of only apps from the App
>>> Store and identified developers.
>>> 
>>> 
>>> Is there any chance this might change in the future?
>>> 
>>> Thanks,
>>> Kevin
>>> 
>>> [[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
> 

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] code-signing for builds of R from the developer page?

[Bob Rudis]

Something like:


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>



  Label
  is.rud.buildr

  ProgramArguments
  
sh
-c
/Users/bob/Development/R-3.6.1/build-and-sign.sh
  

  StartCalendarInterval
  
Hour
13
  

  UserName
  bob

  SessionCreate
  

  WorkingDirectory
  /Users/bob/Development/R-3.6.1

  StandardOutPath
  /Users/bob/tmp/buildr-stdout.log

  StandardErrorPath
  /Users/bob/tmp/buildr-sterr.log




put into ~/Library/LaunchAgents/whatever.you.want.plist

then:

$ launchctl load -w ~/Library/LaunchAgents/whatever.you.want.plist

will run the build-and-sign.sh script at 1300 daily (made that up b/c it just 
turned 1300 here as I was typing) with std[out|err] logs preserved.

The key elements of the plist to enable access to the cert are:

  UserName
  bob

and:

  SessionCreate
  

That should work on any recent/supported macOS.

Use:

  $ launchctl unload -w ~/Library/LaunchAgents/whatever.you.want.plist 

to unload any active launchd agent so you can reload.

To get verbose output from the code signing in the logs do:

codesign -vs "Developer-id-stirng-from-keychain" file

I belive only:

Resources/bin/exec/R

and any dylibs in:

Resources/lib/

[need to|should be] be signed.

While the script name I used is "build and sign" there's no reason you couldn't 
just have a launchd process for the code signing and keep the R build in cron.

There are (or used to be, at least) quite a few google-able solutions to other 
scenarios for this, the most common of which has the use of Jenkins (or other 
build pipeline managers) to manage build pipelines for macOS and iOS apps. I 
did a quick "jenkins macos code sign" and they all still seem to be there (just 
looked at the list, didn't dig into the URLs to see if they're alive).

-boB

> On Sep 21, 2019, at 4:16 PM, Balamuta, James Joseph  
> wrote:
> 
> Greetings and Salutations All, 
> 
> I think `launchd` jobs would properly sign the installer. `launchd` is 
> Apple's re-envisioning of `cron`.
> 
> So, would it be possible to port over the cron job to `launchd`?
> 
> Sincerely,
> 
> JJB
> 
> On 9/20/19, 11:06 PM, "R-SIG-Mac on behalf of Simon Urbanek" 
>  
> wrote:
> 
>For some reason signing doesn't work in cron jobs even if the keychain is 
> unlocked. Hence only runs that I run from the shell are successfully signed 
> (like releases). If anyone has a solution, I'd like to hear it.
> 
>Cheers,
>Simon
> 
> 
>> On Sep 19, 2019, at 12:55 PM, Kevin Ushey  wrote:
>> 
>> Hi,
>> 
>> It looks like the builds of R from http://mac.r-project.org/ are typically
>> not code-signed, and so one normally gets a Gatekeeper warning when trying
>> to install them. E.g. I see (on macOS 10.14.6):
>> 
>> “R-3.6-branch-el-capitan.pkg” can’t be opened because it is from an
>> unidentified developer.
>> 
>> Your security preferences allow installation of only apps from the App
>> Store and identified developers.
>> 
>> 
>> Is there any chance this might change in the future?
>> 
>> Thanks,
>> Kevin
>> 
>>  [[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

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] RSwitch 64-bit

[Bob Rudis]

On http://mac.r-project.org/ (which shld prbly be re-titled to "R for macOS 
Developer's Page"…I'd file a PR for that but do not know where that website 
source tree is maintained) there's a tiny binary at bottom of the page that 
enables switching of the `Current` R framework alias via a GUI.

TLDR: It's 32-bit and the source links stopped working even when the site was 
homed @ AT As a result, it's unusable on the forthcoming Catalina GA release.

I have no idea how popular said tool is, but it's handy, so I threw together a 
Swift 5 version of it (and set a minimum macOS target of 10.14 since I cannot 
ethically enable use of woefully insecure operating systems). A core difference 
between the 2011 version and this 2019 version is that it's a menubar app vs a 
window app.

The code and binary release are at , which 
has links to other social coding sites where the codebase is co-maintained.

I have a bit more work to do on it (mostly just rounding out corners) but it 
has "worked for me" on Catalina betas and any/all contributions are 
welcome/encouraged.

-boB

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Fortran on MacOS Sierra

[Bob Rudis]

Glad you're up and running!

​If you have some specific examples I can try to reproduce (and report) as
I load the betas (I'm on beta 2 now).

-Bob

On Fri, Sep 30, 2016 at 8:26 AM, Ken Beath <k...@kjbeath.com.au> wrote:

> Thanks, yes I sorted it out. I’d read the bit on Makevars but it just
> didn’t seem what I wanted.
>
> There are some problems with the 10.12.1 beta which affect built libraries
> but at the moment I will just hope they go away.
>
> Ken
>
> > On 30 Sep. 2016, at 9:26 pm, Bob Rudis <b...@rud.is> wrote:
> >
> > Coudert's packages are unsigned which seems like a significant oversight
> and a CRAN manual entry recommending installing unsigned binaries does not
> sit well with me and may not work in the next macOS release.
> >
> > Ken: to avoid you having to dig you need to download <
> http://coudert.name/software/gfortran-6.1-ElCapitan.dmg> and install it,
> overriding the security warning (ugh).
> >
> > You then need to add this to your ~/.R/Makevars (or to the site one)
> >
> > F77 = /usr/local/gfortran/bin/gfortran
> > FC = /usr/local/gfortran/bin/gfortran
> > FLIBS = -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
> -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
> >
> > You'll still get the massive amount of warnings (they aren't harmful)
> but the pkg will compile/install from source.
> >
> >
> > On Fri, Sep 30, 2016 at 5:04 AM, Prof Brian Ripley <
> rip...@stats.ox.ac.uk> wrote:
> > This seems to be Sierra, which has 'tidied up' system libraries.
> >
> > The recommendation for El Capitan at http://coudert.name/software.html
> also works correctly on Sierra. (See the manual, preferably before posting.)
> >
> > There are good reasons why the posting guide asks for 'at a minimum' the
> output of sessionInfo() 
> >
> > On 30/09/2016 09:31, Ken Beath wrote:
> > I tried to build frailtypack from source using R 3.3.1 and it failed
> with the following message (after a ridiculous amount of warnings)
> >
> > gfortran-4.8 -dynamiclib -Wl,-headerpad_max_install_names -undefined
> dynamic_lookup -single_module -multiply_defined suppress
> -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o
> frailtypack.so Adonnees.o AparamMultive.o Aparameters.o aGhermite.o
> aaOptim.o aaOptimres.o aaUseFunction.o aaUseFunctionG.o aamarq98o.o
> additive.o afuncpasres.o ahrmsym.o aresidusMartingale.o atestWald.o
> distance.o epoce.o epoce_log.o epoce_long.o frailtypack.o funcpaG_tps.o
> funcpaGcpm.o funcpaGcpm_intcens.o funcpaGcpm_log.o funcpaGsplines.o
> funcpaGsplines_intcens.o funcpaGsplines_log.o funcpaGweib.o
> funcpaGweib_intcens.o funcpaGweib_log.o funcpaMultivCpm.o
> funcpaMultivSplines.o funcpaMultivWeib.o funcpaacpm.o funcpaasplines.o
> funcpaaweib.o funcpaj_tps.o funcpajcpm.o funcpajcpm_log.o funcpajgeneral.o
> funcpajlongisplines.o funcpajlongiweib.o funcpajsplines.o
> funcpajsplines_fam.o funcpajsplines_intcens.o funcpajsplines_log.o
> funcpajweib.o funcpajweib_fam.o funcpajweib_intcens.o funcpajweib_log.o
> f... 
> > gfortran-4.8: warning: couldn’t understand kern.osversion ‘16.0.0
> > ld: library not found for -ldylib1.o
> > collect2: error: ld returned 1 exit status
> > make: *** [frailtypack.so] Error 1
> > ERROR: compilation failed for package ‘frailtypack’
> >
> > I was going to attempt the build with gfortran 4.2 but haven’t been able
> to revert back from 4.8
> >
> > So does it happen with 4.2 and if not, how can I revert back?
> >
> > If not is this an R problem or the package?
> >
> > --
> > Brian D. Ripley,  rip...@stats.ox.ac.uk
> > Emeritus Professor of Applied Statistics, University of Oxford
> >
> > ___
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >
>
>

[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Fortran on MacOS Sierra

[Bob Rudis]

Coudert's packages are unsigned which seems like a significant oversight
and a CRAN manual entry recommending installing unsigned binaries does not
sit well with me and may not work in the next macOS release.

Ken: to avoid you having to dig you need to download <
http://coudert.name/software/gfortran-6.1-ElCapitan.dmg> and install it,
overriding the security warning (ugh).

You then need to add this to your ~/.R/Makevars (or to the site one)

F77 = /usr/local/gfortran/bin/gfortran
FC = /usr/local/gfortran/bin/gfortran
FLIBS = -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
-L/usr/local/gfortran/lib -lgfortran -lquadmath -lm

You'll still get the massive amount of warnings (they aren't harmful) but
the pkg will compile/install from source.


On Fri, Sep 30, 2016 at 5:04 AM, Prof Brian Ripley 
wrote:

> This seems to be Sierra, which has 'tidied up' system libraries.
>
> The recommendation for El Capitan at http://coudert.name/software.html
> also works correctly on Sierra. (See the manual, preferably before posting.)
>
> There are good reasons why the posting guide asks for 'at a minimum' the
> output of sessionInfo() 
>
> On 30/09/2016 09:31, Ken Beath wrote:
>
>> I tried to build frailtypack from source using R 3.3.1 and it failed with
>> the following message (after a ridiculous amount of warnings)
>>
>> gfortran-4.8 -dynamiclib -Wl,-headerpad_max_install_names -undefined
>> dynamic_lookup -single_module -multiply_defined suppress
>> -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o
>> frailtypack.so Adonnees.o AparamMultive.o Aparameters.o aGhermite.o
>> aaOptim.o aaOptimres.o aaUseFunction.o aaUseFunctionG.o aamarq98o.o
>> additive.o afuncpasres.o ahrmsym.o aresidusMartingale.o atestWald.o
>> distance.o epoce.o epoce_log.o epoce_long.o frailtypack.o funcpaG_tps.o
>> funcpaGcpm.o funcpaGcpm_intcens.o funcpaGcpm_log.o funcpaGsplines.o
>> funcpaGsplines_intcens.o funcpaGsplines_log.o funcpaGweib.o
>> funcpaGweib_intcens.o funcpaGweib_log.o funcpaMultivCpm.o
>> funcpaMultivSplines.o funcpaMultivWeib.o funcpaacpm.o funcpaasplines.o
>> funcpaaweib.o funcpaj_tps.o funcpajcpm.o funcpajcpm_log.o funcpajgeneral.o
>> funcpajlongisplines.o funcpajlongiweib.o funcpajsplines.o
>> funcpajsplines_fam.o funcpajsplines_intcens.o funcpajsplines_log.o
>> funcpajweib.o funcpajweib_fam.o funcpajweib_intcens.o funcpajweib_log.o
>> f... 
>> gfortran-4.8: warning: couldn’t understand kern.osversion ‘16.0.0
>> ld: library not found for -ldylib1.o
>> collect2: error: ld returned 1 exit status
>> make: *** [frailtypack.so] Error 1
>> ERROR: compilation failed for package ‘frailtypack’
>>
>> I was going to attempt the build with gfortran 4.2 but haven’t been able
>> to revert back from 4.8
>>
>> So does it happen with 4.2 and if not, how can I revert back?
>>
>> If not is this an R problem or the package?
>>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

[[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] APFS report

[Bob Rudis]

I finally had some cycles to format a few spare external drives as APFS
volumes.

I didn't expect R to behave badly and I was proven correct that it works
with directories & files on APFS volumes equally as well as it's HFS+
counterpart.

You have to use command-line tools to format APFS volumes and Apple makes
sure you know that all your data might disappear, so I don't expect folks
will be using it any time soon.

There are many very appealing features of the new filesystem, but for macOS
folk the biggest one is going to be case-sensitivity. Again, thankfully R
operates at a layer that makes this not an issue.

I'll be moving about 4 TB of data to APFS volumes this week and giving it a
good stress test. If there are any issues that aren't Apple's issues, I'll
post an update.

-Bob

[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Experiences with macOS Sierra

[Bob Rudis]

The detailed update is very much appreciated Prof Ripley.

Many thanks!

-Bob

On Thu, Sep 22, 2016 at 2:39 AM, Prof Brian Ripley 
wrote:

> So far I have encountered few problems.  R.app runs but I do not normally
> use it so my tests were minimal.
>
> My observations are about installing packages from source.
>
> - It seems Apple has been tidying up, and I had ca 20GB more free space
> after upgrading (which is worthwhile on my MBA with a 128GB SSD).  It seems
> that includes removing some headers, including those for openssl (used by
> packages PKI and RSclient - package opensssl uses its own). This is but the
> latest instance in a long-term trend, e.g. iodbc, pcre and liblzma have
> libraries but no headers.
>
> - Finally the POSIX 2008 function clock_gettime is supported (and will be
> used by R): but package scrypt calls it incorrectly.
>
> Xcode 8 is available for EL Capitan but I would caution against using it
> there (despite it being pushed as an update from the AppStore).  AFAICS
> (and googling will find other reports) it defaults to the macOS 10.12 SDK
> and that declares functions such as clock_gettime not available in El
> Capitan.  (I believe that R checks thoroughly enough not to be caught by
> this.)
>
> There is a further problem with Xcode 8, also seen on Sierra.  Packages
> using xml2-config (such as XML) fail to install.  Apple modified
> xml2-config to look on the SDK path, which means packages using it attempt
> to link to .tbd files rather than .dylibs.  Which should be OK but the
> supplied .tbd attempt to link to libraries removed in Sierra and so linking
> fails. (This is not a problem with the version 8 of the Command Line Tools,
> only available for Sierra.)
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] MacOS Sierra

[Bob Rudis]

Hey Roy,

Aye. If you look at recent R-SIG-Mac messages, I gave a report on this
yesterday.

No issues with 3.2, 3.3.1 or R-devel on 10.12 (so far).

-Bob

On Tue, Sep 20, 2016 at 2:59 PM, rmendelss gmail 
wrote:

> Hi All:
>
> Just wanted to double-check, before I even think about an upgrade, if the
> present version of R works with the new release of MacOS Sierra.
>
> Thanks for any information.
>
> -Roy
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

[[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] macOS Sierra

[Bob Rudis]

As an FYI to those pondering upgrading to Sierra, I've been testing R 3.3.1
in a VM under Sierra since the betas and migrated a few key production
systems over to the GM earlier this week and have been running production
code on them using CRAN 3.3.1 macOS binaries and AT macOS R-devel
binaries and haven't seen any issues script-wise or R GUI-wise (I don't use
R GUI that often, though).

I haven't tested Homebrew R yet but that's a plan for the weekend (we have
some endpoint users who prefer Homebrew R installs and I have production
code that needs to run on them as well).

While not R-specific, the preview builds of RStudio are also working fine
apart from some font rendering issues which I believe are due to the way
macOS Sierra webkit handles font ligatures (I use Fira Code for proper
arrows amongst other glyphs).

Since I hadn't seen anything regarding this I figured it might be useful
information for those considering the nascent OS update.

-Bob

[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Non-root OS X installation?

[boB Rudis]

You can follow 

(on another Mac) and then set your R pkg lib to a local, writeable
dir. Upgrading R will be a pain and if you don't have compiler tools
installed, usage of source or some github-released pkgs will be
difficult (install on another mac and then copy over to your work
restricted one).

On Sat, May 2, 2015 at 10:25 AM, Branden R. Williams
 wrote:
> Greetings. I am getting a new mac procured through my company, and I am 
> pretty sure I’m not going to have local administrator access to it. Is there 
> a clean way to install R locally for one user, including all the packages 
> that might be required, so that I don’t need admin access?
>
> thx.
>
> Regards,
>
> Branden R. Williams, DBA, CISSP, CISM
> b...@brandenwilliams.com
> Phone: +1 (214) 727-8227
>
> http://www.brandenwilliams.com/
> Cal: http://meetme.so/drbrando
>
> ___
> 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 3.2.2 Hangs Reading Files in El Capitan

[boB Rudis]

Agreed that I cannot reproduce with generated data sets on el capitan
either but would be glad to test with any real data you have.

On Fri, Dec 4, 2015 at 11:23 AM, Jeroen Ooms  wrote:
> Can you include a reproducible example? This seems to work for me as expected:
>
>   x <- rnorm(1e8)
>   saveRDS(x, tmp <- tempfile())
>   file.info(tmp)$size
>   y <- readRDS(tmp)
>   identical(x,y)
>
> Could be a hw issue with your disk.
>
>
>
>
> On Sun, Nov 29, 2015 at 4:34 PM, Charles DiMaggio
>  wrote:
>> Hi. After upgrading to el capitan R hangs on readRDS() and load()  for 
>> largish (say 500MB or larger) files, requiring a Force Quit of R.  I am 
>> working on a 64 GB Mac Pro machine and had no problem loading these size 
>> files prior to upgrade.  Reading and loading smaller files (1MB or less) 
>> seems to work fine. I re-installed R 3.2.2 GUI 1.66 Mavericks, XQuartz and 
>> CLT after the upgrade. Turned off SIP but experienced the same problem.
>>
>> I've looked over recent list posting about R behavior after upgrade to el 
>> capitan, and have not seen anything about this.  Am hoping 
>> soon-to-be-released R version 3.2.3 (Wooden Christmas-Tree) will address 
>> this weirdness, but wondering if anyone else has experienced anything 
>> similar?
>>
>> First few of lines of Mac Error Report below:
>>
>> Date/Time:   2015-11-28 15:45:00 -0500
>> OS Version:  Mac OS X 10.11.1 (Build 15B42)
>> Architecture:x86_64
>> Report Version:  22
>>
>> Command: R
>> Path:/Applications/R.app/Contents/MacOS/R
>> Version: R 3.2.2 GUI 1.66 Mavericks build (6996)
>> Parent:  launchd [1]
>> PID: 563
>>
>> Event:   hang
>> Duration:1.70s (process was unresponsive for 25 seconds before 
>> sampling)
>> Steps:   17 (100ms sampling interval)
>>
>> Hardware model:  MacPro6,1
>> Active cpus: 8
>>
>> ...
>>
>> Heaviest stack for the main thread of the target process:
>>   17  start + 1 (libdyld.dylib + 13741) [0x7fff88f2f5ad]
>>   17  main + 815 (R + 5967) [0x1053e374f]
>>   17  -[REngine runREPL] + 138 (R + 75578) [0x1053f473a]
>>   17  run_REngineRmainloop + 295 (R + 123751) [0x105400367]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1243228) [0x10561d85c]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 675070) [0x105592cfe]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1044002) [0x1055ece22]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 674823) [0x105592c07]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1029000) [0x1055e9388]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 673910) [0x105592876]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 750621) [0x1055a541d]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1601435) [0x105674f9b]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1592422) [0x105672c66]
>>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1594038) [0x1056732b6]
>>   14  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1596619) [0x105673ccb]
>>   7   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1595584) [0x1056738c0]
>>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1592773) [0x105672dc5]
>>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1600194) [0x105674ac2]
>>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 383889) [0x10554bb91]
>>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 316653) [0x10553b4ed]
>>   1   inflate + 258 (libz.1.dylib + 20735) [0x7fff9e4e30ff] (running)
>>
>>
>> Process: R [563]
>> Path:/Applications/R.app/Contents/MacOS/R
>> Architecture:x86_64
>> Parent:  launchd [1]
>> UID: 501
>> Task size:   350330 pages (+14553)
>> CPU Time:1.604s
>> Note:Unresponsive for 25 seconds before sampling
>> Note:2 idle work queue threads omitted
>>
>>
>> Cheers
>>
>> Charles
>>
>>
>> Charles DiMaggio, PhD, MPH
>> Director of Injury Research
>> Department of Surgery
>> New York University School of Medicine
>> Division of Trauma, Emergency Surgery and Critical Care Surgery
>> Bellevue Hosptial Center
>> 462 First Avenue, NBV 15
>> New York, NY 10016-9196
>> charles.dimag...@nyumc.org
>> Office: 212.263.3202
>> Mobile: 516.308.6426
>>
>>
>>
>>
>>
>>
>>
>> [[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] X11 support on OSX 10.10.4

[boB Rudis]

How did you install XQuartz? It looks like it was via homebrew. The
only official supported one (AFAIK) is via the actual XQuartz package.
I'm on 10.10.4 with XQuartz 2.7.7 (from pkg installer) and R 3.2.1
(from CRAN d/l) and it works fine. I use homebrew for many
sub-libraries (like GDAL) but not for core stuff like X11  R itself.

On Mon, Aug 3, 2015 at 9:21 PM, Jordan Bates jtbat...@asu.edu wrote:
 Hello,

 I'm having trouble getting X11 support to work.  I have XQuartz 2.7.7
 installed.  I've tried installing the R for Mac binaries, with homebrew
 from binaries, and with homebrew from source.  In all cases when I run R,
 capabilities(X11) returns false.

 X11() gives the following error:

 error:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
 can't open file:
 /usr/local/Cellar/r/3.2.1_1/R.framework/Resources/modules/R_X11.so (No such
 file or directory)


 Best regards,
 Jordan

 [[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] latex errors, Rd problems

[boB Rudis]

Since I just encountered similar issues in a package I'm working to get
submitted, here's the output (just included the warning lines):

(/usr/local/texlive/2014basic/texmf-dist/tex/latex/latexconfig/hyperref.cfg))

Package hyperref Message: Driver (autodetected): hpdftex.

(/usr/local/texlive/2014basic/texmf-dist/tex/latex/hyperref/hpdftex.def
(/usr/local/texlive/2014basic/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty)
)

Package hyperref Warning: Option `hyperindex' has already been used,
(hyperref)setting the option has no effect on input line
366.


Package hyperref Warning: Option `pagebackref' has already been used,
(hyperref)setting the option has no effect on input line
366.

)

...

(/usr/local/texlive/2014basic/texmf-dist/tex/latex/base/utf8.def) [2]
(./Rd2.ind [3]

LaTeX Font Warning: Font shape `T1/zi4/m/it' undefined
(Font)  using `T1/zi4/m/n' instead on input line 8.

[4]) (./Rd2.aux)

LaTeX Font Warning: Some font shapes were not available, defaults
substituted.

 )

I can't speak to whether the issues are similar, but I'll be trying on
Ubuntu soon to see if the errors are there as well. I am doing
__**nothing**__ unusual or wrong in the Rd files.

On Sat, Mar 21, 2015 at 9:09 AM, Prof Brian Ripley rip...@stats.ox.ac.uk
wrote:

 On 21/03/2015 12:38, Adrian Dușa wrote:

 On Sat, Mar 21, 2015 at 12:57 PM, Prof Brian Ripley
 rip...@stats.ox.ac.uk mailto:rip...@stats.ox.ac.uk wrote:

 [...]

 I also tried R CMD Rd2pdf (in the command line), and I get this
 at the end:

 Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet
 = quiet,  :
 Running 'texi2dvi' on 'Rd2.tex' failed.
 Messages:
 sh: /usr/local/bin/texi2dvi: No such file or directory

 It might boil down to this missing texi2dvi, but I have the full
 MacTeX-2014 (fresh reinstall today) on my system and it should
 be there.


 Might also be a path issue: here's is the difference between
 R.gui and
 terminal:


 What does R.app (there is no R.gui to my knowledge) have to do with
 this?  See the comment above about 'exactly what you did'.


 Oh, that's right.
 I used R.app as well because I have also tried the devtools package
 which has a check() function... same result (just to test if it was a
 path issue).

 Indeed, this error comes from the R CMD check command in terminal (sorry
 to confuse building with the command R CMD build), with the complete
 messages below:

 Adrians-MBP:~ dusadrian$ R CMD check --as-cran DDIwR_0.2-5.tar.gz
 * using log directory ‘/Users/dusadrian/DDIwR.Rcheck’
 * using R version 3.1.3 (2015-03-09)
 * using platform: x86_64-apple-darwin13.4.0 (64-bit)
 * using session charset: UTF-8
 * using option ‘--as-cran’
 * checking for file ‘DDIwR/DESCRIPTION’ ... OK
 * this is package ‘DDIwR’ version ‘0.2-5’
 * checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
 Maintainer: ‘Adrian Dusa dusa.adr...@unibuc.ro
 mailto:dusa.adr...@unibuc.ro’

 * checking package namespace information ... OK
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking if there is a namespace ... OK
 * checking for executable files ... OK
 * checking for hidden files and directories ... OK
 * checking for portable file names ... OK
 * checking for sufficient/correct file permissions ... OK
 * checking whether package ‘DDIwR’ can be installed ... OK
 * checking installed package size ... OK
 * checking package directory ... OK
 * checking DESCRIPTION meta-information ... OK
 * checking top-level files ... OK
 * checking for left-over files ... OK
 * checking index information ... OK
 * checking package subdirectories ... OK
 * checking R files for non-ASCII characters ... OK
 * checking R files for syntax errors ... OK
 * checking whether the package can be loaded ... OK
 * checking whether the package can be loaded with stated dependencies ...
 OK
 * checking whether the package can be unloaded cleanly ... OK
 * checking whether the namespace can be loaded with stated dependencies
 ... OK
 * checking whether the namespace can be unloaded cleanly ... OK
 * checking loading without being on the library search path ... OK
 * checking dependencies in R code ... OK
 * checking S3 generic/method consistency ... OK
 * checking replacement functions ... OK
 * checking foreign function calls ... OK
 * checking R code for possible problems ... OK
 * checking Rd files ... OK
 * checking Rd metadata ... OK
 * checking Rd line widths ... OK
 * checking Rd cross-references ... OK
 * checking for missing documentation entries ... OK
 * checking for code/documentation mismatches ... OK
 * checking Rd \usage sections ... OK
 * checking Rd contents ... OK
 * checking for unstated dependencies in examples ... OK
 * checking contents of ‘data’ directory ... OK
 * checking data for non-ASCII characters ... OK
 * checking data for