search for: do_dotcod

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 &q...

...rovided by gentoo (an old version of 1.9.0) or the latest version 1.9.1 which I just pulled down. in case someone is wondering, the debugger backtrace provides #0 0x000000000052ac16 in dnrm2_ () #1 0x00000000005185e8 in dqrdc2_ () #2 0x0000000000518db1 in dqrls_ () #3 0x000000000045d5d5 in do_dotCode () #4 0x0000000000472b6b in Rf_eval () ... (if any R wizard were to find it useful to try it out for himself, I could arrange for machine access, or provide other relevant information. if anyone has compiled R 1.9.1 under amd64 with gcc 3.3.3 and found it to be stable, please let me know, to...

...rovided by gentoo (an old version of 1.9.0) or the latest version 1.9.1 which I just pulled down. in case someone is wondering, the debugger backtrace provides #0 0x000000000052ac16 in dnrm2_ () #1 0x00000000005185e8 in dqrdc2_ () #2 0x0000000000518db1 in dqrls_ () #3 0x000000000045d5d5 in do_dotCode () #4 0x0000000000472b6b in Rf_eval () ... (if any R wizard were to find it useful to try it out for himself, I could arrange for machine access, or provide other relevant information. if anyone has compiled R 1.9.1 under amd64 with gcc 3.3.3 and found it to be stable, please let me know, to...

...Breiman's original code). All memory allocations are done in rf.c, using S_alloc(). When I run random forest with the data and setting as mentioned above, it was able to finish growing the 7000 trees, but segfault when returning from rf() to R. GDB gave the following (gdb prompts removed): do_dotCode (call=0x873aff4, op=0x8a5f620, args=0x8a5d010, env=0x86fd0a4) at dotcode.c:1413 1413 break; 1845 PROTECT(ans = allocVector(VECSXP, nargs)); 1846 havenames = 0; 1847 if (dup) { 1849 info.cargs = cargs; 1850 info.allArgs = args; 1851...

...Breiman's original code). All memory allocations are done in rf.c, using S_alloc(). When I run random forest with the data and setting as mentioned above, it was able to finish growing the 7000 trees, but segfault when returning from rf() to R. GDB gave the following (gdb prompts removed): do_dotCode (call=0x873aff4, op=0x8a5f620, args=0x8a5d010, env=0x86fd0a4) at dotcode.c:1413 1413 break; 1845 PROTECT(ans = allocVector(VECSXP, nargs)); 1846 havenames = 0; 1847 if (dup) { 1849 info.cargs = cargs; 1850 info.allArgs = args; 1851...

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

...----------- ### This is one of the memory leaks ==9370== 162 (160 direct, 2 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 42 ==9370== at 0x4A19D35: malloc (vg_replace_malloc.c:149) ==9370== by 0x84490E0: ??? ==9370== by 0x844D346: ??? ==9370== by 0x4BBE1A2: do_dotCode (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BE9035: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BEAF0D: do_begin (in /usr/lib64/R/lib/libR.so) ==9370=...

...tput from gdb, which is given below. Any help would be greatly appreciated. Martyn > eigen(cbind(-1,c(1:2,0),0:2)) # complex values Program received signal SIGSEGV, Segmentation fault. 0xb1dc8 in hqr2_ () (gdb) bt gives:- (gdb) bt #0 0xb1dc8 in hqr2_ () #1 0xb4bb4 in rg_ () #2 0x3909c in do_dotCode (call=0x70421f64, op=0x70421b90, args=0x70679f28, env=0x7067791c) at dotcode.c:386 #3 0x3fc7c in eval (e=0x70421f64, rho=0x7067791c) at eval.c:180 #4 0x41118 in do_set (call=0x70421fa0, op=0x702d4828, args=0x70421f8c, rho=0x7067791c) at eval.c:761 #5 0x3fc7c in eval (e=0x70421fa0, rho...

