[R-SIG-Mac] Here's what Steve said
Prof Brian Ripley
ripley at stats.ox.ac.uk
Mon Mar 21 14:19:19 CET 2011
On Sun, 20 Mar 2011, Berend Hasselman wrote:
>
> On 20-03-2011, at 20:49, Tracy Lightcap wrote:
>
>> Simon:
>>
>> I sent part of your post to Steve Jobs and he wrote back (!). Here's
>> what he said. Is he still dancing around the issue about gfortran?
>>
>
> I would say yes.
> Can Apple guarantee that Intel Fortran and Apple's C compiler coexist and cooperate flawlessly?
> Anyone using R on the Mac and wishing to compile R and/or develop packages with some Fortran would have to get the Intel Fortran compiler according to Job's recommendation. If I'm correct, Intel's compiler are not cheap. Most of us wouldn't want to spend that kind of money.
>
> If and when a transition is necessary, then we'll just have to hope that Simon finds a way of making gfortran usable in the new setup.
>
> As long as we can use Xcode 3, there shouldn't be a problem.
>
> To be honest, I don't think Apple really cares about things such as R.
> The ultimate alternative would be to ditch Mac OS X and change to
> something else.
I don't think that is necessary. Provided you have a reasonable C
compiler to start from, you can always build and install your own GNU
toolchain and build R with that. And that is what fink, MacPorts, ...
do, as I understand it. Simon rightly warns that they give you other
things you do not want, but that's not stopping a simple solution.
There are two relevant things which I know of which are special to the
Apple toolchain.
1) Support (or level of support) for Objective C(++). That's not an
issue for R nor for any of the packages: it is for R.app. However,
the latter is compiled separately and 'should' link to a libR.dylib
compiled under a non-Apple toolchain.
2) The ability to make 'fat binaries' by things like
gcc -arch i386 -arch x86_64
and more generally to select the architecture in this way. However,
we hardly use fat binaries in R (only Rscript, AFAIR) and once ppc is
no longer supported, the standard -m32 and -m64 flags will work with
the standard GCC toolchain.
I would be staggered if the task of producing a suitable toolchain for
Mac OS X was 50% of the work needed for Windows. But of course
someone would need to be prepared to do it, and I suspect that the
volume of Mac users of R is less than 10% of that for Windows.
>
> Apologies for the rant but I really do feel that Apple is behaving stupidly and shortsightedly in this case.
>
> Berend
>
>> Tracy
>>
>> Begin forwarded message:
>>
>>> From: Steve Jobs <sjobs at apple.com>
>>> Date: March 20, 2011 3:29:01 PM EDT
>>> To: "tlightcap at lagrange.edu" <tlightcap at lagrange.edu>
>>> Subject: Fwd: R and your stance on Fortran
>>>
>>>
>>>>
>>>> Xcode 4 (and our general evolution away from gcc to clang/LLVM)
>>>> does not change the availability of Fortran (or the R programming
>>>> language) on the Mac. GNU will continue to distribute GCC (and
>>>> gfortran) for the Mac and code generated by that compiler will
>>>> continue to integrate with code built with our modern clang/LLVM
>>>> tools. (As an aside, our recommended solution for Fortran on the
>>>> Mac has long been the Intel Fortran compiler -- it generates much
>>>> better performing code than GCC's Fortran).
>>>>
>>>>>
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> Resent-From: sjobs at apple.com
>>>>>> From: Tracy Lightcap <tlightcap at lagrange.edu>
>>>>>> Date: March 17, 2011 9:38:32 AM PDT
>>>>>> Resent-To: steve+sjobs2 at apple.com
>>>>>> To: steve at apple.com
>>>>>> Subject: R and your stance on Fortran
>>>>>>
>>>>>> Steve:
>>>>>>
>>>>>> I use R as my main stats engine, as do a lot of Mac users;
>>>>>> there's even a list serv for Mac R users. Now I read this in one
>>>>>> of the posts there:
>>>>>>
>>>>>> As Brian (Ripley, professor of applied statistics, Oxford)
>>>>>> pointed out, R doesn't care. The only annoying part for me as a
>>>>>> Mac binary maintainer is that it means Apple has abandoned the
>>>>>> only branch that supported Fortran back-end, so in the future we
>>>>>> will not be able to provide native Fortran for Xcode. This has
>>>>>> been known for a while and Apple's stance is that they don't care
>>>>>> about Fortran, so in some (but not immediate) future we may be
>>>>>> back to the mess of mixing compilers.
>>>>>>
>>>>>> Note that LLVM and clang don't really have any real benefits for
>>>>>> the R users so far. Tests suggest that they make some parts
>>>>>> slower and we could not measure any overall benefit (unlike let's
>>>>>> say on arm), so people were not rushing to llvm/clang so far.
>>>>>> Apple's move to llvm/clang is really based on a political
>>>>>> decision, not a technical one. The only benefit I see so far is
>>>>>> what Brian mentioned as well that some people will have to
>>>>>> realize that gcc is not the standard and can test on other
>>>>>> compilers to find their bugs.
>>>>>>
>>>>>> Cheers,
>>>>>> Simon (Urbanek, statistics research, AT&T Labs)
>>>>>>
>>>>>> Is it really true that Apple, a company that is alive today
>>>>>> largely due to its inroads in education, is willing to put the
>>>>>> distribution of the most rapidly growing statistics engine used
>>>>>> by academics in jeopardy because "∑ Apple's stance is that they
>>>>>> don't care about Fortran ∑"? R has recently been adopted as the
>>>>>> official language by the Interuniversity Consortium for Political
>>>>>> and Social Research at the University of Michigan, the biggest
>>>>>> trainer of social science grad students in the country. It is
>>>>>> being adopted by universities and colleges, governments, and
>>>>>> research institutions at a staggering pace (the price is right,
>>>>>> you know). That the use of this extremely useful and powerful
>>>>>> application on the Macs in education should be put at risk by a
>>>>>> simple reluctance to not accommodate Fortran is not just unwise;
>>>>>> it's just plain silly.
>>>>>>
>>>>>> Is Simon right? If he is, fix it. Now.
>>>>>>
>>>>>> Tracy Lightcap
>>>>>> Professor and Chair
>>>>>> Department of Political Science
>>>>>> LaGrange College
>>>>>> 601 Broad St.
>>>>>> LaGrange GA 30240-2999
>>>>>> (O) tlightcap at lagrange.edu (H) altlamp at mindspring.com
>>>>>> 706.880.8226
>>>>>> www.lagrange.edu/academics/political-science/faculty/tlightcap.aspx
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>> Tracy Lightcap
>> Professor and Chair
>> Department of Political Science
>> LaGrange College
>> 601 Broad St.
>> LaGrange GA 30240-2999
>> (O) tlightcap at lagrange.edu (H) altlamp at mindspring.com
>> 706.880.8226
>> www.lagrange.edu/academics/political-science/faculty/tlightcap.aspx
>>
>>
>>
>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-SIG-Mac
mailing list