I've recently hunted down a troublesome bug in my own code, and am looking for an easy mechanism to detect this kind of error in other R code. The problem was an undefined variable inside of a function. Unfortunately, R looked for that variable in the global environment and found it since there was variable with that name in my testing scripts (note to self: do not name things "x"). Is there an easy way to report all the non-local objects accessed in a function? Is there any easy way around the usual scoping rules? I want to be able to get to base functions, and am willing to namespace:: or ::: access all of my own functions (it's in a package) if necessary to block the standard scoping rules. The language def section on environments made me hurt. Thanks, C Ryan King Dept Health Studies University of Chicago
Detecting bad lexical scoping
3 messages · Ryan King, Duncan Murdoch, Gabor Grothendieck
On 16/03/2011 4:14 PM, Ryan King wrote:
I've recently hunted down a troublesome bug in my own code, and am looking for an easy mechanism to detect this kind of error in other R code. The problem was an undefined variable inside of a function. Unfortunately, R looked for that variable in the global environment and found it since there was variable with that name in my testing scripts (note to self: do not name things "x"). Is there an easy way to report all the non-local objects accessed in a function?
The problem is that all base functions are non-local objects, so you probably don't want to do exactly that, but the codetools package can do it (using tools::findGlobals) and also provides help in identifying errors. You say you keep your code in a package (which is a good idea) so you should run "R CMD check" on the package. If your code is not in a package, use tools::checkUsage or related functions.
Is there any easy way around the usual scoping rules? I want to be able to get to base functions, and am willing to namespace:: or ::: access all of my own functions (it's in a package) if necessary to block the standard scoping rules. The language def section on environments made me hurt.
Quoting Uwe Ligges, "No". Duncan Murdoch
On Wed, Mar 16, 2011 at 4:14 PM, Ryan King <c.ryan.king at gmail.com> wrote:
I've recently hunted down a troublesome bug in my own code, and am looking for an easy mechanism to detect this kind of error in other R code. ?The problem was an undefined variable inside of a function. Unfortunately, R looked for that variable in the global environment and found it since there was variable with that name in my testing scripts (note to self: do not name things "x"). Is there an easy way to report all the non-local objects accessed in a function? Is there any easy way around the usual scoping rules? ?I want to be able to get to base functions, and am willing to namespace:: or ::: access all of my own functions (it's in a package) if necessary to block the standard scoping rules. ?The language def section on environments made me hurt.
One way is discussed in the Feb 27, 2010 news item on the proto home page: http://r-proto.googlecode.com
Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com