I know ls("package:grid") and find.funs("package:grid") in mvbutils but apparently neither of them can find non-exported functions and methods that are only accessible internally or with ::: or getAnywhere.
I've had to source the files in the /R directory of the source package and use ls() on a clean global environment, but there must be a better way, no?
you can use asNamespace:
> methods(cbind)
[1] cbind.data.frame cbind.grobGrid cbind.ts*
Non-visible functions are asterisked
> r <- unclass(lsf.str(envir = asNamespace("stats"), all = T))
> r[grep("cbind.ts", r)]
[1] ".cbind.ts" "cbind.ts"
cbind.ts in stats package is invisible but can find in envir = asNamespace("stats").
This appears to be something of a perennial here.
If it's this one-liners you're after then this should be a contender (credit #Joshua):
ls(getNamespace("grid"), all.names=TRUE)
(Link is to a question that was asked after the above, but closely related).
As grid is a base package and I haven't yet moved up to R 3... I'm getting 756 functions with Version 2.15.1. vs. 503 from the unclass solution.
Related
I have successfully redefined utils::View as a generic function so that I can use it my package. However, it so happens that RStudio also defines some kind of hook on this function.
Before loading my package, I see:
> View
function (...)
.rs.callAs(name, hook, original, ...)
<environment: 0x000001f74d5ff0b0>
And looking for that .rs.callAs function, I get:
> findFunction('.rs.callAs')
[[1]]
<environment: 0x000001f74eb94598>
attr(,"name")
[1] "tools:rstudio"
After loading my package, I see:
> View
standardGeneric for "View" defined from package "summarytools"
function (...)
standardGeneric("View")
<bytecode: 0x000001f752ecb7e0>
<environment: 0x000001f754a8e678>
Methods may be defined for arguments: ...
Use showMethods("View") for currently available ones.
Since tools:rstudio is not directly visible, I'm not sure there's anything I can do about it. And if I can somehow include its definition in my package, I'm not sure at all that I can redefine View differently depending on whether the R session is running in RStudio or not.
I'm clearly not very optimistic about this, but I thought of asking here before giving up!
I have a weird behavior, when running my R program on another machine.
When I try to run a data.table join df1[df2] I get the error message
Error in `[.default`(x, i) : invalid subscript type 'list'
I assume that for some reason the R environment on the other machine does not find the data.table bracket function (Although I have loaded the library there).
To force R to use the bracket from data.table I would like to call the bracket function explicitly, but I can't find out how.
Here what I've tried
library(data.table)
df1 <- data.frame(a = c("a1","a2","a3"), n = c(1,2,3), b = c(T,T,T))
df2 <- data.frame(a = c("a1","a2","a3"), n = c(1,2,3), b = c(F,T,F))
df1 <- data.table(df1)
df2 <- data.table(df2)
setkey(df1,a,n,b)
setkey(df2,a,n,b)
df1[df2] # produces `[.default`(x, i) : invalid subscript type 'list'
# my tries to call `[.data.table` explicitly all produce errors
`[.data.table`(df1, df2)
data.table::`[.data.table`(df1, df2)
data.table::`[`(df1, df2)
How can I use the bracket function from the data.table package explicitly?
EDIT:
OK, I'm trying to find the root cause of the error.
I'm using R version 3.2.1,
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] data.table_1.9.2 mypackage_1.0 ROracle_1.1-10 DBI_0.2-7
loaded via a namespace (and not attached):
[1] plyr_1.8.1 reshape2_1.4 Rcpp_0.11.2 stringr_0.6.2
is.data.table gives TRUE on both, df1 and df2 just before calling df1[df2] (I'm debugging through the code).
The function that contains the codeline df1[df2] is called inside mypackage_1.0 (A package I'm developing). I have noticed, that if I run the code line by line, instead of calling my package function and debugging it, the code works as expected. So I assume there is something wrong with the package. In the DESCRIPTION file I only import the package data.table under "Suggests". Might it be related to that?
To long for a comment so posting as answer.
General comments related to your case.
You can call [.data.table explicitly by calling not exported data.table function using ::: operator.
data.table:::`[.data.table`(x, i)
Using ::: is not a best practice, as it makes you responsible for a function which package author decided not to expose to users directly. You should keep that in mind, still the R CMD check will not raise an error or warning. According to Writing R Extensions:
Using foo:::f instead of foo::f allows access to unexported objects. This is generally not recommended, as the semantics of unexported objects may be changed by the package author in routine maintenance.
In my opinion if you develop and internal package which will be deployed with explicitly stated version of dependencies, it is pretty safe to use :::.
Update your data.table version, 1.9.2 is pretty old release already.
In your DESCRIPTION file use Imports data.table and don't forget to define imports in NAMESPACE file
Debug your problematic machine with the following
if(is.data.table(df1) && is.data.table(df2)) df1[df2] else stop("not a data.table")
Use sessionInfo() as one of your first step in debugging cross package issues to track attached packagess.
This question is sort of a follow up to this post as I'm still not fully convinced that, with respect to code robustness, it wouldn't be far better to make typing namespace::foo() habit instead of just typing foo() and praying you get the desired result ;-)
Actual question
I'm aware that this goes heavily against "standard R conventions", but let's just say I'm curious ;-) Is it possible to attach a temporary namespace to the search path somehow?
Motivation
At a point where my package mypkg is still in "devel stage" (i.e. not a true R package yet):
I'd like to source my functions into an environment mypkg instead of .GlobalEnv
then attach mypkg to the search path (as a true namespace if possible)
in order to be able to call mypkg::foo()
I'm perfectly aware that calling :: has its downsides (it takes longer than simply typing a function's name and letting R handle the lookup implicitly) and/or might not be considered necessary due to the way a) R scans through the search path and b) packages may import their dependencies (i.e. using "Imports" instead of "Depends", not exporting certain functions etc). But I've seen my code crash at least twice due to the fact that some package has overwritten certain (base) functions, so I went from "blind trust" to "better-to-be-safe-than-sorry" mode ;-)
What I tried
AFAIU, namespaces are in principle nothing more than some special kind of environment
> search()
[1] ".GlobalEnv" "package:stats" "package:graphics"
[4] "package:grDevices" "package:utils" "package:datasets"
[7] "package:methods" "Autoloads" "package:base"
> asNamespace("base")
<environment: namespace:base>
And there's the attach() function that attaches objects to the search path. So here's what I thought:
temp.namespace <- new.env(parent=emptyenv())
attach(temp.namespace)
> asNamespace("temp.namespace")
Error in loadNamespace(name) :
there is no package called 'temp.namespace'
I guess I somehow have to work with attachNamepace() and figure out what this expects before it is called in in library(). Any ideas?
EDIT
With respect to Hadley's comment: I actually wouldn't care whether the attached environment is a full-grown namespace or just an ordinary environment as long as I could extend :: while keeping the "syntactic sugering" feature (i.e. being able to call pkg::foo() instead of "::"(pkg="pkg", name="foo")()).
This is how function "::" looks like:
> get("::")
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
getExportedValue(pkg, name)
}
This is what it should also be able to do in case R detects that pkg is in fact not a namespace but just some environment attached to the search path:
"::*" <- function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
paths <- search()
if (!pkg %in% paths) stop(paste("Invalid namespace environment:", pkg))
pos <- which(paths == pkg)
if (length(pos) > 1) stop(paste("Multiple attached envirs:", pkg))
get(x=name, pos=pos)
}
It works, but there's no syntactic sugaring:
> "::*"(pkg="tempspace", name="foo")
function(x, y) x + y
> "::*"(pkg="tempspace", name="foo")(x=1, y=2)
[1] 3
How would I be able to call pkg::*foo(x=1, y=2) (disregarding the fact that ::* is a really bad name for a function ;-))?
There is something wrong in your motivation: your namespace does NOT have to be attached to the search path in order to use the '::' notation, it is actually the opposite.
The search path allows symbols to be picked by looking at all namespaces attached to the search path.
So, as Hadley told you, you just have to use devtools::load_all(), that's all...
I'm trying to test whether a particular variable or function exists in a package. For example, suppose I wanted to test whether a function called plot existed in package 'graphics'.
The following tests whether a function plot exists, but not what package it comes from:
exists('plot', mode='function')
Or I can test that something called plot exists in the graphics package, but this doesn't tell me whether it's a function:
'plot' %in% ls('package:graphics')
Is there a nice way to ask "does an object called X exist in package Y of mode Z"? (Essentially, can I restrict exists to a particular package?)
(Yes, I can combine the above two lines to first test that plot is in graphics and then ask for the mode of plot, but what if I had my own function plot masking graphics::plot? Could I then trust the output of exists('plot', mode='function')? )
Background: writing tests for a package of mine and want to test that various functions are exported. I'm using package testthat which executes tests in an environment where I can see all the internal functions of the package, and have been stung by exists('myfunction', mode='function') returning true, but I've actually forgotten to export myfunction. I want to test that various functions are exported.
Oh, I found it.
I noticed that in ?ls it says that the first argument ('package:graphics' for me) also counts as an environment. exists' where argument has the same documentation as ls' name argument, so I guessed 'package:graphics' might work there too:
exists('plot', where='package:graphics', mode='function')
[1] TRUE # huzzah!
environment(plot)
<environment: namespace:graphics>
find('+')
#[1] "package:base"
find('plot')
#[1] "package:graphics"
find('plot', mode="function")
#[1] "package:graphics"
All the answers proposed previously walk environments, not namespaces. Their behavior will therefore differ depending on whether the target package was loaded with library(), and in what order.
Here is an approach with utils::getFromNamespace():
function_exists <- function(package, funcname) {
tryCatch({
utils::getFromNamespace(funcname, package)
TRUE
}, error = function(...) { FALSE })
}
An R namespace acts as the immediate environment for all functions in its associated package. In other words, when function bar() from package foo calls another function, the R evaluator first searches for the other function in <environment: namespace:foo>, then in "imports.foo", <environment: namespace:base>, <environment: R_GlobalEnv>, and so on down the search list returned by typing search().
One nice aspect of namespaces is that they can make packages act like better citizens: unexported functions in <environment: namespace:foo> and functions in imports:foo are available only: (a) to functions in foo; (b) to other packages that import from foo; or (c) via fully qualified function calls like foo:::bar().
Or so I thought until recently...
The behavior
This recent SO question highlighted a case in which a function well-hidden in its package's namespace was nonetheless found by a call to a seemingly unrelated function:
group <- c("C","F","D","B","A","E")
num <- c(12,11,7,7,2,1)
data <- data.frame(group,num)
## Evaluated **before** attaching 'gmodels' package
T1 <- transform(data, group = reorder(group,-num))
## Evaluated **after** attaching 'gmodels
library(gmodels)
T2 <- transform(data, group = reorder(group,-num))
identical(T1, T2)
# [1] FALSE
Its immediate cause
#Andrie answered the original question by pointing out that gmodels imports from the the package gdata, which includes a function reorder.factor that gets dispatched to inside the second call to transform(). T1 differs from T2 because the first is calculated by stats:::reorder.default() and the second by gdata:::reorder.factor().
My question
How is it that in the above call to transform(data, group=reorder(...)), the dispatching mechanism for reorder finds and then dispatches to gdata:::reorder.factor()?
(An answer should include an explanation of the scoping rules that lead from a call involving functions in the stats and base packages to a seemingly well-hidden method in gdata.)
Further possibly helpful details
Neither gdata:::reorder.factor, nor the gdata package as a whole are explicitly imported by gmodels. Here are the import* directives in gmodels' NAMESPACE file:
importFrom(MASS, ginv)
importFrom(gdata, frameApply)
importFrom(gdata, nobs)
There are no methods for reorder() or transform() in <environment: namespace:gmodels>, nor in "imports:gmodels":
ls(getNamespace("gmodels"))
ls(parent.env(getNamespace("gmodels")))
Detaching gmodels does not revert reorder()'s behavior: gdata:::reorder.factor() still gets dispatched:
detach("package:gmodels")
T3 <- transform(data, group=reorder(group,-num))
identical(T3, T2)
# [1] TRUE
reorder.factor() is not stored in the list of S3 methods in the base environment:
grep("reorder", ls(.__S3MethodsTable__.))
# integer(0)
R chat threads from the last couple of days include some additional ideas. Thanks to Andrie, Brian Diggs, and Gavin Simpson who (with others) should feel free to edit or add possibly impt. details to this question.
I'm not sure if I correctly understand your question, but the main point is that group is character vector while data$group is factor.
After attaching gmodels, the call for reorder(factor) calls gdata:::reorder.factor.
so, reorder(factor(group)) calls it.
In transform, the function is evaluated within the environment of the first argument, so in T2 <- transform(data, group = reorder(group,-num)), group is factor.
UPDATED
library attaches the import packages into loaded namespace.
> loadedNamespaces()
[1] "RCurl" "base" "datasets" "devtools" "grDevices" "graphics" "methods"
[8] "stats" "tools" "utils"
> library(gmodels) # here, namespace:gdata is loaded
> loadedNamespaces()
[1] "MASS" "RCurl" "base" "datasets" "devtools" "gdata" "gmodels"
[8] "grDevices" "graphics" "gtools" "methods" "stats" "tools" "utils"
Just in case, the reorder generic exists in namespace:stats:
> r <- ls(.__S3MethodsTable__., envir = asNamespace("stats"))
> r[grep("reorder", r)]
[1] "reorder" "reorder.default" "reorder.dendrogram"
And for more details
The call of reorder will search the S3generics in two envs:
see ?UseMethod
first in the environment in which the generic function is called, and then in the registration data base for the environment in which the generic is defined (typically a namespace).
then, loadNamespace registers the S3 functions to the namespace.
So , in your case, library(gmodels) -> loadNamespace(gdata) -> registerS3Methods(gdata).
After this, you can find it by:
> methods(reorder)
[1] reorder.default* reorder.dendrogram* reorder.factor*
Non-visible functions are asterisked
However, as the reorder.factor is not attached on your search path, you cannot access it directly:
> reorder.factor
Error: object 'reorder.factor' not found
Probably this is whole scenario.