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
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
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
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
>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
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]
Thanks Hadley, for making us aware of this tool. I have a question: the
spellchecker part works (I mean I corrected words that were clearly
misspelled leaving acronyms which are common in my field), but I get the
following messages after the spell check:
* using log directory
| 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
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
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
12 matches
Mail list logo