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 <wdun...@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
> <maech...@stat.math.ethz.ch> wrote:
>>
>> >>>>> 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
