[Rd] debuggingState() analogous to tracingState() ?

[Martin Maechler]

I'm taking up an open strand ...

>>>>> Jonathan McPherson <jonathan at rstudio.com>
>>>>>     on Thu, 2 Oct 2014 10:56:01 -0700 writes:

    >> 
    >> > I don't have much of an opinion on these questions.
    >> I've never used the > tracingState() function, though I
    >> use trace() all the time (via > setBreakpoint()).  You
    >> might want to consult people who write debugger >
    >> front-ends.
    >> 
    >> which I am now doing: I'm including ESS-core, Jonathan
    >> (RStudio) and Tobias (StatET) which Duncan mentioned as
    >> being interested and having asked for better debugging
    >> support functionality in the past, such as
    >> 
    >> 
    > Some observations from RStudio which may or may not be
    > helpful:

    > We don't expose any UI that allows the user to modify
    > tracingState(). In fact, turning off tracingState() will
    > make RStudio's breakpoints stop working (as they rely on
    > trace()), without any warning or feedback from the
    > UI. We've never received complaints about this, and so my
    > presumption is that very few people need to turn off
    > tracing globally, and those who do know what they're doing
    > and/or aren't using the IDE debugging features.

    > Some mechanism for globally altering debugging state would
    > be very useful.  Right now we have a problem wherein
    > during debugging the R functions RStudio calls to
    > e.g. analyze and compose the list of objects in the
    > workspace are themselves debugged. Today we're solving
    > this by manually tripping the RDEBUG flag on an
    > environment before we evaluate expressions in it, which I
    > think we can all agree is less than ideal.

    > Do you foresee any non-interactive use for
    > debuggingState()? If so, it might be nice if the state had
    > push/pop rather than on/off semantics, to make the pattern
    > of disabling locally easier to express.

    >> the ability to add a breakpoint to a function that is
    >> currently being evaluated.

    > Yes, this would be useful to us, although unless I'm
    > missing something it seems pretty orthogonal to the rest
    > of the thread. It's not a common feature request.

You are right, that it seems pretty orthogonal to me, too.

    > One thing that would be useful is some officially
    > supported way to debug during source(). Lots of people
    > don't use functions and just have R scripts full of
    > straight-line statements (sometimes containing references
    > to other code via source()). RStudio will let you set
    > breakpoints on top-level statements, and this has proven
    > to be a popular feature, but its implementation is very
    > messy--we effectively create a function from the
    > statements in the file and then use the function debugger,
    > which works for simple scenarios but starts falling apart
    > if you do anything complicated.

Yes, that's yet another interesting idea...
though I'm still overly optimistically assuming that we can educate
users to use functions much more often, also as simple vehicles
and to debug them..  

Thank you, Jonathan, and the other commenters.
My main question (probably buried in too many other musings and statements)
about a good (function-based) UI for different kinds of
debuggingState()s has not been addressed and by any one, so I
assume that did not seem interesting enough and not worth
bothering complicating the interface.

I've finally committed  [to R-devel only]
what I had and looks working fine to me.  With a simple 
"on/off" switch only:

------------------------------------------------------------------------
r66751 | maechler | 2014-10-13 16:57:02 +0200 (Mon, 13 Oct 2014) | 1 line
Changed paths:
   M doc/NEWS.Rd
   M src/include/Defn.h
   M src/library/base/R/debug.R
   M src/library/base/man/debug.Rd
   M src/library/base/man/trace.Rd
   M src/main/debug.c
   M src/main/eval.c
   M src/main/names.c
   M src/main/objects.c

new debuggingState() - possibly to be tweaked
------------------------------------------------------------------------

This -- i.e. debuggingState(TRUE) -- does not (or *should* not)
influence the functioning of explicit browser() calls.

Currently it has an effect on debugonce() , not only on debug()
and this is something that I think should be changed,  but did
not easily see how [there are the RSTEP() vs RDEBUG() flags inside
the C code ...], and did not find too important for now.

Rather get the current proposal out, for you all to look and
hammer at ...

Martin