On 12-12-02 9:52 AM, Milan Bouchet-Valat wrote:
Le dimanche 02 d?cembre 2012 ? 09:02 -0500, Duncan Murdoch a ?crit :
On 12-12-02 8:33 AM, Milan Bouchet-Valat wrote:
Le dimanche 02 d?cembre 2012 ? 06:02 -0500, Steve Lianoglou a ?crit :
Hi,
On Sun, Dec 2, 2012 at 12:31 AM, Worik R <worikr at gmail.com> wrote:
What I mean is how do I get the R compilation or execution process to spit
out a line number with errors and warnings?
Indeed, I often suffer from the same problem when debugging R code too.
This is a real issue for me.
As Duncan mentioned already, you can't *always* get a line number. You
can, however, usually get enough context around the failing call for
you to be able to smoke the problem out.
What are the cases where you cannot get line numbers? Duncan said
source()ed code comes with line numbers, but what's the more general
rule?
The general rule is that parse() needs to be called with the "srcfile"
argument set to a srcfile object. source() does that by default.
OK. But isn't it technically possible to compute a line number even when
no source file is present?
Yes, you don't really need to have a file present, you just need a
srcfile object. For example, on Windows when you use
source("clipboard"), there's no file, just the system clipboard.
If you call fix() on any function, you will
get something like a source file even if srcfile was not set.
Yes, and then you can call source on that object, and you'll get line
number information attached, relative to whatever you sourced.
So it
could make sense to have a line number referring to what you would see
in fix(). Or at least, the last executed line when calling browser() or
when using options(error=recover), like gdb does.
The thing is that if you didn't attach the line number information to
the code, then it's not there. R can't figure out after the fact where
the code came from. It needs to have the debug info in place when it
runs it. How could R figure out where some expression came from that it
happens to be executing? Using eval() on a constructed expression in a
function is not all that uncommon, but to the evaluator, it looks just
like any other evaluation.