>>>>> Michael Lawrence <lawrence.mich...@gene.com>
>>>>> on Wed, 18 Apr 2018 14:16:37 -0700 writes:
> Hi Bill,
> Ideally, your coworker would just make an alias (or shortcut or
> whatever) for R that passed --no-save to R. I'll try to look into this
> though.
> Michael
Yes, indeed!
As some of you know, I've been using R (for ca 23 years now)
almost only from ESS (Emacs Speaks Statistics).
There, I've activated '--no-save' for ca 20 years or so,
nowadays (since Emacs has adopted "custom") I have had this in
my ~/.emacs custom lines
'(inferior-R-args "--no-restore-history --no-save ")
standalone (to paste into your own ~/.emacs ) :
(custom-set-variables '(inferior-R-args "--no-restore-history --no-save "))
--------
The current fashionable IDE to R,
Rstudio, also allows to set such switches by its GUI:
Menu [Tools]
--> (bottom) entry [Global Options]
--> the first sidebar entry [R General]:
Look for two lines mentioning "workspace" or ".RData" and
change to 'save never' ( == --no-save),
and nowadays I also recommend my students to not *read*
these, i.e., '--no-restore'
---
@Michael: I'm not sure what you're considering. I feel that in
general, there are already too many R startup tweaking
possibilities, notably via environment variables.
[e.g., the current ways to pre-determine the active .libPaths() in R,
and the fact the R calls R again during 'R CMD check' etc,
sometimes drives me crazy when .libPaths() become incompatible
for too many reasons .... yes, I'm diverting: that's another story]
If we'd want to allow using (yet another!) environment variable
here, I'd at least would make sure they are not consulted when
explicit --no-save or --vanilla, etc are used.
Martin
> On Wed, Apr 18, 2018 at 1:38 PM, William Dunlap via R-devel
> <r-devel@r-project.org> wrote:
>> A coworker got tired of having to type 'yes' or 'no' after quitting R: he
>> never wanted to save the R workspace when quitting. So he added
>> assignInNamespace lines to his .Rprofile file to replace base::q with
>> one that, by default, called the original with save="no"..
>>
>> utils::assignInNamespace(".qOrig", base::q, "base")
>> utils::assignInNamespace("q", function(save = "no", ...)
>> base:::.qOrig(save = save, ...), "base")
>>
>> This worked fine until he decide to load the distr package:
>>
>> > suppressPackageStartupMessages(library(distr))
>> Error: package or namespace load failed for ‘distr’ in
>> loadNamespace(name):
>> there is no package called ‘.GlobalEnv’
>>
>> distr calls setGeneric("q"), which indirectly causes the environment
>> of base::q, .GlobalEnv, to be loaded as a namespace, causing the error.
>> Giving his replacement q function the environment getNamespace("base")
>> avoids the problem.
>>
>> I can reproduce the problem by making a package that just calls
>> setGeneric("as.hexmode",...) and a NAMEPACE file with
>> exportMethods("as.hexmode"). If my .Rprofile puts a version of
as.hexmode
>> with environment .GlobalEnv into the base namespace, then I get the same
>> error when trying to load the package.
>>
>> I suppose this is mostly a curiosity and unlikely to happen to most
people
>> but it did confuse us for a while.
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
