search for: importmethodsfrom

...hods)". Do I also have to import the namespace of "methods" package? 2) If I use import("pkg1") in the namespace of "pkg2", does this also (correctly) import the S4 classes and methods of "pkg1"? Or do I explicitly have to use importClassesFrom resp. importMethodsFrom? 3) If I import the Namespace of "pkg2" in "pkg3", where the namespace of "pkg2" has import("pkg1") (or maybe importClassesFrom, importMethodsFrom) and I also want to use S4 classes and methods of "pkg1" in "pkg3". Is it sufficient to...

...summary(m) } --------------------------- And my namespace file looks like this, where I've attempted to follow the instructions in "Writing R Extensions" http://cran.r-project.org/doc/manuals/R-exts.html#Name-spaces-with-S4-classes-and-methods --------------------------- import(lme4) importMethodsFrom(lme4, "summary") export("ss") --------------------------- But when I call my new function, I get the summary.default method instead of the mer method. > m <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy) > ss(m) Length Class Mode 1 mer S4 Thanks,...

...;R Under development (unstable) (2011-12-15 r57901)" section 1.6.6 of 'Writing R Extensions' says Note that exporting methods on a generic in the namespace will also export the generic, and exporting a generic in the namespace will also export its methods. and Note that importMethodsFrom will also import any generics defined in the namespace on those methods However, if PkgA promotes 'unique' to a generic and exports that DESCRIPTION: Imports: methods R/f.R: setGeneric("unique") NAMESPACE: export(unique) and PkgB creates and exports a met...

...ions: 1. Do I need to worry about this? If so, what can I do about it? I suppose I could add an importFrom directive, but it will be a pain unless there is an "allbut(diag)" option I'm not aware of. (I assume that methods and classes can be listed in importFrom, i.e., there are no importMethodsFrom or importClassesFrom functions). 2. If I don't need to worry, is there a way to turn the message off? I as a developer need to see it, but users don't and it may worry them unnecessarily. Updating all 17 of my test/*.Rout.save files is a nuisance as well, but only a nuisance. I'd l...

...AICtab") tab$AIC When I run this code as a regular R script everything works fine, tab$AIC has the desired value. But when I try to run this code from within a package I wrote, tab$AIC is NULL. I've tried adding "import(lme4)", "importClassesFrom(lme4)" and "importMethodsFrom(lme4)" into the NAMESPACE file of my package, but it didn't help, tab$AIC is still NULL. Thanks for any kind of hint! Best Regards, Ben

...t approach with caution, namespaces do change the language semantics, and we will likely encounter some surprises. The new directives, in addition to those described in Luke Tierney's article in the June, 2003 R News, are: exportClasses(...) exportMethods(...) importClassesFrom(package, ...) importMethodsFrom(package, ...) The `...' arguments are the names of classes or of generic functions as appropriate. The exportClasses and exportMethods directives export the corresponding class definitions and all the methods for the functions. Similarly, the importClassesFrom and importMethodsFrom import th...

...cover a new class with the following lines in the zzz.R file in the R directory while creating an R package. >setClass("rpa", contains="list") >show.rpa <- function (...) {cat("rpa object \n")} The corresponding lines were also added to NAMESPACE file: >importMethodsFrom(methods,show) >exportClasses(rpa) >S3method(show,rpa) The CMD check and CMD build do not produce warning messages related to this issue (only warnings are about missing .Rd files). After installing the package ('test' is the package name) I start R and require the new package: >...

...the 'Depends:' field of the DESCRIPTION file or is it correct to import Package A only? Finally, Package C has a single exported function named 'myfunc' which needs to use the method for 'foo' defined in Package B, so its NAMESPACE file has importFrom(A, "foo") importMethodsFrom(B, "foo") importClassesFrom(B, "bar") export("myfunc") Is this the correct thing to do? The error I get under this setup is that 'myfunc' cannot find the method for 'foo' defined in Package B when 'myfunc' calls 'foo' on an object of...

...,...) { print(class(summary(object))) coef(summary(object)) } The NAMESPACE tries to pull in the necessary bits and pieces from lme4 to extract summaries and coefficients: export("coeftab","coeftab.default") importClassesFrom(lme4,"mer","summary.mer") importMethodsFrom(lme4,"coef","summary","show","print") exportMethods("coef","summary","show","print") exportClasses("mer","summary.mer") S3method(coeftab,default) The package passes the routine parts of R CMD chec...

