similar to: Find Source File Corresponding to Sourced 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

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

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>

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

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

Dear R-Core Team, I found an unexpected behaviour in utils::removeSource (also present in r-devel as of today). --- # create a function which accepts NULL argument foo <- function(x, y) { if (is.null(y)) y <- "default foo" attr(x, "foo") <- y x } # create a function which utilizes 'foo' testSrc <- function() { x <- 1:3 x <- foo(x,

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() { #

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-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,

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

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

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 >

Hi Henrik, It would help to understand your use case for pairlists. Thanks, Michael On Wed, Oct 12, 2016 at 9:40 AM, Michael Lawrence <michafla at gene.com> wrote: > The coercion is probably the most viable workaround for now, as it's > consistent with what happens internally for calls. All pairlists/calls > are converted to list for subassignment, but only calls are

In my .Rprofile I have the following functions which display the current directory in the main R window title bar, and modify base::setwd() to keep this up to date. I like this because I can always tell where I am in the file system. cd <- function(dir) { base::setwd(dir) utils::setWindowTitle( short.path(base::getwd()) ) } short.path <- function(dir, len=2) { np

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, Suppose I have x = parse(text = " {y=50+50+50#'asfasf' } ") now x is an expression with some src attributes. > x expression({y=50+50+50#'asfasf' }) attr(,"srcfile") <text> attr(,"wholeSrcref") {y=50+50+50#'asfasf' } My question is, how can I get my string back (the string passed to parse() as the text argument)? >

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' ??? ##

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

Hello, I am migrating my package lambda.r to R3.0.0 and am experiencing some issues with the getParserData function (which replaces the parser package). Basically the function works in the R shell but fails when either called from RUnit or from R CMD check. I've narrowed it down to the function getSrcfile, which is returning different values depending on the code path. From the command line