On 29/07/2015 5:33 PM, Jim Hester wrote:
> 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 brack
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)
I agree that we don't want to depend on implementation details. Some
sort of abstraction that is higher resolution than srcrefs would be
nice. Right now, it would be inconvenient using srcrefs to get to the
exact column range of a symbol, for example, but an IDE wants that to
highlight the symbol.
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 technolo
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
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
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". I
On 29/07/2015 12:55 PM, Michael Friendly wrote:
On 7/19/2015 3:50 AM, peter dalgaard wrote:
>> For some, but not allI repositories I get the error message below:
>> >Error in install.packages(update[instlib == l, "Package"], l, contriburl =
>> >contriburl, :
>> > specifying 'contriburl' or 'ava
On 7/19/2015 3:50 AM, peter dalgaard wrote:
For some, but not allI repositories I get the error message below:
>Error in install.packages(update[instlib == l, "Package"], l, contriburl =
>contriburl, :
> specifying 'contriburl' or 'available' requires a single type, not type =
>"both"
>
>Is it
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 t
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 th
On 29.07.2015 17:11, Michael Friendly wrote:
On 7/28/2015 1:32 PM, Uwe Ligges wrote:
Just add the line
R_LIBS_SITE=F:/R/library
to the file R_HOME/etc/x64/Renviron.site
Thanks, Uwe
I have no way to test this and our IT people who do the installation
know nothing of R, so follow-up question
On 7/28/2015 1:32 PM, Uwe Ligges wrote:
Just add the line
R_LIBS_SITE=F:/R/library
to the file R_HOME/etc/x64/Renviron.site
Thanks, Uwe
I have no way to test this and our IT people who do the installation
know nothing of R, so follow-up questions:
* There is no R_HOME/etc/x64/Renviron.sit
13 matches
Mail list logo
