[ESS] ess-tracebug behavior [probably wishlist]
spinuvit at gmail.com
Sat May 4 12:28:13 CEST 2013
>> Ross Boylan <ross at biostat.ucsf.edu>
>> on Fri, 03 May 2013 18:38:02 -0700 wrote:
> I am now using the latest git:
There have been some (not yet documented) breaking changes in tracebug's
> C-c C-t d to debug a function. It was exported from a package, and did appear
> on the autocompletion list.
> I did enter the debugger when I hit it, though no special code display. The
> status area of emacs listed a bunch of keys like (M)-N for next. I hit Esc-n
> and got an error"M-n is undefined". If I enter the R window I can debug in the
> usual R way. Apparently Esc-N (uppercase) works; having to hit the shift key
> for a basic debugging operation is awkward.
Why Esc? M-S-n should work and is pretty convenient.
Debuging is now working as a minor mode which is active only during the
debug. You can customize ess-debug-minor-mode-map to whatever keys you
M-N, M-U, M-C were chosen because they are quite easy to type (unless
you use Esc) and they don't overlap with any editing or navigation
commands. Everything else we have considered didn't work so well; this
is the best solution out there.
> I wanted to trace into a function that had not been exported. C-c C-t d did
> have it on the completion list--impressive.
All visible functions from the current context are available. At top
level you can also debug non-exported function if you are developing
the package (aka C-c C-t a).
> However, although it told me it had set debugging, I did not actually
> get a debugger on it. I typed n in the debugger prompt and it simply
> returned (mice.impute.2lmixed.logit was the inner function I was
> trying to debug):
> debug: type <- c(2, type)
> debug: if (any(type == 1)) return(mice.impute.2lmixed.logit(y, ry, x,
> Browse> any(type==1) # set debug on mice.impute.2lmixed.logit here
>  TRUE
> Browse> n
> debug: return(mice.impute.2lmixed.logit(y, ry, x, type))
I will investigate this. There might be some limitations of debug, but
from my tests the above scenario should work as expected, unless ... see bellow.
> After using ess-developer on the package (C-c C-t a mice) the private function
> is part of the completion list for C-c C-t d at the top level.
Ok, so you discovered it by yourself:)
> I thought the first time I tried this it did not stop, but when I try
> to reproduce it's OK. However, the completion lists the function
> twice, once as mice.impute2l.mixed.logit and once as
Ok, this explains why you didn't get your debug in the first time. Your
inner function is also an exported function or you have a copy of it in
This is how namespaces work in R, there are two copies, one in package
environment (visible in search()) and one in the namespace. Both copies
are enclosed (environment(foo)) by the namespace. Thus the behavior is
The difference is arising when you debug one of them and not another;
from global context only the package's function is accessible, from the
package's context only the namespace copy is accessible. So you must
take care of these issue.
The worst case happens when you debug a package level function. If you
call it directly the package version is invoked, but when this function
is called by another function from the same package, then the namespace
version is invoked.
I might be able to handle these issues transparently for the user. Will
look into it. For time being you have to keep track of it yourself.
> C-c C-t D did not remove the debugging from the function. Actually, I'm not
> sure the uppercase D is getting through;
It is now bound to C-c C-t u (aka (u)nflag, or (u)ndebug). I removed C-c
C-t D by mistake.
> when it was echoing I only saw a lower case d, and the status message
> is "flagged for debugging" after I select the function.
Yes, you were calling -flag-for-debug.
> C-u C-t d does debugonce.
Good idea. but you meant C-u C-c C-t d. A bit of a mouthful:)
BTW, for convenience all dev commands are also available with C- prefix
(C-c C-t C-d).
> For the record: options(deparse.max.lines) limits the stack trace (an
> R, not ESS, feature). It's only partly effective, limiting the stack
> trace but not the function body dump as you enter the browser.
This is what R doc says:
‘deparse.max.lines’: controls the number of lines used when
deparsing in ‘traceback’, ‘browser’, and upon entry to a
function whose debugging flag is set. Initially unset, and
only used if set to a positive integer.
So you say this doesn't work as advertised? I would be a bit reluctant
to clean the display from ESS, as it opens the possibility to "clean"
Thanks for the input,
More information about the ESS-help