[Rd] Detaching "ctest"
Kurt Hornik
Kurt.Hornik@ci.tuwien.ac.at
Tue, 10 Apr 2001 09:33:00 +0200
>>>>> Jonathan Rougier writes:
> On Mon, 9 Apr 2001, Kurt Hornik wrote:
>> >>>>> Jonathan Rougier writes:
>> > OK! if you put it like that, then I think that .First should
>> definitely > *not* be used for package set-up, as it prevents
>> .Rprofile commands from > being the last things executed before the
>> prompt, and thus removes > "complete user control" of the set-up.
>>
>> Not sure if I understand this.
>>
>> Upon startup,
>>
>> * Then, unless `--no-init-file' was given, R searches for a file
>> called `.Rprofile' in the current directory or in the user's home
>> directory (in that order) and sources it.
>>
>> * It also loads a saved image from `.RData' if there is one (unless
>> `--no-restore' or `--no-restore-data' was specified).
>>
>> * Finally, if a function `.First' exists, it is executed. This
>> function (as well as `.Last' which is executed at the end of the R
>> session) can be defined in the appropriate startup profiles, or
>> reside in `.RData'.
>>
>> as per R-intro, so the user has perfect control over what happens by
>> providing a suitable .First in e.g. his ~/.Rprofile.
> You are right -- I was discounting the "inelegant" use of an empty
> .First in .Rprofile to mask the one defined in the global environment.
> I have approached this in terms of preventing an unwanted package from
> being loaded, but I can see the advantages of using a .First
> definition in the user's .Rprofile to explicitly load packages as
> well. I guess my worry would be that as the core of R gets smaller
> and more packages are added to the default list it would be simpler
> for the user to remove the one or two packages that are not wanted,
> rather than having to specify explicitly in a .First all the packages
> that are required, as would be the case currently.
Agreed. Actually, I think that .First *is* the right mechanism for
taking care of this, but not necessarily though explicit coding. What I
have in mind is something like
R> customize()
or
R> customize("packages")
(as opposed to customize("options"))
bringing up a mechanism through which packages can be selected. (There
is an additional issue of specifying their order ...) This could then
be saved into, say, a user or site R configuration file (R.ini, .Rini),
containing e.g.
[Packages]
ctest = TRUE
ts = FALSE
etc (modulo order ...). The startup mechanism could then look for such
a file and build .First-style code from it ...
-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._