similar to: R_ext/Altrep.h should be more C++-friendly

Michael, Thanks for reaching out. This was brought up by Romaine Francois offline to me as well. What he does as a workaround is #define class klass extern "C" { #include <R_ext/Altrep.h> } #undef class While we consider changing Altrep.h, the above should work for you in the immediate term. Let me know if it doesn't. ~G On Mon, Oct 8, 2018 at 4:17 PM, Michael

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

Hi all, I would like to determine if an ALTREP object is from my package, I see there is a function `ALTREP_CLASS` defined in RInternal.h but its return value is neither a `R_altrep_class_t` object nor an STRSXP representing a class name. I do not know how to correctly use it. Any suggestions? Thanks, Jiefei [[alternative HTML version deleted]]

Benjamin, You happened to send a link which points to the OP's own package :) I think Jiefei would like to know how one can "officially" determine if an arbitrary ALTERP object belongs to a class that he owns. Regards, Denes On 10/19/20 10:22 AM, Benjamin Christoffersen wrote: > It seems as if you can you use the ALTREP macro as done in this > package:

While implementing R's new 'altrep' functionality in the TERR engine, I discovered a bug in R's 'deferred_string' altrep object: it is not using the correct value of the 'OutDec' option when it expands a deferred_string. See the following example: R 3.5.1: (same results in R 3.6.0 devel engine built 10/5) > options(scipen=0, OutDec=".") >

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,

If I have loaded the C code: SEXP altrep_STRING_IS_SORTED(SEXP x) { return ScalarInteger(STRING_IS_SORTED(x)); } and defined the function: issort <- function(x) .Call("altrep_STRING_IS_SORTED",x) I am seeing the following results in R 3.5.1/Linux: > issort(LETTERS) [1] NA > issort(as.character(1:100)) ## should return NA [1] 1 >

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

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

> You happened to send a link which points to the OP's own package :) I > think Jiefei would like to know how one can "officially" determine if an > arbitrary ALTERP object belongs to a class that he owns. Argh, I am sorry! I did not notice that. My best bet for what I thought the question was is section 1.1.2 of R Internals where they note that: `unsigned int alt : 1; /* is

> 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

It seems as if you can you use the ALTREP macro as done in this package: https://github.com/Jiefei-Wang/SharedObject/blob/804b6ac58c63a4bae95343ab43e8b1547b07ee6b/src/C_interface.cpp#L185 and in base R: https://github.com/wch/r-source/blob/54fbdca9d3fc63437d9e697f442d32732fb4f443/src/include/Rinlinedfuns.h#L118 The macro is defined here in Rinternals.h:

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

thanks for clearing that up, so these methods are actually not meant to be exported on Windows and OSX? Some of the ALTREP methods that now use 'attribute_hidden' would be very useful to packages that aim to be ALTREP aware, should the currently (exported) API be considered final? thanks for your time & best, Mark On Tue, Jun 4, 2019 at 6:52 PM Tierney, Luke <luke-tierney at

On Mon, Apr 22, 2024 at 5:14?PM Simon Urbanek <simon.urbanek at r-project.org> wrote: > > > > 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

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

I believe the performance of isUnsorted() in sort.c could be improved by calling REAL() once (outside of the for loop), rather than calling it twice inside the loop. As an aside, it is implemented in the faster way in doSort() (sort.c line 401). The example below shows the performance improvement for a vectors of double of moving REAL() outside the for loop. # example as implemented in

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

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,

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