search for: unexporting

A new function in my heplots package wants to use a non-exported utility function in the car package, df.terms, but this depends on other non-exported functions. From the Writing R extensions manual, I thought I could do this via (in my NAMESPACE) importFrom(car, car:::df.terms, car:::df.terms.default, car:::is.aliased) but I get: ** preparing package for lazy loading Error : objects

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,

...lt;ffffffff886305a1>] :nfsd:nfsd+0x0/0x2cb Nov 23 10:42:26 sulphur kernel: [<ffffffff886305a1>] :nfsd:nfsd+0x0/0x2cb Nov 23 10:42:26 sulphur kernel: nfsd: last server has exited Nov 23 10:42:26 sulphur kernel: nfsd: unexporting all filesystems Nov 23 10:42:44 sulphur kernel: kmem_cache_create: duplicate cache nfsd4_files Nov 23 10:42:44 sulphur kernel: [<ffffffff88646f29>] :nfsd:nfs4_state_start+0x52/0x18f Nov 23 10:42:44 sulphur kernel: [<ffffffff886303ae>...

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

Dear list members, I'm encountering the following problem with package dependencies and imports: The Rcmdr package doesn't declare a formal dependency (via depends or suggests in the package DESCRIPTION) on the rgl package because the latter apparently causes problems on some systems. This allows the Rcmdr package to build and check on systems without rgl present; if rgl isn't

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

Hi all, this question has already been posted on stackoverflow, however without success, see also http://stackoverflow.com/questions/27886535/proper-way-to-use-cbind-rbind-with-s4-classes-in-package. I have written a package using S4 classes and would like to use the functions rbind, cbind with these defined classes. Since it does not seem to be possible to define rbind and cbind directly as S4

I know how to set graphic parameters by calling par(), but what I'd like is a way to set 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

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Sat, 24 Jan 2015 06:39:37 -0800 writes: > On Sat, Jan 24, 2015 at 12:58 AM, Mario Annau > <mario.annau at gmail.com> wrote: >> Hi all, this question has already been posted on >> stackoverflow, however without success, see also >>

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 <- names(x)

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

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

...mplementations to copy the contents into a > > private header. > > glibc and dietlibc provide <sys/inotify.h>. newlib and uclibc don't. klibc > provides <sys/inotify.h> but it depends on <linux/inotify.h> Oh.. Sorry. uclibc provides <sys/inotify.h>. So unexporting <linux/inotify.h> breaks only klibc. -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital...

Well, For this particular use case why not just transform the parameters at the R level and then call the existing function? Is there not a closed form mapping? ~G On Jul 1, 2016 2:50 PM, "Joshua Ulrich" <josh.m.ulrich at gmail.com> wrote: > On Fri, Jul 1, 2016 at 6:13 AM, Luis Usier > <luis.henrique.usier at gmail.com> wrote: > > Gabriel, > > > >