partools (version 1.1.6)

dbs:

Description

Aids in debugging of code written for the cluster operations in the parallel package.

Usage

dbs(nwrkrs,xterm=NULL,src=NULL,ftn=NULL)
writemgrscreen(cmd)
killdebug()
dbsmsgstart(cls)
dbsmsg(msg)
dbsdump()

Arguments

cls

A cluster for the parallel package.

nwrkrs

Number of workers, i.e. size of the cluster.

xterm

The string "xterm" or name of compatible terminal.

src

Name of the source file to be debugged.

ftn

Name of the function to be debugged.

cmd

R command to be executed in manager screen.

msg

A message to write to the debugging record file. Can be either a character string or any expression that is printable by cat.

Details

A major obstacle to debugging cluster-based parallel applications is the lack of a terminal, thus precluding direct use of debug and browser. This set of functions consists of two groups, one for ``quick and dirty'' debugging, that writes debugging information to disk files, and the other for more sophisticated work that deals with the terminal restriction. For both methods, make sure setclsinfo has been called. For ``quick and dirty'' debugging, there is dbsmsg, which prints messages to files, invoked from within code running at the cluster nodes. There is one file for each member of the cluster, e.g. dbs.001, dbs.002 and so on, and dbsmsg writes to the file associated with the worker invoking it. Initialize via dbsmsgstart. Another quick approach is to call dbsdump, which will call R's dump.frames, making a separate output file for each cluster node. These can then be input to debugger to examine stack frames. The more elaborate debugging tool, dbs, is the only one in this partools package requiring a Unix-family system (Linux, Mac). To discuss it, suppose you wish to debug the function f in the file x.R. Run, say, dbs(2,xterm="xterm",src="x.R",ftn="f"). Then three new terminal windows will be created, one for the cluster manager and two for the cluster workers. The cluster will be named cls. Automatically, the file x.R will be sourced by the worker windows, and debug(f) will be run in them. Then you simply debug as usual. Go to the manager window, and run your parallel application launch call in the usual way, say clusterEvalQ(cls,f(5)). The function f will run in each worker window, with execution automatically entering browser mode. You are now ready to single-step through them, or execute any other browser operation. If xterm is NULL, you will be prompted to create the terminal windows by hand (or use existing ones), and run screen there as instructed. Terminal works on Macs; label the windows by hand, by clicking "Shell" then "Edit". When finished with the debugging session, run killdebug from the original window (the one from which you invoked dbs) to quit the various screen processes.

Examples

## Not run: ------------------------------------
# # quick-and-dirty method
# cls <- makeCluster(2) 
# setclsinfo(cls)
# # define 'buggy' function
# g <- function(x,y) {u<-x+y; v<-x-y; dbsmsg(c(u,v)); u^2+v^2} 
# clusterExport(cls,"g") 
# # set x and y at cluster nodes
# clusterEvalQ(cls,{x <- runif(1); y <- runif(1)}) 
# # start debugging session
# dbsmsgstart(cls) 
# # run
# clusterEvalQ(cls,g(x,y)) 
# # files dbs.1 and dbs.2 created, each reporting u,v values
# 
# # dbs() method
# # make a test file
# cat(c("f <- function(x) {","   x <- x + 1","   x^2","}"),file="x.R",sep="\n")
# dbs(2,src="x.R",ftn="f")
# # now type in manager window:
# clusterEvalQ(cls,f(5))
# # the 2 worker windows are now in the browser, ready for debugging
# 
# stopCluster(cls)
## ---------------------------------------------