[ESS] debugging, mostly tracebug

[Vitalie Spinu]

  >> Ross Boylan <ross at biostat.ucsf.edu>
  >> on Thu, 04 Apr 2013 17:11:04 -0700 wrote:

 > I had hoped that the package would let me position breakpoints on the fly, but
 > it seems not to work that way.  Instead you insert breakpoints into a source
 > file and then read it in.  This means you can not set a breakpoint at a new
 > location while in a debugging session, and also that you must clear the
 > breakpoints before "really" saving the file (e.g., a VCS commit).  Is my
 > understanding correct, or is there a better way?

Yes. Your understanding is correct. Breakpoint facility is a convenience
wrapper around R's browser() function. It offers handy ways to create,
navigate and delete breakpoints of various kinds. You can kill all the
breakpoints in the file with Prefix-K.

As to the marking for debugging on the fly, C-c C-t d
(ess-dbg-flag-for-debugging) is designed for that. It is essentially a
visual wrapper around debug() and trace() and is supposed to work both
for functions and methods.  To undebug,  C-c C-t D.

Unfortunately there is a long standing limitation in the ess-tracebug
that doesn't allow debuging from within a debug session. I plan to solve
that in a very near future.

 > Is the enable/disable breakpoints a half way house, so that one can enable and
 > disable on the fly, or does that require rereading the source too?

Yes. Breakpoints are for visually marking the source. C-c C-t d is for
flagging for debugging. 

Your desire for "imaginary breakpoints" goes against "source is real"
philosophy. Suppose I source a function, modified it in several places
and inserted a breakpoint. What do you expect would happen? The new
function is sourced with breakpoint, or the old "real" function in R's
environment is altered by inserting a breakpoint? I hope you see that
the second case is absurd.

And I hope you don't propose to source the code in the file each time
the user inserts a breakpoint. Only the user can decide when to source
his or her code. 

Unlike matlab, R doesn't track your sources and you have to make them
"alive" by sourcing the code.

 > I followed the instructions at http://code.google.com/p/ess-tracebug/, hoping
 > that it would magically realize that the code I was fiddling with was in a
 > package/namespace.  Seemingly it did not.

How do you propose it would magically realize that?  And if I really
want them in GlobalEnv?

 > Vitalie Spinu previously ("developing packages with namespaces" around Feb 6)
 > recommended using ess-developer, and Barry Rowlingson suggested devtools.  Can
 > either of those be combined with ess-tracebug?

Ess-developer does a fair amount of magic. It recognizes functions as
being part of namespace and inserts them silently. For all the rest
(regions, paragraphs) it asks the user for the environment to insert
them.

The work flow is as follows. Toggle ess-developer on. Insert a
breakpoint in a function. C-c C-c on a function. Evaluate the
problematic code.

 > I'm  not sure how R got this far with such minimal debugging
 > facilities.  

What would be there to add?


    Vitalie