search for: r_checkstack

Greetings R developers, R will run a little faster when executing "pure R" code if the function R_CheckStack() is modified. With the modification, the following code for example runs 15% faster (compared to a virgin R-2.5.1 on my Windows XP machine): N = 1e7 foo <- function(x) { for (i in 1:N) x <- x + 1 x } foo(0) The crux of the...

...undefined reference to `INTEGER' sparseQR.c:(.text+0x62a): undefined reference to `LENGTH' sparseQR.c:(.text+0x65a): undefined reference to `R_do_slot' sparseQR.c:(.text+0x662): undefined reference to `REAL' sparseQR.c:(.text+0x69a): undefined reference to `R_CheckStack' sparseQR.c:(.text+0x69f): undefined reference to `R_CheckStack' sparseQR.c:(.text+0x6b8): undefined reference to `R_do_slot' sparseQR.c:(.text+0x6c0): undefined reference to `REAL' sparseQR.c:(.text+0x6df): undefined reference to `R_do_slot' sparseQR.c:(.text+0x6e7): undefined...

...lpthread -lm -pgf90libs /usr/lib64/crt1.o(.text+0x21): In function `_start': ../sysdeps/x86_64/elf/start.S:109: undefined reference to `main' CHMfactor.o(.text+0x28): In function `CHMfactor_to_sparse': /tmp/R.INSTALL.TW3399/Matrix/src/CHMfactor.c:5: undefined reference to `R_CheckStack' CHMfactor.o(.text+0xa5):/tmp/R.INSTALL.TW3399/Matrix/src/CHMfactor.c:14: undefined reference to `Rf_error' CHMfactor.o(.text+0xe5):/tmp/R.INSTALL.TW3399/Matrix/src/CHMfactor.c:14: undefined reference to `R_NilValue' Other modules worked and could be compiled without any problem...

...threads by setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only works correctly when called form the main thread (see https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Threading-issues); in particular, any function that does allocations, e.g. via allocVect...

Dear r-devel members, I encountered a C stack limit issue, when I tried to embed R 2.5 into my application. In the R-exts document, it says:"Note that R's own front ends use a stack size of 10Mb". I desire to know: is it possible to decrease this stack size by modifying R's source code? If it's possible, which part of the source code is responsible for the issue? Thank

...by setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow >> 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only works correctly when called form the main thread (see https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_doc_manuals_r-2Drelease_R-2Dexts.html-23Threading-2Dissues&d=DwIFaQ&amp...

...y setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow > > 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only works correctly when called form the main thread (see https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Threading-issues); in particular, any function that does allocations, e.g. via allocVect...

...setting R_interrupts_suspended = TRUE; by wrapping the calls to functions from the R API with R_ToplevelExec(), longjmps across thread boundaries can be avoided; the only reason for R_ToplevelExec() itself to fail with an R-style error (longjmp) is a pointer protection stack overflow > > 3) R_CheckStack() might be executed (indirectly), which will (probably) signal a stack overflow because it only works correctly when called form the main thread (see https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_doc_manuals_r-2Drelease_R-2Dexts.html-23Threading-2Dissues&d=DwIFaQ&amp...

I will say this first -- I can't copy/paste the error message from the screen, so it's being retyped. Errors might occur. SORRY. I've been experiencing some interesting stack warnings recently when moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 series. In particular, I'm getting warnings of "Error: C stack usage is too close to the limit" before

Dear all, I had a R segmentation fault, and then invoked debug mode and ran step by step. When I reached "terms(Y~X1*X2*...*X16)", I would then have "segmentation" fault. However, if I just ran this under regular "R interactive" mode, it would be fine though taking long time. My questions are: 1. Is there a known limit of terms for a formula? 2. Why does the

Dear all, I had a R segmentation fault, and then invoked debug mode and ran step by step. When I reached "terms(Y~X1*X2*...*X16)", I would then have "segmentation" fault. However, if I just ran this under regular "R interactive" mode, it would be fine though taking long time. My questions are: 1. Is there a known limit of terms for a formula? 2. Why does the