similar to: Character encodings and packages

I see another thing in function 'NewName' in bind.c. In else if (*CHAR(tag)) , 'ans' is basically copied from 'tag'. Could the whole thing there be just the following? ans = tag; It seems to me that it can also replace ans = R_BlankString; in 'else'; so, else if (*CHAR(tag)) and else can be merged to be just else . --------------------------------------------

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

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

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.

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

Partly about new features and partly about old features that are not being used. R_exts/GraphicsEngine.h says /* * The current graphics engine (including graphics device) API version * MUST be integer * * This number should be bumped whenever there are changes to * GraphicsEngine.h or GraphicsDevice.h so that add-on packages * that compile against these headers (graphics systems

R-devel (pre-2.5.0) now has enough facilities to allow packages with non-ASCII character strings to work reasonably well in locales where the fonts use support the characters used. For example, names in Western European languages can be used on both Latin-1 (and hence Windows 1252) and UTF-8 systems. It should also be possible to make use of non-ASCII object names. To enable this, two

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) {

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

This pre-announcement is being sent for information to both R-help and BioC. Please use R-devel at r-project.org for any follow-up discussion. ----------------------------------------------------------------------- We are about at the end of a several-week process of adding support for non-Latin character sets and non-Western-European languages to R. - For Linux users, R works in the UTF-8

This pre-announcement is being sent for information to both R-help and BioC. Please use R-devel at r-project.org for any follow-up discussion. ----------------------------------------------------------------------- We are about at the end of a several-week process of adding support for non-Latin character sets and non-Western-European languages to R. - For Linux users, R works in the UTF-8

This is a follow-up on my initial posts regarding character encodings on Windows (https://stat.ethz.ch/pipermail/r-devel/2017-August/074728.html) and Patrick Perry's reply (https://stat.ethz.ch/pipermail/r-devel/2017-August/074830.html) in particular (thank you for the links and the bug report!). My initial posts were quite chaotic (and partly wrong), so I am trying to clear things up a

You seem confused about Latin-1: those characters are not in Latin-1. (MicroSoft code pages are a proprietary encoding, some code pages such as CP1252 being extensions to Latin-1.) You have not given the 'at a minimum information' asked for in the posting guide so we have no way to reproduce this, and without showing us the output on your system, we have no idea what you saw. [As a

This particular issue has a simple fix. Currently, the "R_check_locale" function includes the following code starting at line 244 in src/main/platform.c: #ifdef Win32 { char *ctype = setlocale(LC_CTYPE, NULL), *p; p = strrchr(ctype, '.'); if (p && isdigit(p[1])) localeCP = atoi(p+1); else localeCP = 0; /* Not 100% correct, but CP1252 is a

R-devel has new versions of the X11(), png() and jpeg() devices on Unix-alikes. The intention is that these are used identically to the previous versions (which remain available) but will produce higher-quality output with more features. Pros: Antialiasing of text and lines (can be turned off) but no blurring of fills. Buffering of the X11 display and fast repainting from a backing image.

Hi, I came across the problem with rsync-2.5.5 on Cygwin/Win2K while rsyncing with filenames which have 'strange' (non latin-1) characters in filenames. The problem is that filenames on Windows system are coded (in our case) in codepage 852, while server (Linux system) has filename coding according to ISO-8859-2. This two are not fully compatible, causing rsync to simply skip copying some

I've rolled up R-2.7.1.tar.gz a short while ago. This is a maintenance release and fixes a number of mostly minor bugs and platform issues. Notably, the numeric interpretation of "-", "+", and "." has reverted to pre-2.7.0 behaviour See the full list of changes below. You can get it (in a short while) from http://cran.r-project.org/src/base/R-2/R-2.7.1.tar.gz

I've rolled up R-2.7.1.tar.gz a short while ago. This is a maintenance release and fixes a number of mostly minor bugs and platform issues. Notably, the numeric interpretation of "-", "+", and "." has reverted to pre-2.7.0 behaviour See the full list of changes below. You can get it (in a short while) from http://cran.r-project.org/src/base/R-2/R-2.7.1.tar.gz

On 23.08.2017 12:02, Braun, Stefan wrote: > 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 <-

We've just upgraded our Sun compilers from (top line of cc -V) cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11 (aka Forte 6) to cc: Forte Developer 7 C 5.4 2002/03/09 although the later seem to be known as Sun ONE these days. A few comments which may be helpful to other users: 1) It seems that to use C++ code (e.g. package Matrix) you now need to add -lCstd to SHLIB_CXXLDFLAGS. We will