similar to: Recursively parsing srcrefs

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

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

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

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

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)

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.

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

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote: > On Fri, Mar 1, 2024 at 1:00?PM Duncan Murdoch <murdoch.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

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

I am wondering what the specific need for this is or is it just an exercise? Where does it matter if a chunk of code assigns using "<-" beforehand or "->" after hand, or for that matter assigns indirectly without a symbol? And whatever you come up with, will it also support the global assignment of "->>" as compared to ""<<-" too? I

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.

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

I would also be interested in that. For me, this is interesting for my QCA package, over which Dmitri and I have exchanged a couple of messages. The "<-" operator is used to denote necessity, and the "->" is used for sufficiency. Users often make use of Boolean expressions such as A*B + C -> Y (to calculate if the expression A*B + C is sufficient for the outcome Y)

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

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

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

On 10.03.2016 15:49, Duncan Murdoch wrote: > On 10/03/2016 8:27 AM, Kirill M?ller wrote: >> I can't seem to reliably obtain parse data via getParseData() for >> functions from installed packages. The parse data seems to be available >> only for the *last* file in the package. >> >> See [1] for a small example package with just two functions f and g in >>

On 11/10/2015 10:36 PM, Duncan Murdoch wrote: > On 11/10/2015 8:05 PM, Ben Bolker wrote: >> >> It seems odd/inconvenient to me that the "ignore.environment" argument >> of identical() only applies to closures (which I read as 'functions' -- >> someone can enlighten me about the technical differences between >> functions and closures if they like