similar to: formals(x)<- drops attributes including class

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

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

If you can afford a dependency on rlang, `rlang::zap_srcref()` deals with this. It's recursive over expression vectors, calls (including calls to `function` and their hidden srcref arg), and function objects. It's implemented in C for efficiency as we found it to be a bottleneck in some applications (IIRC caching). I'd be happy to upstream this in base if R core is interested. Best,

Thanks, this was what I expected. There is a desire to eliminate the usage of pairlist from user code, which suggests the alternative of allowing for function arguments to be stored in lists. That's a much deeper change though. On Wed, Oct 12, 2016 at 12:31 PM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > Michael, thanks for this info. > > I've stumbled upon

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 >

On Sat, Oct 15, 2016 at 2:00 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>>> on Wed, 12 Oct 2016 15:21:13 -0700 writes: > > > Thanks, this was what I expected. There is a desire to > > eliminate the usage of pairlist from user code, which > >

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

In R <= 2.13.x, calling 'parse( con)' where 'con' is a connection, 'options( keep.source)' is TRUE, and default 'srcfile' would preserve the source. In R >= 2.14.1, it doesn't. > tf <- tempfile() > options( keep.source=TRUE) > texto <- c( 'function() { # comment', '}') > parse( text=texto) expression(function() { #

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>

Hello, It seems that the parsing information attached to expressions parsed by the parse() function when keep.source=TRUE is not provided to the eval() function. Please consider this code: path <- tempfile() code <- '(function() print( str( sys.calls() ) ))()' writeLines(code, path) sys.source(path, envir=globalenv(), keep.source=TRUE) > OUTPUT: Dotted pair list of 4 $ :

Hi all, When I run the following code, R segfaults: text <- "?" srcfile <- srcfilecopy("test.r", text) parse(textConnection(text), srcfile = srcfile) It doesn't segfault if text is ASCII, or it's not wrapped in textConnection, or srcfile isn't set. Hadley -- http://hadley.nz [[alternative HTML version deleted]]

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

I have just committed some changes to R-devel (which will become R 2.5.0 next spring) to add source references to parsed R code. Here's a description of the scheme: The design is done through 2 old-style classes. "srcfile" corresponds to a source file: it contains a filename, the working directory in which that filename is to be interpreted, the last modified timestamp of the

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.

On 5/28/24 19:35, Hadley Wickham wrote: > Hi all, > > When I run the following code, R segfaults: > > text <- "?" > srcfile <- srcfilecopy("test.r", text) > parse(textConnection(text), srcfile = srcfile) > > It doesn't segfault if text is ASCII, or it's not wrapped in > textConnection, or srcfile isn't set. Thanks, this is

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

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

I get an R error and no segfault: > parse(textConnection(text), srcfile = srcfile) Error in parse(textConnection(text), srcfile = srcfile) : test.r:1:1: unexpected $end 1: ? ^ This is R 4.3.0, so maybe the bug has been introduced since then... Version and system info: > version _ platform x86_64-pc-linux-gnu arch x86_64 os linux-gnu system

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