R help - Apr 2004 - Line numbers in error messages

Hi all,

I have searched but to know avail.  Is there a way to get a line number 
when a function crashes?  I am doing an edit->source->run cycle.

Feel free to cc me as I subscribe to the list in digest.

Thanks
W

Webb Sprague wrote:
> 
> Hi all,
> 
> I have searched but to know avail.  Is there a way to get a line number
> when a function crashes?  I am doing an edit->source->run cycle.
I don't think so, but traceback(), debug() and options(error = recover)
are your friends.
Also, you might want to check out the CRAN package "debug".

Uwe Ligges


 
 
> Feel free to cc me as I subscribe to the list in digest.
>
> Thanks
> W
> 
> ______________________________________________
> 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

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.

I already use ESS.  If it would give line numbers, my life would be perfect!

Is there something about debugging in S/R that I am missing?  I don't 
want to have to run a debugger except when there is a real problem, not 
just some silliness.

W

Please ignore this message -- it was an old one that I meant to delete, not 
send, because I found that in R, information about the expression and 
function of each frame didn't seemed to be stored in dumps, which makes 
this of thing difficult to do (at least I couldn't find this information in 
a sample dump.)

-- 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