similar to: getNativeSymbolInfo fails with Fortran symbol.

Hi, When loading a package that provides the user-supplied RNG hook user_unif_rand, calling getNativeSymbolInfo("user_unif_rand") returns informations about the loaded symbol. I am using this to identify which package currently provides the RNG hook. The results are the same on windows and linux if only one library provides the hook. If one loads a second package that provides this

In the odesolve routine lsoda(), I allow the function (named func) that calculates the system of differential equations to be defined in a dll that has been dynamically loaded from the file named in dllname. I use getNativeSymbolInfo(func, dllname)$address to get the address of the function and pass it to a C function called via the .Call interface. Inside that C function, I use

I asked Tomas. Apparently this works: getNativeSymbolInfo("dotTcl",PACKAGE=getLoadedDLLs()$tcltk) and the tcltk behavior was changed by r84265 | hornik | 2023-04-15 08:44:36 +0200 (Sat, 15 Apr 2023) | 1 line Try forcing symbols in ff calls. Index: library/tcltk/src/init.c =================================================================== --- library/tcltk/src/init.c

Let me get more specific. I think it this can be answered then I can translate the information to other calls. In the arima 'R' code there is a reference to .Call(R_TSconv, a, b) If from the console I type: > .Call(R_TSConv, c(1,-1), c(1,-1)) I get: Error: object "R_TSConv" not found If I do > getNativeSymbolInfo("R_TSConv") I get: Error in

I have a use case with tcltk-package where I need to repeatedly call Tcl/Tk functions very quickly. For such purpose, the standard R-interface turned out to be too slow, and better option has been to call package's C-function dotTcl directly from my own C-code. Before R 4.4.0 it was possible to use getNativeSymbolInfo("dotTcl","tcltk")$address (or

Dear R-devel, Apologies for sending what is probably a very simple question to R-devel: I am definitely missing something very simple and can't work out what it is. I've been trying to find the problem here for about a month and need some help! I am trying to work out how to run a C program from an R script. Rather than try the C program directly, I'm trying to get a much simpler

I have been trying to make use of the odesolve library on my university's Linux grid - currently R version 2.0.1 is installed and the system runs 64-bit Scientific Linux based on Redhat. I cannot seem to get lsoda working when I define the model as a shared C library. For example, the following snippet uses the mymod.c example bundled with the package: ### START rm(list=ls())

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

I cannot understand why a function appears to be available to R (is.loaded('planckwR') returns TRUE) but the call with .C results in an error message: C symbol name 'planckwR' not in DLL for package <path to DLL file here> This is what I do: Loading a homebrewed DLL, compiled with MS VS97. The functions are all void, the C calling sequence is used and all arguments

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

This might fall under the purview of bundles, but I could not find any example bundles which demonstrated what I am after. I would like to construct two packages (A, B) which utilize a number of common C functions. The most straightforward way to do this is just copy the relevant .c and .h files from one src directory to the next, but this is tedious especially in the face of multiple

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

I have a package that solves systems of ordinary differential equations coded as an R function (odesolve, on CRAN). The function is passed to R code, and c and Fortran code called by it uses lang4() and eval() to evaluate the R function inside a compiled c function to use in a compiled ODE solver. This works quite well, but can be slow. I'd like to be able to supply the name of a compiled

I use recordPlot() to save plots to disk that I render later to a variety of formats. This works fine for base R plots and ggplot2 plots, and also used to work for lattice plots. However somewhere in version 2.14 things stopped working for lattice plots. Here is an example: library(lattice); histogram(rnorm(100)); x <- recordPlot(); saveRDS(x, "myplot.rds"); y <-

Greetings, I am working on modifying some code from the nlme package. I have had many discussions on the mixed models mailing list and have been directed to simply 'hack' the source code to have the degrees of freedom generated by one function to use in the output of another function that doesn't generate them. My current holdup is an error regarding a .c file called

Hello, Does anyone on this list know what inner_perc_table is or where it is typically found? I am trying to modify some source code and it is used with the .C() function. When I try and run it, it states that 'inner_perc_table is not found'. It is only called in such a way and isn't defined at any point in the previous code in which the function works. Should this be in some other

Luis, C_rnorm is a symbol but it's not exported. This means that you *can* do this by using stats:::C_rnorm. That said, it's not exported, which means that it's not supported to do this. So your package likely would not be allowed on CRAN, for example. Best, ~G On Jun 30, 2016 2:08 PM, "Luis Usier" <luis.henrique.usier at gmail.com> wrote: > Hi all, > >

On Fri, Jul 1, 2016 at 6:13 AM, Luis Usier <luis.henrique.usier at gmail.com> 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

Hi all, The dict package provides a dictionary (hashtable) data structure much like R's built-in environment objects, but with the following differences: - The Dict class can be subclassed. - Four different hashing functions are implemented and the user can specify which to use when creating an instance. I'm sending this here as opposed to R-packages because this package will

Hi everyone, I'm thinking about breaking up a large package I have to avoid loading some of the more specialised parts when it isn't necessary. The package is dependent on shared libraries. The base one will keep all of the core stuff like constructors etc and the specialised parts will need to access these. It is obviously possible to set the "local" flag to false, however