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
(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> 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 > >> > >> > >> > >> 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 > > > > > > 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 > > > 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> > >> Reply-To: c...@r-project.org > >> To: veronica.vincio...@brunel.ac.uk, > >> spencer.gra...@effectivedefense.org, hamedhas...@gmail.com, > >> 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>: gk > >> Hamed Haselimashhadi <hamedhas...@gmail.com>: BDWreg > >> Spencer Graves <spencer.gra...@effectivedefense.org>: Ecfun Ecdat > >> Veronica Vinciotti<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> > >> 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 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 > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel