similar to: R 2.5.1 is released

Hello, It seems that the parsing information attached to expressions parsed by the parse() function when keep.source=TRUE is not provided to the eval() function. Please consider this code: path <- tempfile() code <- '(function() print( str( sys.calls() ) ))()' writeLines(code, path) sys.source(path, envir=globalenv(), keep.source=TRUE) > OUTPUT: Dotted pair list of 4 $ :

After a bit more investigation, I think I've found the cause of the bug, and I have a patch. This bug happens with grep(), when: * Running on Windows. * The search uses fixed=TRUE. * The search pattern is a single byte. * The current locale has a multibyte encoding. ======================= Here's an example that demonstrates the bug: # First, create a 3-byte UTF-8 character y <-

Dear R-devel When 'install.packages' runs, it updates all html files in all packages. Mostly, there seems to be no actual change to the html file contents, but the date/time does change. This has causing been me a bit of trouble, because I keep synchronized versions of R on several different machines, and whenever I install a package, many MB of file transfers are required; my slow upload

Recent functionality in jsonlite allows for streaming json to a user supplied connection object, such as a file, pipe or socket. RFC7159 prescribes json must be encoded as unicode; ISO-8859 (including latin1) is invalid. Hence I would like R to write strings as utf8, irrespective of the type of connection, platform or locale. Implementing this turns out to be unsurprisingly difficult on windows.

Hi, I am trying to use sub, regexpr on expressions like log(D) ~ log(N)+I(log(N)^2)+log(t) being a model specification. The aim is to produce: "ln D ~ ln N + ln^2 N + ln t" The variable names N, t may change, the number of terms too. I succeded only partially, help on regular expressions is hard to understand for me, examples on my case are rare. The help page on R-help

Zitat von Ashim Kapoor <ashimkapoor at gmail.com>: > Dear All, > > My query is: > > Do we always need to use perl = TRUE option when doing ignore.case=TRUE? > > A small example : > > my_text = > "RECOVERY OFFICER-II\nDEBTS RECOVERY TRIBUNAL-III\n RC No. 162/2015\nSBI > VS RAMESH GUPTA.\n Dated: 01.03.2016 Item no.01\n > Present:

I suspect your UTF-8 string is being stripped of its encoding before write, and so assumed to be in the system native encoding, and then re-encoded as UTF-8 when written to the file. You can see something similar with: > tmp <- '?' > tmp <- iconv(tmp, to = 'UTF-8') > Encoding(tmp) <- "unknown" > charToRaw(iconv(tmp, to =

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>

Dear R developers, Print method for function now tries to open the source file associated with srcref of the function. It outputs only the warning, if file cannot be open, and forgets to print the function definition. Example: eval(parse(text = "tf <- function(a){ b <- a^4 b }", srcfile = srcfile("xxx at 17"))) > tf <srcref: file "xxx at 17"

I wanted to raise the possibility of improving strcapture performance in cases where perl = TRUE. I believe we can do this in a non-breaking way by calling regexpr instead of regexec (conditionally when perl = TRUE). To illustrate this I've put together a 'proof of concept' function called strcapture2 that utilises output from regexpr directly (following a very nice substring approach

>From my understanding, translation is implied in this line of ?file (from the Encoding section): The encoding of the input/output stream of a connection can be specified by name in the same way as it would be given to iconv: see that help page for how to find out what encoding names are recognized on your platform. Additionally, "" and "native.enc" both

Michael, thanks for looking at my first issue with utils::strcapture. Another issue is how it deals with lines that don't match the pattern. Currently it gives an error > strcapture("(.+) (.+)", c("One 1", "noSpaceInLine", "Three 3"), proto=list(Name="", Number=0)) Error in strcapture("(.+) (.+)", c("One 1",

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

Hi, In R 3.4.0, the "Pattern Matching and Replacement" documentation that describes regexec(), gregexpr(), etc. states that the "text" argument to regexec is a character vector, "or an object which can be coerced by as.character to a character vector": regexec(pattern, text, ignore.case = FALSE, perl = FALSE, fixed = FALSE, useBytes = FALSE)

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

Hi Bill, Thanks, another good suggestion. strcapture() now returns NAs for non-matches. It's nice to have someone kicking the tires on that function. Michael On Wed, Sep 21, 2016 at 12:11 PM, William Dunlap via R-devel <r-devel at r-project.org> wrote: > Michael, thanks for looking at my first issue with utils::strcapture. > > Another issue is how it deals with lines that

Changing the default behavior of regmatches would break its use with gregexpr, where the number of matches per input element faries, so a zero-length character vector makes more sense than NA_character_. > x <- c("John Doe", "e e cummings", "Juan de la Madrid") > m <- gregexpr("[A-Z]", x) > regmatches(x,m) [[1]] [1] "J"

if you want "to extract regex matches into a new column in a data.frame" then there are some package functions which do exactly that. three examples are namedCapture::df_match_variable, rematch2::bind_re_match, and tidyr::extract. For a more detailed discussion see my R journal submission (under review) about regular expression packages,

A very common use case for regmatches is to extract regex matches into a new column in a data.frame (or data.table, etc.) or otherwise use the extracted strings alongside the input. However, the default behavior is to drop empty matches, which results in mismatches in column length if reassignment is done without subsetting. For consistency with other R functions and compatibility with this use

The new behavior is that it yields NAs when the pattern does not match (like strptime) and for empty captures in a matching pattern it yields the empty string, which is consistent with regmatches(). Michael On Wed, Sep 21, 2016 at 2:21 PM, William Dunlap <wdunlap at tibco.com> wrote: > If there are any matches then strcapture can see if the pattern has the same > number of capture