Line numbers with errors and warnings?

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