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
> >
> >______________________________________________
> >[EMAIL PROTECTED] 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
>
> ______________________________________________
> [EMAIL PROTECTED] 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
[EMAIL PROTECTED] University of Washington, Seattle
______________________________________________
[EMAIL PROTECTED] 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
