[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
needed):
install_name_tool -change `otool -L ~/R.app/Contents/MacOS/R|grep
'libR\.dylib'|sed 's|.\(.\{0,\}\) (comp.\{0,\}|\1|'` libR.dylib ~/
R.app/Contents/MacOS/R
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...
Cheers,
Simon
More information about the R-SIG-Mac
mailing list