Re: [R-SIG-Mac] Experiences with El Capitan

[Spencer Graves]

On 10/12/2015 10:21 PM, Roy Mendelssohn - NOAA Federal wrote:

CLT = command line tools.  Otherwise you only have the compilers from the Xcode 
interface.

in order to have tex2dvi, you need a tex distribution installed.  I do remember 
if Simon has one on his R mac site, nut you can do an install from say  (as the 
RStudio help says):


To build manuals and vignettes you'll also need to install the MacTeX LaTeX 
distribution (or another version of LaTeX for the Mac). You can download MacTeX 
from here:http://www.tug.org/mactex/downloading.html.

HTH,



  Yes, it didn't just help, it fixed the problem.  Thanks.  (My 
Father once said, "That not only hit the spot, it erased it.")



   Best Wishes,
  Spencer


Roy


On Oct 12, 2015, at 7:58 PM, Spencer Graves  wrote:



On 10/12/2015 8:51 PM, Kevin Ushey wrote:

The simplest way to fix your issue is to symlink R to /usr/local/bin, e.g.

 ln -s /Library/Frameworks/R.framework/Resources/bin/R /usr/local/bin/R

This worked.  Thanks.  Spencer


... but not completely:  "R CMD build" worked.  "R CMD check" ended with:


Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
  pdflatex is not available




Or, as Professor Ripley said in his initial post, R installers from
3.2.2 on El Capitan will now install a symlink at /usr/local/bin/R, so
you might want to just re-install or update R.

Updating the CLT is normally just a matter of downloading the latest

What's CLT?  Central Limit Theorem?  Charlotte Douglas International Airport?



version of Xcode from the App Store, if I understand correctly. (You

  I requested "Xcode" at the App Store.  It asked for my Apple password then went 
away.  I rebooted and still got "pdflatex is not available".



may need to read + confirm a license agreement on your next run of the
clang compiler -- try running 'clang' after installing Xcode to see if
you're prompted)

$ clang
xcrun: error: invalid active developer path 
(/Library/Developer/CommandLineTools), missing xcrun at: 
/Library/Developer/CommandLineTools/usr/bin/xcrun


  Thanks again for your prompt reply.  Other suggestions?  (All this 
worked before I upgraded to OS X 10.11.)  Spencer


Kevin

On Mon, Oct 12, 2015 at 6:33 PM, Spencer Graves
  wrote:

On 10/5/2015 2:46 PM, Simon Urbanek wrote:

On Oct 5, 2015, at 3:34 AM, Rainer M Krug  wrote:


peter dalgaard  writes:




Agreed.

I just would like to dd that in the case of using homebrew, which
installs everything under /usr/local/... which did not cause any
problems at all. I moved the contents of /usr/local to an other location
before upgrade because the upgrade to Yosemite took because of a large
/usr/local several hours instead of about half an hour, moved it back
afterwards and everything worked fins without problems.

One question concerning mixed usage of homebrew and the Official R
installers:

do the Official R installers fail if an R binary already exist, or do
they raise a warning?

To make this easier, would it be possible, to install the binaries under
/usr/local/bin/R.X.Y.Z and then just create links in /usr/local/bin ?
Tghis would make the whole process more transparent and easier to switch
between different versions and means of installation.


R installer never installs any R binaries outside of the framework/app.
The only thing we provide on 10.10 is a softlink for R and Rscript in
/usr/local/bin into the framework (removing anything else in that name if it
exists). In earlier OS X versions this applies to /usr/bin instead.

Cheers,
Simon



Thanks for the clarifications,

Rainer


-pd


On 04 Oct 2015, at 18:53 , Prof Brian Ripley
wrote:

The machine which provides the 'r-devel-osx-x86_64-clang' checks on
the CRAN check farm has been upgraded from Yosemite to El Capitan
and a complete round of checks has been run.


1) There is a lot of misinformation around about 'System Integrity
Protection' aka 'rootless'.

Upgrading to El Capitan moves files which are not allowed under /usr
to /Library/SystemMigration/usr, so you will be able to see what was
lost. This includes /usr/bin/R, /usr/bin/Rscript (but the installer
installs these under /usr/local/bin on El Capitan as from R 3.2.2),
/usr/X11R6, /usr/texbin .  Contrary to reports from betas, the link
/usr/X11 is preserved.

