[R-SIG-Mac] How to start two different versions of R on a Mac (in emacs)?

Simon Urbanek simon.urbanek at r-project.org
Fri Sep 16 17:56:08 CEST 2011 

On Sep 16, 2011, at 11:46 AM, Steve Lianoglou wrote:

> Hi Simon,
> 
> Thanks for the quick reply ... very informative.
> 
> I don't exactly follow on what the compiling issues are, though.
> 
> You said:
> 
>> The only remaining difference is compilation of packages which uses the R framework and thus that does rely on the Current link. You have several choices there - you can build R without a framework (that's how it's built on Linux and some people prefer to use it that way on the Mac as well), or you can run it in place or you can change the flags of your installed R to link libR directly. Obviously, this only makes sense if you want to build packages in two different R versions at exactly the same time ...
> 
> What do you mean by "running it in place" and "this only makes sense
> if you want to build packages in two different R versions at exactly
> the same time"?
> 
> Let's say I'm running R-devel in this "Kasper-fashion" and fire an
> `install.packages('whatever', by='source')`, are you saying that the
> package will be linking against the wrong libR?

Yes. The linking is done via "-framework R" so that does respect the Current symlink. As I said in the previous e-mail one of the options is to go back to
LIBR = -L$(R_HOME)/lib$(R_ARCH) -lR -dylib_file libRblas.dylib:$(R_HOME)/lib$(R_ARCH)/libRblas.dylib
which is what R uses until you install it into a framework.


> Or is there a problem
> if I'm running R-2.13 in one window, and R-devel in another, then I
> try to make them install/compile packages at the same time? I mean,
> that sounds like a weird scenario, and I'm not sure why that would
> matter anyway, but I'm trying to make sense of the "exactly the same
> time" thing here, too.
> 

I meant that compiling is the only time when it matters, so you can set the symlink properly only for one compilation but not for two in parallel. So let's say if you set the symlink in the R script then it's safe in any scenario except for the case where you run R-2.13 CMD INSTALL followed by R-devel CMD INSTALL before R-2.13 CMD INSTALL finishes.

Cheers,
Simon


