> I guess that the problem is that the .tar.gz file is . wait for it .
> not a binary package for OS X. Those usually have .tgz extension, where as
> .tar.gz files are usually source packages.
>
> You might try type="source" in install.packages.
Thanks, type="source", does work; though
On Aug 16, 2012, at 00:29 , Michael Donohue wrote:
> After updating to R 2.15.1 on OS X 10.8, I am seeing:
>
>> install.packages("nlme_3.1-104.tar.gz", repos = NULL)
> Error: file ‘nlme_3.1-104.tar.gz’ is not an OS X binary package
>
> R CMD INSTALL is working fine, but I'm curious if anyone is
After updating to R 2.15.1 on OS X 10.8, I am seeing:
> install.packages("nlme_3.1-104.tar.gz", repos = NULL)
Error: file ‘nlme_3.1-104.tar.gz’ is not an OS X binary package
R CMD INSTALL is working fine, but I'm curious if anyone is having the same
issue.
Thanks,
Mike
___
On 15 Aug 2012, at 14:26, Simon Urbanek wrote:
> On Aug 15, 2012, at 5:28 AM, Berend Hasselman wrote:
>
>> To be completely sure: for ML I only have to install
>> gfortran-lion-5666-3.pkg (from r.research.att.com) and Xcode + CLI tools?
>
> No, the "regular" Fortran from the top of the page
On Aug 15, 2012, at 5:28 AM, Berend Hasselman wrote:
> To be completely sure: for ML I only have to install
> gfortran-lion-5666-3.pkg (from r.research.att.com) and Xcode + CLI tools?
No, the "regular" Fortran from the top of the page or from CRAN - there is no
Xcode add-on.
Cheers,
Simon
_
On 14-08-2012, at 22:39, Simon Urbanek wrote:
> On Aug 14, 2012, at 3:49 PM, Berend Hasselman wrote:
>
>> On 14-08-2012, at 20:10, Simon Urbanek wrote:
>>
>>> Mountain Lion has been around for a few days and, interestingly, so far no
>>> one has complained here, but the default privacy settin
Erika tracked this down to a known issue with valgrind and (C-level)
system calls. See https://bugs.kde.org/show_bug.cgi?id=301281
I've added a workaround in R-patched/R-devel: set the environment
variable R_OSX_VALGRIND (to anything), preferably before starting the
session but I guess it wou
