similar to: translateChar in NewName in bind.c

For the 2nd example, I say that R 3.4.1 result is acceptable, as names(c(x)) and names(x) are equal. The change exposed by the 2nd example is in line with statement of the NEWS item corresponding to PR#17284: "c() and unlist() are now more efficient in constructing the names(.) of their return value, ...." However, currently, the NEWS item is for R-devel, not R 3.4.1 patched.

Can we use the "bytes" encoding for such environment variables invalid in the current locale? The following patch preserves CE_NATIVE for strings valid in the current UTF-8 or multibyte locale (or non-multibyte strings) but sets CE_BYTES for those that are invalid: Index: src/main/sysutils.c =================================================================== --- src/main/sysutils.c

Hi guys, I've got a question about the API mkchar(). I have met some difficulty in parsing utf-8 string to mkchar() in R-2.7.0. I was intending to parse an utf-8 string str_jan (some Japanese characters such as?, whose utf-8 code is E381B5) to R API SEXP mkChar(const char *name) , we only need to create the SEXP using the string that we parsed. Unfortunately, I found when parsing the

I'm trying to find information about how to use Rprintf with a UTF-8 encoded string, and I'm not sure what the right cross-platform usage is. I found an earlier thread about this (http://r.789695.n4.nabble.com/How-to-print-UTF-8-encoded-strings-from-a-C-routine-to-R-s-output-td4724337.html) but it wasn't very helpful. If I want to print a UTF-8 string, I can do one of the

Looking at shash in unique.c, from R-2.10.1 I'm wondering if it makes sense to hash the pointer itself rather than the string it points to? In other words could the SEXP pointer be cast to unsigned int and the usual scatter be called on that as if it were integer? shash would look like a slightly modified version of ihash like this : static int shash(SEXP x, int indx, HashData *d) {

On 1/31/23 09:48, Ivan Krylov wrote: > Can we use the "bytes" encoding for such environment variables invalid > in the current locale? The following patch preserves CE_NATIVE for > strings valid in the current UTF-8 or multibyte locale (or > non-multibyte strings) but sets CE_BYTES for those that are invalid: > > Index: src/main/sysutils.c >

Full_Name: Partho Bhowmick Version: 2.8.1 OS: Windows XP Submission from: (NULL) (199.43.48.131) While trying to install package sn (I have tried multiple mirrors), I get the following message trying URL 'http://www.revolution-computing.com/cran/bin/windows/contrib/2.8/sn_0.4-10.zip' Content type 'application/zip' length 320643 bytes (313 Kb) opened URL downloaded 313 Kb

/Hello. SUMMARY: $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv()" Error in substring(x, m + 1L) : invalid multibyte string at '<ff>' $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv('BOOM')" [1] "\xff" BACKGROUND: I launch R through an Son of Grid Engine (SGE) scheduler, where the R

On 09.05.2017 13:19, Duncan Murdoch wrote: > On 09/05/2017 3:42 AM, Kirill M?ller wrote: >> Hi >> >> >> I'm having trouble sourcing or parsing a UTF-8 file that contains >> characters that are not representable in the current locale ("foreign >> characters") on Windows. The source() function stops with an error, the >> parse() function

I would like to propose that Rf_mkString(NULL) and Rf_mkChar(NULL) return NA rather than segfault. Case: the mkString() and mkChar() functions are convenient to wrap strings returned by e.g. external C libraries into an R vector. However sometimes a library returns NULL instead of a string when the result is unavailable. In some C libraries this can happen unexpectedly or is even undocumented. A

Hi I'm having trouble sourcing or parsing a UTF-8 file that contains characters that are not representable in the current locale ("foreign characters") on Windows. The source() function stops with an error, the parse() function reencodes all foreign characters using the <U+xxxx> notation. I have added a reproducible example below the message. This seems well within the

Since R 2.5.0 it has been possible to declare the encodings of character strings (at the level of individual elements of a character vector). As a reminder, here is the announcement in NEWS o R now attempts to keep track of character strings which are known to be in Latin-1 or UTF-8 and print or plot them appropriately in other locales. This is primarily intended to make it possible

Dear list, I installed R 3.3.2 on a Red Hat Linux Enterprise 7.3 machine by adding the EPEL-repository and then installing it via yum. R starts up and seems to be doing fine at first sight. However, when I try to list the files in a directory with the command files <- list.files(path="/home/username/directory_name/", pattern="*.Rda",, full.names=T, recursive=FALSE) I get

Dear All, I am running a Ubuntu 8.04 System and trying to install the Design-package. Hmisc is already installed, all fortran compilers and a Tex-Package are also on board. I searched the net and the help list for analogue threads, but didn't find any. Whenever I run the install.packages("Design")-Command, the following error message shows up in the terminal window: -- **

For example, the following changes are necessary when i convert a Japanese hiragana into katakana in chattr. R code: > chartr("\u3041-\u3093","\u30a1-\u30f3","\u3084\u3063\u305f\u30fc") --- R-alpha.orig/src/main/character.c 2007-09-05 07:13:27.000000000 +0900 +++ R-alpha/src/main/character.c 2007-09-13 16:10:21.000000000 +0900 @@ -2041,6 +2041,16 @@

I'm using list.files() on my home directory, like this: crnt.files <- list.files(dir.to.check, full.names=TRUE, all.files=TRUE, recursive=TRUE) With dir.to.check set to the full path to my home directory. After a while I get: Error in list.files(dir.to.check, full.names = TRUE, all.files = TRUE, : 'translateCharUTF8' must be called on a CHARSXP This happens on one of my

>>>>> Tomas Kalibera >>>>> on Tue, 31 Jan 2023 10:53:21 +0100 writes: > On 1/31/23 09:48, Ivan Krylov wrote: >> Can we use the "bytes" encoding for such environment variables invalid >> in the current locale? The following patch preserves CE_NATIVE for >> strings valid in the current UTF-8 or multibyte locale (or

The other day I was working on an example which used tempfile() to create file for use by the graphics device. And while I love tempfile()---as it is portable and clever and the files get cleaned by R and all that---I noticed one missing feature I would like to see: beside a starting name pattern, and an optional directory, an 'file extension' argument would be nice to have. As e.g. in

I get a segfault when trying to read a SAS transport file with rather long rows using read.xport from package foreign (version 0.4-7). The culprit seems to be these lines in xport_read in SASxport.c: 590 } else { 591 c = strchr(tmpchar, ' '); 592 *c = '\0'; 593

On 09/05/2017 3:42 AM, Kirill M?ller wrote: > Hi > > > I'm having trouble sourcing or parsing a UTF-8 file that contains > characters that are not representable in the current locale ("foreign > characters") on Windows. The source() function stops with an error, the > parse() function reencodes all foreign characters using the <U+xxxx> > notation. I have