From mail at joeconway.com  Fri Jul  6 19:35:41 2007
From: mail at joeconway.com (Joe Conway)
Date: Fri, 06 Jul 2007 10:35:41 -0700
Subject: [Rd] problem with findFun call from embedded R
In-Reply-To: <468D1876.2030605@vanderbilt.edu>
References: <468C0961.9020804@joeconway.com> <468D1876.2030605@vanderbilt.edu>
Message-ID: <468E7D6D.1040604@joeconway.com>

Jeffrey Horner wrote:
> Joe Conway wrote:
>> I was debugging a problem reported to me regarding PL/R, and found 
>> that I can duplicate it using only R sources. It might be 
>> characterized as possibly a misuse of the findFun() function, but I 
>> leave that for the R devel experts to decide.

>> My question is -- is the above an abuse of findFun() by RNamedCall.c 
>> (meaning I should avoid the same pattern)? Or maybe it should be 
>> wrapped in something similar to R_ToplevelExec?

> Yes, when one embeds R, findFun() will call error() which causes the 
> longjmp() to the top level, so the embedding application shouldn't use 
> findFun().

OK, thanks for the confirmation. I just wonder if RNamedCall.c ought to 
be changed then...

>  Here's what I've written for the next version of RApache. Note that 
> it's behavior is slightly different than the original findFun(), in that 
> it doesn't search the enclosing environments. (Also, comments welcome as 
> the implementation is based on the original, and I'm unsure if promise 
> evaluation is needed.)
> 
> 
> /* This one doesn't longjmp when function not found */
> static SEXP MyfindFun(SEXP symb, SEXP envir){

Yes, if I patch RNamedCall.c with the attached (based on your function), 
everything seems to work.

Thanks,

Joe


-------------- next part --------------
A non-text attachment was scrubbed...
Name: myfindfun.diff
Type: text/x-patch
Size: 667 bytes
Desc: not available
Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20070706/caba9bd9/attachment.bin 


[Rd] problem with findFun call from embedded R
Joe Conway