search for: usedynlib

I am considering a package with a namespace (Rgraphviz from Bioc). I essentially want to have some error handling for loading the dll, something like wrapping it into tryCatch or similar (reason: see below). Right now I am loading the dynamic libraries by useDynLib in my NAMESPACE file. When I look at the code from loadNamespace, I have the impression that what I want is impossible (.onLoad and the user settable hooks are called after the dynamic libraries have been loaded). Is that true? And is the only way to proceed, to not use useDynLib in my NA...

Hi, Has something changed regarding the useDynLib in the NAMESPACE file in packages? I've written a package that works in e.g. 2.12/2.13 but simply cannot find the dynamic library under windows. The version on CRAN is older than the one I'm talking about and depends on a newer version of R but I want to make the package available to pe...

...venient if one could change the package name in only one place (the DESCRIPTION file) and have that propagate to all other uses of the package name in the package. Suppose the package were named "myPkg". Then the problem areas are: 1. The NAMESPACE file has myPkg hard-coded like this: useDynLib(myPkg, .registration=TRUE) 2. The configure.ac file has myPkg hard-coded like this: AC_INIT([myPkg], 1.0.0) 3. There are various references to myPkg hard-code throughout the R code, e.g. myPkg::myFun, but I am ok here as I assume this would work where an .onLoad would be used to grab the package...