> 
> 
> 
> On Fri, Sep 16, 2011 at 11:15 AM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> Just a quick heads-up on that guide -- installing nightlies from tar balls has some consequences you may want to be aware of. Most notably the installer scripts in the .pkg make sure R architectures match your system, but if you install the tar balls (which are designed for OS X 10.5) that will not be the case. This is an issue for OS X 10.6 and 10.7 since they no longer support ppc. If you really want to install the tar balls (there is no real reason to do so) you should either know what you are doing or run the postflight script (As root) *before* you mess with the Current link:
>> https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/packaging/leopard/scripts/postflight
>> 
>> Note that the guide and the script you posted essentially does what I posted here except it fails to mention the package compiling issues ;).
>> 
>> Cheers,
>> Simon
>> 
>> 
>> On Sep 16, 2011, at 11:03 AM, Steve Lianoglou wrote:
>> 
>>> Hi,
>>> 
>>> There is also a (somehow recent) post on the bioc-devel mailing list
>>> from Kasper that can help here, too:
>>> 
>>> https://stat.ethz.ch/pipermail/bioc-devel/2011-July/002684.html
>>> 
>>> He assumes you've downloaded R-2.13 and and R-devel binaries from
>>> r.research.att.net and install via the `tar fvxz R*.tar.gz -C /`
>>> 
>>> He then has a shell script (which you need to fix the line wrapping on
>>> -- I provide fixed version as a gist below) that does some minor
>>> surgery to symbolic links and changes some relative paths to absolute
>>> ones in the various ".../Resources/bin/R" files.
>>> 
>>> At the end of the day, you will have R-2.13.1 installed and invokable
>>> from the cmd line as "R" (or R-2.13), and the devel branch is
>>> invokable as R-devel.
>>> 
>>> I just used that for the R-devel bits (ie, I commented out things that
>>> have to do w/ R-2.13) and successfully compiled a mixed R/C package
>>> from source in the R-devel that I just downloaded and "relinked". I
>>> made a gist of the script from Kasper's post and commented out the
>>> lines that were messing around with R-2.13 for now:
>>> 
>>> https://gist.github.com/1222291
>>> 
>>> Perhaps you will find it helpful and hopefully not too dangerous, but
>>> use at your own risk, of course. Please be sure to read Kasper's
>>> original post and don't just run the script I linked to in the gist
>>> without understanding what it does. If there are any unintended
>>> side-effects, you'll have to reinstall your R versions from scratch,
>>> or fix your installed `.../Resources/bin/R` scripts by hand.
>>> 
>>> HTH,
>>> -steve
>>> 
>>> 
>>> On Fri, Sep 16, 2011 at 9:18 AM, Simon Urbanek
>>> <simon.urbanek at r-project.org> wrote:
>>>> 
>>>> On Sep 16, 2011, at 12:57 AM, Hofert Jan Marius wrote:
>>>> 
>>>>> 
>>>>> On 2011-09-16, at 02:30 , Simon Urbanek wrote:
>>>>> 
>>>>>> 
>>>>>> On Sep 14, 2011, at 3:02 PM, Hofert Jan Marius wrote:
>>>>>> 
>>>>>>> Dear Simon,
>>>>>>> 
>>>>>>> thanks for your help, that clarified a lot.
>>>>>>> As I could read it is not "recommended" to make the adjustment.
>>>>>>> 
>>>>>>> Can RSwitch be called from the command line? If so, one could at least create a command (or alias) "R-2.13" that first calls RSwitch and sets the version accordingly and then starts R. That would be quite convenient.
>>>>>>> 
>>>>>> 
>>>>>> Actually, it's the other way around - switching versions is trivial from the command line simply using "ln" (see the FAQ) so obviously you can do that in the script. RSwitch is just a wrapper that allows you to do that from the GUI. But note that the issue is that the Current link can only be correct for one version, so you can use one or the other but not both at the same time. Setting R home to the versioned version allows you to use both at the same time but some issues remain (compiling packages etc.).
>>>>>> 
>>>>>> Cheers,
>>>>>> Simon
>>>>> 
>>>>> Dear Simon,
>>>>> 
>>>>> thanks for helping.
>>>>> 
>>>>> I realized that setting it with ln is just a convenience [not having to click anything], but of course that does not imply that one can suddenly open two versions. I even tried and one runs into problems quite quickly.
>>>>> That's a pity, I have to admit that this is the first time that the Mac is not behaving nicely and inferior to Linux. I don't have Linux installed but as far as I know from Linux users, they can have multiple versions installed *and* work with them in parallel. As one can read on http://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Why-is-R_002ehome_0028_0029-not-versioned_003f : "The advanatage of this setup is that it is possible to install multiple R versions in parallel and they all will be fully functional ...". Obviously it is not an advantage in comparison to Linux systems. I was wondering about that, that's why I asked.
>>>>> 
>>>> 
>>>> I think you may have missed my first e-mail -- if you change the R home path to the *versioned* path then your home is no longer dependent on the Current link and thus you get the same setup as on Linux.
>>>> 
>>>> The only remaining difference is compilation of packages which uses the R framework and thus that does rely on the Current link. You have several choices there - you can build R without a framework (that's how it's built on Linux and some people prefer to use it that way on the Mac as well), or you can run it in place or you can change the flags of your installed R to link libR directly. Obviously, this only makes sense if you want to build packages in two different R versions at exactly the same time ...
>>>> 
>>>> Cheers,
>>>> Simon
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> On 2011-09-14, at 20:39 , Simon Urbanek wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sep 14, 2011, at 2:25 PM, Hofert Jan Marius wrote:
>>>>>>>> 
>>>>>>>>> Dear expeRts,
>>>>>>>>> 
>>>>>>>>> I recently switched to emacs (aquamacs) and I am amazed by its capabilities. I used to use RSwitch to switch between R-2.13 and R-2.14. Since I am now able to start R in different frames of emacs, I was wondering if I can simply start R-2.13 in one frame and R-2.14 in another frame.
>>>>>>>>> 
>>>>>>>>> On experimenting, the first thing I realized was that in a terminal, I only have "R", "R32" and "R64" available; so no "R-2.13.32bit", "R-2.14.32bit", "R-2.13.64bit", "R-2.14.64bit" [or similar]. If I start "R", it starts the version that RSwitch has selected. But that means I can't start different R versions at the same time... However, I know that it works on Linux, so is there a Mac solution, too? It would be nice if one is not required to use RSwitch but can simply choose in emacs which R version should be started.
>>>>>>>>> 
>>>>>>>>> The first step seems to be to locate the different installed R versions, which should probably be in /Library/Frameworks/R.framework/Versions/2.13/Resources and /Library/Frameworks/R.framework/Versions/2.14/Resources. But if RSwitch points to R-2.14 and I start the R version in the former directory (so R-2.13), it starts R-2.14 anyway...
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> For the command-line R (and only the command line R!) you can simply create a copy of the R launcher script and replace all occurrences of the R home path with the full *versioned* home path, so for example for 2.13 you would use something like
>>>>>>>> 
>>>>>>>> sed 's:/Library/Frameworks/R.framework/Resources:/Library/Frameworks/R.framework/Versions/2.13/Resources:g' R > R-2.13
>>>>>>>> 
>>>>>>>> This will make your R script independent of the current framework version. However, note that some things will break - for example you won't be able to compile packages properly. For details see the FAQ:
>>>>>>>> http://r.research.att.com/bin/macosx/RMacOSX-FAQ.html#Why-is-R_002ehome_0028_0029-not-versioned_003f
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Simon
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac at r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Steve Lianoglou
>>> Graduate Student: Computational Systems Biology
>>>  | Memorial Sloan-Kettering Cancer Center
>>>  | Weill Medical College of Cornell University
>>> Contact Info: http://cbio.mskcc.org/~lianos/contact
>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
>  | Memorial Sloan-Kettering Cancer Center
>  | Weill Medical College of Cornell University
> Contact Info: http://cbio.mskcc.org/~lianos/contact
> 
>

More information about the R-SIG-Mac mailing list