similar to: Registration of native routines

On Tue, Feb 14, 2017 at 5:25 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: > > Registration has similar benefits to name spaces in R code: > > - it ensures that the routines used by .C, .Call etc are those in your package (without needing a PACKAGE argument). > - it avoids polluting the search space for native routines with those from your package. > - it checks

Have you tried using tools:::package_native_routine_registration_skeleton()? If you don't like its output, you can easily edit its results and still avoid most pitfalls. Cheers, Jari Oksanen ________________________________________ From: R-devel <r-devel-bounces at r-project.org> on behalf of Berend Hasselman <bhh at xs4all.nl> Sent: 10 May 2017 09:48 To: Christophe Dutang Cc:

Dear list, I am trying to update a package to pass the CRAN-checks. But I am struggling with the following note: File 'psgp/libs/i386/psgp.dll': Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols' File 'psgp/libs/x64/psgp.dll': Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols' It is good practice to register native

On Tue, Feb 14, 2017 at 11:25 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: > Registration of 'native routines' (entry points in compiled code loaded into > R) has been available for over 14 years, but few packages make use of it > (less than 10% of those on CRAN with compiled code). > > Registration has similar benefits to name spaces in R code: > > -

Thanks a lot for your answer Jeroen! I should have mentioned that I had actually only checked with the win-builder, as I did not have R-devel installed on my computer. But based on your answer I installed R-devel locally on a Linux-server (Redhat), and the package could be checked without the NOTE. So you might be right that this is a windows issue. However, another package that I am maintaining

Thanks for your email. I try to change the name in lowercase but it conflicts with a C implementation also named halton. So I rename the C function halton2() and sobol2() while the Fortran function are HALTON() and SOBOL() (I also try lower case in the Fortran code). Unfortunately, it does not help since I get init.c:97:25: error: use of undeclared identifier 'halton_'; did you mean

My older packages have some Fortran and C routines. The 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,

? 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,

> ... reports that the fortran names of all the registered fortran functions are ?undocumented objects?... Those symbols should not be exported. In quantreg v5.33, NAMESPACE has 'exportPattern(".")'. Maybe it is a good time to remove that and export explicitly the symbols that are meant for export. Georgi Boshnakov ------------------------------ Message: 6 Date: Fri, 28

I'm writing a package that interfaces to the FAME database, via a library of compiled C routines accessible through a Linux .so file. My .onLoad() function loads the .so like this: dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F) and after that I also load my own fame.so via library.dynam("fame", package = "fame") The code in fame.so uses

Hi all, Looking at the body for the function rnorm, I see that the body of the function is: .Call(C_rnorm, n, mean, sd) I want to implement functions that generate normal (and other) random variables. Now, I understand that I can perfectly well just call the R wrapper for these functions and that will be almost indistinguishable for most purposes, but for whatever reason I wanted to try and

Hi @ all, i set a server to a costumer of mine with a TE207P for use with 2 E1 Lines. I set them together into one group in zaptel/zapata.conf The point is now, the customer has a free-volumina of 60k minutes per month, per line. How can i make a kind of load balancing, that both lines will be trafficed the same way ? I read something about DIAL(Zap/r1/.) for using round robin, and

Hi everybody, I'm trying to develop an R package with Fortran and OpenMP. I wrote a simple hello world but I'm not able to set the number of threads. I found this old email chain <http://r.789695.n4.nabble.com/Set-the-number-of-threads-using-openmp-with-C-td2284685.html> and I tried to set my compile instructions accordingly but i had no luck. *This is my makevars:*

On 28/06/2019 6:27 a.m., Koenker, Roger W wrote: > Thanks, I was just coming to that conclusion and beginning to look for a way to make a list of > exportable objects. After library(quantreg), ls("package:quantreg") will list all the names you currently export. So cat(ls("package:quantreg"), sep = ", ") will print the list in a form suitable for including

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

Dear All, I am trying to convert a package to native routine registration, and not sure how to best solve the problem of C functions that are only used for a single platform, i.e. Windows, Linux (& Unix) or macOS. If I simply provide a different method table for each platform, then the .Call() statements for the other platforms will generate R CMD check warnings, both for the

I noticed that in https://svn.r-project.org/R/trunk/src/library/stats/R/loess.R that we are now calling R_loess_raw, R_lowesw, R_lowesp, etc. I'm interested to know what is the benefit/reason for the 'R_', as I am unfamiliar with this prefix and do not see it mentioned in 'Writing R Extensions.' Thanks, Ben

I have setup a package directory structure with all the relevent files in the src, R, man and data directories. Also have the correct DESCRIPTION and NAMESPACE files in the root directory. I don't wisk to recompile the .dll file in the src directory as it currently works fine if I locate it in the same workdirectory as my R source code that calls it. This is a little tedious having to move

I got this to work on Linux but it is not working on Windows. *My understanding is that this should also work 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

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 people with older versions. >