...99 > barprint(x) [1] "barprint method for bar" [1] 99 Fine. Here is the bit that I have not figured out. ------------- #the .r file for package waz wazbar <- function(x) { barprint(new("bar",x)) } #the NAMESPACE file for package waz import(methods,barpkg) importMethodsFrom(barpkg) importClassesFrom(barpkg) export(wazbar) #then in R > require(wazpkg) Loading required package: wazpkg [1] TRUE > wazbar(99) Error in .setMethodsForDispatch(f, fdef, resetMlist) : Internal error: did not get a valid generic function object for function "print" Er...

...lt;- function(object, ...) { print("x") } the package has a NAMESPACE file: ----------- exportPattern("^[^\\.]") ##importFrom(nlme,ranef) import(nlme) ---------- (I've tried both import() and importFrom() -- I would prefer to use importFrom() if I can ... I also tried importMethodsFrom(nlme,ranef) , but it fails -- it seems to be intended for S4 and not S3 methods?) The package also has a tests directory with a single file, which looks like this: > library(raneftest) > x <- 1 > class(x) <- "x" > ranef.x(x) [1] "x" > ranef(x...

I represent a graph as an adjacency matrix of class "dgCMatrix" (from the Matrix package). > xx 5 x 5 sparse Matrix of class "dgCMatrix" a b c d e a . 1 1 . . b 1 . 1 . . c 1 1 . 1 1 d . . 1 . 1 e . . 1 1 . To check if the matrix defines and undirected graph, I have made the following functions/methods: is.UG <- function (object) { UseMethod("is.UG") }

Hi, I'm hoping to get some clarification of the intent of some of directives used in NAMESPACE files. 1. Is import(somePkg) also intended to import all classes and methods that are exported via exportClasses and exportMethods in somePkg? I think import pulls in classes and methods, but it isn't clear from the docs whether this is as intended. 2. What is exportMethods intended

...ptional list of value #' names to subset. Can be used to subset the dataList column further, #' returning only the selected items in the new LongTable. #' #' @return [`LongTable`] A new `LongTable` object subset based on the specified #' parameters. #' #' @importMethodsFrom BiocGenerics subset #' @import data.table #' @export subset.long.table <- function(x, rowQuery, columnQuery, assays) { longTable <- x rm(x) if (!missing(rowQuery)) { if (tryCatch(is.character(rowQuery), error=function(e) FALSE)) { select <- grep(...

Hi I'm missing something here but I cannot figure out what. What I can see is that the same code works when I load it via source(...) yet fails when I execute it after loading the package I have built (which includes the code. Below is a transcript of my R session. First I load the code from a file, using source(). Then I execute it fine. Then I remove the function object, I load the

Hi, I've noticed an issue with S4 methods and namespaces which only arises in particular, difficult to reproduce configurations. One example is the ggbio package in Bioconductor, which currently emits these warnings when its namespace is loaded: ---------------------- library(ggbio) Loading required package: ggplot2 Attaching package: ‘ggbio’ The following object(s) are masked from

...uality control functions (e.g. tools::checkFF()) were wrongly identifying the source of S4 methods in a package and so not checking them. o The default type of display by browseEnv() when using R.app on Mac OS X has been incorrect for a long time. o The implementation of importMethodsFrom in a NAMESPACE file could be confused and fail to find generics when importing from multiple packages (reported and fixed by Michael Lawrence). o The detection of the C stack direction is better protected against compiler optimization. (PR#15011.) o Long custom line type...

...uality control functions (e.g. tools::checkFF()) were wrongly identifying the source of S4 methods in a package and so not checking them. o The default type of display by browseEnv() when using R.app on Mac OS X has been incorrect for a long time. o The implementation of importMethodsFrom in a NAMESPACE file could be confused and fail to find generics when importing from multiple packages (reported and fixed by Michael Lawrence). o The detection of the C stack direction is better protected against compiler optimization. (PR#15011.) o Long custom line type...

...uality control functions (e.g. tools::checkFF()) were wrongly identifying the source of S4 methods in a package and so not checking them. o The default type of display by browseEnv() when using R.app on Mac OS X has been incorrect for a long time. o The implementation of importMethodsFrom in a NAMESPACE file could be confused and fail to find generics when importing from multiple packages (reported and fixed by Michael Lawrence). o The detection of the C stack direction is better protected against compiler optimization. (PR#15011.) o Long custom line type...