[Rd] Detaching "ctest"

[Peter Dalgaard BSA]

Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

> >>>>> Jonathan Rougier writes:

> >> remove(".First", pos=5)
> > Warning message: 
> > remove: variable ".First" was not found 
> >> remove(".First", inherits=TRUE)
> > Warning message: 
> > remove: variable ".First" was not found
> 
> Which looks rather strange to me ... 

One of the anomalies with the base frame is that you cannot remove
variables from it (this has to do with the fact that base has its
values bound directly to symbols, whereas other frames are essentially
hashed lists). The error message is a bit weird, though. 

> > Is it not possible to remove things from "base"?  The alternative is
> > to mask the .First with a blank one in my .Rprofile, but this seems
> > rather inelegant.

You can't. However, you wouldn't really gain anything by it since the
base frame is not saved as part of your workspace. The intended way is
as Kurt said: Override .First in your own .Rprofile.

> > So my questions are:
> 
> > (1) Why has ctest been included among the start-up options, and why has
> > this mechanism of using the .First been used, rather than relying on
> > people putting the command require("ctest", quietly=TRUE) into the
> > .Rprofile?
> 
> > (2) Is there an elegant way of me stopping ctest from being loaded, other
> > then editing the Rprofile in R-1.2.1/lib/R/library/base/R/?
> 
> There was a great amount of discussion on r-core whether or not ctest
> should be preloaded.  We all agree that base is way too large, and that
> it eventually should basically be a core S language interpreter, with
> everything else available ``on demand''.  Re add-on packages, there are
> two obvious possibilities:
> 
> * only provide base by default, and let users or site admins customize
>   the list of packages they want by default.
> 
> * provide packages like ctest (and maybe ts) by default, and have site
>   admins or users overrule the default settings.
> 
> In a Unix-centric world the former would be the obvious choice.
> However, there was great concern about the situation on Windows, where
> the intermediate ``site admin'' level typically would not be available,
> and we do not want to have first time R windows users start complaining
> about R as a stats package that cannot even do a t test.  Hence, we went
> for the latter.

Not too sure whether the former is really all that obvious even on
Unix. We'll be getting casual users there too who'd expect that
standard procedures like t.test are available by default and site
admins who wouldn't know anything about the packages they install (and
on Linux, the situation is quite often a single-user one anyway).
However, I do like the idea of having a small core, in particular with
a view to e.g. calling R in shell scripts.

I think the current situation is mainly a stopgap, which got inserted
when we realised that moving t.test into ctest and autoloading ctest
when t.test was requested led to a situation that was really difficult
to explain to users ("cor.test only works after t.test?"). Longer
term, I think we need something more elegant than .Rprofile/.First to
let the users edit their default configuration easily. I'm not quite
sure what I want, but say for the sake of argument that the user
interface was

> configure("packages")

which could do different things depending on whether you were using a
GUI, terminal interface, ESS, or maybe even batch mode. In simple
modes it might simply be based on edit()ing the output of

  data.frame(package=.packages(all=T),
             load=!is.na(match(.packages(all=T),.packages())))

- although you might want to distinguish between the usual profile-ish
things (site-level/user-level/directory-level/workspace-specific) too.
With a GUI, you'd likely want something with checkboxes instead.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._