Re: [R] [External] Re: Parser For Line Number Tracing
Thanks Duncan for being a bulldog on this issue. Finding bugs like this take energy and tenacity. JN On 2025-01-21 11:40, Duncan Murdoch wrote: And now I've found the elusive bug in show.error.locations = TRUE as well, and posted a patch for that too. Back to the original topic of this thread: I think most users should routinely use options(show.error.locations = TRUE) e.g. in their .Rprofile. That will often speed up bug fixes, especially if my patch is incorporated. Duncan Murdoch On 2025-01-20 5:56 p.m., Duncan Murdoch wrote: I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On 2025-01-20 9:37 a.m., Duncan Murdoch wrote: Sorry, I'm not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan Murdoch On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and report that, or another option (e.g. "highest"?) could be added to do that. And still I think traceback() should show the top call in Ivo's example. Duncan On 2025-01-19 11:46 a.m., [email protected] wrote: On Sun, 19 Jan 2025, 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. No. There are already many ways to influence the way the default error handler prints information about errors, mstly via options(). In particular you may want to look at entries in ?options for show.error.locations showErrorCalls showWarningCalls and adjust your options settings accordingly. Best, luke 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, sel
Re: [R] [External] Re: Parser For Line Number Tracing
And now I've found the elusive bug in show.error.locations = TRUE as well, and posted a patch for that too. Back to the original topic of this thread: I think most users should routinely use options(show.error.locations = TRUE) e.g. in their .Rprofile. That will often speed up bug fixes, especially if my patch is incorporated. Duncan Murdoch On 2025-01-20 5:56 p.m., Duncan Murdoch wrote: I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On 2025-01-20 9:37 a.m., Duncan Murdoch wrote: Sorry, I'm not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan Murdoch On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and report that, or another option (e.g. "highest"?) could be added to do that. And still I think traceback() should show the top call in Ivo's example. Duncan On 2025-01-19 11:46 a.m., [email protected] wrote: On Sun, 19 Jan 2025, 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. No. There are already many ways to influence the way the default error handler prints information about errors, mstly via options(). In particular you may want to look at entries in ?options for show.error.locations showErrorCalls showWarningCalls and adjust your options settings accordingly. Best, luke 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. __ [email protected] mailing list -- To UNSUBSCRIBE and m
Re: [R] [External] Re: Parser For Line Number Tracing
I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On 2025-01-20 9:37 a.m., Duncan Murdoch wrote: Sorry, I'm not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan Murdoch On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and report that, or another option (e.g. "highest"?) could be added to do that. And still I think traceback() should show the top call in Ivo's example. Duncan On 2025-01-19 11:46 a.m., [email protected] wrote: On Sun, 19 Jan 2025, 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. No. There are already many ways to influence the way the default error handler prints information about errors, mstly via options(). In particular you may want to look at entries in ?options for show.error.locations showErrorCalls showWarningCalls and adjust your options settings accordingly. Best, luke 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. __ [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] [External] Re: Parser For Line Number Tracing
Sorry, I'm not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan Murdoch On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and report that, or another option (e.g. "highest"?) could be added to do that. And still I think traceback() should show the top call in Ivo's example. Duncan On 2025-01-19 11:46 a.m., [email protected] wrote: On Sun, 19 Jan 2025, 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. No. There are already many ways to influence the way the default error handler prints information about errors, mstly via options(). In particular you may want to look at entries in ?options for show.error.locations showErrorCalls showWarningCalls and adjust your options settings accordingly. Best, luke 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. __ [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] [External] Re: Parser For Line Number Tracing
John, What would be nice is not necessarily trivial. Consider an example. After running a line of code with an assignment statement, did you know the last value has been saved in .Last.value as in this snippet of code: > x <- 12 > .Last.value [1] 12 > y <- .Last.value**2 > y [1] 144 > .Last.value [1] 144 Now how many novices would know to use this, say in a complicated calculation where another statement uses the results from before? So, what if R saved an unevaluated line of code as .Last_text_evaluated or something. For all I know, something like that may exist and perhaps might be shown by something like ls(all.names=TRUE) or something. Novices likely will not know about, nor many experts. It might not even be set if an error happens. Even if available, no current mechanism exists to show it after each line. oThere are ways to save your history and restore it and so on, and running R interactively may allow something as simple as using up-arrows to see the last statements. RSTUDIO allows you to see all recent commands in a window. So, if a program STOPS, you should be able to at least see the preceding line of code. But what do you suggest should be the last command in something like a multiple embedded loop? Is it the code for many lines, or just the one being run? How do you deal with commands spread over multiple lines? -Original Message- From: Sorkin, John Sent: Sunday, January 19, 2025 3:47 PM To: [email protected]; 'Ivo Welch' ; [email protected] Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing Avi, Yes, R (really S) was not designed for novice users but rather for experts. For better or worse it has evolved into a programming language used by tyros, and experts. Debugging tools should be easy to use, generally known, and helpful for tyro and expert. It would certainly help if R reported the line number, or the code, that generated the error. John John David Sorkin M.D., Ph.D. Professor of Medicine, University of Maryland School of Medicine; Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical Center; PI Biostatistics and Informatics Core, University of Maryland School of Medicine Claude D. Pepper Older Americans Independence Center; Senior Statistician University of Maryland Center for Vascular Research; Division of Gerontology and Paliative Care, 10 North Greene Street GRECC (BT/18/GR) Baltimore, MD 21201-1524 Cell phone 443-418-5382 From: R-help on behalf of [email protected] Sent: Sunday, January 19, 2025 3:31 PM To: 'Ivo Welch'; [email protected] Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing Arguably, R was not designed or evolved for truly novice users, nor really was Python or just about all computer languages. As they evolved and became in many ways more powerful, they tended to get ever less user friendly in the way you are asking for and gotten so bloated that many features are not familiar even to expert users. Compiled languages can have ways to keep track of what LINE of code is being worked on. You can sometimes compile them with a flag that preserves information needed or to have it run with less overhead. Interpreted languages that can be typed in as you go along are a challenge in that a concept like line number may not be trivial to use. Do you remember what was the 325th line you typed in? R does not normally display line numbers in a prompt. As noted, there is plenty of debug info, not to mention what you can examine while running inside a debugger, that can be helpful. Another consideration to consider is that you can run snippets of R code in cells as in a Markdown document, Notebook, Quarto or Jupyter notebook along with pieces of text around it. RSTUDIO supports some of these and there are likely other variants out there. Since each cell can contain a limited set of code, down to as little as one instruction, and you can run segments one after another, or all at once to a point, and there can be text with info between cells, you might find where things go wrong and localize them in many cases. Of course, if a cell contains a loop that breaks after N iterations, not so much. It is a problem now that so many people do not study a programming language for itself, but only want to do the minimum needed to use it as a one-time tool for solving something else they are studying. These days, you can ask a pseudo-AI to write you a snippet of code that may work and learn next to nothing you can use to do more. -Original Message- From: R-help On Behalf Of Ivo Welch Sent: Sunday, January 19, 2025 12:01 PM To: [email protected] Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing understood. but
Re: [R] [External] Re: Parser For Line Number Tracing
Avi, Yes, R (really S) was not designed for novice users but rather for experts. For better or worse it has evolved into a programming language used by tyros, and experts. Debugging tools should be easy to use, generally known, and helpful for tyro and expert. It would certainly help if R reported the line number, or the code, that generated the error. John John David Sorkin M.D., Ph.D. Professor of Medicine, University of Maryland School of Medicine; Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical Center; PI Biostatistics and Informatics Core, University of Maryland School of Medicine Claude D. Pepper Older Americans Independence Center; Senior Statistician University of Maryland Center for Vascular Research; Division of Gerontology and Paliative Care, 10 North Greene Street GRECC (BT/18/GR) Baltimore, MD 21201-1524 Cell phone 443-418-5382 From: R-help on behalf of [email protected] Sent: Sunday, January 19, 2025 3:31 PM To: 'Ivo Welch'; [email protected] Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing Arguably, R was not designed or evolved for truly novice users, nor really was Python or just about all computer languages. As they evolved and became in many ways more powerful, they tended to get ever less user friendly in the way you are asking for and gotten so bloated that many features are not familiar even to expert users. Compiled languages can have ways to keep track of what LINE of code is being worked on. You can sometimes compile them with a flag that preserves information needed or to have it run with less overhead. Interpreted languages that can be typed in as you go along are a challenge in that a concept like line number may not be trivial to use. Do you remember what was the 325th line you typed in? R does not normally display line numbers in a prompt. As noted, there is plenty of debug info, not to mention what you can examine while running inside a debugger, that can be helpful. Another consideration to consider is that you can run snippets of R code in cells as in a Markdown document, Notebook, Quarto or Jupyter notebook along with pieces of text around it. RSTUDIO supports some of these and there are likely other variants out there. Since each cell can contain a limited set of code, down to as little as one instruction, and you can run segments one after another, or all at once to a point, and there can be text with info between cells, you might find where things go wrong and localize them in many cases. Of course, if a cell contains a loop that breaks after N iterations, not so much. It is a problem now that so many people do not study a programming language for itself, but only want to do the minimum needed to use it as a one-time tool for solving something else they are studying. These days, you can ask a pseudo-AI to write you a snippet of code that may work and learn next to nothing you can use to do more. -Original Message- From: R-help On Behalf Of Ivo Welch Sent: Sunday, January 19, 2025 12:01 PM To: [email protected] Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing understood. but, please, consider not people like me but unwary beginners and students of R. I have used R now for decades, and even I am baffled by it. Couldn't you make R code easier to debug not only for people like me (who can indeed tweak their environments) but also for novice users? On Sun, Jan 19, 2025 at 8:46 AM wrote: > > On Sun, 19 Jan 2025, 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. > > No. There are already many ways to influence the way the default error > handler prints information about errors, mstly via options(). In > particular you may want to look at entries in ?options for > > show.error.locations > showErrorCalls > showWarningCalls > > and adjust your options settings accordingly. > > Best, > > luke > > > > > 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 <
Re: [R] [External] Re: Parser For Line Number Tracing
Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and report that, or another option (e.g. "highest"?) could be added to do that. And still I think traceback() should show the top call in Ivo's example. Duncan On 2025-01-19 11:46 a.m., [email protected] wrote: On Sun, 19 Jan 2025, 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. No. There are already many ways to influence the way the default error handler prints information about errors, mstly via options(). In particular you may want to look at entries in ?options for show.error.locations showErrorCalls showWarningCalls and adjust your options settings accordingly. Best, luke 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. __ [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] [External] Re: Parser For Line Number Tracing
Arguably, R was not designed or evolved for truly novice users, nor really was Python or just about all computer languages. As they evolved and became in many ways more powerful, they tended to get ever less user friendly in the way you are asking for and gotten so bloated that many features are not familiar even to expert users. Compiled languages can have ways to keep track of what LINE of code is being worked on. You can sometimes compile them with a flag that preserves information needed or to have it run with less overhead. Interpreted languages that can be typed in as you go along are a challenge in that a concept like line number may not be trivial to use. Do you remember what was the 325th line you typed in? R does not normally display line numbers in a prompt. As noted, there is plenty of debug info, not to mention what you can examine while running inside a debugger, that can be helpful. Another consideration to consider is that you can run snippets of R code in cells as in a Markdown document, Notebook, Quarto or Jupyter notebook along with pieces of text around it. RSTUDIO supports some of these and there are likely other variants out there. Since each cell can contain a limited set of code, down to as little as one instruction, and you can run segments one after another, or all at once to a point, and there can be text with info between cells, you might find where things go wrong and localize them in many cases. Of course, if a cell contains a loop that breaks after N iterations, not so much. It is a problem now that so many people do not study a programming language for itself, but only want to do the minimum needed to use it as a one-time tool for solving something else they are studying. These days, you can ask a pseudo-AI to write you a snippet of code that may work and learn next to nothing you can use to do more. -Original Message- From: R-help On Behalf Of Ivo Welch Sent: Sunday, January 19, 2025 12:01 PM To: [email protected] Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing understood. but, please, consider not people like me but unwary beginners and students of R. I have used R now for decades, and even I am baffled by it. Couldn't you make R code easier to debug not only for people like me (who can indeed tweak their environments) but also for novice users? On Sun, Jan 19, 2025 at 8:46 AM wrote: > > On Sun, 19 Jan 2025, 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. > > No. There are already many ways to influence the way the default error > handler prints information about errors, mstly via options(). In > particular you may want to look at entries in ?options for > > show.error.locations > showErrorCalls > showWarningCalls > > and adjust your options settings accordingly. > > Best, > > luke > > > > > 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") > >>
Re: [R] [External] Re: Parser For Line Number Tracing
Luke, The fact that there are alternative ways to do things does not mean that the a new, better way, should not be considered. You note three options that I have never heard for, nor read about despite using R for many years. Ibest most uses don't know about these options. Ivo, was correct when he said, " 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." John John David Sorkin M.D., Ph.D. Professor of Medicine, University of Maryland School of Medicine; Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical Center; PI Biostatistics and Informatics Core, University of Maryland School of Medicine Claude D. Pepper Older Americans Independence Center; Senior Statistician University of Maryland Center for Vascular Research; Division of Gerontology and Paliative Care, 10 North Greene Street GRECC (BT/18/GR) Baltimore, MD 21201-1524 Cell phone 443-418-5382 From: R-help on behalf of luke-tierney--- via R-help Sent: Sunday, January 19, 2025 11:46 AM To: Ivo Welch Cc: [email protected] Subject: Re: [R] [External] Re: Parser For Line Number Tracing On Sun, 19 Jan 2025, 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. No. There are already many ways to influence the way the default error handler prints information about errors, mstly via options(). In particular you may want to look at entries in ?options for show.error.locations showErrorCalls showWarningCalls and adjust your options settings accordingly. Best, luke > > 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 >> >> > > ___
Re: [R] [External] Re: Parser For Line Number Tracing
understood.
but, please, consider not people like me but unwary beginners and
students of R. I have used R now for decades, and even I am baffled
by it. Couldn't you make R code easier to debug not only for people
like me (who can indeed tweak their environments) but also for novice
users?
On Sun, Jan 19, 2025 at 8:46 AM wrote:
>
> On Sun, 19 Jan 2025, 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.
>
> No. There are already many ways to influence the way the default error
> handler prints information about errors, mstly via options(). In
> particular you may want to look at entries in ?options for
>
> show.error.locations
> showErrorCalls
> showWarningCalls
>
> and adjust your options settings accordingly.
>
> Best,
>
> luke
>
> >
> > 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.
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: [email protected]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/
__
[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] [External] Re: Parser For Line Number Tracing
On Sun, 19 Jan 2025, 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.
No. There are already many ways to influence the way the default error
handler prints information about errors, mstly via options(). In
particular you may want to look at entries in ?options for
show.error.locations
showErrorCalls
showWarningCalls
and adjust your options settings accordingly.
Best,
luke
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.
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [email protected]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/
__
[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.
