The help pages are at
https://github.com/wch/r-source/blob/trunk/src/library/base/man/iconv.Rd
or the equivalent at https://github.com/r-devel/r-svn
or https://svn.r-project.org/R/trunk/src/library/base/man/iconv.Rd
they still have \x examples in them, but maybe the use of \x is not
flagged in the particular context of those examples?
On 2022-07-19 1:32 PM, Spencer Graves wrote:
Hi, Bill, Tomas, et al.:
On 7/19/22 12:10 PM, Bill Dunlap wrote:
Have you tried changing the \x's in that file with \u's?
> qx <- c("\xf6", "\xf8", "\xdf", "\xfc")
> Encoding(qx) <- "latin1"
> qu <- c("\uf6", "\uf8", "\udf", "\ufc")
> Encoding(qu)
[1] "UTF-8" "UTF-8" "UTF-8" "UTF-8"
> qx == qu
[1] TRUE TRUE TRUE TRUE
I have not tried anything yet for three reasons:
1. I don't know that I have access to anything that can do the
proper test that's required, so I can know if I've fixed it or not.
I'm not sure what you need. AFAIK r-hub's test platforms are still
down, but win-builder and
2. Tomas' blog included examples that seemed to say to replace
"\xa0" with "\u00a0", NOT "\ua0", and I don't know if this difference
matters or not.
3. Can someone provide me with a link to the correct
development version of help('iconv')? The current version includes
the exact offending "\x" strings that I have. If I know the fix in
the correct development version of help('iconv'), I can copy that.
Without that, I'm being asked to correct something that may not have
been corrected in the development version of the base package.
There are \x's in the examples there
Thanks,
Spencer
(charToRaw shows that qu and qx are not byte-for-byte identical: '=='
coerces the latin1 strings to utf-8.)
-Bill
On Tue, Jul 19, 2022 at 9:38 AM Spencer Graves
<spencer.gra...@effectivedefense.org
<mailto:spencer.gra...@effectivedefense.org>> wrote:
Hi, Tomas:
On 7/19/22 2:20 AM, Tomas Kalibera wrote:
>
> On 7/19/22 08:37, Spencer Graves wrote:
>> Hello:
>>
>>
>> What's the recommended fix for "Warning in
gsub(gsLi$pattern,
>> gsLi$replacement, xo) : unable to translate 'Ekstr<f8>m' to a
wide
>> string; Error in gsub(gsLi$pattern, gsLi$replacement, xo) :
input
>> string 1 is invalid"?
>>
>>
>> This is in:
>>
>>
>>
https://github.com/sbgraves237/Ecfun/blob/master/man/subNonStandardCharacters.Rd
<https://github.com/sbgraves237/Ecfun/blob/master/man/subNonStandardCharacters.Rd>
>>
>>
>>
>> R-devel is now rejecting some non-ASCII characters that it
>> previously accepted; see below.
>
> Please see
>
https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions
<https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions>
>
>
> Looking at the code I guess you should change the strings in icx
to use
> \u escapes instead of \x. The use of \x as it is there was
probably
> correct when the code was ran in Latin-1 encoding, but not in
other
> encodings. Using \u would make it portable. Feel free to ask more
if my
> guess is wrong and reading the blog post doesn't help.
"subNonStandardCharacters.Rd" copies examples from:
https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/iconv
<https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/iconv>
This file still contains "\x" in 5 places. What's the
recommended
fix? Replace "\x" with "\u00" everyplace?
I could try that, but I don't know if I have access to
platforms that
would tell me if I fixed it or not ;-)
Thanks very much.
Spencer Graves
>
> Best
> Tomas
>
>
>
>>
>>
>> Thanks,
>> Spencer Graves
>>
>>
>> -------- Forwarded Message --------
>> Subject: CRAN package Ecfun and its reverse dependencies
>> Date: Wed, 13 Jul 2022 06:34:24 +0100
>> From: Prof Brian Ripley <rip...@stats.ox.ac.uk
<mailto:rip...@stats.ox.ac.uk>>
>> Reply-To: c...@r-project.org
>> To: veronica.vincio...@brunel.ac.uk
<mailto:veronica.vincio...@brunel.ac.uk>,
>> spencer.gra...@effectivedefense.org
<mailto:spencer.gra...@effectivedefense.org>, hamedhas...@gmail.com
<mailto:hamedhas...@gmail.com>,
>> dennis.pran...@gmail.com <mailto:dennis.pran...@gmail.com>
>> CC: c...@r-project.org
>>
>> Dear maintainers,
>>
>> This concerns the CRAN packages
>>
>> BDWreg DWreg Ecdat Ecfun gk
>>
>> maintained by one of you:
>>
>> Dennis Prangle <dennis.pran...@gmail.com
<mailto:dennis.pran...@gmail.com>>: gk
>> Hamed Haselimashhadi <hamedhas...@gmail.com
<mailto:hamedhas...@gmail.com>>: BDWreg
>> Spencer Graves <spencer.gra...@effectivedefense.org
<mailto:spencer.gra...@effectivedefense.org>>: Ecfun Ecdat
>> Veronica Vinciotti<veronica.vincio...@brunel.ac.uk
<mailto:veronica.vincio...@brunel.ac.uk>>: DWreg
>>
>> We have asked for an update fixing the check problems shown at
>> <https://cran.r-project.org/web/checks/check_results_Ecfun.html
<https://cran.r-project.org/web/checks/check_results_Ecfun.html>>
>> with no update from the maintainer thus far.
>>
>> Thus, package Ecfun is now scheduled for archival on
2022-08-08, and
>> archiving this will necessitate also archiving its CRAN strong
reverse
>> dependencies.
>>
>> Please negotiate the necessary actions.
>>
>> The CRAN Team
>>
>> ______________________________________________
>> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
______________________________________________
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
