On Sep 16, 2011, at 11:56 AM, Simon Urbanek wrote:
>
> 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.
>
Ok, just to be really explicit to avoid further confusion:
If you want to use CRAN R builds in parallel then the safest approach is to
modify the R script by:
a) changing unversioned framework paths to versioned ones
*and*
b) set the Current symlink to the version that is being started
This is as safe as you can get with pre-built binaries, but it has the
limitation I mentioned (no concurrent package compilation with different
versions in parallel). All this will *only* work on the command line and you
will still have issues with things that have been built on R with with
non-versioned paths (i.e., CRAN) which include hard-coded paths (but this
should be very rare).
For anything more safe you'll have to build R yourself (either without a
framework or without installing it into a framework).
Cheers,
Simon
>
>>
>>
>>
>> On Fri, Sep 16, 2011 at 11:15 AM, Simon Urbanek
>> <[email protected]> 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
>>>> <[email protected]> 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
>>>>> [email protected]
>>>>> 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
>>
>>
>
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
