similar to: Custom C finalizers for .Call

Jeroen, I agree that it may be useful to have some kind of "finally"-like infrastructure. However, in the use cases you list there are already ways to do that - the same way that R_alloc uses. First, you don't need to call UNPROTECT - the whole point is that the protection stack is automatically popped in case of an abnormal termination. That is precisely how memory leaks are

Engine keys are private key files which are only understood by openssl external engines. ?The problem is they can't be loaded with the usual openssl methods, they have to be loaded via ENGINE_load_private_key(). ?Because they're files, they fit well into openssh pub/private file structure, so they're not very appropriately handled by the pkcs11 interface because it assumes the private

I've architected this in a way that looks future proof at least to the openssl provider transition. What will happen in openssl 3.0.0 is that providers become active and will accept keys via URI. The current file mechanisms will still be available but internally it will become a file URI. To support the provider interface, openssl will have to accept keys by URI instead of file and may

On Tue, Nov 24, 2015 at 12:10:12AM +0100, Jeroen Ooms wrote: > Currently it is all to easy for package authors to introduce a memory > leak or stack imbalance by calling Rf_error() or > R_CheckUserInterrupt() in a way that skips over the usual cleanup > steps. I have a more modest request: Please improve the documentation of exactly what Rf_error() does and how it should be used!

To anyone following the Windows toolchain saga: The gcc 4.9.2 toolchain that is currently in Rtools33 has too many incompatibilities with existing code, so we won't be using it in the R 3.2.0 build. I will soon be uploading to CRAN a new version of Rtools33 that is very similar to Rtools32, containing gcc 4.6.3. We are continuing to work on the new toolchain, and hope to have it ready

Dear all, I try to understand why on my computer I do not clear all data with this code: #include <R.h> static int count = 0; class A { public: A(){ printf("c %d\n", count); count++; } ~A(){count--; printf("d %d\n", count); } }; extern "C" { void testAL(){ A a; { A b; } error("does not write [d 0]"); } }

Engine keys are keys whose file format is understood by a specific engine rather than by openssl itself. Since these keys are file based, the pkcs11 interface isn't appropriate for them because they don't actually represent tokens. The current most useful engine for openssh keys are the TPM engines, which allow all private keys to be stored in a form only the TPM hardware can decode,

Hello! I (try to) convert the external R header files to Pascal (Delphi). At one place I stumbled over a macro that uses a method that is not declared in a LGPL header file: In Rinternals.h: #define error_return(msg) { Rf_error(msg); return R_NilValue; } #define errorcall_return(cl,msg){ Rf_errorcall(cl, msg); return R_NilValue; } ~~~~~~~~

R Listers, One of the list contributors suggested I abandon attempts to build R-1.9.1 and focus on building R-2.3.1. I believe the main set of packages have been built properly (with some changes to the code) - however, when building the Recommended packages, the build fails. CODE CHANGES: ============= 1. My C compiler requires a ";" on line 589 of ..../src/main/printutils.c. Here

The Bioconductor build for a package DirichletMultinomial on R Under development (unstable) (2013-02-26 r62077) -- "Unsuffered Consequences" at http://bioconductor.org/checkResults/devel/bioc-LATEST/DirichletMultinomial/george2-buildsrc.html shows * creating vignettes ... ERROR ... Error: processing vignette ?DirichletMultinomial.Rnw? failed with diagnostics: chunk 21 (label

I'm having a problem with the error and warning functions. I've tried this on multiple machine so I'm fairly sure it's not machine dependent and I've tried it on the latest versions 2.6.0-2.7.1. Whenever my program gets to an error or warning it crashes the entire program rather than throwing the error like it should. Here are the relevant bits. ... char const * const

I haven't done any R memory debugging lately, but https://www.mail-archive.com/rcpp-devel at lists.r-forge.r-project.org/msg10289.html shows how I used to have gdb break where valgrind finds a problem so you could examine the details. Also, running your code after running gctorture(TRUE) can help track down memory problems. -Bill On Wed, Feb 7, 2024 at 12:03?PM Therneau, Terry M., Ph.D.

I am trying to get R 1.0 running on the Mac. The main target is MacX. Anyone else working on that? For the recent Macintosh system, I am trying to compile R using MachTen. The R core compiles and runs without any changes, using the Unix make files. The libraries give some problems, presumably due to handling of shared libraries. It seems I am missing something to link. Before I spend my time

Dear R-devel, My g++ complains about the first argument to Rprintf being non-const char *. For example when compiling the line Rprintf("hello world\n"); the following warning is emitted: warning: deprecated conversion from string constant to 'char*' Is there a reason for the non-const? It is curious that Rf_error, which is similar to RPrintf, is const. If there is a need

I've recently updated the coxme package, which calls internal routines from the bdsmatrix package.? (It is in fact mentioned as an example of this in the Extensions manual.) The call connections are a blocks like this, one for each of the 9 called C routines. void bdsmatrix_prod4(int nrow,??? int nblock,?? int *bsize, ??????????????????? double *bmat, double *rmat, ??????????????????? int

I asked a question that might help me track down what changed between 2.3.1 that did build and the 2.4.0 version that will not build. Some of the undefined names the linker was complaining about looked like #define symbols that were not picked up by configure. The first thing I was hoping for was to find out if this problem looked familiar? Whether or not, I'm willing to try to work on

Hi, we have installed R-2.8.1 using the current pgi compiler (8.0.2) for AMD64 on a SLES9 system. When I try to install "Matrix" everything is fine until the last step. make[1]: Leaving directory `/tmp/R.INSTALL.TW3399/Matrix/src/AMD' pgCC -L/usr/lib64 -L/usr/X11R6/lib64 -pgf90libs -o Matrix.so CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o

And remove the cast on the return value of R_GETCCallable. And check that your function is found before using it. #include <R.h> #include <Rinternals.h> #include <R_ext/Rdynload.h> void bdsmatrix_prod4(int nrow, int nblock, int *bsize, double *bmat, double *rmat, int nfrail, double *y) { DL_FUNC fun = NULL; if (fun==NULL)

Could Rvsnprintf (in src/main/errors.c) be added to the R API with prototype in include/R_ext/Print.h say? Here's my problem. I'm trying to write some code that is not totally tied to R. Hence I want R style error messaging to be isolated in a small module. I do not want #include <R.h> and calls to error (Rf_error) in most of my code. Hence I want to write a module with something

I was debugging a problem reported to me regarding PL/R, and found that I can duplicate it using only R sources. It might be characterized as possibly a misuse of the findFun() function, but I leave that for the R devel experts to decide. The below results are all with R-2.5.1 (I can't seem to download r-patched at the moment, but didn't see anything in the 2.5.1-patched release