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 <wor...@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
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
