Thanks Duncan and Frederick,
I suspected as much - there doesn't appear to be any reason why conflicts
between by.x and names(y) shouldn't and cannot be checked, but I can see
how this might be more trouble than its worth given it potentially may
break downstream packages (i.e. any cases where thi
Hello, All:
I just posted a "Draft Proposal for improving the ability of R
users to search R packages" to Wikiversity
(https://en.wikiversity.org/wiki/Draft_Proposal_for_improving_the_ability_of_R_users_to_search_R_packages).
You are all invited to rewrite it in any way you th
On 17/02/2018 6:36 PM, frede...@ofb.net wrote:
Hi Scott,
Thanks for the patch. I'm not really involved in R development; it
will be up to someone in the R core team to apply it. I would hazard
to say that even if correct (I haven't checked), it will not be
applied because the change might break
Hi Scott,
Thanks for the patch. I'm not really involved in R development; it
will be up to someone in the R core team to apply it. I would hazard
to say that even if correct (I haven't checked), it will not be
applied because the change might break existing code. For example it
seems like reasonab
Of course, right after writing this e-mail I tested on my Windows
machine and did not see what I expected:
> charToRaw(before)
[1] c3 a9
> charToRaw(after)
[1] e9
so obviously I'm misunderstanding something as well.
Best,
Kevin
On Sat, Feb 17, 2018 at 2:19 PM, Kevin Ushey wrote:
> From my unde
>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 a
I think the problem in R-devel happens when there are non-ASCII characters
in any
of the strings passed to gsub.
txt <- vapply(list(as.raw(c(0x41, 0x6d, 0xc3, 0xa9, 0x6c, 0x69, 0x65)),
as.raw(c(0x41, 0x6d, 0x65, 0x6c, 0x69, 0x61))), rawToChar, "")
txt
#[1] "Amélie" "Amelia"
Encoding(txt)
#[1] "unk
| Confirmed for R-devel (current) on Ubuntu 17.10. But ... isn't the regexp
| you use wrong, ie isn't R-devel giving the correct answer?
No, I don't think R-devel is correct (or at least consistent with the
documentation). My interpretation of gsub("(\\w)", "\\U\\1", entry,
perl = TRUE) is "Take
On 17 February 2018 at 21:10, Hugh Parsonage wrote:
| I was told to re-raise this issue with R-dev:
|
| In the documentation of R-dev and R-3.4.3, under ?gsub
|
| > replacement
| >... For perl = TRUE only, it can also contain "\U" or "\L" to convert
the rest of the replacement to upper or l
I was told to re-raise this issue with R-dev:
In the documentation of R-dev and R-3.4.3, under ?gsub
> replacement
>... For perl = TRUE only, it can also contain "\U" or "\L" to convert the
> rest of the replacement to upper or lower case and "\E" to end case
> conversion.
However, the fol
The attached patch.diff will make merge.data.frame() append the suffixes to
columns with common names between by.x and names(y).
Best,
Scott Ritchie
On 17 February 2018 at 11:15, Scott Ritchie wrote:
> Hi Frederick,
>
> I would expect that any duplicate names in the resulting data.frame would
11 matches
Mail list logo