...setting non-ASCII encodings when needed. (Fixes #7) BUG FIXES * `write.description()` now tries much harder to respect users' original DESCRIPTION field formatting instead of forcibly re-wrapping certain fields at 60 characters. * `@details` and `@description` now work correctly * `@useDynLib` now works correctly: @useDynLib packageName routine1 routine2 produces useDynLib(packageName, routine1) useDynLib(packageName, routine2) in the NAMESPACE file, instead of separate (wrong) useDynLib statements as before. * All namespace import directives now behav...

...setting non-ASCII encodings when needed. (Fixes #7) BUG FIXES * `write.description()` now tries much harder to respect users' original DESCRIPTION field formatting instead of forcibly re-wrapping certain fields at 60 characters. * `@details` and `@description` now work correctly * `@useDynLib` now works correctly: @useDynLib packageName routine1 routine2 produces useDynLib(packageName, routine1) useDynLib(packageName, routine2) in the NAMESPACE file, instead of separate (wrong) useDynLib statements as before. * All namespace import directives now behav...

...nLoad failed in loadNamespace Error in library("RIO_1.4.0") : package/namespace load failed fail. Without the '--with-package-versions' option the installed package loads without problem with the call library("RIO") file Namesapce defines (amoung other directives): useDynLib(RIO) I also tryed useDynLib("RIO_1.4.0") to no avail. But RIO/libs contains the file RIO.so anyway. I checked in 'Writing R Extensions" section 'Package name spaces' but did not find an answer. Any hints? Regards, Matthias -- Matthias Burger...

Hello! I am truing to compile an R-package having c-code. I put foo.c in src/ folder and useDynLib("foo") in NAMESPACE file. When trying R CMD check, I got an error message that shared object 'foo' is not found. Then I did R CMD SHLIB foo.c first. However, after that, I got warnings from R CMD check that there is an object file in /src folder. Even worse is if I run R CMD S...

Now I try to add some C and Fortan code to my package, so the NAMESPACE file is useDynLib(eha) importFrom(survival, Surv) export(mlreg.fit, risksets) but I get ..... * checking R files for library.dynam ... OK * checking S3 generic/method consistency ... WARNING Error in .try_quietly({ : Error in library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE) : pa...

...e Fortran is ancient and I am started to convert it to Fortran 2018 (thanks ChatGPT). To have a mixture of Fortran and C code in a package I have had a src/init.c file that provides names for routines of the form F77_name, and I called the routines with .Fortran(F77_name, ...) and in NAMESPACE had useDynLib(package name, .registration=TRUE, .fixes="F_"). Now I find that I can get rid of init.c, and change NAMESPACE to use useDynLib(package name, list of compiled routine names) (without .registration and .fixes) after making sure the Fortran and C routines are not named the same as the pack...

...nit_pkgname and so need the registration info to be merged. Most of the rest fail because of errors in the package but some try to do tricky things computing names of routines, and this is noted in the skeleton output. A few of you are using the older mechanism of specifying entry points in a useDynLib call in the NAMESPACE file. This shares the first and fourth benefits (but registration is faster), but not the second and third. $5.4 of the 'Writing R Extensions' manual has been re-written with a worked example of adding registration. Shortly, R CMD check --as-cran will note if regis...

? Fri, 25 Oct 2024 15:03:54 -0500 fh at fharrell.com ?????: > Now I find that I can get rid of init.c, and change NAMESPACE to use > useDynLib(package name, list of compiled routine names) (without > .registration and .fixes) after making sure the Fortran and C > routines are not named the same as the package name. The routines > are called using .Fortran(binary module name, args) or .Call(C binary > module name, ...). >...

...th their number of parameters. I retrieve rnorm from the list and pass it on to .Call, which then works fine. However, is there an easier way to do this? Specifically, I would like to call the DLL registered routines from within functions in a package I am writing. The manual tells me I should use useDynLib(). So if I added useDynLib("stats") to my namespace, would that work? Could I then have a function such as: function(x, y, z) .Call(C_rnorm, x, y, z) in my package? If not, what is the proper way of calling these functions from other packages? Should I use "C_rnorm" or &qu...

...s compiled C or Fortran code, but I have none of that in my code. I imagine this is a simple problem (perhaps with my NAMESPACE file), but I don't know what it is. (The text of the NAMESPACE file is at the bottom of this e-mail.) Thank you in advance for your help! Rebecca NAMESPACE file: useDynLib(REEMtree) export(AutoCorrelationLRtest, FixedEffectsTree, RandomEffectsTree, LMEpredict, PredictionTest, RandomEffectsTree, RMSE, simpleREEMdata, REEMtree, FEEMtree) import(nlme) import(rpart) S3method(is,REEMtree) S3method(logLik,REEMtree) S3method(plot,REEMtree) S3method(predict,REEMtree)...

...s to do this? What is the popper accepted current standard for unloading compiled code? The options as I understand them are: 1. dyn.unload 2. library.dynam.unload used with either A. .Last.lib B. .onUnload If it makes a difference my package does use a NAMESPACE so the package is loaded through useDynLib. Thanks, Andrew Redd

...imple package with NAMESPACE file, such that datasets are loaded only dynamically. > a2 <- function(x=a1) x+4 > a1 <- 1:10 > package.skeleton("aaa", list=c("a1", "a2")) Then I modified the help files and added the file NAMESPACE with these 2 lines: useDynLib(aaa) export(a1, a2) Then "R CMD BUILD aaa" works fine, but "R CMD CHECK aaa" gives: ......... * checking R files for syntax errors ... OK * checking R files for library.dynam ... OK * checking S3 generic/method consistency ... WARNING Error in .tryQuietly({ : Error in library(p...

...to use: !$call omp_set_num_threads(ncores) !$omp parallel private(iam) iam=omp_get_thread_num() !$omp critical write(*,*) 'Hello from', iam !$omp end critical !$omp end parallel end subroutine hello end module hello_openmp *and this is my R function:* #'@export #'@useDynLib helloOpenMP, .registration = TRUE hello <- function(ncores=4) { .Fortran("hello", ncores = as.integer(ncores)) } *Alas, when I call hello things only run with one thread:* > hello(ncores = 2)$ncores Hello from 0 [1] 2 Could you point me in the right direction? Wha...

...ork on windows, is that correct?* If so, what should I do? differently? To get it to work on Linux, I modified my R script as follows: #' OpenMP Hello World #' #' @param nthreads The number of threads that you want to use #' @example #' hello(nthreads=2) #' @export #' @useDynLib helloOpenMP, .registration = TRUE hello <- function(nthreads=4) { (OpenMPController::omp_set_num_threads(nthreads)) .Fortran("hello") return('Each thread will say hi to you!') } > hello(nthreads = 2) Hello from 0 Hello from 1 [1] "Each thre...

...ems. I do build, check, and install all without fail and can use these functions in an R session. Now, I add in a namespace file in the top level directory and, following the namespace example found at the link below, I construct a namespace that has the following in it: ### begin namespace file useDynLib(foo) export(g) ### end namespace file http://cran.r-project.org/doc/manuals/R-exts.html#An-example Because I don't want there to be an .Rd file for the function f I remove it from the "man" directory. I say remove because I use package.skeleton() and it automatically creates an empty...

...orm from the list and >> pass it on to .Call, which then works fine. >> >> However, is there an easier way to do this? Specifically, I would like to >> call the DLL registered routines from within functions in a package I am >> writing. The manual tells me I should use useDynLib(). So if I added >> useDynLib("stats") to my namespace, would that work? Could I then have a >> function such as: >> >> function(x, y, z) .Call(C_rnorm, x, y, z) >> >> in my package? If not, what is the proper way of calling these functions >>...

...e. // std::cout << "My first R Package Test." << std::endl; } I also wrote an R wrapper called hello as follows: *** helloworld.R hello <- function() { .Call("helloworld", PACKAGE="MyPackage"); } The namespaces file (NAMESPACE) is as follows: useDynLib(MyPackage) export(hello) I have compared mine against other package sources available that do the same thing and cannot find the key difference. Thank you for your help in advance, Tom