similar to: problem gsub in the locale of CP932 and SJIS (PR#9751)

On Windows, grep(fixed=TRUE) throws errors with some UTF-8 strings. Here's an example (must be run on Windows to reproduce the error): Sys.setlocale("LC_CTYPE", "chinese") y <- rawToChar(as.raw(c(0xe6, 0xb8, 0x97))) Encoding(y) <- "UTF-8" y # [1] "?" grep("\n", y, fixed = TRUE) # Error in grep("\n", y, fixed = TRUE) : invalid

Full_Name: Stefan Raberger Version: 2.8.1 OS: Windows XP Submission from: (NULL) (213.185.163.242) Hi there, I recently noticed some strange behaviour of the command "type.convert", depending on the startup mode used. But there also seems to be different behaviour on different PCs (all running the same OS and the same version of R). On PC1: When I start R in SDI mode (RGui --no-save

After a bit more investigation, I think I've found the cause of the bug, and I have a patch. This bug happens with grep(), when: * Running on Windows. * The search uses fixed=TRUE. * The search pattern is a single byte. * The current locale has a multibyte encoding. ======================= Here's an example that demonstrates the bug: # First, create a 3-byte UTF-8 character y <-

In what way is this a bug in R? It looks like a bug in the package, and as Defn.h is not part of R's API any packge using it is `at risk' (and cannot be installed in a binary-only installation, or even an installed version of R). In particular, Defn,.h depends on config.h, and it seems you installed a binary version of R and used separate sources. I would suggest building R from

Hi, I was trying to have R read files faster with readChar(). That was before I noticed that readChar() is not that bad! In any case, below I suggest a few simple changes that will make readChar slightly faster. I followed readChar(useBytes=T), and tried to identify all O(N) operations, where N is the size of the file. The assumption is that for LARGE files we want to avoid any O(N) operations,

Full_Name: Richard Boyce Version: 2.1.-1 OS: Debian testing/unstable Submission from: (NULL) (128.95.123.29) While building a custom package using a modified version of Duncan's REventLoop with R version 2.1 (Debian package r-base, r-base-dev) and R source from apt-get source 2.1.1 I get the following error: $ R CMD build vjREventLoop * checking for file

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

----- Am 8. Nov 2016 um 15:26 schrieb Johannes Ranke johannes.ranke at jrwb.de: > Hi > > try > > apt-get build-dep r-base > > this installs the headers required for building current R, which probably also > covers older versions - at least it will give you X11 headers. > > Good luck, > > Johannes > > Hi Johannes, i tried that and it didn't

Hi, Martijn sent the following patch to me in private and agreed that i post it here. In any other program in OpenBSD base, i'd probably agree with the basic approach. Regarding OpenSSH, however, i worry whether wcwidth(3) can be used. While wcwidth(3) is POSIX, it is not ISO C. Does OpenSSH target platforms that don't provide wcwidth(3)? If so, do you think the problem can be solved

Dear all, I am new to R system. When I tried to edit data read from a csv file, R system crushed, I got an error message as follows: > edit(data) *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0x49d020b1] /lib/libc.so.6[0x49d034a2] /usr/lib/R/modules//R_X11.so[0x33ed7a] /usr/lib/R/modules//R_X11.so[0x34050d]

Dear all, I am new to R system. When I tried to edit data read from a csv file, R system crushed, I got an error message as follows: > edit(data) *** buffer overflow detected ***: /usr/lib/R/bin/exec/R terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0x49d020b1] /lib/libc.so.6[0x49d034a2] /usr/lib/R/modules//R_X11.so[0x33ed7a] /usr/lib/R/modules//R_X11.so[0x34050d]

Hello all, I am writing an R interface to some C++ files which make use of std::wstring classes for internationalization. Previously (when I wanted to make R strings from C++ std::strings), I would do something like this to construct a string in R from the results of the parse. SET_VECTOR_ELT(vals, i++, mkString(header.GetHeader().c_str())); However, now the call header.GetHeader().c_str()

Hi! I've been trying to compile R with gcc version 3.4.2 on a box running Solaris 2.6. I keep on hitting this error during the compile: gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -std=gnu99 -c dynload.c -o dynload.o In file included from dynload.c:33: ../../src/include/Defn.h:943: error: parse error before "mbstate_t" make[3]: ***

** problem ** Current code triggers a defragfs bug [1]: ``` tw-tst:~ # defragfs.ocfs2 /mnt/test_from_dd1 defragfs.ocfs2 1.8.7 [ERROR]Move extent failed:"/mnt/test_from_dd1" - No space left on device [ERROR]"/mnt/test_from_dd1":No space left on device ``` I added some debug messages in relevant functions. When above error messages appeared, the la-window still had enough

This patch adds a simple callback framework. Modified loadfile and floadfile to look for callbacks and call them if present Supports multiple callbacks Modified com32/modules/linux.c to demonstrate functionality (it's a little more complicated than it should be just to demonstrate multiple callbacks). Add progress argument to display a percentage indicator when loading. Example boot:

Two patches follow this message. One fixes the default implementation of SEEK_HOLE/DATA. This patch applies atop Josef's last posted patch. The second patch implements the same on ocfs2. The test tool for the same is available here. http://oss.oracle.com/~smushran/seek_data/seek_test.c It is improved since the last post. It runs cleanly on zfs, ocfs2 and ext3 (default behavior). Users

Two patches follow this message. One fixes the default implementation of SEEK_HOLE/DATA. This patch applies atop Josef's last posted patch. The second patch implements the same on ocfs2. The test tool for the same is available here. http://oss.oracle.com/~smushran/seek_data/seek_test.c It is improved since the last post. It runs cleanly on zfs, ocfs2 and ext3 (default behavior). Users

ping... On 4/21/23 3:35 PM, Joseph Qi wrote: > Hi, > Could you please share a reproducer? > > Thanks, > Joseph > > On 4/6/23 11:40 PM, Heming Zhao wrote: >> ** problem ** >> >> Current code triggers a defragfs bug [1]: >> >> ``` >> tw-tst:~ # defragfs.ocfs2 /mnt/test_from_dd1 >> defragfs.ocfs2 1.8.7 >> [ERROR]Move extent

Hi, Could you please share a reproducer? Thanks, Joseph On 4/6/23 11:40 PM, Heming Zhao wrote: > ** problem ** > > Current code triggers a defragfs bug [1]: > > ``` > tw-tst:~ # defragfs.ocfs2 /mnt/test_from_dd1 > defragfs.ocfs2 1.8.7 > [ERROR]Move extent failed:"/mnt/test_from_dd1" - No space left on device > [ERROR]"/mnt/test_from_dd1":No space

Hi all, I have been previously been using scatterplot3d package to create some graphs but unfortunately it does not allow me to rotate the plot on all three axis. The cloud() function in the lattice package does allow me to do so. When I was using scatterplot3d I was using a script (Shown Below) to calculate the mean, quartiles and range limits for all three axis and I was representing that on the