similar to: Why does typeof() modify an object's "named" field?

Hello, I?m experimenting with ALTREP and was wondering if there is a preferred way to create an ALTREP wrapper vector without using .Internal(wrap_meta(?)), which R CMD check doesn?t like since it uses an .Internal() function. I was trying to create a factor that used an ALTREP integer, but attempting to set the class and levels attributes always ended up duplicating and materializing the

Hi all, Take this simple script, which I'm trying to use to understand when modification in-place occurs, and when a new object is created: message("Global") x <- 1:3 .Internal(inspect(x)) x[2] <- 1L .Internal(inspect(x)) message("In function") (function() { x <- 1:3 .Internal(inspect(x)) x[2] <- 1L .Internal(inspect(x)) })() If I run it from the

Hi Jiefei and Kylie, Great to see people engaging with the ALTREP framework and identifying places we may need more tooling. Comments inline. On Thu, Jul 18, 2019 at 12:22 PM King Jiefei <szwjf08 at gmail.com> wrote: > > If that is the case and you are 100% sure the reference number should be 1 > for your variable *y*, my solution is to call *SET_NAMED *in C++ to reset > the

Hi, I expected NAMED to be 1 in all these three cases. It is for one of them, but not the other two? > R --vanilla R version 2.14.0 (2011-10-31) Platform: i386-pc-mingw32/i386 (32-bit) > x = 1L > .Internal(inspect(x)) # why NAM(2)? expected NAM(1) @2514aa0 13 INTSXP g0c1 [NAM(2)] (len=1, tl=0) 1 > y = 1:10 > .Internal(inspect(y)) # NAM(1) as expected but why different to x?

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

Hello, I would like for my C function to be able to manipulate some values stored in an R data frame. To achieve this, a need the (real) memory address where the R data frame stores its data (hopefully in a contiguous way). Then, from R, I call the C function and passing this memory address as a parameter. The question: how can we get the memory address of the R data frame? Thank you! L.

Hi Kylie, For your question, I don't think a wrapper can completely solve your problem. The duplication occurs since your variable y has more than 1 reference number( Please see highlighted), so even you have a wrapper, any changes on the value of the wrapper still can trigger the duplication. > .Internal(inspect(y)) > @7fb0ce78c0f0 13 INTSXP g0c0 *[NAM(7)]* matter vector (mode=3,

Hi, I just found a strange increase in the reference number and I'm wondering if there is any reason for it, here is the code. > a=c(1,2,3) > .Internal(inspect(a)) @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3 > is.vector(a) [1] TRUE > .Internal(inspect(a)) @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(7)] (len=3, tl=0) 1,2,3 The variable *a* initially has one

Hi Jiefei and Duncan, I suspect what is likely happening is that one of ENSURE_NAMEDMAX or MARK_NOT_MUTABLE are being hit for x. These used to set named to 3, but now set it to 7 (ie the previous and current NAMEDMAX value, respectively). Because these are macros rather than C functions, its not easy to figure out why one of them is being invoked from do_isvector (a cursory exploration

Hi all, The coercion function defined for the ALTREP object will not be called by R when an assignment operation implicitly introduces coercion for a large ALTREP object. For example, If I create a vector of length 10, the ALTREP coercion function seems to work fine. ``` > x <- 1:10 > y <- wrap_altrep(x) > .Internal(inspect(y)) @0x000000001f9271c0 13 INTSXP g0c0 [REF(2)] I am

> .Internal(inspect(1:10)) @300e4e8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) > .Internal(inspect(seq(1,10))) @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... > system.time(1:1e7) user system elapsed 0 0 0 > system.time(seq(1,1e7)) user system elapsed 0.05 0.00 0.04 It seems that result of function 'seq' doesn't use compact

Hi Gabriel, here is a simple package for reproducing the problem. https://github.com/Jiefei-Wang/testPkg Best, Jiefei On Thu, Oct 8, 2020 at 5:04 AM Gabriel Becker <gabembecker at gmail.com> wrote: > Jiefei, > > Where does the code for your altrep class live? > > Thanks, > ~G > > On Wed, Oct 7, 2020 at 4:25 AM Jiefei Wang <szwjf08 at gmail.com> wrote: >

Thanks -- I'll commit a fix after some testing. Best, luke On 04/29/2018 06:22 AM, Duncan Murdoch wrote: > On 28/04/2018 11:11 PM, Suharto Anggono Suharto Anggono via R-devel wrote: >>> .Internal(inspect(1:10)) >> @300e4e8 13 INTSXP g0c0 [NAM(3)]? 1 : 10 (compact) >>> .Internal(inspect(seq(1,10))) >> @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,...

Hey Duncan, Hard to debug? That's an understatement. Eyes bleeding.... In any case, I tried all your suggestions. To get "integer" for the final column, I had to change the code to get integers instead of strings. double[] d1 = ((REXPVector) ((RList) tableRead).get(0)).asDoubles(); double[] d2 = ((REXPVector) ((RList) tableRead).get(1)).asDoubles(); double[] d3 = ((REXPVector)

Hi, I am trying to use existing C++ code from R. I have no problems compiling C code and using it in R, but with C++ I'm running into problems. Here's the compiler output: Macintosh-10:~/Desktop/dissertation/Model - CPP version/R labguest$ g++ -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 *.cpp In file included from

Hello, I've created this class: setClass("example", representation ( size = "numeric", id = "character" ) ) Suppose I create a new instance of this class: > x <- new("example", 4, "id_value") This creates an S4 object with two slots. Am I correct in thinking that slots are "filled" by SEXPs?

On Mon, 21 Jan 2019, Martin Maechler wrote: >>>>>> Travers Ching >>>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > > > I have a toy alt-rep string package that generates > > randomly seeded strings. example: library(altstringisode) > > x <- altrandomStrings(1e8) head(x) [1] > >

Hello, I have encountered two bugs when using ALTREP APIs. 1. STDVEC_DATAPTR >From RInternal.h file it has a comment: /* ALTREP support */ > void *(STDVEC_DATAPTR)(SEXP x); However, this comment might not be true, the easiest way to verify it is to define a C++ function: void C_testFunc(SEXP a) > { > STDVEC_DATAPTR(a); > } and call it in R via > a=1:10 > >

Thanks Duncan. I can't tell you how helpful all your terrific replies have been. I think the biggest surprise is that nobody appears to be using Java and R together like I"m trying to do. I suppose it should be a surprise since there are no books on the subject and almost no technical documentation other than a few sites here and there. ----- I originally had the "int" as the

>>>>> Martin Maechler >>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >>>>> Hugh Parsonage >>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes: >> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): >> $> R --vanilla >> x <- c(0L, -2e9:2e9) >> # > Segmentation