search for: unexported

...ects 'car:::df.terms', 'car:::df.terms.default', 'car:::is.aliased' are not exported by 'namespace:car' ERROR: lazy loading failed for package 'heplots' \S 1.6.1 of the manual says regarding importFrom(): 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. Questions: 1. Why doesn't this work? 2. Is my only alternative to copy these functions to my package, also unexported? thx, -Michael -- Michae...

Make the msgqueue_0148cdec_acr_func and msgqueue_0148cdec_func static to avoid the following sparse warnings: drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c:230:1: warning: symbol 'msgqueue_0148cdec_acr_func' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c:241:1: warning: symbol 'msgqueue_0148cdec_func' was not declared.

From: Joerg Roedel <jroedel at suse.de> The function is now only used in IOMMU core code and shouldn't be used outside of it anyway, so remove the export for it. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- drivers/iommu/iommu.c | 4 ++-- include/linux/iommu.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/iommu.c

Drivers have no business looking at dma-mapping or swiotlb internals. Signed-off-by: Christoph Hellwig <hch at lst.de> --- kernel/dma/swiotlb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index af2e304c672c43..9f1fd28264a067 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -921,7 +921,6 @@ bool is_swiotlb_active(struct

How do you get around the problem of having tests for functions that are not exported in NAMESPACE? It seems rather self-defeating to have to export everything so that 'R CMD CHECK pkg' won't crash when it encounters a test case for an internal function. I don't want someone using the package to call the function, but the package itself should be able to see its own contents.

I need to access some internal function of a package temporarily. These functions normally that are not visible outside of the package. I know the MyPackage:::myfunction mechanism, but that does not solve my problem. Instead, I need to add the "internal namespace" of the package to the search path, then I can run a few commands with these functions available, and then the internal

Thanks to Matthias Burger, I came to know that in r-devel, a lot of symbols are no longer exported in libR.so, which breaks the package rpvm since it calls these functions in serialize.c. R_InitInPStream R_InitOutPStream Since the change is fairly recent (earlier this month), I guess the core team will be making further changes. In any case, please add these two to the exported list. Thanks,

We are running kernel 2.6.18-164.6.1.el5 with exporting 3 aoe provided ext4 directories. For a couple of weeks we had a small number of users using the system with no issues, today we added 7 users and the system crashed and did not perform correctly since. Nov 23 10:20:03 sulphur rpc.idmapd[5199]: nfsdcb: id '-2' too big! Nov 23 10:42:25 sulphur nfsd[27306]: nfssvc: Setting version

First time posting on this forum. The short version of the question is how to keep the documents of private (unexported) functions private. It seems that the documents of the private functions will be compiled into the user manual even if the corresponding functions are not exported. Is there a solution to this? I want to have documents for these functions for my own use, but I don’t want to release them to distract...

...me systems. This allows the Rcmdr package to build and check on systems without rgl present; if rgl isn't present, then menu items using it are disabled (in the development version of the Rcmdr package, not installed in the first place). If rgl is present, however, the Rcmdr package uses some unexported functions in it. I've done this via rgl::: to avoid importing from the rgl namespace: Because rgl isn't declared as a dependency, I can't import its namespace. In the current R 2.4.0 alpha and R 2.5.0 devel, however, using rgl::: generates a warning when the package is checked. Is ther...

Dear all, It looks like I do not grasp the concept of masked functions enough as to solve this trivial problem. The code that replicates the problem (a source code tree that realizes a R package actually) is under github so one can call it clone it easily from the command line (though more experienced users will spot the problem by browsing through the package code): git clone http://jcborras at

Hi all, this little series removes the last swiotlb API exposed to modules. Diffstat: arch/x86/include/asm/xen/swiotlb-xen.h | 6 ------ arch/x86/kernel/pci-dma.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++------- drivers/pci/xen-pcifront.c | 6 ------ kernel/dma/swiotlb.c | 1 - 5 files changed, 7

...he call in the package file R/zzz.R using the .onLoad function: .onLoad <- function(...) { # Bind activation of cbind(2) and rbind(2) for S4 classes methods:::bind_activation(TRUE) } This works as expected. However, running R CMD check I am now getting the following NOTE since I am using an unexported function in methods: * checking dependencies in R code ... NOTE Unexported object imported by a ':::' call: 'methods:::bind_activation' See the note in ?`:::` about the use of this operator. How can I get rid of the NOTE and what is the proper way to define the methods cbind and...

...et the default values so that subsequent calls to par() use my defaults. The reason to want this is that every time I create a new graphic window (I'm using quartz on OSX, and so far no answers in the Mac mailing list), my parameters get reset to the builtin defaults. I read about the "unexported variable .Pars," but would like to know if there's any way to manipulate that variable. thanks Carl

...t; >> .onLoad <- function(...) { # Bind activation of cbind(2) >> and rbind(2) for S4 classes >> methods:::bind_activation(TRUE) } This works as >> expected. However, running R CMD check I am now getting >> the following NOTE since I am using an unexported >> function in methods: >> >> * checking dependencies in R code ... NOTE Unexported >> object imported by a ':::' call: >> 'methods:::bind_activation' See the note in ?`:::` about >> the use of this operator. How can I ge...

Hi, since lattice uses nested lists in various situations, it has had an unexported function called updateList for a while, which looks like > lattice:::updateList function (x, val) { if (is.null(x)) x <- list() if (!is.list(x)) stop("x must be NULL or a list") if (!is.list(val)) stop("val must be a list") xnames &...

Gabriel, Thanks for that! I guess I really should have figured that one out sooner, huh? I understand why that wouldn't be CRAN-compliant. But then, what *is* the proper way to do it? Is there any way I can call unexported functions from another package and have it accepted by CRAN? Also, if I instead re-write the random variable generating functions, do you have any idea of where the source code is in the stats package? As I said above, I can't seem to find the source code for the functional forms. Thanks, Lu...

I am trying to update an unsupported package and got the warning: * checking dependencies in R code ... WARNING 'library' or 'require' calls not declared from: 'Hmisc' 'R2HTML' 'tcltk' Missing or unexported object: 'utils::.win32consoleCompletion' See the information on DESCRIPTION files in the chapter 'Creating R packages' of the 'Writing R Extensions' manual. Is it only an error in the description file or in the code? Regards Knut

On Wed, Sep 17, 2008 at 12:32:40PM +0300, Kirill A. Shutemov wrote: > On Tue, Sep 16, 2008 at 07:09:02PM +0300, Adrian Bunk wrote: > > On Tue, Sep 16, 2008 at 07:10:25AM -0700, Ulrich Drepper wrote: > > > Kirill A. Shutemov wrote: > > > >> What is the error message? > > > > > > > > /usr/include/asm-generic/fcntl.h:117: error: redefinition

...; wrote: > > Gabriel, > > > > Thanks for that! I guess I really should have figured that one out > sooner, > > huh? > > > > I understand why that wouldn't be CRAN-compliant. But then, what *is* the > > proper way to do it? Is there any way I can call unexported functions > from > > another package and have it accepted by CRAN? > > > There may be ways to call unexported functions that R CMD check will > not detect, but you should not look for ways to violate the spirit of > the policy. Work-arounds include asking the package mainta...