[R] Line numbers in error messages

[Tony Plate]

I agree it's not completely straightforward, but given the current 
function, the current expression, and a list of which expressions have 
already been executed (presumably from the execution engine), one should be 
able to deduce a line number in many cases.

-- Tony Plate

At Monday 06:32 PM 4/12/2004, Thomas Lumley wrote:
>On Mon, 12 Apr 2004, Tony Plate wrote:
>
> > Isn't source file information often recorded in the "source" attribute on
> > functions (or calls)?  Could either the execution engine or the debugger
> > refer to that information?  (Though, in the debugger it might be impossible
> > to uniquely identify expressions that appear multiple times in the function
> > code.)  If line info was printed out only when source was saved in the
> > "source" attribute, this could still be useful.
>
>Yes, but it's still not that straightforward.  The "source" attribute is
>just text. The execution engine doesn't know where it is in the text, and
>there's no guarantee that, for example, deparse() on an expression will
>return a substring of the original text.  And that's before things get
>really complicated.
>
>Consider:
> > lm(y~x)
>Error in eval(expr, envir, enclos) : Object "y" not found
> > traceback()
>7: eval(expr, envir, enclos)
>6: eval(predvars, data, env)
>5: model.frame.default(formula = y ~ x, drop.unused.levels = TRUE)
>4: model.frame(formula = y ~ x, drop.unused.levels = TRUE)
>3: eval(expr, envir, enclos)
>2: eval(mf, parent.frame())
>1: lm(y ~ x)
>
>The majority of these expressions (lines 3, 4, 5 and 7) do not appear
>anywhere in any of the functions being called.
>
>Now, it might well be possible to produce something that would give
>source line numbers where they were available, with a few false negatives.
>This would be an interesting project, but it isn't trivial.
>
>         -thomas
>
>
>
> > -- Tony Plate
> >
> >
> > At Monday 05:41 PM 4/12/2004, Duncan Murdoch wrote:
> > >On Mon, 12 Apr 2004 15:20:58 -0700, you wrote:
> > >
> > > >Hi Patrick,
> > > >
> > > >>It's very simple using a browser() line in your function somewhere you
> > > >>know your code's OK, then run line by line.
> > > >>
> > > >The problem is that sometimes you have code of a few hundred lines, to
> > > >which you have added a strange little line that craps out because of
> > > >some silly mistake that would be apparent if you knew which line to look
> > > >at.  However....  you don't want to start inserting browser statements
> > > >inside the code, hoping to get close, you just want to know what line
> > > >caused the issue.
> > >
> > >This is something that's on my wish list too, but it would require
> > >fairly low-level changes.  Right now the parser doesn't record source
> > >file information on a line, so there's no way an error message could
> > >report it.
> > >
> > >It's not absolutely obvious how to do it, either:  code can come from
> > >files, from saved images, from stuff you typed at the console prompt,
> > >from a connection, as the result of evaluating an expression, etc.
> > >It's a lot more complicated to do this in an interpreted language like
> > >R than in a compiled language.
> > >
> > >Duncan Murdoch
> > >
> > >______________________________________________
> > >R-help at stat.math.ethz.ch mailing list
> > >https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> > >PLEASE do read the posting guide! 
> http://www.R-project.org/posting-guide.html
> >
> > ______________________________________________
> > R-help at stat.math.ethz.ch mailing list
> > https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide! 
> http://www.R-project.org/posting-guide.html
> >
>
>Thomas Lumley                   Assoc. Professor, Biostatistics
>tlumley at u.washington.edu        University of Washington, Seattle