[ESS] debugging, mostly tracebug

[Ross Boylan]

On 4/5/2013 2:18 AM, Vitalie Spinu wrote:
>    >> 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.
Bummer!
>   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.
Do you mean ess-dbg-flag-for-debugging will not work if run from within 
the browser?  And does "will not work" mean debugging doesn't get put 
on, or that it does, but ess-tracebug loses the ability to follow the 
source location?
>
>   > 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.
I was referring to the ess-bp-toggle-state command.
>
> Your desire for "imaginary breakpoints" goes against "source is real"
> philosophy. Suppose I source a function, modified it in several places
you mean modified the source file, or modify the function within R by, 
e.g., apply debug() or trace() to it, or  perhaps just redefining it 
completely?
> and inserted a breakpoint. What do you expect would happen?
Since I don't follow the scenario it's hard to comment.  In general the 
version in the source file and in the R image might be out of sync, but 
I'm not sure what the relevance is to debugging.

>   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.
"imaginary breakpoints" is your phrase, not mine.  In most debugging 
systems the source is real but breakpoints are maintained dynamically 
during the debugging session, and can be put on or off at will.  I do 
not think such a facility is absurd, though it may be technically 
difficult in R.

I don't think sourcing the code, or otherwise redefining the function 
during debugging, could possibly work for dynamic breakpoints.  Either 
the old version of the function will stick around for use by the 
debugging session, in which case redefining the function has no effect 
on the current session, or a new function is created and the old one 
destroyed, which would take the debugging session with it.  Neither 
route achieves the goal of adding and removing breakpoints during one 
debugging session.
>
> 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?
The documents for tracebug do not address namespaces; my hope (not 
expectation) was that they would be handled automatically.  In this 
context that would mean detecting that the function being taken in was 
in a namespace and updating that version of a function.  As you point 
out, that might not be the desired behavior (also realizing that a 
function that is not exported is part of a namespace requires looking 
harder).

ess-developer adopts the more explicit route of requiring you to specify 
a default namespace (I thought, but see below).
>
>   > 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.
Hmm, are you saying that it was unnecessary to specify a default 
namespace for ess-developer?
>
> 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?
I listed them in the next sentence:
> I'm  not sure how R got this far with such minimal debugging 
> facilities.  As far as I know, one can't step into a function (without 
> first saying debug(function), which is permanent), can't step n steps 
> forward, and can't add and remove breakpoints on the fly.  Or am I 
> missing something?
As Kasper pointed out, debugonce deals with the problem of permance, but 
I think the others remain, including the fact that you have to say debug 
or debugonce to step into a function, as opposed to issuing, say, a step 
command.  To clarify, when I say "can't step n steps forward" I mean all 
at once.  Obviously you can do n steps one at a time from browser.  A 
related function is to be a able to click on a source line and say "run 
to there".  That's particularly handy if there's a big loop in between 
where you are and where you want to go.

Some debuggers allow you to change the flow of execution, e.g., 
reposition the next step to execute or edit variables.  But those are 
relatively advanced features.  I believe that changes made while in the 
browser are not seen by the program when it continues, though I might be 
wrong.

While I'm at it, there are some strengths to R's debugging environment.  
One basically has access to all of R while in the debugger so that it's 
easy to print out values and perform operations.  In many debuggers 
those tasks are difficult to impossible.

Ross