similar to: mean(x) for ALTREP

Hi Bob, Thanks for sending around the link to that. It looks mostly right and looks like a useful onramp. There are a few things to watch out for though (I've cc'ed Romain so he's aware of these comments). @romain I hope you taake the following comments as they are intended, as help rather than attacks. The largest issue I see is that the contract for Get_region is that it *populates

Dear Listmembers, wanting to learn more about ALTREP I wrote the following function to extract a subsequence from an integer vector: #include <Rinternals.h> SEXP integer_get_region(SEXP _x, SEXP _i, SEXP _n) { int i = INTEGER(_i)[0]; int n = INTEGER(_n)[0]; SEXP result = PROTECT(Rf_allocVector(INTSXP, n)); INTEGER_GET_REGION(_x, i, n, INTEGER(result)); UNPROTECT(1); return

I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): $> R --vanilla x <- c(0L, -2e9:2e9) # > Segmentation fault Tried to reproduce on Linux but the above worked as expected. Not an issue merely with the length of the vector; for example, x <- rep_len(1:10, 1e10) works, though the altrep vector must be long to reproduce: x <- c(0L, -1e9:1e9) #ok Segmentation

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); *

>>>>> luke-tierney >>>>> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes: > On Tue, 8 Sep 2020, Martin Maechler wrote: >>>>>>> Martin Maechler >>>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >> >>>>>>> Hugh Parsonage >>>>>>> on Tue, 8 Sep 2020

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

Thanks, Hernando, Sorry, "API" is a bit confusing term in this context, but what I want to discuss is the "API" that Writing R Extension defines as quoted in my previous email. It's probably different from an ordinary sense when we casually say "R C API". You might wonder why I care about such a difference. This is because calling a "non-API" is

Hello, I don't believe it is illegal, as ALTREP "implements an abstraction underneath the C API". And is "compatible with all code which uses the API". Please see slide deck by Gabriel Becker, with L Tierney, M Lawrence and T Kalibera. https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP .pdf ALTREP framework implements an abstraction underneath

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

On Tue, 8 Sep 2020, Hugh Parsonage wrote: > Thanks Martin. On further testing, it seems that the segmentation > fault can only occur when the amount of obtainable memory is > sufficiently high. On my machine (admittedly with other processes > running): > > $ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)" > Segmentation fault > > $ R --vanilla

Hi all, I believe I have found a bug (or perhaps just an oversight) with the ALTREP wrapper classes. The short form of this is that I believe that the wrapper classes need to override the default ALTREP `Extract_subset_method()` with a method that calls `Extract_subset()` on the "wrapped" object. I have a patch prepared here: https://github.com/DavisVaughan/r-source/pull/1 There is

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

Writing R Extension[1] defines "API" as: Entry points which are documented in this manual and declared in an installed header file. These can be used in distributed packages and will only be changed after deprecation. But, the document (WRE) doesn't have even a single mention of ALTREP, the term "ALTREP" itself or any entry points related to ALTREP. Does this mean,

Thanks for your convincing comment, but it seems the R core team has a different opinion... A few hours ago, src/include/R_ext/Altrep.h got this comment: /* Not part of the API, subject to change at any time. */ commit: https://github.com/r-devel/r-svn/commit/2059bffde642f8426d1f39ab5dd995d19a575d4d While I'm glad to see their attempt to make it clear, I'm confused. That

> On Apr 22, 2024, at 7:37 PM, Gabriel Becker <gabembecker at gmail.com> wrote: > > Hi Yutani, > > ALTREP is part of the official R api, as illustrated by the presence of > src/include/R_ext/Altrep.h. Everything declared in the header files in that > directory is official API AFAIK (and I believe that is more definitive than > the manuals). > That is not true

Hi Yutani, ALTREP is part of the official R api, as illustrated by the presence of src/include/R_ext/Altrep.h. Everything declared in the header files in that directory is official API AFAIK (and I believe that is more definitive than the manuals). The documentation of ALTREP has lagged behind its implementation unfortunately, which may partially my fault for not submitting doc patches for it

Thank Denes for the clarification, glad to see my package got one citation from my own question:) Also, thank Benjamin for sending many useful documents. Actually, the question is related to the SharedObject package that Benjamin has pointed to. I wanna avoid sharing an object that has already been shared, so I need to check whether an object is an ALTREP that is defined in my package. Since the

Hello, I'm developing a package (lazyvec) that makes full use of the ALTREP framework (R >= 3.6.0). One application of the package is to wrap existing ALTREP vectors in a new ALTREP vector and pass all calls from R to the contained object. The purpose of this is to provide a diagnostic framework for working with ALTREP vectors and show information about internal calls. The package builds

Hi Gabriel, thanks for your detailed explanation, that definitely clarifies the design choices that were made in setting up the ALTREP framework and I can see how those choices make sure existing code won't break. My specific use-case for wanting to check whether a vector is an ALTREP is the following: the fst package wraps an external C++ library (fstlib, independent from R) that was made