[R] Line numbers with errors and warnings?
Duncan Murdoch
murdoch.duncan at gmail.com
Sun Dec 2 20:21:56 CET 2012
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.
>
> This could be especially useful for packages that were not installed
> with keep.source=TRUE. It could even help getting more useful error
> messages on R-help...
If you're debugging a package, then why not install it with
keep.source=TRUE?
Duncan Murdoch
More information about the R-help
mailing list