similar to: Source references from the parser

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

Hi, I'm trying to understand whether the new source file references can help me with something I want to do. Let's say I have foo <- parse(text = " a <- 1; b <- 2**2 a + b ") I now wish to recover the sources for the parsed expressions. I can get them one at a time: > foo[[2]] b <- 2^2 > as.character(attr(foo, "srcref")[[2]]) [1] "b <-

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.

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

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

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

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

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 <luke-tierney at uiowa.edu> wrote: > > On Sun, 19 Jan

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

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

I noticed the following file descriptor leak when I couldn't remove a package unless I shut down the R session that had loaded and used it. The function that triggered the problem printed the output of a call to parse(). Each time one prints a srcref a connection is opened and not closed. It looks like it happens in as.character.srcref's call to getSrcLines, which has some logic I

Hello, Consider this file (/tmp/test.R) : <file> f <- function( x, y = 2 ){ z <- x + y print( z ) } </file> I get this in R 2.7.2 : > p <- parse( "/tmp/test.R" ) > str( attr( p, "srcref" ) ) List of 1 $ :Class 'srcref' atomic [1:4] 1 1 4 1 .. ..- attr(*, "srcfile")=Class 'srcfile' length 4 <environment>

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.

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

First, why does this expression have a 'srcref' element: > exprA <- substitute(function(x) a*x, list(a=2)) > print(exprA) function(x) 2 * x > str(as.list(exprA)) List of 4 $ : symbol function $ :Dotted pair list of 1 ..$ x: symbol $ : language 2 * x $ :Class 'srcref' atomic [1:8] 1 20 1 34 20 34 1 1 .. ..- attr(*, "srcfile")=Classes

Hello, I submit a patch for review that implements code coverage tracing in the R interpreter. It records the lines that are actually executed and their associated frequency for which srcref information is available. I perfectly understands that this patch will not make its way inside R as it is, that they are many concerns of stability, compatibility, maintenance and so on. I would like to have

Just checking in to see whether it is intended or not that assigning new formals to a function/closure causes any attributes to be dropped: EXAMPLE: > fcn <- structure(function() {}, foo="foo", class=c("foo")) > str(fcn) function () - attr(*, "srcref")=Class 'srcref' atomic [1:8] 1 18 1 30 18 30 1 1 .. ..- attr(*, "srcfile")=Classes

On 30/03/2023 10:32 a.m., Ivan Krylov wrote: > Dear R-devel, > > In a package of mine, I use removeSource on expression objects in order > to make expressions that are semantically the same serialize to the > same byte sequences: > https://github.com/cran/depcache/blob/854d68a/R/fixup.R#L8-L34 > > Today I learned that expressions containing function definitions also >

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.

Dear R-devel, In a package of mine, I use removeSource on expression objects in order to make expressions that are semantically the same serialize to the same byte sequences: https://github.com/cran/depcache/blob/854d68a/R/fixup.R#L8-L34 Today I learned that expressions containing function definitions also contain the source references for the functions, not as an attribute, but as a separate