[R] Line numbers with errors and warnings?

[John Sorkin]

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.
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 the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  Any unauthorized use, disclosure or distribution is
prohibited.  If you are not the intended recipient, please contact the
sender by reply email and destroy all copies of the original message.