similar to: manual 'Writing R Extensions': bug in example

Hi, I am trying to implement on a Win7 box the showArgs example of section 5.10.2 "Calling .External" of the R extension manual. I am using interchangeably gcc (RTools) and Visual C++ (via Makefile.win) to build a package. I get a couple of runtime oddities when the dll compiled with Visual C++. I'd value comments, observations and tips from interested readers. I tried my best to

(earlier I sent it as html by mistake). Hi, How can I get from C an object name used as a function argument? I have sample code in C that gives me access to the name of the function being called: SEXP xname(SEXP x) { const char *fun_name = CHAR(PRINTNAME(CAR(x))); x = CDR(x); const char *arg_name = isNull(TAG(x)) ? "" : CHAR(PRINTNAME(TAG(x)));

The Rprofmem facility is currently enabled only if the configuration option --enable-memory-profiling is used. However, the overhead of having it enabled is negligible when profiling is not actually being done, and can easily be made even smaller. So I think it ought to be enabled all the time. I've attached a patch doing this, which also makes a number of other improvements to Rprofmem,

Hi, I'm quite knew in R, so I might not have the R specific jargon. But here is my problem, I'm trying to access and use variabels given by a function environment, more specifically the rho in do_optim in src/main/optim.c According to the documentation http://cran.r-project.org/doc/manuals/R-ints.html#The-_0027data_0027 the envsxp is defined as a tagged pairlist. "ENVSXP: Pointers

Hello, (This is follow up from this thread: http://www.nabble.com/execution-time-of-.packages-td22304833.html but with a different focus) I am often confused by the result of the profiler, when a loop is involved. Consider these two scripts: script1: Rprof( ) x <- numeric( ) for( i in 1:10000){ x <- c( x, rnorm(10) ) } Rprof( NULL ) print( summaryRprof( ) ) script2:

Hello R-devel, As mentioned on Fosstodon [1] and discussed during RCOH [2], named arguments to sum(), min(), max() and prod() are currently processed the same way as the un-named ones. Additionally, when specifying the na.rm argument more than once, the last specified value is silently taken into account. Most of this behaviour is exactly as documented, but it's arguably a source of mistakes

I've been inspired to look at the R source code by some strange timing results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and

Dear Group, I'm trying to build a set of new graphic device drivers. I use the devNull example a a beginning point: $ R CMD SHLIB devNull.c gcc -shared -L/usr/local/lib -o devNull.so devNull.o (everything works OK) $ R CMD SHLIB devNull.cpp g++ -shared -L/usr/local/lib -o devNull.so devNull.o (everything works OK) The difficulties start when trying to compile manually. I compile the

Dear Prof Ripley, Prof Brian Ripley wrote: > But it is not taken 'verbatim from src/main/print.c' (at least not in > that version of R), and the code is not run with USE_RINTERNALS defined > when write-barrier checking is enabled. > > The example has been updated to match the current code in 2.7.0 alpha. I just assumed that it is copied verbatim without checking because

Ok, Here's the c code that's loaded into R as dll on windows: #include <R.h> #include <Rdefines.h> SEXP test1(SEXP col); SEXP test1(SEXP col) { SEXP col2; Rprintf("no value!\n"); return col2; } Compiles ok with bcc32 into a dll, loads into R as part of a library, I Run library(rkdb), then > .Call("test1", 2) no value! And puf! Rterm crashes.

Hi I am new to writing C code and am trying to write an R extension in C. I have hit a wall with F77_CALL(dgemm) in that it produces wrong results. The code below is a simplified example that multiplies the matrices Ab and Bm to give Cm. The results below show clearly that Cm is wrong. Am= 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Bm= 1 1 1 1 1

On 2023-04-15 6:00 am, r-devel-request at r-project.org wrote: > Date: Fri, 14 Apr 2023 13:38:00 +0300 > From: Ivan Krylov<krylov.r00t at gmail.com> > To:r-devel at r-project.org > Subject: [Rd] sum(), min(), max(), prod() vs. named arguments in ... Message-ID: <20230414133800.75383dae-6792 at arachnoid> > Content-Type: text/plain; charset="us-ascii" > >

Hi, I recently ran into a problem with 'merge' that stems from the way how missing values in the key column (i.e., the column specified in the "by" argument) are handled. I wonder whether the current behavior is fully consistent. Please have a look at this example: > x <- data.frame( key = c(1:3,3,NA,NA), val = 10+1:6 ) > y <- data.frame( key = c(NA,2:5,3,NA),

Any idea why CHAR(asChar(STRING_ELT( produces NA whereas CHAR(STRING_ELT( gets a pointer to a string? It's generally expected that STRING_ELT should already be a character, but why the coercion does not work? Here is a simple example (consistent over R2.5.1-R2.6 rev 42284, I didn't check earlier versions, but it used to be different in 2.4): install.packages("inline")

Could you help me in getting a package to compile from source in Windows? I'm running Windows NT 4.0 on a pentium 450 with 128 Mb of Ram. I've got R 1.0.0. I am developing a package for R which includes a bit of C code. I have things working in Unix just fine, and now I want to port it to Windows NT. I've been following the instructions in the R complements to Venables and

Dear R-devel community, There appears to be an inconsistency in R C API about the exceptions that can be raised from C code. Mapping of R C funs to corresponding R functions is as follows. error -> stop warning -> warning REprintf -> message Rprintf -> cat Rprint/cat is of course not an exception, I listed it just for completeness. The inconsistency I would like to report is

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Dear R .Call() insiders, Can someone enlighten me how to properly finalize external pointers in C code (R-2.5.1 win)? What is the relation between R_ClearExternalPtr and the finalizer set in R_RegisterCFinalizer? I succeeded registering a finalizer that works when an R object containing an external pointer is garbage collected. However, I have some difficulties figuring out how to do that in an

Dear R-devel, I think the following describes a bug in R. It seems to be associated with dyn.load() and/or something that happens at start-up. I have not filed a bug report yet (because I doubt my ability to rule out other explanations) but would happily do so if requested. Observation: If two dlls are loaded as a result of dyn.load() calls in .Rprofile, subsequent calls to dyn.load()

Dear R contributors, Considering the following sample C code, that illustrates two possible uses of a Cholesky decomp for inverting a matrix, equally valid at least in theory: SEXP test() { int d = 2; int info = 0; double mat[4] = {2.5, 0.4, 0.4, 1.7}; double id[4] = {1.0, 0.0, 0.0, 1.0}; double lmat[3]; F77_CALL(dpotrf)("L", &d, mat, &d, &info); lmat[0] = mat[0]; lmat[1]