similar to: LC_TIME not set correctly by Sys.setlocale() ?

On 23/06/2017 15:35, Joris Meys wrote: > Related to the following question on Stackoverflow: > https://stackoverflow.com/questions/44723690/unexpected-behavior-of-sys-setlocale#44723690 > > It appears as if Sys.setlocale() does not update LC_TIME correctly for use > in date formatting. Although R reports that LC_TIME is changed to the new > setting after use of Sys.setlocale(),

<I was not sure if this should go to R-devel or R-help. If I e-mailed this to the wrong place, please let me know.> Hello dear R-devel members, I came by an oddity, with regards to how character variables are being transformed when they are in Hebrew, and when Sys.setlocale is changed. Here is an example: # first, let's set the locale to Hebrew Sys.setlocale("LC_ALL",

Contrary to, say, Sys.setenv(), Sys.setlocale() returns it's value visibly. This means that if you for instance add: Sys.setlocale("LC_COLLATE", "C") to your .Rprofile file, it will print: [1] "C" at startup. The workaround is to wrap the call in invisible(), but I'd argue that any "setter" function should return invisibly. Some more details:

In order to print unicode characters with llvm, I used setLocale in llvm ir: call i8* @setlocale(i32 6, i8* getelementptr inbounds ([1 x i8]* @pe, i32 0, i32 0)) nounwind where @pe is defined as follows: @pe = private unnamed_addr constant [1 x i8] zeroinitializer, align 1 However, I got the following error: *** glibc detected *** ./test/bin/executable: free(): invalid next size

Can you help me to use Sys.setlocale("LC_NUMERIC", "cs_CZ") (comma as a decimal point) in some useful way, without all the workarounds? After switching to Sys.setlocale("LC_NUMERIC", "cs_CZ"): -- How do I set attributes in read.csv2() not to get columns of real numbers (decimal point = comma, field separator = semicolon) as factors? Wokrkaround: I can go

Hi all, I am having some problems in updating some packages from source. I start with : install.packages("Boom",lib="C:/RownLib",type="source") I get the following error message : * installing *source* package 'Boom' ... ** package 'Boom' successfully unpacked and MD5 sums checked ** libs *** arch - i386 c:/Rtools/mingw_32/bin/g++ -std=gnu++11

Hi, As far as I can see, no. On checking, I have confirmed that the only location of cygwin1.dll is : C:\Rtools\bin Thanks Vivek 2017-06-03 12:57 GMT+02:00 Duncan Murdoch <murdoch.duncan at gmail.com>: > On 03/06/2017 6:31 AM, Vivek Sutradhara wrote: > >> Hi all, >> I am having some problems in updating some packages from source. I start >> with : >>

On 03/06/2017 6:31 AM, Vivek Sutradhara wrote: > Hi all, > I am having some problems in updating some packages from source. I start > with : > install.packages("Boom",lib="C:/RownLib",type="source") > > I get the following error message : Do you have multiple copies of cygwin1.dll? Duncan Murdoch > > * installing *source* package

Dear R users, I'm trying to have a gWiddgetsRGtk2 script run under R-2.4.1. The script run OK under Linux but all accentuated characters appear as "?" when the script is run under Windows. As Gtk+ requires UTF-8, I thought it was the source of the problem and tried to change the default encoding (1252) in the following way:

Hi Ali, On 28/01/13 06:38, ali_sedaghat wrote: > Hi Ciao, my compiler is written in java and generates some .ll files as its > output. Each of these .ll files is converted to an object file using llc. > Then, I use clang++ to link them and generate an executable file without > linking with any external libraries, so I cannot understand what you mean. > Sorry, if my question sounds

Windows (MSVC, MinGW) version of setlocale don't care about LC_* environment variables. For example, flac cannot pass the test for --until and --skip options the script calls it with --skip=0:01.1001 and it expects decimal comma (--skip=0:01,1001) on my system. One solution is to write a local version of strtod that always accepts both decimal comma and decimal point. Another solution is not

When checking an R package of mine, I get * checking R files for syntax errors ... WARNING Warning in Sys.setlocale("LC_CTYPE", "en_US") : OS reports request to set locale to "en_US" cannot be honored 'Sys.setlocale' is not used in any of my R functions. What should I do to fix the Warning? I have never seen this before. My locale is "sv_SE",

Hi Ciao, my compiler is written in java and generates some .ll files as its output. Each of these .ll files is converted to an object file using llc. Then, I use clang++ to link them and generate an executable file without linking with any external libraries, so I cannot understand what you mean. Sorry, if my question sounds silly to you -- View this message in context:

Hi Ali, did you link your program statically? Try linking it dynamically. Ciao, Duncan. On 27/01/13 07:36, Ali Sedaghat wrote: > In order to print unicode characters with llvm, I used setLocale in llvm ir: > > call i8* @setlocale(i32 6, i8* getelementptr inbounds ([1 x i8]* @pe, i32 > 0, i32 0)) nounwind > > where @pe is defined as follows: > > @pe = private

On 03/06/2017 7:00 AM, Vivek Sutradhara wrote: > Hi, > As far as I can see, no. > > On checking, I have confirmed that the only location of > cygwin1.dll is : > C:\Rtools\bin I would re-install Rtools, and make sure C:\Rtools\bin appears first in your PATH. Duncan Murdoch > > Thanks > Vivek > > 2017-06-03 12:57 GMT+02:00 Duncan Murdoch <murdoch.duncan at

Full_Name: Edward McNeil Version: 2.3.0 OS: Widows XP Submission from: (NULL) (203.170.234.5) Type the following: > Sys.setlocale("LC_ALL","C") > hist(1:10) CRASH

On RedHat Enterprise Linux 6, the test below fails (this is using the stock GCC 4.4.7) from R-devel r72707. LC_CTYPE is unset when I run it, but LANG=en_US.UTF-8 It also failed "yesterday" where as far as I recall the test code looked a bit different. Best, Kasper > ## Results differed by platform, but some gave incorrect results on string 10. > > > ## str() on large

>>>>> Kasper Daniel Hansen <kasperdanielhansen at gmail.com> >>>>> on Fri, 19 May 2017 20:09:24 -0400 writes: > I rebuilt R with > export LC_CTYPE=en_US.UTF-8 > and the test still fail. Surprisingly, when I run R from the bin directory > and execute the test code, it runs without error: >> oloc <-

I have a Ubuntu server with an R installation that has 384 packages installed. We are trying to replicate the system on a Red Hat Enterprise server. I downloaded the list of packages from the Ubuntu machine and read it into an R session on the new machine. Then I ran install.packages(listofpackages). Now I have 352 packages on the new machine but several very common packages (like much of the

This is a continuation of the R-devel thread with subject "suggestion to fix packageDescription() for Windows users" : As I said there, a patch should rather address the underlying problem in packageDescription rather than a kludgy workaround patch for citation(). (For that same reason, Ben Marwick proposed to fix packageDescription() rather than the symptom seen in citation().)