Re: [R] Parser For Line Number Tracing
On 2025/01/19 01:41, Ivo Welch 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. tried something like RStudio? el __ [email protected] 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.
Re: [R] Parser For Line Number Tracing
I think I considered doing that many years ago, but one or more of the
following stopped me:
- It will mess up old test scripts that are checking for the old
format error messages.
- Some errors are due to a severe lack of resources (e.g. full stack,
out of some other kind of memory, etc.) and error reporting for those
has to be done very carefully so as not to crash R.
- The error handling code is pretty hairy, and I was somewhat afraid
of touching it.
On the other hand, it's probably not too hard to write a package that
includes something like my suggestion below and perhaps some other
changes specifically directed at newbies.
So I might suggest looking for that package and writing it if it hasn't
already been written. There are various coding parties each year that
might want to take it on if you don't have time to do so. I've cc'd
Heather Turner, who has been involved in organizing them recently; I
don't know if she's still doing that.
Duncan
On 2025-01-19 10:24 a.m., Ivo Welch wrote:
Hi Duncan — Wonderful. Thank you. Bug or no bug, I think it would be
a huge improvement for user-friendliness if R printed the last line by
default *every time* a script dies. Most computer languages do so.
Should I file it as a request for improvement to the R code
development team? Maybe R can be improved at a very low cost to the
development team and a very high benefit to newbies.
Regards,
/ivo
On Sun, Jan 19, 2025 at 2:39 AM Duncan Murdoch wrote:
On 2025-01-18 8:27 p.m., Ivo Welch wrote:
I am afraid my errors are worse! (so are my postings. I should have
given an example.)
```
x <- 1
y <- 2
nofunction("something stupid I am doing!")
z <- 4
```
and
```
source("where-is-my-water.R")
Error in nofunction("something stupid I am doing!") :
could not find function "nofunction"
```
and no traceback is available.
Okay, I see. In that case traceback() doesn't report the line, but it
still is known internally. You can see it using the following function:
showKnownLocations <- function() {
calls <- sys.calls()
srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v,
"srcref"))) {
srcfile <- attr(srcref, "srcfile")
paste0(basename(srcfile$filename), "#", srcref[1L])
} else ".")
cat("Current call stack locations:\n")
cat(srcrefs, sep = " ")
cat("\n")
}
I haven't done much testing on this, but I think it can be called
explicitly from any location if you want to know how you got there, or
you can set it as the error handler using
options(error = showKnownLocations)
For example, try this script:
options(error = showKnownLocations)
f <- function() showKnownLocations()
x <- 1
f()
y <- 2
nofunction("something stupid I am doing!")
z <- 4
I see this output from source("test.R"):
> source("test.R")
Current call stack locations:
. . . . test.R#4 test.R#2
Error in nofunction("something stupid I am doing!") :
could not find function "nofunction"
Current call stack locations:
. . . . test.R#6
The first report is from the explicit call in f() on line 2 that was
invoked on line 4, and the second report happens during error handling.
I supppose the fact that traceback() isn't showing you the line 6
location could be considered a bug.
Duncan Murdoch
__
[email protected] 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.
Re: [R] Parser For Line Number Tracing
Hi Duncan — Wonderful. Thank you. Bug or no bug, I think it would be
a huge improvement for user-friendliness if R printed the last line by
default *every time* a script dies. Most computer languages do so.
Should I file it as a request for improvement to the R code
development team? Maybe R can be improved at a very low cost to the
development team and a very high benefit to newbies.
Regards,
/ivo
On Sun, Jan 19, 2025 at 2:39 AM Duncan Murdoch wrote:
>
> On 2025-01-18 8:27 p.m., Ivo Welch wrote:
> > I am afraid my errors are worse! (so are my postings. I should have
> > given an example.)
> >
> > ```
> > x <- 1
> > y <- 2
> > nofunction("something stupid I am doing!")
> > z <- 4
> > ```
> >
> > and
> >
> > ```
> >> source("where-is-my-water.R")
> > Error in nofunction("something stupid I am doing!") :
> >could not find function "nofunction"
> > ```
> >
> > and no traceback is available.
>
> Okay, I see. In that case traceback() doesn't report the line, but it
> still is known internally. You can see it using the following function:
>
> showKnownLocations <- function() {
>calls <- sys.calls()
>srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v,
>
> "srcref"))) {
> srcfile <- attr(srcref, "srcfile")
> paste0(basename(srcfile$filename), "#", srcref[1L])
>} else ".")
>cat("Current call stack locations:\n")
>cat(srcrefs, sep = " ")
>cat("\n")
> }
>
> I haven't done much testing on this, but I think it can be called
> explicitly from any location if you want to know how you got there, or
> you can set it as the error handler using
>
>options(error = showKnownLocations)
>
> For example, try this script:
>
>options(error = showKnownLocations)
>f <- function() showKnownLocations()
>x <- 1
>f()
>y <- 2
>nofunction("something stupid I am doing!")
>z <- 4
>
> I see this output from source("test.R"):
>
>> source("test.R")
>Current call stack locations:
>. . . . test.R#4 test.R#2
>Error in nofunction("something stupid I am doing!") :
> could not find function "nofunction"
>Current call stack locations:
>. . . . test.R#6
>
> The first report is from the explicit call in f() on line 2 that was
> invoked on line 4, and the second report happens during error handling.
>
> I supppose the fact that traceback() isn't showing you the line 6
> location could be considered a bug.
>
> Duncan Murdoch
>
>
__
[email protected] 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.
Re: [R] Parser For Line Number Tracing
On 2025-01-18 8:27 p.m., Ivo Welch wrote:
I am afraid my errors are worse! (so are my postings. I should have
given an example.)
```
x <- 1
y <- 2
nofunction("something stupid I am doing!")
z <- 4
```
and
```
source("where-is-my-water.R")
Error in nofunction("something stupid I am doing!") :
could not find function "nofunction"
```
and no traceback is available.
Okay, I see. In that case traceback() doesn't report the line, but it
still is known internally. You can see it using the following function:
showKnownLocations <- function() {
calls <- sys.calls()
srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v,
"srcref"))) {
srcfile <- attr(srcref, "srcfile")
paste0(basename(srcfile$filename), "#", srcref[1L])
} else ".")
cat("Current call stack locations:\n")
cat(srcrefs, sep = " ")
cat("\n")
}
I haven't done much testing on this, but I think it can be called
explicitly from any location if you want to know how you got there, or
you can set it as the error handler using
options(error = showKnownLocations)
For example, try this script:
options(error = showKnownLocations)
f <- function() showKnownLocations()
x <- 1
f()
y <- 2
nofunction("something stupid I am doing!")
z <- 4
I see this output from source("test.R"):
> source("test.R")
Current call stack locations:
. . . . test.R#4 test.R#2
Error in nofunction("something stupid I am doing!") :
could not find function "nofunction"
Current call stack locations:
. . . . test.R#6
The first report is from the explicit call in f() on line 2 that was
invoked on line 4, and the second report happens during error handling.
I supppose the fact that traceback() isn't showing you the line 6
location could be considered a bug.
Duncan Murdoch
__
[email protected] 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.
Re: [R] Parser For Line Number Tracing
I am afraid my errors are worse! (so are my postings. I should have
given an example.)
```
x <- 1
y <- 2
nofunction("something stupid I am doing!")
z <- 4
```
and
```
> source("where-is-my-water.R")
Error in nofunction("something stupid I am doing!") :
could not find function "nofunction"
```
and no traceback is available.
__
[email protected] 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.
Re: [R] Parser For Line Number Tracing
On 2025-01-18 6:41 p.m., Ivo Welch 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'?
The basic R parser already does that.
For example, try putting these lines in test.R:
x <- 1
y <- 2
stop("something bad!")
z <- 4
Then run source("test.R"), and it will die with the uninformative message
Error in eval(ei, envir) : something bad!
But then traceback() will show you the line:
> traceback()
5: stop("something bad!") at test.R#3
4: eval(ei, envir)
3: eval(ei, envir)
2: withVisible(eval(ei, envir))
1: source("~/temp/test.R")
See the first line of the traceback? It shows that the problem was on
line 3 of test.R.
If that line was in a function that had been called from somewhere else,
both the function line triggering the error and the line that called the
function would have been shown in different parts of the traceback.
This all depends on calling source() with parameter keep.source = TRUE.
The default value of that parameter is getOption("keep.source"), so if
you're not seeing the line numbers, you may have set that option to FALSE.
Duncan Murdoch
__
[email protected] 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.
Re: [R] Parser For Line Number Tracing
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 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'? > >__ >[email protected] 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. __ [email protected] 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.
Re: [R] Parser For Line Number Tracing
Hi Ivo,
I maintain 'package:this.path' that I believe does what you want. I
regularly add this to my own code when I need to:
warning(sprintf("remove this later at %s#%d",
this.path::try.this.path(), this.path::LINENO()), call. = FALSE,
immediate. = TRUE)
Of course, modify as needed.
Regards,
Iris
On Sat, Jan 18, 2025 at 6:41 PM Ivo Welch 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'?
>
> __
> [email protected] 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.
__
[email protected] 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.
Re: [R] Parser For Line Number Tracing
great. wonderful. will check it out, and hopefully widely recommend
it (to my students, too). Non-descriptive R error messages have had
most of our school abandon R in favor of python. :-(
On Sat, Jan 18, 2025 at 3:46 PM Iris Simmons wrote:
>
> Hi Ivo,
>
>
> I maintain 'package:this.path' that I believe does what you want. I
> regularly add this to my own code when I need to:
>
> warning(sprintf("remove this later at %s#%d",
> this.path::try.this.path(), this.path::LINENO()), call. = FALSE,
> immediate. = TRUE)
>
> Of course, modify as needed.
>
>
> Regards,
> Iris
>
> On Sat, Jan 18, 2025 at 6:41 PM Ivo Welch 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'?
> >
> > __
> > [email protected] 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.
__
[email protected] 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.
