As just seen, R’s debugging tools are effective. However, they’re not very convenient. Fortunately, there are various tools that make the process easier. In approximate chronological order of development, they are as follows:
Note
As of this writing (July 2011), work is in progress by the teams that develop the StatET and RStudio IDEs to add debugging tools.
All of these tools are cross-platform, working on Linux, Windows, and Mac systems, with the exception of the REvolution Analytics product. That IDE is available only on Windows systems with Microsoft Visual Studio. All of the tools are open source or free, again with the exception of the REvolution Analytics product.
So, what do these packages have to offer? To me, one of the biggest problems with R’s built-in debugging tools is the lack of a window that shows the big picture—a window displaying your R code with a cursor that moves through the code as you single-step through it. For example, consider this excerpt from our previous browser output:
Browse[2]> n debug at cities.r#17: n <- length(x) Browse[2]> n debug at cities.r#18: i <- x[n]
This is nice, but where are these lines in our code? Most GUI debuggers for other languages feature a window showing the user’s source code, with a symbol indicating the next line to be executed. All of the R tools listed at the start of this section remedy this lack in core R. The Bravington debug package creates a separate window for exactly this purpose. The other tools have your text editor double as that window, thus saving space on your screen compared to using debug.
In addition, these tools allow you to set breakpoints and handle other debugging operations without moving your screen’s cursor from the editor window to your R execution window. This is convenient and saves typing as well, greatly enhancing your ability to concentrate on the real task at hand: finding your bugs.
Let’s consider the cities example again. I opened the GVim text editor on my source file in conjunction with edtdbg, did some startup for edtdbg, and then hit the [ (left bracket) key twice to single-step twice through the code. The resulting GVim window is shown in Figure 13-1.
Note
Operation of edtdbg for Emacs is the same as shown here, just with different keystrokes used for the commands. For instance, F8 is used for single-stepping instead of [.
First, note that the editor’s cursor is now on this line:
wmins <- apply(dd[-n, ], 1, imin)
This shows the line to be executed next.
Whenever I want to single-step a line, I simply hit the [ key while I’m in the editor window. The editor then tells the browser to execute its n command, without my needing to move the mouse to the R execution window, and then the editor moves its cursor to the next line. I can also hit ] for the browser’s c command. Each time I execute a line or lines in this manner, the editor’s cursor moves right along.
Whenever I make a change to my source code, typing ,src (the comma is part of the command) into my GVim window will tell R to call source() on it. Each time I want to rerun my code, I hit ,dt. I rarely, if ever, need to move my mouse away from the editor window to the R window and back. In essence, the editor has become my debugger in addition to providing its editing operations.