Debugging R code. by Marek Rychlik February 28, 2009

Transcription

1 Debugging R code by Marek Rychlik February 28, 2009 Debugging facilities in R R supports writing bug-free programs in several ways: The function debug takes a function as its argument, and whenever the function is called, it enters a browser (also called the break loop). While in the browser, the user can examine the values of variables at the moment the break loop is entered and execute the following commands line-by-line. R offers exception handling. It is a modern, efficient way to handle errors. Exception handling requires the program developer to use special forms, such as calling the function simpleerror in the program when en error situation is detected. Typically a call to this function would occurr in a deeply nested function call. The pending function call immediately ceases. Thus a simple error is a kind of exceptions or condition. Using simpleerror we signal the condition. Normally, if we do not handle the condition, R will throw us out of our code, and print an error message at the interpreter level. To make the exception mechanism useful, exceptions need to be cought. The form trycatch may be used to intercept the exceptions before they reach the top level of the interpreter. Other facilities exist, but they will not be discussed here The most practical approach to debugging R code during development is using the debug function. This function provides a somewhat rudimentary single-stepping facility, i.e. we step through the code line by line. It should be noted that the preferred way to debug programs today is source level debugging offered by IDE s (Integrated Development Environments). An example of an IDE is the Microsoft VisualStudio Express, used for debugging programming languages such as C, C#, Java, and VisualBasic. Unfortunately, there appears to be no IDE for R at this time. In addition to single stepping, an IDE provides convenient summary of the state of the program. I am not a great advocate of IDE s because they have bugs of their own, and sometimes a bug in an IDE can bring program development to a grinding halt. The Emacs editor provides interfaces to many more austere debuggers, such as gdb (GNU debugger). When Emacs is used to debug C or C++, it steps through the code, but instead of printing individual lines of code it displays a window-full of source code in a separate window. Thus, one is able to view the surrounding code of the currently executing line, and immediately make changes. The ESS package for Emacs ( Emacs Speaks Statistics ) currently does not support source code debugging in this sense, but it goes a long way towards making debugging R programs more efficient. About TEX MACS The current notes are generated with TEX MACS, which is a WYSIWIG editor and document system with ideas borrowed from L A TEX and Emacs. TEX MACS supports interaction with many external programs. R is one of them, and thus one can include R sessions directly in the document. This maked writing tutorials like this one easier.

2 An example of a debugging session Using debug with R consists of two steps: Enclosing the code to be debugged in a function. If your code is already in a function, you do nothing. However, if your code is in a script file constructed as a sequence of calls to various R commands, you need to enclose the body of your script in a function. Calling debug on the function. Nothing will happen as a result of calling debug until the function gets called. Only then the browser is entered. Let us use our own implementation of the factorial function as an example. fac <- function(x) { if(x==0) else x * fac(x-) debug(fac) fac(3) else x * fac(x - ) debug: else x * fac(x - ) debugging in: fac(x - ) else x * fac(x - ) debug: else x * fac(x - ) debugging in: fac(x - ) else x * fac(x - ) debug: else x * fac(x - ) debugging in: fac(x - ) 2

3 else x * fac(x - ) debug: else x * fac(x - ) exiting from: fac(x - ) exiting from: fac(x - ) exiting from: fac(x - ) exiting from: fac(3) [] 6 During our first interaction, we just stepped through the code by pressing the Enter key. Our second interaction is more advanced: fac(3) else x * fac(x - ) where where : fac(3) debug: else x * fac(x - ) where where : fac(3) debugging in: fac(x - ) else x * fac(x - ) where where : fac(x - ) where 2: fac(3) debug: else x * fac(x - ) where where : fac(x - ) where 2: fac(3) debugging in: fac(x - ) 3

4 else x * fac(x - ) where where : fac(x - ) where 2: fac(x - ) where 3: fac(3) debug: else x * fac(x - ) debugging in: fac(x - ) else x * fac(x - ) debug: else x * fac(x - ) exiting from: fac(x - ) exiting from: fac(x - ) exiting from: fac(x - ) exiting from: fac(3) [] 6 We called the browser command where which lists the enclosing frames (also called environments in R). In other words, it tells us where we are in the call stack. In our next session we will obtain more information about the state of the program: fac(3) else x * fac(x - ) x [] 3 parent.frame() <environment: R_GlobalEnv n debug: else x * fac(x - ) debugging in: fac(x - ) 4

5 else x * fac(x - ) x [] 2 parent.frame() <environment: 0x27a5bb8 Q We examined the value of variable x and examined the value returned by parent.frame(), i.e. the object representing the environment which was in effect when the current call occurred. In this particular example, we demonstrated that a call results in a change of the environment. 5