[Rd] odd assignInNamespace / setGeneric interaction

[Martin Maechler]

>>>>> 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