similar to: suggestion how to use memcpy in duplicate.c

Hello, As this little program illustrates, duplicating a STRSXP does not seem deep enough. require( inline ) fx <- cfunction( signature( x = "character"), ' SEXP y = PROTECT( duplicate( x ) ); int n = LENGTH(x); int nc = 0 ; char* p = 0 ; for( int i=0; i<n; i++){ p = (char*)( CHAR( STRING_ELT( y , i ) ) ); nc = strlen( p ) ; for( int j=0; j<nc; j++){ p[j] =

# Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### 1. as.numeric behaves differently in R than in S and I think this shows a bug in how S3

--- Prof Brian D Ripley <ripley@stats.ox.ac.uk> wrote: >A matrix list? R lists are just vectors with elements of different types, >and R matrices are just vectors with a dimension attribute. When I saw the above I tried to create a matrix from a list but could not get it to work: my.lm <- lm( rnorm(10) ~ I(1:10) ) my.list <- list(1, 2, 3, 4, 5, 6, my.lm, my.lm, my.lm)

Hi R-Developers, After my message about a month ago concerning attributes being lost during simple operations, Martin Maechler invited me to fix the code if I was in a hurry (especially for attributes in general). We've just made the following changes here, which appear to implement the rules in the Blue Book (pg. 257) Enclosed is the output from "diff -c" from /R-0.61.1/src

### I got bit again by the same bugs I wrote about a year ago. ### The bugs are related to matrices and arrays of lists. ### 1. There is a clear inconsistency in how R handles two ### functionally equivalent statements. ### array() is able to take a list and create a matrix. ### matrix() is unable to create that matrix. > vector("list", 2) [[1]] NULL [[2]] NULL >

Hello, It has been a while since my last R Devel build, and now I'm running into an issue I'm not sure how to isolate. After updating to the latest SVN sources, and using: ---<--------------------cut here---------------start------------------->--- tools/rsync-recommended R_PAPERSIZE=letter \ R_BATCHSAVE="--no-save --no-restore" \ R_BROWSER=xdg-open \ LIBnn=lib \

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

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.

Consider the following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx

Dear all, I started a large run this afternoon, and when I came back after dinner, three of five processes had stopped with the error message: Error in matrix(nullprofile, length(nullprofile), nprofiles) : Unimplemented feature in copyVector I have seen anything about this anywhere (and I don't know where to look...). As you might guess, I'm trying to make a matrix where the

Experimenting with altrep objects and v3 serialization, I discovered a possible bug. Calling DATAPTR on a compact_intseq object returns a pointer to the expanded integer sequence in memory. If you modify this data, the object values appear to be changed. However, if the compact_intseq object is then serialized (with version=3), only the original integer sequence info is written. For example,

Hi, I am curious about whether there exist thread-safe functions in `Rinternals.h`. I know that R is single-threaded designed, but for the simple and straightforward functions like `DATAPTR` and `INTEGER_GET_REGION`, are these functions safe to call in a multi-thread environment? Best, Jiefei [[alternative HTML version deleted]]

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

Jiefei, Beyond the general response that Luke gave, to be a bit more specific to what you said, DATAPTR and INTEGER_GET_REGION involve ALTREP method execution (for ALTREP objects, obviously) so even they are not as simple and straightforward as they were a couple years ago. They should not (any longer) be thought of as being guaranteed to be essentially bare metal data retrieval from memory.

Hi everybody, I have been interfacing some C++ library code into an R package but ran into optimization issues specific to memory management that require some insight into the GC. One of the C++ libraries returns simple vectors of integers, doubles and complex which are allocated and managed from the library itself. I cannot know the length of the array beforehand, so I cannot pre-allocate that

Hi, I'm new to LLVM and have some questions about using the JIT on Windows x64. I am aware that this is currently broken but am attempting to use the hack/patch proposed in this bug http://llvm.org/bugs/show_bug.cgi?id=3739. I checked out the revision the patch was created for (66183) and applied it but the assembler generated seems to fail whenever it reaches a movaps insctruction.

Hi, Similar questions have come up before on the list and elsewhere but I haven't found a solution yet. winbuilder's install.out shows data.table's .c files compiled with -O3 on Win32 but -O2 on Win64. The same happens on R-Forge. I gather that some packages don't work with -O3 so the default is -O2. I've tried this in data.table's Makevars (entire contents) : ====

Hello, Until last weekend, I used to build R Devel smoothly with this switch (--enable-strict-barrier) on, but now it fails on my Debian system (found the culprit after posting on r-sig-debian). Configuring and building with: ---<--------------------cut here---------------start------------------->--- tools/rsync-recommended R_PAPERSIZE=letter \ R_BATCHSAVE="--no-save

I can work on this. Thanks Luke. ~G On Wed, Jul 24, 2019 at 8:25 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > If one of you wanted to try to create a patch to support ALTREP > generic vectors here are some notes: > > The main challenge I am aware of (there might be others): Allowing > DATAPTR to return a writable pointer would be too dangerous because > the GC

Hi, This problem started as of r73472 ("Merged in the rest of the basic ALTREP framework."); I tested r73471 and it did not exist. I'm building R devel on Ubuntu 16.04.3 LTS (64-bit), with the following flags: CC="gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer" CFLAGS="-fno-omit-frame-pointer -g -O2 -Wall -pedantic -mtune=native" and using