...[0x5fb43040, 0xf8c8e130) (defined) ==30841== Invalid write of size 4 ==30841== at 0xCD719F0: ehg139_ (loessf.f:1444) ==30841== by 0xCD72E0C: ehg131_ (loessf.f:467) ==30841== by 0xCD73A5A: lowesb_ (loessf.f:1530) ==30841== by 0xCD2C774: loess_ise (loessc.c:219) ==30841== by 0x486C7F: do_dotCode (dotcode.c:1744) ==30841== by 0x4AB040: bcEval (eval.c:4544) ==30841== by 0x4B6B3F: Rf_eval (eval.c:498) ==30841== by 0x4BAD87: Rf_applyClosure (eval.c:960) ==30841== by 0x4B6D5E: Rf_eval (eval.c:611) ==30841== by 0x4B7A1E: do_eval (eval.c:2193) ==30841== by 0x4AB040: bcEval (eva...

...$1 = 2 (gdb) print j $2 = -4099 If you use 'R -d valgrind' it stops in the same spot on the first call to supsmu: 1 ==8058== Invalid read of size 8 ==8058== at 0x56A65DA: smooth_ (ppr.f:1087) ==8058== by 0x56A64D5: supsmu_ (ppr.f:1028) ==8058== by 0x80B2488: do_dotCode (dotcode.c:1753) ==8058== by 0x80C9405: Rf_eval (eval.c:441) ... ==8058== Address 0x5EFDA80 is 0 bytes after a block of size 232,024 alloc'd ==8058== at 0x401A6EE: malloc (vg_replace_malloc.c:149) ==8058== by 0x80EFBC9: Rf_allocVector (memory.c:1952) ==8058== by...

...9 Rf_eval + 1196 (in libR.dylib) [0x10013ca1c] 19 do_set + 709 (in libR.dylib) [0x10013ea55] 19 Rf_eval + 1676 (in libR.dylib) [0x10013cbfc] 19 do_dotCode + 6074 (in libR.dylib) [0x100111e9a] 6 pa + 2960 (polio_3A.c:258 in polio_3A.so) [0x101707b70] 5 pa + 2989 (polio_3A.c:256 in polio_3A.so) [0x101707b8d]...

..._64-linux-gnu/libtk8.6.so+0x6dcc6) ??? #9 0x7f7874546c7a (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x6bc7a) ??? #10 0x7f787453f6c4 (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x646c4) ??? #11 0x7f7874bf0c0b in tcltk_init /usr/local/src/R-devel/src/library/tcltk/src/tcltk.c:697 ??? #12 0x5582e3aa93c1 in do_dotCode /usr/local/src/R-devel/src/main/dotcode.c:1743 ??? #13 0x5582e3b41f79 in bcEval /usr/local/src/R-devel/src/main/eval.c:6775 ??? #14 0x5582e3b6a5df in Rf_eval /usr/local/src/R-devel/src/main/eval.c:620 ??? #15 0x5582e3b702b9 in R_execClosure /usr/local/src/R-devel/src/main/eval.c:1780 ??? #16 0...

...Collect (size_needed=6777) at memory.c:1286 #2 0x080bdaa0 in R_gc_internal (size_needed=6777) at memory.c:1859 #3 0x080bd729 in Rf_allocVector (type=13, length=13554) at memory.c:1722 #4 0x08090a71 in CPtrToRObj (p=0x98db958, arg=0x98b29f8, Fort=1, type=13) at dotcode.c:209 #5 0x080933cb in do_dotCode (call=0x89f3880, op=0x8222154, args=0x833b380, env=0x8346e90) at dotcode.c:1907 #6 0x080a035d in Rf_eval (e=0x89f3880, rho=0x8346e90) at eval.c:427 #7 0x080a195a in do_set (call=0x89f390c, op=0x8218610, args=0x89f38b8, rho=0x8346e90) at eval.c:1102 #8 0x080a01e1 in Rf_eval (e=0x89f390...

...allocations are done in rf.c, using S_alloc(). When I > run random > forest with the data and setting as mentioned above, it was > able to finish > growing the 7000 trees, but segfault when returning from rf() > to R. GDB > gave the following (gdb prompts removed): > > do_dotCode (call=0x873aff4, op=0x8a5f620, args=0x8a5d010, > env=0x86fd0a4) > at dotcode.c:1413 > 1413 break; > 1845 PROTECT(ans = allocVector(VECSXP, nargs)); > 1846 havenames = 0; > 1847 if (dup) { > 1849 info.cargs = cargs; > 1850...

...xlindx=..., nnzlmax=197231, lnz=..., xlnz=..., iw=..., iwmax=1410, iwork=..., xsuper=..., tmpmax=100244, tmpvec=..., wwm=..., wwn=..., cachsz=64, level=8, x=..., s=..., u=..., c=..., y=..., b=. .., small=9.9999999999999995e-07, ierr=0, maxit=100, timewd=...) at srqfn.f:27 #7 0x00007ffff7b037a2 in do_dotCode # <-- R code starts here (call=<optimized out>, op=<optimized out>, args=<optimized out>, env=<optimized out>) So both TINY and LARGE are invalid pointers at this point, suspiciously small ones at that (on my 64-bit Linux, a typical pointer looks like 0x7fffff??...

Hi, Could someone please point to an example of passing strings from .C() calls back to R? I want to be able to do something like this: str <- .C("return_foo_string", str=character(1))$str void return_foo_string(char ** str) { *str = "foo"; } The above code has at least two memory allocation "concerns": 1) How to properly allocate "foo". I

Does .C duplicate unnecessary arguments? For instance fit <- .C("xxx", as.integer(n), x, y, z=double(15)) The first and fourth arguments would have NAMED = 0. Is my guess that .C won't make yet one more (unnecessary) copy correct? (Just trying to understand). Terry T

Full_Name: Rob Foxall Version: 2.2.0 OS: Windows XP Submission from: (NULL) (149.155.96.5) I was using multinom from nnet package, when I did something stupid -- I entered in an incorrect factor variable as response. This factor had only one level. Instead of R telling me not to be so dumb, it crashed, clicking on debug coming up with the message "An exception 'Unhandled Win32

Full_Name: Benjamin Tyner Version: 2.1.0, 4/18/2005 OS: i686-redhat-linux-gnu Submission from: (NULL) (4.64.8.220) # Just run my.test() below in a newly opened R session. Once too many models have been fit (~20 on my system), the computed standard error jumps to a different value. This is (superficially) due to a different residual sum of squares, not a different one.delta. No other aspect of