similar to: 'help' information not modified when I modify man files

Hi, I'm updating the LMGene package from Bioconductor. "Writing R Extensions" suggests that all source files (the ones in the R directory) have a .R ending, so I added it to the (one) source file. The next time I installed and ran R, R didn't understand any of the functions. I tried various things and eventually went back to the file and dropped the .R ending, installed, ran R.

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

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

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

Full_Name: Guy W. Tillinghast Version: 2.8.0 OS: Windows XP professional Submission from: (NULL) (24.248.24.3) I am encountering difficulty asking R to manipulate the correct columns in Expression Set class (object 4). I download the ALL data with: library(golubEsets) data(Golub_Merge) Note, the data has the samples not in order. This is not R's fault (at least not that I can tell): >

> 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

This is an update on some current work on the C API for use in R extensions. The internal R implementation makes use of tens of thousands of C entry points. On Linux and Windows, which support visibility restrictions, most of these are visible only within the R executble or shared library. About 1500 are not hidden and are visible to dynamically loaded shared libraries, such as ones in packages,

Thanks for working on this Luke! We appreciate your efforts to make it easier to tell what's in the exported API and we're very happy to work with you on any changes needed to tidyverse/r-lib packages. Hadley On Thu, Jun 6, 2024 at 9:47?AM luke-tierney--- via R-devel < r-devel at r-project.org> wrote: > This is an update on some current work on the C API for use in R >

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

Thanks for sharing this overview of an interesting and much-needed project. You mention that R exports about 1500 symbols (on platforms supporting visibility) but this subject isn't mentioned explicitly again in your note, so I'm wondering how things tie together. Un-exported symbols cannot be part of the API - how would people use them in this case? In a perfect world the set of

On Fri, 7 Jun 2024, Steven Dirkse wrote: > You don't often get email from sdirkse at gams.com. Learn why this is important > Thanks for sharing this overview of an interesting and much-needed project. > You mention that R exports about 1500 symbols (on platforms supporting > visibility) but this subject isn't mentioned explicitly again in your note, > so I'm wondering

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,

Would it be reasonable to move the non-API stuff that cannot be hidden into header files inside a "details" directory (or some other specific naming scheme)? That's what I use when I need to separate a public API from an internal API. On Fri, Jun 7, 2024 at 7:30?AM luke-tierney--- via R-devel <r-devel at r-project.org> wrote: > > On Fri, 7 Jun 2024, Steven Dirkse

I am updating the CRAN package LMGene, and I'm having trouble installing the new version. I changed the working package name to WLMG so I could use the new version without removing the old version from the R directory. I set up R_LIBS to allow installation in a different directory. When I did R CMD INSTALL -l /linux-ws/tilling/Rlib WLMG it put the right files in the right place. However,

I am looking for the appropriate field to let package authors to declare the pkg documentation language for spell checkers. The most important case is to specify a preference between "en-US" or "en-GB" which can be used by the hunspell or spelling pkg to select the appropriate dictionary. WRE defines the "Language" field for documentation language, but from the

On Tue, 2020-09-08 at 12:08 +0200, Tomas Kalibera wrote: > I am not sure if I understand correctly, but if you were accessing > directly the memory of SEXPs from Go implementation instead of > calling > through exported access functions documented in WRE, that would be a > really bad idea. Of course fine for research and experimentation, but > the internal structure can and does

On Wed, 24 Apr 2024, Hadley Wickham wrote: >> >> >> >>>>> That is not true at all - the presence of header does not constitute >>>> declaration of something as the R API. There are cases where internal >>>> functions are in the headers for historical or other reasons since the >>>> headers are used both for the internal

If users post a bug or problem issue to an R-based news group (R-devel, R-help, BioC - though BioC is far more forgiving) they get yelled at for not reading the posting guide and FAQ. "Please *_do_* read the FAQ, the posting guide, ..." the yellers do say. So I read the BioC FAQ and it says... http://www.bioconductor.org/docs/faq/ "Bug reports on packages should perhaps be

If users post a bug or problem issue to an R-based news group (R-devel, R-help, BioC - though BioC is far more forgiving) they get yelled at for not reading the posting guide and FAQ. "Please *_do_* read the FAQ, the posting guide, ..." the yellers do say. So I read the BioC FAQ and it says... http://www.bioconductor.org/docs/faq/ "Bug reports on packages should perhaps be