similar to: Summary: too many arguments in foreign function call

Hi all, I've just been working with a piece of fortran code (Leo Breiman's random forest code) that needs a lot of arguments. When I use .Fortran, I get the message 'too many arguments in foreign function call'. Neither the help page for .Fortran (actually Foreign) nor "Writing R Extensions" explains how many arguments are too many. Looking at the code in

Hi all, I've just been working with a piece of fortran code (Leo Breiman's random forest code) that needs a lot of arguments. When I use .Fortran, I get the message 'too many arguments in foreign function call'. Neither the help page for .Fortran (actually Foreign) nor "Writing R Extensions" explains how many arguments are too many. Looking at the code in

Full_Name: Jonathan Paisley Version: 2.1.1 OS: Mac OS X 10.4.2 Submission from: (NULL) (81.178.107.67) I was following an example from library/grid/doc/grid.pdf ("Introduction to grid") and had the following code, where I'd mis-typed 1,3 instead of 1,2 as the first arguments to grid.layout. Sourcing this code causes the R GUI to crash. I've enclosed a partial backtrace from

> From: Robert Gentleman [mailto:rgentlem@jimmy.harvard.edu] > > Greg, > you might be better off writing a wrapper, > > R->foo where foo has less than 65 args and does nothing more than > unpack them and calls bar (the original) with as many args as you > want, not much code change and not much cost... Hi Rob, [BTW, sorry about the crosspost

Hi, I have a R program that call a C function. I define a vector of pointer as int nLC=3; int pownLC = nLC*nLC double *MatCovExtra[nT+1]; for(k=0;k<K+1;k++) { MatCovExtra[k] = (double*)R_alloc(pownLC, sizeof(double)); } where nT>K. Then i put some values on the vector associated with the pointer: for(k=0;k<K+1;k++) { for(i=0;i<nLC;i++)

For using R's .Call interface to C functions, all the examples I've seen have the C function return type SEXP. Why? What does R actually do with this return type? What happens if I *don't* return a SEXP? Reason I ask, is I've written some R code which allocates two long lists, and then calls a C function with .Call. My C code writes to those two pre-allocated lists, thus, I

The R_registerRoutines C function allows the number of parameters to a .Call function to be registered. For example, the tools package function md5sum() calls "Rmd5", which has been registered to require just one parameter. But if it is called with the wrong number of parameters, only the first error gets caught: > library(tools) >

Re: src/main/dotcode.c:do_dotCode() The value, if there is one, of a function called by .C or .Fortran is not captured, so one needs a wrapper. To avoid that, the user would have to declare that there is a value, specify its type, and supply an R variable to hold the value. Presumably, all of these could be combined in a new "VALUE=var" parameter. Then do_dotCode could arrange the

Hi- There is a public doman geostatistics package used in the minieral industry called GSLIB and I would like to use it from R. However it is fortran (but portable and easy to compile on windows and linux)and has its own file format and control file format. It seems easiest to write an r function to dump r data to an ascii file, build a control file in ascii; call the GSLIB program with

If anyone has a few extra CPU cycles to spare, I'd appreciate it if you could verify a problem that I have encountered. Run the code below and tell me if it crashes your R before completion. library(lme4) data(bdf) dump<-sapply( 1:50000, function(i) { fm <- lme(langPOST ~ IQ.ver.cen + avg.IQ.ver.cen, data = bdf, random = ~ IQ.ver.cen | schoolNR); cat("

Consider the following simple C program: /*** hello_r.c ***/ #include <Rinternals.h> SEXP hello() { return mkString("Hello, world!\n"); } int main(void) { SEXP x = hello(); return x == NULL; /* i.e. 0 on success */ } This program segfaults: % myR/bin/R CMD LINK gcc -I./R-2.9.0/src/include -L./myR/lib64/R/lib -lR hello_r.c -o hello_r > /dev/null % hello_r zsh:

We are having problems building R on Red Hat Linux 6.0/Sparc. R compiles with no problem but then it fails "make tests". Specifically, the line eigen(cbind(-1,c(1:2,0),0:2)) # complex values causes a segmentation fault. Previous versions of Red Hat Linux did not give this problem. The eigen() function is one of the rare cases in the base library where Fortran code is called via the

Batch: Putting q(save=F) at the end of my file does not work in my context because I can no longer source the file without quitting. I have that quit statement in my .First so that I always quit that way interactively. The problem is that it is ignored in batch. eigen: The crash occurs on my 586 running Red Hat Linux 2.0.27 but not on my son's 486 running SLackware Linix 2.0.29. We both

Can anyone spot the problem here. Following is an edited script of the install session. The gist is: * syntax error in original src/main/dotcode.c Easily remedied (or at least, such that compiles without error message ... ) change line 449-450 (two lines preceding return) #ifdef HAVE_F77_UNDERSCORE if(PRIMVAL(op)) { *q++ = '_'; *q = '\0'; #endif }

(Sorry for the cross-post--- I wasn't sure which list is more appropriate...) Hi everyone, I've run into segfaults when using my randomForest package on large dataset (e.g., 100 x 15200) and large number of trees (e.g., ntree=7000 and mtry=3000). I'm wondering if anyone can give me some hints on where to look for the problem. The randomForest package mainly consists of two things:

(Sorry for the cross-post--- I wasn't sure which list is more appropriate...) Hi everyone, I've run into segfaults when using my randomForest package on large dataset (e.g., 100 x 15200) and large number of trees (e.g., ntree=7000 and mtry=3000). I'm wondering if anyone can give me some hints on where to look for the problem. The randomForest package mainly consists of two things:

I've stumbled upon a small bug/inconsitency in do_External and do_dotcall: Here's an example: % LC_ALL=C R --vanilla < symname-bug.R R version 2.8.0 (2008-10-20) *snip* > options(error=expression(0)) > ## Call 'R_GD_nullDevice' with incorrect parameter count: > .Call("R_GD_nullDevice", 1) Error in .Call("R_GD_nullDevice", 1) :

Dear R-devel, While tracking down some hard-to-reproduce bugs in a package I maintain, I stumbled on a behavior change between R 2.15.0 and the current R-devel (or SVN trunk). In 2.15.0 and earlier, if you passed an 0-length vector of the right mode (e.g., double(0) or integer(0)) as one of the arguments in a .C() call with DUP=TRUE (the default), the C routine would be passed NULL (the C

Full_Name: Ricardo Aponte Version: R 2.4.0 OS: Solaris 10 Submission from: (NULL) (200.71.37.195) Hello I'm having trouble building R under Unix. I've searched for information about it on google or the R database but I didn't find any answer on my problem. I would be thankful if somebody could help me working that out. ./configure R is now configured for

Hello to everyone! I use .Call to call a C function without arguments wich calls a fortran optimization package. My C function uses others C and Fortran functions and it works fine when I call it from a main() in a C program. But when I call it from R with .Call("name_of_the_c_function"), R gives me some weird output. This weird output is a worng answer to my optimization problem