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 <wor...@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? If you call fix() on any function, you will get something like a source file even if srcfile was not set. 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.
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... Regards > Duncan Murdoch > > > > >>> option(error=browser) is a help. But it still does not say what piece of > >>> code caused the error. > >> > >> I typically run with a slightly different setting: > >> > >> R> options(error=utils:::dump.frames) > >> > >> Whenever my script throws an error, after I'm done cursing at it I > >> then wonder where this error happened, so I call: > >> > >> R> traceback() > >> > >> And you'll see the details of the stack that just blew up, starting > >> (or ending, can't remember) with the call itself, then the parent > >> call, and its parent, etc. all the way up to the top most call (likely > >> the line in your script itself). > >> > >> If that's not enough information for me to figure out how to fix the > >> code in my script, I'll then call: > >> > >> R> debugger() > >> > >> and this will then give me (more or less) the same information that > >> `traceback` showed (but in reverse order (which is why I never > >> remember the order of traceback)) and you are asked at what point > >> you'd like to enter the exploded wreckage to explore (via picking a > >> number) ... this way you can poke at the local variables until you see > >> what went wrong. > > This is very useful of course to find the problematic function, but > > quite often I end up wondering what exact command triggered an error. > > For example, "subscript out of bounds" is hard to match to a precise `[' > > use in a whole function. > > > > Even when using browser(), sometimes you cannot know where you are in > > the function. So the line number, or the contents of the last line, > > would be relevant information. > > > >> Your error: > >> > >> Error in `[.xts`(x, xsubset) : subscript out of bounds > >> > >> Is suggesting that you are trying to index an `xts` object with an > >> illegal value -- can you find the part in your code that's trying to > >> do this in your own script? You can put a call to `browser()` before > >> that part and explore the value of the subscript vs. the length of > >> your xts object to see what the problem is. > >> > >> If you can't find this point, then take the traceback/debugger route. > >> > >>> This is costing me a lot of time chasing down errors in mine and others > >>> code... > >> > >> ... which is typical when your wading in uncharted territory. As you > >> get a better feel of how to resolve these issues, your time-to-fix > >> these things will get better, so ... stay strong. > > Of course experience helps, but without the most relevant information > > (line number) you productivity is always affected... ;-) > > > > > > Regards > > > > ______________________________________________ > > R-help@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. > > ______________________________________________ R-help@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.