[R] Line numbers with errors and warnings?

[Milan Bouchet-Valat]

Le dimanche 02 décembre 2012 à 14:21 -0500, Duncan Murdoch a écrit :
> 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.
OK.

> > 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?
Of course. I just wondered whether this step could possibly be avoided.
It can be useful to have debugging details when casual users report a
bug, without reinstalling the package. Not a big deal, though.


Regards