similar to: Recent changes in R related to CHARSXPs

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

That would be because the product nc * ni overflows in cbuf = buf = CallocCharBuf(nc * ni); Since we disallow strings with more than 2^31-1 bytes we could test and reject this. It might be more future-proof to change the declaration of int j, ni, nc; to R_xlen_t j, ni, nc; and let the character allocation code reject, but that would create a memory leak since the Free call

I've rolled up R-2.6.0.tar.gz a short while ago. This is a development release which contains a number of new features. In particular, the handling of data with a large number of identical strings should be more memory-efficient. Also, a number of mostly minor bugs have been fixed. See the full list of changes below. You can get it (later today) from

I've rolled up R-2.6.0.tar.gz a short while ago. This is a development release which contains a number of new features. In particular, the handling of data with a large number of identical strings should be more memory-efficient. Also, a number of mostly minor bugs have been fixed. See the full list of changes below. You can get it (later today) from

Hi, We sometimes see offers to contribute, asking what needs to be done. If they know C, how about the 111 FIXMEs? But which ones would be most useful to fix? Which are difficult and which are easy? Does R-core have a process to list and prioritise the FIXMEs? ~/R/Rtrunk/src/main$ grep "[^/]FIXME" * | wc -l 111 ~/R/Rtrunk/src/main$ grep -A 1 "[^/]FIXME" * arithmetic.c:/*

Hi Jiefei, The issue here is that while the memory consequences of what you're describing may be true, this is simply how R handles character vector (what you're calling string) values internally. It doesn't actually have anything to do with ALTREP. Standard character vector SEXPs have an array of CHARSXP pointers in their payload (what is returned by DATAPTR) as well. As far as I

Hello from Bioconductor, I'm developing a package to share R objects across clusters using boost library. The concept is similar to mmap package: https://cran.r-project.org/web/packages/mmap/index.html . However, I have a problem when I was trying to write Dataptr_method for the alternative string. Based on my understanding, the return value of the Dataptr_method function should be a vector

On Fri, 10 May 2019, ??? wrote: > Hi Gabriel, > > Thanks for your explanation, I totally understand that it is almost > impossible to change the data structure of STRSXP. However, what I'm > proposing is not about changing the internal representation, but rather > about how we design and use the ALTREP API. > > I might do not state the workarounds clearly as English is

Hi Gabriel, Thanks for your explanation, I totally understand that it is almost impossible to change the data structure of STRSXP. However, what I'm proposing is not about changing the internal representation, but rather about how we design and use the ALTREP API. I might do not state the workarounds clearly as English is not my first language. Please let me explain them again in detail.

We've had this more general topic on R-help, and also in R-devel recently. There's one case here where I get the feeling R never gets into swapping but more directly aborts possibly from a bug we can more easily fix. Today I've been working (successfully! - not yet committed) at fixing str() for very large strings. In this process, I've found that pc <- function(.)

Hello. I've been looking at vecsexps for my binding. Concerning strings, I'm wondering: are they supposed to be null-delimited? Are they delimited by the info in the SEXPHEADER macro in Rinternals.h? Basically, what are the macros or functions to access the values of the vecsexps? I'm thinking of CHARSXPs and INTSXPs for the moment... All the best, -- Guillaume Yziquel

Hi. I am the maintainer of Rmpi package. Now I have a problem regarding the change of CHAR () in R 2.6.0. According to R 2.6.0 NEWS: ******* CHAR() now returns (const char *) since CHARSXPs should no longer be modified in place. This change allows compilers to warn or error about improper modification. Thanks to Herve Pages for the suggestion. ******* Unfortunately this

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've been observing the recent SVN log entries about encoding information in CHARSXPs with great interest. This looks like a very nice addition. While this is still work in progress, I'd like to suggest the following extra: At least in RKWard, all shown strings need to be converted to UTF-8 (the internal storage format used in Qt QStrings). This needs to be done independent of

On Fri, 1 Nov 2019, Jan Gorecki wrote: > Thank you Luke. > That is why I don't use Rf_inherits but INHERITS which does not > allocate, provided in the email body. Your definition can allocate because STING_ELT can allocate. getAttrib can GC in general. Currently it would not GC or allocate in this case, but this could change. You can't assume thread-safety for calls into the R

Hello, I have list of 600K lists, each sublist a list of two elements, the first a character, the second a list of six named elements, some characters some numrics. LISTA (600K) (:= h) |__ List of two elements |__ Character |__ Named List of 6 elements (characters and numerics) This works, sip <- lapply(h,function(r) r[[2]][['sip']]) but I wish to unlist this

As per `?intToUtf8`, and in the comments to `valid_utf8`[1], R intends to prevent illegal UTF-8 such as UTF-8 encoded UTF-16 surrogate pairs.? `R_nchar`, invoked via `base::nchar`, explicitly validates UTF-8 strings[2], but allows the surrogate: ??? > Encoding('\ud800') ??? [1] "UTF-8" ??? > nchar('\ud800')? // should be an error ??? [1] 1 The problem manifests

I've rolled up R-2.9.2.tar.gz a short while ago. This is a maintenance release and fixes a number of mostly minor issues. See the full list of changes below. You can get it from http://cran.r-project.org/src/base/R-2/R-2.9.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course (Duncan Murdoch is out of town, so Windows

I've rolled up R-2.9.2.tar.gz a short while ago. This is a maintenance release and fixes a number of mostly minor issues. See the full list of changes below. You can get it from http://cran.r-project.org/src/base/R-2/R-2.9.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course (Duncan Murdoch is out of town, so Windows

I am trying to connect to an internal database and use the sqlQuery command to reduce and retrieve data using the following code: channel <-odbcConnect("some_dsn", uid="", pwd="") txt<-'SELECT Date, Region, Price FROM TableXYZ WHERE Type="Domestic"' sqlQuery(channel, cat(txt,"\n"),errors=TRUE,) close(channel) However, I get the