-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error in loadNamespace(name) : #68
Comments
Hm, I think it's because the directory name is different from what profvis is looking for. @hadley was there a change in devtools so that packages are built in a directory like
|
@jimhester is more likely to know than me |
This is the content of the Rprof output file:
The problem is that profvis tries to infer the package name from the path, but in this case the directory name isn't the same as the package name. (We can't always count on the user calling |
It looks like the zip files from GitHub use that convention (like |
When you say package name, I presume you mean |
I'd also prefer not to require people to have to manually enter a package, and also there could be multiple packages installed that way. Also, if it required an option, I'm not sure how that would be exposed in the RStudio IDE for people who want to start profiling via the GUI. When I say not 100% reliable, I mean that it will probably work for 99% of cases. What I have in mind won't work if the repo name differs from the package name, and I don't know if it will work for packages from other sources (like bitbucket). |
I'm also bumping into this issue. Note that this occurs for me with the current EDIT: I think I'm bumping into something slightly different so I'll record that in a separate issue. |
Note that detecting the package name based on the repository name won't work in general (e.g. the package |
@kevinushey that's one of the of cases in the 1% that I had in mind. :-/ Here's the challenge: given the data in the Rprof data file, how do you find the
If the directory were something like An alternative is to have devtools rename the directory to match what's in the |
Ack, good point! If that's the case then perhaps a failed attempt to load the namespace of an inferred package should not be an error? (I think it would just imply we don't have source references; is that correct?) It would also be nice if |
The issue is these RProf is returning the name of the source file alias, not the original source file. You can get the latter from the passed function directly, which will also get you the package name. devtools::install_github("csgillespie/efficient", args="--with-keep.source", force=TRUE)
library(efficient)
attr(attr(simulate_monopoly, "srcref"), "srcfile")$original
#> /Users/jhester/Library/R/3.3/library/efficient/R/efficient |
I should note this isn't really a devtools issue, you will see the same behavior anytime you install a package from a directory with a different name than the package name. We could change the devtools behavior, but this case would still remain. git2r::clone("https://github.com/csgillespie/efficient", "test")
install.packages("test", repos = NULL, type = "source", INSTALL_opts = "--with-keep.source")
library(efficient)
attr(attr(simulate_monopoly, "srcref"), "srcfile")
#> /.../R/test/R/monopoly.R |
@jimhester Do you see a way to get the package name we don't have the actual function object? That could happen if you ran |
I've added some heuristics that will work where the package directory is |
@wch You can get a mapping of all files used in loaded namespaces along with their package name with the following, which can then be used to find the figure out what namespace to load. It is basically instantaneous to run. # helper to extract captures
regcaptures <- function(x, m) {
ind <- !is.na(m) & m > -1L
so <- attr(m, "capture.start")[ind]
eo <- so + attr(m, "capture.length")[ind] - 1L
substring(x[ind], so ,eo)
}
package_map <- function(loaded_ns = loadedNamespaces()) {
res <- lapply(loaded_ns, function(ns) {
# Get the first exported function, need to filter out S4 mangled names however (.__T__)
first_export <- head(grep("^\\.__[TC]__", getNamespaceExports(ns), value = TRUE, invert = TRUE, fixed = FALSE), n = 1)
if (length(first_export) > 0) {
f <- get(first_export, envir = asNamespace(ns), inherits = FALSE)
src <- getSrcref(f)
if (!is.null(src)) {
# retrieve all of the source lines from the installed namespace, which
# have the source line directives included
lines <- getSrcLines(attr(src, "srcfile"), 1, Inf)
# Find and extract the line directives
m <- regexpr("^#line \\d+ \"(.*)\"$", lines, perl = TRUE)
regcaptures(lines, m)
}}})
data.frame(filename = unlist(res), package = rep(loaded_ns, times = lengths(res)))
}
map <- package_map()
head(map)
#> filename
#> 1 /.../test/R/datasets.R package
#> 2 /.../test/R/monopoly.R efficient
#> 3 /.../test/R/snakes_and_ladders.R efficient
#> 4 /.../test/R/test_rcpp.R efficient
#> 5 /.../RtmpOolYvL/devtools64c82ab8169f/rstats-db-DBI-73e0945/R/DBObject.R DBI
#> 6 /.../RtmpOolYvL/devtools64c82ab8169f/rstats-db-DBI-73e0945/R/DBDriver.R DBI |
@jimhester That's great! It's better than the fix that I put in. I think my fix will still be useful as a fallback, in case the package in question isn't loaded. (This can happen if the Rprof file was generated outside of profvis.) |
I'm trying to profile some relatively simple code. The code below worked a few months ago:
A couple of other points:
R CMD INSTALL
profvis is happy.R> profvis::profvis(efficient::simulate_monopoly(10)) Error in parse_rprof(prof_output, expr_source) : No parsing data available. Maybe your function was too fast?
The number
10
affects the length of the simulation.Neither of the functions are byte-compiled.
A bit more info:
The text was updated successfully, but these errors were encountered: