similar to: S4SXP type vs S4 object bit?

Hi Travers, Just an additional remarks to Michael's answer, if your S4 class inherits from R's basic types, say integer, the resulting object will be an INTSXP. If your S4 class does not inherit from any class, it will be an S4SXP. You can think about this question from the object-oriented framework: If one class inherits the integer class, what should R do to make all the integer related

I have a toy alt-rep string package that generates randomly seeded strings. example: library(altstringisode) x <- altrandomStrings(1e8) head(x) [1] "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1" "5PN2qmWqBlQ9wQj99nsQzldVI5ZuGX" ... etc object.size(1e8) Object.size will call the set_altstring_Elt_method for every single element, materializing (slowly) every element of the vector. This

Hi Inaki, > "Performant"... in terms of what. If the cost of copying the data > predominates over the computation time, maybe you didn't need > parallelization in the first place. Performant in terms of speed. There's no copying in that example using `mclapply` and so it is significantly faster than other alternatives. It is a very simple and contrived example, but

Below is a toy alt-rep string example, that generates N random strings: https://gist.github.com/traversc/a48a504eb062554f2d6ff8043ca16f9c example: `x <- altrandomStrings(1e8)` `head(x)` [1] "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1" "5PN2qmWqBlQ9wQj99nsQzldVI5ZuGX" ... `object.size(1e8)` Object.size will call the `set_altstring_Elt_method` for every single element, materializing

Just throwing my two cents in: I think removing/deprecating fork would be a bad idea for two reasons: 1) There are no performant alternatives 2) Removing fork would break existing workflows Even if replaced with something using the same interface (e.g., a function that automatically detects variables to export as in the amazing `future` package), the lack of copy-on-write functionality would

Hello, Consider this : > setClass("track", representation(x="numeric", y="numeric")) [1] "track" > o <- new( "track", x = 1, y = 2 ) > for( i in o ){ + cat( "hello\n") + } Error: invalid type/length (S4/1) in vector allocation This happens at those lines of do_for: n = LENGTH(val); PROTECT_WITH_INDEX(v =

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

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

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

On 1/22/19 6:17 PM, Kevin Ushey wrote: > I think that object.size() is most commonly used to answer the question, > "what R objects are consuming the most memory currently in my R session?" > and for that reason I think returning the size of the internal > representations of objects (for e.g. ALTREP objects; unevaluated promises) > is the right default behavior. I

Hi all I had written a gdb macro to dump the string representation of an SEXPREC type when I realised everything I needed was in inspect.c already in the typename() function. However, the typename function doesnt handle the RAWSXP type, so if possible, could the following patch be applied (I've just put in inline as it is a trivial 1-liner)? Index: src/main/inspect.c

Hi devel team, I'm working on C/C++ level ALTREP compatibility for a package. The package previously used pointers to access the data of a SEXP, so it would not work for some ALTREP objects which do not have a pointer. I plan to rewrite the code and use functions like get_elt, get_region, and get_subset to access the values of a vector, so I have a few questions for ALTREP: 1. Since an

Sorry for post a lot of things, for the first part of code, I copied my C++ iter macro by mistake(and you can see an explicit type casting). Here is the macro definition from R_exts/Itermacros.h #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \ strt, nfull, expr) do { \ * const** etype *px = DATAPTR_OR_NULL(sx); *

Using the IRanges package from Bioconductor and somewhat recent R-2.9.1. ov = IRanges(1:3, 4:6) length(ov) # 3 seq(along = ov) # 1 2 3 as wanted seq_along(ov) # 1! I had expected that the last line would yield 1:3. My guess is that somehow seq_along don't utilize that ov is an S4 class with a length method. The last line of the *Details* section of ?seq has a typeo. Currently it is

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

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

Hello Luke and Gabriel, Thank you very much for your quick responses. The explanation of STDVEC is very helpful and I appreciate it! For the wrapper, I have a few new questions. 1. Like Luke said a mutable object is not possible. However, I noticed that there is one extra argument *deep* in the function duplicate. I've googled all the available documentation for ALTREP but I did not find

On Sat, 11 May 2024, Travers Ching wrote: > The following code snippet causes R to hang. This example might be a > bit contrived as I was experimenting and trying to understand > promises, but uses only base R. > > It looks like it is looking for "not_a_variable" recursively but since > it doesn't exist it goes on indefinitely. > > x0 <- new.env() > x1

On Sat, May 11, 2024 at 9:34?AM luke-tierney--- via R-devel <r-devel at r-project.org> wrote: > > On Sat, 11 May 2024, Travers Ching wrote: > > > The following code snippet causes R to hang. This example might be a > > bit contrived as I was experimenting and trying to understand > > promises, but uses only base R. > > This has nothing to do with promises.

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