[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