If an installer tries to create a disallowed file such as
/usr/bin/R, this is silently ignored (at least in the cases we
tested).  So you can install e.g. R 3.1.3 but the executables will
not appear in the default Terminal path (more details in the current
manual).


2) After updating you need to re-install the Command Line Tools and
R (to get the links in /usr/local).  I did not need to re-install
Java nor XQuartz.

   How do you suggest I "re-install the Command Line Tools and R"?


   I upgraded to 10.11 days ago but only now tried "R CMD 

Re: [R-SIG-Mac] XCode / gcc / R compatibility issues on Yosemite with XCode 7 and on El Capitan

[Berend Hasselman]

> On 13 Oct 2015, at 16:14, Prof Brian Ripley  wrote:
> 
> On 13/10/2015 14:36, Simon Urbanek wrote:
>> 
>> On Oct 12, 2015, at 4:22 PM, Jenny Brown  wrote:
>> 
>>> Thank you to both of you.  I believe my issue is solved by using the binary
>>> distribution of gfortran libraries, as it was dynamic linking that was
>>> causing me the most headache.  And that seems to solve that.
>>> 
>>> I still have to modify the etc/Makeconf file to use the right directory for
>>> -L and the right library name for gfortran  it comes written as
>>> gfortran-4.8 in the Makeconf but that gives a not-found on my system.
>> 
>> 
>> It means you're not using the Fortran we use (as I said below) - see
>> http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
> 
> Also, you do not need to modify etc/Makeconf ... the manual says
> 
> 'The default compilers specified in 
> /Library/Frameworks/R.framework/Resources/etc/Makeconf depend on the version 
> of OS X under which R was installed, and are appropriate to the latest 
> version of the command-line tools for that version of OS X. The settings can 
> be changed, either by editing that file or in a file such as ~/.R/Makevars 
> (see the next section).'
> 
> I have in ~/.R/Makevars on my laptop
> 
> F77 = /usr/local/gfortran/bin/gfortran
> FC = /usr/local/gfortran/bin/gfortran
> FLIBS =  -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0 
> -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
> 
> 

This is Coudert’s gfortran, I presume?
Can it be used together with R binary provided by CRAN and Simon?
Or would one have to recompile R from scratch using Coudert’s gfortran?

Berend

> 
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>>  I'm
>>> not entirely clear on when the Makeconf is initially written during a
>>> binary install of R.  But it does seem that I can adjust the lines related
>>> to fortran and get it to work for compiling my source packages.
>>> 
>>> Thanks!
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Oct 8, 2015 at 1:33 AM, Prof Brian Ripley 
>>> wrote:
>>> 
 On 08/10/2015 02:37, Simon Urbanek wrote:
 
