search for: srcrefs

Hi, The result of as,character() on 'srcref' objects doesn't have the closing ')' in some cases involving 'quote': > e4 <- quote({2+2}) > class(attr(e4, "wholeSrcref")) [1] "srcref" > as.character(attr(e4, "wholeSrcref")) [1] "e4 <- quote({2+2}" As a result printing the object also lacks it and gives an

Dear R-devel, I found this behavior disturbing, if `1 + f()` is called, `sys.call()` called inside of `f` will return a quoted `f()` with a "srcref" that prints "1 + f()". I don't know which one is good but I don't think they can be correct at the same time. Here's a reproducible example: f <- function(){ sc <- sys.call() print(sc) attr(sc,

Hi all, Is it possible to "recursively" parse srcrefs to match the recursive structure of the underlying code? I'm interested in this because it's the final step in allowing functions to modify other functions while preserving the original source. I've tried to make a bit of demo of what I want to do below, and I think I may uncovered a b...

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>

Hi, on R version 2.15.1 (2012-06-22) (Platform: i686-pc-linux-gnu (32-bit)) sourced functions have srcref attached as an attribute. Are such data also available for S4 generics and methods? How? (See sample code below) Thank you. Bests, Renaud f <- textConnection( " f <- function(){} setGeneric('myfun', function(x, ...) standardGeneric('myfun'))

On 01/03/2024 5:25 a.m., Dmitri Popavenko wrote: > Dear?Duncan, > > On Fri, Mar 1, 2024 at 11:30?AM Duncan Murdoch <murdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> wrote: > > ... > If you parse it with srcrefs, you could look at the source.? The parser > doesn't record whether it was A -> B or B <- A anywhere else. > > > Thank you, this gets me closer but it still needs a little push: > > > foo <- function(x) { > ? x <- substitute(x) > ? return(attr(x,...

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

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

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

For documentation we use a system that generates Rd files from special comments in the code. (inlinedocs). It is crucial to be able to get the defining source code for objects like methods to extract the comments from it. Here is an R session that shows how this works for several kinds of methods and (at the end of the session) how if fails for methods of "initialize" >

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 $ :

On Fri, Mar 1, 2024 at 1:00?PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > ... > I was thinking more of you doing something like > > parse(text = "A -> B", keep.source = TRUE) > > I forget what the exact rules are for attaching srcrefs to arguments of > functions, but I do remember they are a little strange, because not > every possible argument can accept a srcref attribute. For example, you > can't attach one to NULL, or to a name. > > Srcrefs are also fairly big and building them is slow, so I think we >...

wholeSrcref attribute is documented in ?parse to be the source reference corresponding to the already parsed text. The implementation in the parser matches the documentation - the code stops at the last byte/character of the expression, that is, on the closing brace - which is the "already parsed text". I think this works as documented (also source() uses the current implementation

Dear Duncan, On Fri, Mar 1, 2024 at 11:30?AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > ... > If you parse it with srcrefs, you could look at the source. The parser > doesn't record whether it was A -> B or B <- A anywhere else. > Thank you, this gets me closer but it still needs a little push: > foo <- function(x) { x <- substitute(x) return(attr(x, "srcref")[[2]]) } > foo...

...urdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> wrote: > > ... > I was thinking more of you doing something like > > ? parse(text = "A -> B", keep.source = TRUE) > > I forget what the exact rules are for attaching srcrefs to arguments of > functions, but I do remember they are a little strange, because not > every possible argument can accept a srcref attribute.? For example, > you > can't attach one to NULL, or to a name. > > Srcrefs are also fairly big and building them i...

...urdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> wrote: > > ... > I was thinking more of you doing something like > > parse(text = "A -> B", keep.source = TRUE) > > I forget what the exact rules are for attaching srcrefs to arguments of > functions, but I do remember they are a little strange, because not > every possible argument can accept a srcref attribute. For example, > you > can't attach one to NULL, or to a name. > > Srcrefs are also fairly big and building them i...

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

Dear R developers, Print method for function now tries to open the source file associated with srcref of the function. It outputs only the warning, if file cannot be open, and forgets to print the function definition. Example: eval(parse(text = "tf <- function(a){ b <- a^4 b }", srcfile = srcfile("xxx at 17"))) > tf <srcref: file "xxx at 17"

...<mailto:murdoch.duncan at gmail.com>> wrote: > > > > ... > > I was thinking more of you doing something like > > > > parse(text = "A -> B", keep.source = TRUE) > > > > I forget what the exact rules are for attaching srcrefs to arguments > of > > functions, but I do remember they are a little strange, because not > > every possible argument can accept a srcref attribute. For example, > > you > > can't attach one to NULL, or to a name. > > > > Srcrefs are a...

When large calls cause errors R may stall for extended periods.? This is particularly likely to happen with `do.call`, as in this example with a 24 second stall: ??? x <- runif(1e7) ??? system.time(do.call(paste0, list(abs, x)))? # intentional error ??? ## Error in (function (..., collapse = NULL)? : ??? ##?? cannot coerce type 'builtin' to vector of type 'character' ??? ##