[Rd] Detaching "ctest"
Thu, 5 Apr 2001 21:30:11 +0200
>>>>> Jonathan Rougier writes:
> On Fri, 30 Mar 2001, Kurt Hornik wrote:
>> >>>>> Peter Dalgaard BSA writes:
>> > ...
>> >> 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.
>> Nice idea! Two remarks.
>> * We might want similar ways of setting `preferences' such as options.
>> [E.g., via something like Emacs M-x customize, or in a GUI style.]
>> * In any case, as far as I am concerned the real problem is not having a
>> convenient interface but on agreeing on what the choices should be,
>> and how well-educated users or site admins need to be to make the
>> right choices. E.g., when it comes to setting a default profile for
>> packages, how does the user find out which packages he wants?
> I certainly agree with this last point. However, the problem is
> lessened if the user can use .Rprofile to tune the set-up. The
> current arrangement prevents that (or, at least, makes it rather
> inelegant) by using .First to load ctest (and, in the future, other
> mandatory packages?). It seems to me that in an ideal world .Rprofile
> would be the very last thing invoked before the prompt. That way
> whatever set-up is put in place by the system administrator or the
> default, the individual user still has control.
But this is exactly what happens---settings from .Rprofile do override
the system and site defaults. The question is whether .First should be
used for package setup, or something else ...
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: email@example.com