search for: applyclosur

Hi, Short version of my question: Rf_applyClosure was marked attribute_hidden in Oct 2023, and I am curious why and if there is an alternative interface to it planned. Long version: I have been toying with building a package that makes it easier to do non-standard evaluation directly using promises, rather than wrapping these in a custom type (...

Would you consider the following patch to eval.c to allow compatibility with RCC? (It's in the applyClosure function.) @@ -432,6 +432,14 @@ SEXP f, a, tmp; RCNTXT cntxt; +#ifdef RCC + SEXP comp; + PROTECT(comp = getAttrib(op, install("RCC_CompiledSymbol"))); + if (comp != R_NilValue) /* compiled version exists */ + op = comp; + UNPROTECT(1); +#endif /* RCC */ +...

...nFrame( stats, install( "rnorm") ) ) ; SEXP call = PROTECT( LCONS( rnorm, CONS( ScalarInteger(10), CONS(ScalarReal(0), R_NilValue ) ) ) ); SEXP res = PROTECT( eval( call , R_GlobalEnv ) ); UNPROTECT(4) ; return res ; It works, but I was wondering if there was another way. I've seen applyClosure, but I'm not sure I should attempt to use it or if using a call like above is good enough. Romain PS: using Rcpp's C++ classes you would express the code above as : Environment stats("package:stats") ; Function rnorm = stats.get( "rnorm" ) return rnorm( 10, 0.0 ) ;...

...x7042310c, rho=0x7067791c) at eval.c:379 #13 0x3fc7c in eval (e=0x70423120, rho=0x7067791c) at eval.c:180 #14 0x40b58 in do_begin (call=0x7041eddc, op=0x702d48c8, args=0x70423134, rho=0x7067791c) at eval.c:588 #15 0x3fc7c in eval (e=0x7041eddc, rho=0x7067791c) at eval.c:180 #16 0x3ffcc in applyClosure (call=0x70677868, op=0x7042347c, arglist=0x706778cc, rho=0x702dca50, suppliedenv=0x702d4008) at eval.c:293 #17 0x3fcf0 in eval (e=0x70677868, rho=0x702dca50) at eval.c:189 #18 0x5370c in R_ReplConsole (rho=0x702dca50, savestack=0, browselevel=0) at main.c:274 #19 0x53b74 in mainloop () at...

...ll=0x405ba4b0, op=0x402d8d00, args=0x405ba49c, env=0x40941944) at names.c:862 862 args = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env); #7 0x807c6a1 in Rf_eval (e=0x405ba4b0, rho=0x40941944) at eval.c:172 172 tmp = PRIMFUN(op) (e, op, CDR(e), rho); (gdb) up #8 0x807cb40 in Rf_applyClosure (call=0x405b6a7c, op=0x405ba550, arglist=0x402d8008, rho=0x409437bc, suppliedenv=0x402d8008) at eval.c:342 342 PROTECT(tmp = eval(body, newrho)); (gdb) up #9 0x807c7cb in Rf_eval (e=0x405b6a7c, rho=0x409437bc) at eval.c:192 192 tmp = applyClosure(e, op, tmp, rho, R_NilValue); (gdb) up...

...als. FIXME: It looks like eval.c- this code should preceed the building of the environment so that -- eval.c: /* The default return value is NULL. FIXME: Is this really needed eval.c- or do we always get a sensible value returned? */ -- eval.c:/* **** FIXME: This code is factored out of applyClosure. If we keep eval.c- **** it we should change applyClosure to run through this routine -- eval.c: /* The default return value is NULL. FIXME: Is this really needed eval.c- or do we always get a sensible value returned? */ -- eval.c:/* **** FIXME: Temporary code to execute S4 methods i...

...esses to migrate to other nodes on the cluster transparently. See www.mosix.org for details. However, my R processes were refusing to migrate. Using strace, and delving into the R code, I found that it was due to a large number of calls to the system setjmp and longjmp routines - the setjmp is in applyClosure() in eval.c and the longjmps could be just about anywhere. The problem is that setjmp and longjmp preserve the signal handling context, and any change in signal handling has to be done on the machine that the R process started on. If the process has migrated there is some overhead as the remote...

...b89c in do_Machine (call=0x50550958, op=0x502d4a08, args=0x502cf008, env=0x5055082c) at arithmetic.c:162 #2 0x48dd8 in do_internal (call=0xd9308, op=0x502d49e0, args=0x502cf008, env=0x5055082c) at names.c:768 #3 0x39f5c in eval (e=0x502dbd80, rho=0x5055082c) at eval.c:156 #4 0x3a2ac in applyClosure (call=0x505507c8, op=0x502dbe0c, arglist=0x502cf008, rho=0x502cf008, suppliedenv=0x502cf008) at eval.c:269 #5 0x39fd4 in eval (e=0x505507c8, rho=0x502cf008) at eval.c:165 #6 0x3b370 in do_set (call=0x50550804, op=0x502cf7c4, args=0x505507f0, rho=0x502cf008) at eval.c:749 #7 0x39f5c in...

...P - && length(result) >= 6) - return result; - else - return R_NilValue; + && length(result) >= 6) { + +#ifdef R_CODE_COVERAGE + if (R_Code_Coverage) record_code_coverage(result); +#endif + + } else { + result = R_NilValue; + } + + return result; } SEXP applyClosure(SEXP call, SEXP op, SEXP arglist, SEXP rho, SEXP suppliedenv)

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