similar to: R and LANGUAGE

A colleague?s R program behaved differently when I ran it, and we thought we traced it probably to different results from string comparisons as below, with different R versions. However the platforms also differed. A friend ran it on a few machines and found that the comparison behavior didn?t correlate with R version, but rather with platform. I wonder if you?ve seen this. If it?s not some

Hello everyone, I am new to R and I have experienced some bugs when using Rterm on Windows. Chinese characters in the console output are discarded by Rterm, and trying to type them into the console will crash the Rterm application. ---ENVIRONMENT--- Platform = x86_64-w64-mingw32 OS = Windows 10 Pro 1709 chs R version = 3.4.3 Active code page = 936 (Simplified Chinese) ---STEPS TO

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

r-help: I have an R package suggestion. After spending several hours the other day installing about a dozen packages, I had an idea. In xemacs, there is a "sumo" package which allows me to install a large bundle of xemacs packages at one time (about a 120 modes including ESS). I think R should have a similar bundle. It would be so much easier than hunting/downloading/installing.

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

It does appear the ess package on CRAN for Ubuntu 8.04 fails to install the file 'ess-sas-sh-command'. This prevents invoking SAS via 'M-x SAS'. http://cran.mirrors.hoobly.com/bin/linux/ubuntu/README.html --Dale On Fri, Jul 11, 2008 at 12:39 PM, Rodney Sparapani <rsparapa at mcw.edu> wrote: > Dale Steele wrote: >> >> I re-installed from Hardy packages on

Thank you, Brad (and others), >>>>> Brad Bell on Mon, 4 Feb 2019 07:21:18 -0700 writes: > I get the failure message. To be specific: adcomp.git> R CMD BATCH --quiet test_nlminb.R adcomp.git> cat test_nlminb.Rout >> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) >> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) >>

Full_Name: rodney sparapani Version: 1.9.0 OS: Solaris 9 Submission from: (NULL) (141.106.120.97) I'm following the instructions for the Sun Forte compiler. I had success with 1.8.1 so I think the compiler settings are correct (config.site): CC="cc -xarch=v8plusa" CFLAGS="-xO5 -xlibmil -dalign" F77="f95 -xarch=v8plusa" FFLAGS="-xO5

This is a reproducible bug that I reported earlier. The work-around is to remove the link foreign.tgz so that the build does not attempt to create the foreign library. However, there is actually nothing wrong with the foreign source so the problem must be somewhere in the configure process. After make install, then use the original source as follows and everything should work: R CMD INSTALL

The attached code produces corrupted pdfs (test2.pdf, test4.pdf and test5.pdf). The resulting pdf depends on how many cores are available on the machine. I don't see why there should be any difference between the pdfs (exept for the timestamp). Doing many operations involving mclapply can increase the size of the resulting pdf by ten times! Thank you for checking this. require(multicore)

Thank you for the report and initial debugging. I am not sure what is going wrong, we may have to rely on your help to debug this (I do not have a system to reproduce on). A user-targeted advice would be to use RGui (Rgui.exe). Does the problem also exist in R-devel? https://cran.r-project.org/bin/windows/base/rdevel.html Your example? print("ABC\u4f60\u597dDEF") is printing two

Hi I haven't found a way to produce a tabulation from factor data with NA values using xtabs. Please find a minimal example below, it's also on R-pubs [1]. Tested with R 3.1.2 and R-devel r67720. It doesn't seem to be documented explicitly that it's not supported. From reading the code [2] it looks like the relevant call to table() doesn't set the "useNA"

>>>>> akshay kulkarni >>>>> on Wed, 31 May 2023 20:55:33 +0000 writes: > dear members, > I am using arfima() from forecast package to model a time > series. The following is the code: >> LYGH[[202]] > [1] 45.40 3.25 6.50 2.15 >> arfima(LYGH[[202]]) > Error in .fdcov(x, fdf$d, h, nar = nar, nma = nma,

I repeat my emails of 11/15/01 and 2/26/02, since it looks like this ESS bug is still not fixed in ESS 5.1.23, and I think some resolution is needed. When help() is invoked, ESS makes a copy of .Last.value in the .GlobalEnv, which is *not* where R normally stores it (R stores it in package:base). When this copy becomes stale it leads to wrong answers. The bug is in essd-r.el, lines 63-64:

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 <- Sys.getlocale("LC_CTYPE") > mbyte.lc <- { + if(.Platform$OS.type == "windows") + "English_United States.28605" + else if(grepl("[.]UTF-8$", oloc,

On 22/11/2014, 2:59 PM, Stuart Ambler wrote: > A colleague?s R program behaved differently when I ran it, and we thought > we traced it probably to different results from string comparisons as > below, with different R versions. However the platforms also differed. A > friend ran it on a few machines and found that the comparison behavior > didn?t correlate with R version, but

Dear Martin, Sad that the bug is beyond your ken... Fortunately, the error happens only rarely...The length of LYGH was 719 and there were only two such errors..I will just replace them with NA and make do. By the by, what if I send LYGH as an attachment to your actual mail ( not the r-help mail)? Will it help? Can you then pinpoint the cause? Or should I raise a bug

I get the failure message. To be specific: adcomp.git>R CMD BATCH --quiet test_nlminb.R adcomp.git>cat test_nlminb.Rout > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) > xhat <- rep(1, 10) > abs( opt$objective - f(xhat) ) < 1e-4? ## Must be TRUE [1] FALSE My system is described by: adcomp.git>uname

Hi, read.dcf() can modify the locale variable LC_CTYPE, and here is a minimal example: > Sys.getlocale('LC_CTYPE') [1] "en_US.UTF-8" > read.dcf(textConnection('a: b'), all = TRUE) a 1 b > Sys.getlocale('LC_CTYPE') [1] "C" After diagnosing the problem, it seems the on.exit() call in read.dcf() is the culprit:

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