similar to: interpreting the output of getParseData()

Hi, With R-3.1.0 I get: > getParseData(parse(text = "{1}", keep.source = TRUE)) line1 col1 line2 col2 id parent token terminal text 7 1 1 1 3 7 9 expr FALSE 1 1 1 1 1 1 7 '{' TRUE { 2 1 2 1 2 2 3 NUM_CONST TRUE 1 3 1 2 1 2 3 5 expr FALSE 4 1 3 1

Hi, The imaginary unit is gone in the 'text' column in the returned data frame from getParseData(), e.g. in the example below, perhaps the text should be 1i instead of 1: > p=parse(text='1i') > getParseData(p) line1 col1 line2 col2 id parent token terminal text 1 1 1 1 2 1 2 NUM_CONST TRUE 1 2 1 1 1 2 2 0 expr

Hi, The text column for '->' becomes '<-' in the data frame returned by getParseData(): > getParseData(parse(text='1->x')) line1 col1 line2 col2 id parent token terminal text 7 1 1 1 4 7 0 expr FALSE 1 1 1 1 1 1 2 NUM_CONST TRUE 1 2 1 1 1 1 2 7 expr FALSE 3

Hi, I have run into a problem with parseData from the utils package.? When an assignment is done with = instead of <-, the information provided by parseData does not include an entry for the assignment. For this input, stored in file "BadPosition.R": y <- 5 foo = 7 And running this code: parsed <- parse("BadPosition.R", keep.source=TRUE) parsedData <-

The fix is now in R-devel, 75386. I have not ported to R-patched, because the fix breaks two packages which are working around this bug (and to my knowledge without having reported it before). So thanks again for the report! Best Tomas On 08/16/2018 10:06 AM, Tomas Kalibera wrote: > Dear Barbara, > > thank you for the report. This is something to be fixed in R - I am > now

Dear Barbara, thank you for the report. This is something to be fixed in R - I am now testing a patch that adds the extra node for the equality assignment expression. Best, Tomas On 07/30/2018 05:35 PM, Barbara Lerner wrote: > Hi, > > I have run into a problem with parseData from the utils package.? When > an assignment is done with = instead of <-, the information provided by

I don't know, maybe it would make sense to keep the whole expression, that's the text of the tag after all. Also, if we don't keep the whole expression, then it is not a valid string literal any more, because it does not have quoting. I can try to look into a patch. This is for 4.1 I believe, so in some sense it is not urgent? Gabor On Wed, Apr 22, 2020 at 3:31 PM <luke-tierney

On 29/07/2015 12:13 PM, Jim Hester wrote: > I would like to map the parsed tokens obtained from utils::getParseData() > to the parse tree and elements obtained by base::parse(). > > It looks like back when this code was in the parser package the parse() > function annotated the elements in the tree with their id, which would > allow you to perform this mapping. However when the

Looks like a bug. Will have a look when I get a chance. Simpler version: getParseData(parse(text = 'r"-|hello|-"')) > getParseData(parse(text = 'r"(hello)"')) line1 col1 line2 col2 id parent token terminal text 1 1 1 1 10 1 3 STR_CONST TRUE "hello) 3 1 1 1 10 3 0 expr FALSE The opening

On 29/07/2015 2:30 PM, Michael Lawrence wrote: > Probably need a generic tree based on "ParseNode" objects that > associate the line information with the symbol (for leaf nodes). As > Duncan notes, it should be possible to gather that from the table. > > But it would be nice if there was an "expr" column in the parse data > column in addition to

This seems like a bug to me: code <- 'x <- r"(hello, "world")"' getParseData(parse(text = code)) #> line1 col1 line2 col2 id parent token terminal text #> 7 1 1 1 24 7 0 expr FALSE #> 1 1 1 1 1 1 3 SYMBOL TRUE x #> 3 1 1 1 1 3 7 expr

Hi, I've noticed that partial parse data from parse() is irretrivable when it errors due to encountering '``' - two backticks in sequence. The print output also looks more limited than a regular parser error which leads me to suspect this is a bug. If this is the case could someone with the authority please add it to R's bug tracker? My reprex follows. Thanks, Miles ``` r

Both codetools and compiler get by without this. codetools uses source refs to generate messages; I don't recall if compiler does but it could easily do so. I would be wary about committing to this sort of implementation specific stuff -- we might want to go to completely different parser technology at tome point, which would be harder if we committed to these sort of details. Best, luke On

As Michael guessed my main use cases was code analysis. A concrete example where this would help is with my test code coverage tool covr. There is currently a bug when tracking coverage for if / else statements when the clauses do not contain brackets (https://github.com/jimhester/covr/issues/39). Because only one source reference is generated in this case (because it is parsed as a single

Hi all, Is the next behaviour suitable? identical(F,FALSE) ## [1] TRUE utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE)) ## line1 col1 line2 col2 id parent token terminal text ## 14 1 1 1 10 14 0 expr FALSE ## 1 1 1 1 1 1 3 SYMBOL_FUNCTION_CALL TRUE c ## 3 1 1 1 1 3

Probably need a generic tree based on "ParseNode" objects that associate the line information with the symbol (for leaf nodes). As Duncan notes, it should be possible to gather that from the table. But it would be nice if there was an "expr" column in the parse data column in addition to "text". It would contain the parsed object. Otherwise, to use the table, one is

I have two use cases in mind: 1) Code indexing/searching, where the table gets me almost all of the way there, except I ask for all of the text (including the calls) and then parse that, because it's nice to get back an actual code object when you are searching code (in addition to where the code lives). The extra parsing step is just a minor inconvenience. 2) Code analysis, which I'm

As others have pointed out, this is expected behaviour. Let me get on that hill I'll die on: it is absolutely not suitable. It is way beyond time to remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given the amount of times I had to point out that: T <- t(matrix(0:3,nrow=2)) isTRUE(T) was the reason the code didn't do what it's supposed to do. (Also don't use

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 two files a.R and b.R. See [2] for a documented test run on installed package (Ubuntu 15.10, UTF-8 locale, R 3.2.3). Same behavior with

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