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 wrote:
> If there are any matches then st
If there are any matches then strcapture can see if the pattern has the
same number of capture expressions as the prototype has columns and give an
error if not. That seems appropriate.
If there are no matches, then there is no easy way to see if the prototype
is compatible with the pattern, so s
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
wrote:
> Michael, thanks for looking at my first issue with utils::strcaptur
Hi
Thanks for the further analysis. Sounds reasonable to me.
What would be good to get from you is:
- a test that does recursive getGraphicsEvent() calls, that is fixed by
your patch
- a test that produces the newline prompt from getGraphicsEvent(), that
is fixed by your other patch
- a
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("(.+) (.+)"
I agree that the file shows the _reasons_ but that is not the same as
a _process_.
With the high volume of packages that the CRAN maintainers handle, an
explicit procedure beyond "request it" is needed or should at least be
spelled out. We have pushed everything CRAN-related else towards
automatio
Thanks for the suggestion. Checked in that change.
Michael
On Wed, Sep 21, 2016 at 11:06 AM, William Dunlap via R-devel
wrote:
> The new strcapture function in R-devel is handy, capturing
> the matches to the parenthesized subpatterns in a regular
> expression in the columns of a data.frame, who
Note that read.pattern in gsubfn does accept stringsAsFactors = FALSE,
e.g. using your input lines and pattern:
library(gsubfn)
Lines <- c("Three 3", "Twenty 20")
pat <- "([[:alpha:]]*) +([[:digit:]]*)"
s2 <- read.pattern(text = Lines, pattern = pat, stringsAsFactors = FALSE,
col.names = c("Name
The new strcapture function in R-devel is handy, capturing
the matches to the parenthesized subpatterns in a regular
expression in the columns of a data.frame, whose column
names and classes are given by the 'proto' argument. E.g.,
> p1 <- data.frame(Name="", Number=0)
> str(strcapture("([[:alpha
The README states clearly that a package is orphaned under any of three
conditions:
1. The Maintainer requests is.
2. The maintainer email bounces
3. The maintainer is unresponsive to requests regarding the package from
CRAN maintainers
But I think that it is a good idea to include th
The CRAN policy page
(https://cran.r-project.org/web/packages/policies.html) implies that
there is a formal procedure for orphaning a package but none is
mentioned in the Extensions manual
(https://cran.r-project.org/doc/manuals/r-devel/R-exts.html).
This page (https://cran.r-project.org/src/contr
doKeybd() gets called in CHelpKeyIn() and NHelpKeyIn() in
library/grDevices/src/devWindows.c, where the call is encapsulated in an
'if (dd->gettingEvent)' block. So the only times this code ever calls
doKeybd() is when gettingEvent is in fact set.
Further, it's called in two locations in X11_event
> David Winsemius
> on Tue, 20 Sep 2016 23:46:48 -0700 writes:
>> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel
wrote:
>>
>> 'c' has an undocumented 'use.names' argument. I'm not sure if this is
>> a documentation or implementation bug.
> It came up on
13 matches
Mail list logo
