similar to: Is ALTREP "non-API"?

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

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

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

> 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

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 Tomas, There has been an R CMD check error with xfun and r-devel on Windows for a while: https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/xfun-00check.html Basically it means that the following would return TRUE before: normalizePath('a/b', mustWork = FALSE) == normalizePath('./a/b', mustWork = FALSE) but it became FALSE at some point in r-devel. I think

I confirmed the revert fixed my failing test. Thanks! 2023?2?23?(?) 20:12 Hiroaki Yutani <yutani.ini at gmail.com>: > Thanks for the prompt response, I'll confirm it after the new R-devel > binary is available. > Also, thanks for the detailed explanation. I agree with you in general. > > > "/" in "C:/" is a path separator or not, and whether it is

Thanks for the prompt response, I'll confirm it after the new R-devel binary is available. Also, thanks for the detailed explanation. I agree with you in general. > "/" in "C:/" is a path separator or not, and whether it is trailing or not It seems a Windows' path basically consists of two components; a drive specification (e.g., C:) and the directory structure

Thanks so much for your wonderful work, Luke! I didn't expect such a clarification to happen this soon. This is really great. For convenience, I created a quick web page to search the result of tools:::funAPI(). https://yutannihilation.github.io/R-fun-API/ Hope this helps those who are too lazy to install R-devel to check. Best, Yutani 2024?6?6?(?) 23:47 luke-tierney--- via R-devel

Sorry to ask about a bit drifted topic, but will there be an alternative API to DATAPTR? > DATAPTR is not in the API and can't be at least in this form I believe it's vital for ALTREP to return the pointer to the expanded version of a SEXP just like the implementation in base R does [1]. At least, VECSXP has no other measure to expose the pointer if I understand correctly. Best,

On 2/23/23 03:27, Hiroaki Yutani wrote: > Hi, > > I found dirname() behaves differently on R-devel on Windows. Since I'm not > sure which behavior is right, let me ask here before filing this to R's > Bigzilla. > > On R 4.2.2., we get > > > dirname("C:/") > [1] "C:/" > > However, on R-devel (r83888), we get > >

Hi, I found dirname() behaves differently on R-devel on Windows. Since I'm not sure which behavior is right, let me ask here before filing this to R's Bigzilla. On R 4.2.2., we get > dirname("C:/") [1] "C:/" However, on R-devel (r83888), we get > dirname("C:/") [1] "." ?dirname says 'dirname returns the part of the

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

Hi, By looking at a doc about ALTREP https://svn.r-project.org/R/branches/ALTREP/ALTREP.html (by the way congratulations for that and for R-3.5.0 in general), I was a little bit surprised by the following example: > x <- 1:1e10 > system.time(print(mean(x))) [1] 5e+09 ?? user? system elapsed ?38.520?? 0.008? 38.531 Taking 38.520 s to calculate a mean value of an arithmetic

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