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]]
Michael Lawrence
2018-Apr-18 21:16 UTC
[Rd] odd assignInNamespace / setGeneric interaction
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 On Wed, Apr 18, 2018 at 1:38 PM, William Dunlap via R-devel <r-devel at 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 at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
>>>>> Michael Lawrence <lawrence.michael at 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 at 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 at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel