[ESS-bugs] ESSR is not attached when running R under gdb
Martin Maechler
maechler at stat.math.ethz.ch
Fri Aug 15 16:56:33 CEST 2014
This is not a release stopper... but is happening to me about once a
month... and sometimes I'm losing too many of my few remaining hairs
about it:
If you start R "under gdb" (C level debugger; important, e.g. for
debugging R packages containing C code), via
C-u M-x R -d gdb [Enter]
The first misfeature is that ESS does not end showing you the *R*
buffer {because it does not see the usual prompt}.
That has always been the case; IIRC, ESS also *hangs*, waiting for
the correct prompt.... this is a bit more of a pain, and I think we
should at least have a timeout instead of indefinite hanging.... still
I can live with that as I know to be impatient and type C-g
eventually (but many less experienced emacs/ESS users will already
have suffered till here)
But now, I manually go to *R*, am in the debugger, maybe set some
break points (after all it is about debugging some of the C code), and
start R, by typing
'run' or just 'r'.
R starts, and I have an *R* buffer with R running as usual..... with
one *BIG* exception: the ESSR environment is not attached, and
consequently,
many ESS features fail.. and partly fail quite confusingly {confusing
to me, even; as I typically have forgotten from last time, that it is
the missing ESSR}.
Now ideally, I would never get into this problem (when ESS supported
the gdb -> R interface better).
However -- even before improving such a gdb -> R interface -- I think
we should have and provide a simple way, i.e., a function such as
M-x ess-load-ESSR {that we could then also add to a menu}.
Such a function would also be useful if a user accidentally detach()es
ESSR ... or some cleanup.packages() function he may run which
detach()es a lot of things and accidentally also ESSR.
As I say: Not a release stopper, but something I'd be extremely happy
if we fixed it soon.
Martin
More information about the ESS-bugs
mailing list