I recommend making sure your code is built with functions and using the debugger and breakpoints (e.g. [1]) to follow the flow of the code to lead you to where your problem is.
If you are used to building thousand-line top-level scripts then you might not welcome this suggestion, but in that you already have problems you have not admitted to... such things (large top-level scripts) are monsters that will swallow you whole at the slightest change in R, packages, or data. [1] https://rstudio-education.github.io/hopr/debug.html On January 18, 2025 3:41:18 PM PST, Ivo Welch <ivo.we...@gmail.com> wrote: >I often find myself hunting where in my program an error has happened, >(of course, in R, many error messages are mysterious in themselves, >too, making it even harder.) the way I do it is mostly with inserting >`message()` statements. > >what I would really like to have is a parser that inserted 'curline ><<- ##' into the R code, where '##' is the filename and line number. >something like 'addtracker one.R two.R' and thereafter I can run two.R >and, when the program dies, use `print curline` to find out where my >error has roughly occurred. > >has someone already written such an 'instrumenter'? > >______________________________________________ >R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide https://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code. -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
