[R-SIG-Mac] RSwitch - making it easier to test pre-release versions of R
Rob J Goedman
goedman at mac.com
Wed Sep 20 01:30:03 CEST 2006
Could another way of using RSwitch be between two identical versions
of R, i.e. what triggers the list that shows up?
I would love to use it to switch between an R version with many
(most) packages installed and a version with hardly any additional
packages installed. Installing a package takes fairly long with many,
many installed packages - at least I think that's why the final part
of R CMD INSTALL takes a long pause after printing 'done(...)' on my
Updating/developing/testing a package, particularly when several
other are contributing as well, I tend to build/install over and over.
On Sep 19, 2006, at 3:18 PM, Kasper Daniel Hansen wrote:
> I have now played around a little with Rswitch, and I think it is a
> great idea. It makes it very easy to test packages in the devel
> version of R (which I am doing right now :).
> It seems to be very close to be extremely useable for us package
> developers, but I have some questions/suggestions below.
> Perhaps a use case is in order: generally I am less interested in
> older versions of R (but I applaud you for making it very easy to
> keep those around), I am however interested in having easy access to
> the following
> * The current devel version, since that is almost a requirement to
> be on the bleeding BioC edge
> * The release candidate when the R update time is nearing. 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)
> Now to the comments:
> * If I have a running R session, will this session be affected by
> switching the symlink?
> * I think it would be quite valuable to have a Versions hierarchy
> inside ~/Library/R
> * 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,
> * 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. And perhaps even allow
> for something R-devel, R-alpha, R-patched? I have no idea whether
> that would be easy or feasible.
> 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
> Thanks for the effort, Kasper
> On Sep 13, 2006, at 1:37 PM, Simon Urbanek wrote:
>> On Sep 13, 2006, at 11:25 AM, stefano iacus wrote:
>>> We discussed this in the past and now you remind me the point with
>>> the announcement of this nice utility.
>>> I know it can be for this release (I'm just writing it here as a
>>> memo) but this might be considered as a feature request:
>>> it would be nice to include RSwitch inside R.app with a panel
>>> showing which versions of the Framework are compatible with the
>>> particular version of R.app currently running (probably not too
>>> much variability though).
>> Technically, none. A R.app is always linked to a specific version of
>> the framework, so it won't work with any other version. In practice,
>> it might if the R API didn't change too much, but that is not
>> guaranteed. (Framework version = X.Y part of the X.Y.Z R version, so
>> patch releases are compatible, but they are installed in the same
>> location, so you cannot have multiple patch-revisions of R in
>> Versions unless you do that manually).
>> Actually, for R 2.4 and higher started through the R.app GUI, it's
>> not really an issue, because the GUI now automatically sets version-
>> specific R_HOME, so you can have two R.apps - one to start R 2.4 and
>> one to start R 2.5 and they both ignore the currently set version
>> (and can run in parallel). The "Current" symlink applies mainly to R
>> started from the command line and pre-2.4 versions of R.
>>> The selected version would be used at next start of R.app (like
>>> when you choose OS X system disk for next boot) and of course a
>>> "restart now" button would be nice as well.
>> The only way (I can think of) to provide a solution would be to put
>> the actual R.app binary inside the R framework and let the user-
>> visible R.app be just a wrapper that launches the correct R.app from
>> a framework. However, this doesn't sound quite right, because it
>> would involve two R.apps launching each other and what the user sees
>> is not what s/he gets ....
>>> The restart button is something I really miss in daily use,
>>> independently from the above feature request.
>> That is not trivial (short of writing a wrapper), because R
>> termination is handled by libR itself and not the R.app. We may want
>> to dig into that, though, because currently q("yes") will close R.app
>> without saving any open editor windows, because R.app doesn't even
>> get the message that R is closing, so it doesn't have the chance to
>> save anything - and we should definitely fix that ...
>>> On 14/set/06, at 00:04, Simon Urbanek wrote:
>>>> In case you didn't know it is possible to have multiple R versions
>>>> installed on your Mac. The R framework uses a versioning system
>>>> can keep multiple R versions in parallel at /Library/Frameworks/
>>>> You can change the current version by setting the "Current" symlink
>>>> there. For those as lazy as me there is now a small GUI tool now
>>>> available at
>>>> (on the bottom) which I call RSwitch and it allows you to change
>>>> current R version in one click. Since we are getting close to the
>>>> beta stage of the next release, the best use of it is once you
>>>> install the current alpha/beta version of R to switch between the
>>>> release and your old R version as necessary.
>>>> Note: even if you switch the current R version, you will still need
>>>> to use the corresponding version of the GUI as well, otherwise
>>>> strange things will happen. Switching versions while R is running
>>>> also have undesirable effects if you try to load packages after the
>>>> change as they will be loaded from the wrong version of R, so use
>>>> with care.
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac at stat.math.ethz.ch
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
More information about the R-SIG-Mac