[R] Line numbers with errors and warnings?

[Duncan Murdoch]

On 12-12-02 5:02 PM, John Sorkin wrote:
> Gentleman,
> This thread has been of great interest. Perhaps I missed part of it, but
> do far I have not seen an example of code that has line numbers that
> demonstrates how one can (in some instances) recover the line number of
> an error. Can I impose upon the people who contributed to this thread to
> post example code? The question if very important, and the discussion
> about solutions has been somewhat abstract to this point.

 From my post this morning:

> For example, in Windows, if I put this code into the clipboard:
>
> f <- function() {
>    stop("this is the error")
> }
>
> g <- function() {
>    f()
> }
>
> g()
>
> then run source("clipboard") followed by traceback(), this is what I see:
>
>  > source("clipboard")
> Error in f() (from clipboard#2) : this is the error
>  > traceback()
> 7: stop("this is the error") at clipboard#2
> 6: f() at clipboard#6
> 5: g() at clipboard#9
> 4: eval(expr, envir, enclos)
> 3: eval(ei, envir)
> 2: withVisible(eval(ei, envir))
> 1: source("clipboard")
>
> You can ignore entries 1 to 4; they are part of source().  Entries 5, 6,
> and 7 each tell the line of the script where they were parsed.
>
> Duncan Murdoch


> Thank you,
> John
>
> John David Sorkin M.D., Ph.D.
> Chief, Biostatistics and Informatics
> University of Maryland School of Medicine Division of Gerontology
> Baltimore VA Medical Center
> 10 North Greene Street
> GRECC (BT/18/GR)
> Baltimore, MD 21201-1524
> (Phone) 410-605-7119
> (Fax) 410-605-7913 (Please call phone number above prior to faxing)>>>
> Milan Bouchet-Valat <nalimilan at club.fr> 12/2/2012 4:00 PM >>>
> 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
>
> ______________________________________________
> R-help at 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.
>
> *_Confidentiality Statement:_*
>
> This email message, including any attachments, is for ...{{dropped:7}}