> Jenny,
> 
> I suspect you may not have the correct information. The CRAN Mavericks
> binary of R is not built with gcc, it's actually build using Apple clang
> and we're neither using nor requiring homebrew, so most of what you are
> describing doesn't make sense to me. I have tested Xcode 7 with the
> gfortran-4.8 we supply and it works just fine on 10.11 (tested on Hmisc). 
> I
> have only 10.6, 10.9 and 10.11 so I can't check 10.10, but I would
> certainly recommend building on 10.9 with Xcode 6 for compatibility 
> (that's
> what we do for CRAN). If you don't care about binary compatibility then
> Xcode 7 on 10.11 is fine (FWIW Hmisc package compiled on 10.11 actually
> works for me on 10.9 so it could even be that you may get away with using
> 10.11 if you don't use system dependencies with higher versions).
> 
 
 It also works for me on 10.10.  If the 'Command Line Tools OS X 10 for
 Xcode 7' Apple package is installed on 10.10 (specifically file
 http://adcdownload.apple.com/Developer_Tools/Command_Line_Tools_OS_X_10.10_for_Xcode_7/Command_Line_Tools_OS_X_10.10_for_Xcode_7.dmg),
 it installs
 
 % clang --version
 Apple LLVM version 7.0.0 (clang-700.0.74)
 Target: x86_64-apple-darwin14.5.0
 
 hence targets OS X 10.10 aka Darwin 14.  My 10.10 machine does not have
 Xcode installed, only the CLT: you do not need Xcode's SDKs to compile R
 nor any CRAN package.  (You do need Xcode to compile R.app.)
 
 For Fortran on Yosemite/El Capitan I use the gfortran 5.2 build at the
 sites given in the current R-admin manual ('Other builds of gfortran are
 available: see https://gcc.gnu.org/wiki/GFortranBinaries and
 http://coudert.name/software.html').  My recollection is that the
 'gfortran-4.8 for Mavericks' on r.research.att.com does compile all but
 one of the CRAN packages on Yosemite (SWATmodel which compiles executables
 from Fortran code), in some cases with warnings.
 
 Note that any recent(ish) build of gfortran will have dynamic libgfortran
 and libquadmath libraries, and installations of most Fortran-using packages
 will link to these.  So you either need to install those libraries on all
 the machines or arrange for the packages you distribute to point to the
 copies in the CRAN build (in R_HOME/lib) as is done for the CRAN binary
 packages.  (I believe they are post-processed by
 https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Simon/packages/1.fixr
 .)  My recollection is that a very few packages also link to libgcc_s, also
 in R_HOME/lib.
 
 
 
 Cheers,
> Simon
> 
> 
> On Oct 7, 2015, at 10:47 AM, Jenny Brown  wrote:
>> 
>> I am 

[R-SIG-Mac] rgl crashes R.app in El Capitan

[Fox, John]

Dear r-sig-mac list members,

I can reliably crash R.app in R 3.2.2 under El Capitan with

  library(rgl)
  demo("rgl")  # a few returns

My session info:

> sessionInfo()
R version 3.2.2 (2015-08-14)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11 (El Capitan)

locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

other attached packages:
[1] rgl_0.95.1367

I see this problem only in R.app, not when R is run in a terminal or in RStudio.

This problem was original brought to my attention by Jose Conde (to whom I'm 
cc'ing this message), who encountered the problem using the scatter3d() 
function in the car package via the Rcmdr, but the problem isn't unique to 
either scatter3d() or the Rcmdr. In the case of scatter3d() the command

scatter3d(prestige ~ income + education, data=Prestige)

which draws a regression surface, reliably crashes R.app, but

scatter3d(prestige ~ income + education, data=Prestige, surface=FALSE)

which plots only points (as spheres) doesn't.

I hope that this provides enough clues to diagnose the problem.

John

-
John Fox, Professor
McMaster University
Hamilton, Ontario
Canada L8S 4M4
web: socserv.mcmaster.ca/jfox


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

Re: [R-SIG-Mac] rgl crashes R.app in El Capitan

[Duncan Murdoch]

On 13/10/2015 3:03 PM, Fox, John wrote:
> Dear r-sig-mac list members,
>
> I can reliably crash R.app in R 3.2.2 under El Capitan with
>
>   library(rgl)
>   demo("rgl")  # a few returns
>
> My session info:
>
>> sessionInfo()
> R version 3.2.2 (2015-08-14)
> Platform: x86_64-apple-darwin13.4.0 (64-bit)
> Running under: OS X 10.11 (El Capitan)
>
> locale:
> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
>
> other attached packages:
> [1] rgl_0.95.1367
>
> I see this problem only in R.app, not when R is run in a terminal or in 
> RStudio.
>
> This problem was original brought to my attention by Jose Conde (to whom I'm 
> cc'ing this message), who encountered the problem using the scatter3d() 
> function in the car package via the Rcmdr, but the problem isn't unique to 
> either scatter3d() or the Rcmdr. In the case of scatter3d() the command
>
> scatter3d(prestige ~ income + education, data=Prestige)
>
> which draws a regression surface, reliably crashes R.app, but
>
> scatter3d(prestige ~ income + education, data=Prestige, surface=FALSE)
>
> which plots only points (as spheres) doesn't.
>
> I hope that this provides enough clues to diagnose the problem.
>
>

I don't have El Capitan, I'm still running under OS X 10.9.5
(Mavericks), and it doesn't crash.

Since you're using the latest rgl, you must have built it yourself --
CRAN doesn't distribute binaries for it (at least for Mavericks).  Did
you get any errors or warnings during compilation?

Duncan Murdoch

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

Re: [R-SIG-Mac] rgl crashes R.app in El Capitan

[Fox, John]

Dear Duncan,

> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:34 PM
> To: Fox, John; r-sig-mac@r-project.org
> Cc: jose.con...@upr.edu
> Subject: Re: rgl crashes R.app in El Capitan
> 
> On 13/10/2015 3:03 PM, Fox, John wrote:
> > Dear r-sig-mac list members,
> >
> > I can reliably crash R.app in R 3.2.2 under El Capitan with
> >
> >   library(rgl)
> >   demo("rgl")  # a few returns
> >
> > My session info:
> >
> >> sessionInfo()
> > R version 3.2.2 (2015-08-14)
> > Platform: x86_64-apple-darwin13.4.0 (64-bit)
> > Running under: OS X 10.11 (El Capitan)
> >
> > locale:
> > [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > other attached packages:
> > [1] rgl_0.95.1367
> >
> > I see this problem only in R.app, not when R is run in a terminal or
> in RStudio.
> >
> > This problem was original brought to my attention by Jose Conde (to
> whom I'm cc'ing this message), who encountered the problem using the
> scatter3d() function in the car package via the Rcmdr, but the problem
> isn't unique to either scatter3d() or the Rcmdr. In the case of
> scatter3d() the command
> >
> > scatter3d(prestige ~ income + education, data=Prestige)
> >
> > which draws a regression surface, reliably crashes R.app, but
> >
> > scatter3d(prestige ~ income + education, data=Prestige,
> surface=FALSE)
> >
> > which plots only points (as spheres) doesn't.
> >
> > I hope that this provides enough clues to diagnose the problem.
> >
> >
> 
> I don't have El Capitan, I'm still running under OS X 10.9.5
> (Mavericks), and it doesn't crash.

That was my experience as well -- I didn't experience this problem under either 
Mavericks or Yosemite. BTW, I reinstalled R 3.2.2 and XQuartz after upgrading 
to El Capitan. I usually upgrade fairly early to see whether there are any 
problems.

> 
> Since you're using the latest rgl, you must have built it yourself --
> CRAN doesn't distribute binaries for it (at least for Mavericks).  Did
> you get any errors or warnings during compilation?

Right again. I ran update.packages() to make sure that the error wasn't fixed 
and compiled packages that didn't yet have Mac binaries. AFAICS, there were no 
errors in compiling the rgl package.

BTW, my apologies for posting my message twice -- my mailer complained about 
the address in the first message and I thought it wasn't sent.

Thanks for looking into this,
 John

> 
> Duncan Murdoch

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

[R-SIG-Mac] rgl crashes R.app under El Capitan

[Fox, John]

Dear r-sig-mac list members,

The following reliably crashes R.app for R 3.2.2 under El Capitan (at least for 
me):

library(rgl)
demo("rgl") # press return a few times

My session info:

> sessionInfo()
R version 3.2.2 (2015-08-14)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11 (El Capitan)

locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

other attached packages:
[1] rgl_0.95.1367

As far as I can tell, this problem occurs only in R.app, not when R is run from 
a terminal, nor in RStudio.

The problem was brought to my attention by José Conde (whom I've cc'd this 
message), who encountered the problem using the scatter3d() function from the 
car package through the Rcmdr GUI -- but the problem apparently isn't specific 
either to the Rcmdr or to scatter3d().

In the case of scatter3d(), the problem occurs only when displaying a 
regression surface, as in

scatter3d(prestige ~ income + education, data=Prestige)

but not in

scatter3d(prestige ~ income + education, data=Prestige, surface=FALSE)

I hope that this provides enough clues to resolve the problem.

Best,
 John
-
John Fox, Professor
McMaster University
Hamilton, Ontario
Canada L8S 4M4
web: socserv.mcmaster.ca/jfox

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