Displaying 20 results from an estimated 1200 matches similar to: "Changes to parser in R-devel"
2013 Jan 14
1
Issue with getParserData in R3.0.0
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
2020 Apr 22
2
parse data wrong for R 4.0. raw strings
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
2015 Jul 29
2
Mapping parse tree elements to tokens
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 code was included in R
this functionality was removed.
?getParseData
2015 Jul 29
3
Mapping parse tree elements to tokens
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
2014 Jun 12
1
regression bug with getParseData and/or parse in R-3.1.0
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
2020 Jan 15
4
A bug understanding F relative to FALSE?
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
2020 Apr 22
1
[External] parse data wrong for R 4.0. raw strings
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
2015 Jul 29
2
Mapping parse tree elements to tokens
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
2013 Sep 18
1
getParseData() for imaginary numbers
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
2013 Jul 05
3
should the text for RIGHT_ASSIGN be -> in getParseData()?
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
2015 Jul 29
1
Mapping parse tree elements to tokens
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
2023 Nov 11
1
New syntax for positional-only function parameters?
6 ?????? 2023 ?. 22:54:24 GMT+03:00, mikkmart via R-devel <r-devel at r-project.org> ?????:
>The pattern of functions accepting other functions as inputs and
>passing additional ... arguments to them is prevalent throughout
>the R ecosystem. Currently, however, all such functions must one
>way or another tackle the problem of inadvertently passing arguments
>meant to go to
2016 Mar 10
2
getParseData() for installed packages
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
2024 Mar 04
1
[External] Re: capture "->"
Maybe someone has already suggested this, but if your functions accepted
strings you could use sub or gsub to replace the -> with a symbol that
parsed at the same precedence as <-,
say <<-. Then parse it and deal with it. When it is time to display the
parsed and perhaps manipulated formulae to the user, deparse it and do the
reverse replacement.
> encode <-
2016 Mar 10
2
getParseData() for installed packages
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
>>
2018 Jul 30
2
Problem with parseData
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 <-
2018 Oct 02
1
Problem with parseData
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
2020 Apr 13
3
detect ->
Adrian,
Indeed, this has come up in a few places, but as Gabor says, there is no
such thing as right hand assignment at any point after parsing is complete.
This means the only feasible way to detect it, which a few projects do I
believe, is process the code while it is still raw text, before it goes
into the parser, and have clever enough regular expressions.
The next question, then, is why
2015 Sep 19
0
New version of the R parser in pqR
I have rewritten the R parser in the new version of pqR that I
recently released (pqR-2015-09-14, at pqR-project.org). The new
version of the parser is much cleaner, is faster (sometimes quite
substantially faster), has a better interface to the read-eval-print
loop, and provides a better basis for future extensions. The deparser
has also been substantially revised in pqR, and is better
2014 Jan 25
0
interpreting the output of getParseData()
Hi,
I'm trying to make sense of the output of getParseData(). The "parent" column is supposed to refer to the "id" of the parent of the given item, but there are numbers in the parent column that do not exist in the id column. Example:
> p <- parse(text="f<-function(){if(TRUE)1 else 2}")
> df <- getParseData(p)
> df
line1 col1 line2 col2 id