[R-SIG-Mac] RSwitch - making it easier to test pre-release versions of R

Simon Urbanek simon.urbanek at r-project.org
Wed Sep 20 01:55:08 CEST 2006

On Sep 19, 2006, at 6:18 PM, Kasper Daniel Hansen wrote:

> [...]
> In a way I guess that is the same as the release candidate, but  
> there seems to be a release candidate as well as a devel version on  
> Simon's R page (I assume that the devel version there is the stuff  
> that is going to be either R-2.4.1 or R.2.5.0)

Just for completeness - R-devel = trunk = future 2.5.0, R24-branch =  
future 2.4.0 [alpha now] (once 2.4.0 is out it will be future 2.4.0  
patched, then 2.4.1 etc.).

> * If I have a running R session, will this session be affected by  
> switching the symlink?

It depends on the R_HOME used by the session, but mostly yes -  
whenever R needs to access R_HOME (packages installation for  
example), it will be affected by the switch. By default R uses the  
current version, but that can be changed either by modifying R_HOME  
in the R shell script or by using R.app.

> * I think it would be quite valuable to have a Versions hierarchy  
> inside ~/Library/R

Yes. On one hand, it's entirely up to the user what s/he uses, but  
the R.app GUI could default to ~/Library/R/x.y

> * Would it be easy to have Rswitch report some more specifics on  
> the R-version, at least for the "devel" version, right now all I  
> see is 2.4, whereas R --version reports something like R-2.4.0  
> alpha (date, revision).

Not easily, but possible. Currently it simply shows you the  
directories in R.framework/Versions, so you can name them any way you  
want (in theory, you'll need to re-install the framework).

> * Perhaps it would make sense to have the versions in the  
> R.framework be x.y.z instead of now where they are x.y.

This change (from x.y.z to x.y) is deliberate, because framework  
versions are compatible at patch-level, so in order to allow easy  
upgrade from x.y.0 to x.y.1 we need the same name. However, you can  
create any custom versions you want. It is not documented, but possible.

> And perhaps even allow for something R-devel, R-alpha, R-patched? I  
> have no idea whether that would be easy or feasible.

It is just directories, they have no intrinsic meaning, so feel  
free :). Technically, it would be possible to allow non-standard  
installation in make install-R-framework.

> On a grander scale it might be extremely worthwhile to make this  
> app into a menu bar thing, with the ability to pull down the newest  
> devel version. That at least would make life even easier for  
> someone like me.

I can post the source, it's really tiny, so if someone has a skeleton  
of a menu-bar app, it should be possible to merge it.

Since we are speaking about different R versions and testing - there  
is one cool trick that allows you to run arbitrary non-installed(!) R  
versions via the R.app GUI. Let's say you have copied the R.app GUI  
to your home directory. First you need to modify it slightly (Xcode  

install_name_tool -change `otool -L ~/R.app/Contents/MacOS/R|grep  
'libR\.dylib'|sed 's|.\(.\{0,\}\) (comp.\{0,\}|\1|'` libR.dylib ~/ 

then you can use any R to run it like this:

R CMD ~/R.app/Contents/MacOS/R

Of course, if the libR is too different, it may fail, but you can  
test R without "make install" this way (no framework needed). You can  
create a battery of shell scripts for all your favorite R versions  
and run them form Finder...


More information about the R-SIG-Mac mailing list