>>>>> 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
The problem is not specific to redefining the q function, but to the interaction of assignInNamespace and setGeneric. The latter requires, roughtly, that the environment of the function being replaced by an S4 generic is (or is the descendent of) the environment in which it lives. E.g., the following demonstrates the problem % R --quiet --vanilla> assignInNamespace("plot", function(x, ...) stop("No plotting allowed!"),getNamespace("graphics"))> library(stats4)Error: package or namespace load failed for ?stats4? in loadNamespace(name): there is no package called ?.GlobalEnv? and defining the bogus plot function in the graphics namespace avoids the problem % R --quiet --vanilla> assignInNamespace("plot", with(getNamespace("graphics"), function(x,...) stop("No plotting allowed!")), getNamespace("graphics"))> library(stats4) >I suppose poeple who use assignInNamespace get what they deserve. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Apr 19, 2018 at 2:33 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:> >>>>> 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 >[[alternative HTML version deleted]]
Michael Lawrence
2018-Apr-19 16:40 UTC
[Rd] odd assignInNamespace / setGeneric interaction
To clarify, I am going to fix the issue in the methods package (actually I already have but need to test further). There's no intent to change the behavior of q(). On Thu, Apr 19, 2018 at 8:39 AM, William Dunlap <wdunlap at tibco.com> wrote:> The problem is not specific to redefining the q function, but to > the interaction of assignInNamespace and setGeneric. The > latter requires, roughtly, that the environment of the function > being replaced by an S4 generic is (or is the descendent of) > the environment in which it lives. > > E.g., the following demonstrates the problem > > % R --quiet --vanilla >> assignInNamespace("plot", function(x, ...) stop("No plotting allowed!"), >> getNamespace("graphics")) >> library(stats4) > Error: package or namespace load failed for ?stats4? in loadNamespace(name): > there is no package called ?.GlobalEnv? > > and defining the bogus plot function in the graphics namespace avoids the > problem > > % R --quiet --vanilla >> assignInNamespace("plot", with(getNamespace("graphics"), function(x, ...) >> stop("No plotting allowed!")), getNamespace("graphics")) >> library(stats4) >> > > I suppose poeple who use assignInNamespace get what they deserve. > > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Thu, Apr 19, 2018 at 2:33 AM, Martin Maechler > <maechler at stat.math.ethz.ch> wrote: >> >> >>>>> 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 > >