similar to: Documentation cross references

Hi! Thanks for this service! It is very helpful to know what is being developed. I distribute the content to other venues and I noticed some times that the updates are duplicated. For example, the sentence "?is.R()? is deprecated as no other S dialect is known to be in use (and this could only identify historical dialects, not future ones)." is duplicated in different days: Day 1:

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

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

As described here, "Markdown will... perform a bit of randomized decimal and hex entity-encoding to help obscure your address from address-harvesting spambots" on automatic email address links like <rwhe at ludism.org>. http://daringfireball.net/projects/markdown/syntax#autolink I have had a problem with my RSS feed for months, where certain entries would refresh every hour or

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,

Announcing CRANberries -- An RSS feed about New and Updated CRAN packages A new RSS feed [1] is now available that summarizes uploads to CRAN. This makes it possibly to quickly obtain concise information about which (of the now over one thousand !!) packages were added or updated at CRAN and its mirrors. To this end, two basic variants are provided: - a feed for new packages where we display

Announcing CRANberries -- An RSS feed about New and Updated CRAN packages A new RSS feed [1] is now available that summarizes uploads to CRAN. This makes it possibly to quickly obtain concise information about which (of the now over one thousand !!) packages were added or updated at CRAN and its mirrors. To this end, two basic variants are provided: - a feed for new packages where we display

On 9/8/20 1:13 PM, Dan Kortschak wrote: > 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

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 9/8/20 11:47 AM, Dan Kortschak wrote: > Thanks, Tomas. > > This is unfortunate. Calling between Go and C is not cheap; the gc > implementation of the Go compiler (as opposed to gccgo) uses different > calling conventions from C and there are checks to ensure that Go > allocated memory pointers do not leak into C code. For this reason I > wanted to avoid these if at all

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

Hello. There used to be changelog of sorts for R-devel [1] and R-release [2]. Neither have been updated since 2015-07-24. Have these moved elsewhere, or are they no longer being updated? Thank you, Avi [1] <http://developer.r-project.org/blosxom.cgi/R-devel/NEWS> [2] <http://developer.r-project.org/blosxom.cgi/R-3-2-branch/NEWS>

If a package has importClassesFrom(P, C) in its NAMESPACE, then should it _also_ have importClassesFrom(P, <superclasses of C exported from P>) importClassesFrom(Q, <superclasses of C exported from Q>) ## and so on ... ? I think that WRE could be more clear on this point, and in any case I _think_ that the answer is yes. Notably, I think that this rule would

On Tue, Sep 1, 2015 at 10:57 AM, peter dalgaard <pdalgd at gmail.com> wrote: > > On 01 Sep 2015, at 16:21 , Avraham Adler <avraham.adler at gmail.com> wrote: > >> Hello. >> >> There used to be changelog of sorts for R-devel [1] and R-release [2]. >> Neither have been updated since 2015-07-24. Have these moved >> elsewhere, or are they no longer

How about allowing underscore? (I believe WRE is silent on this, and I have not tried submitting a package with underscore in the title.) As I pointed out in my OP, _optim()_ works. And we have the advantage that we can distinguish package from function. The purpose of consistent editing is surely to provide the affordances that save us from needing extra documentation, as per Donald Norman's

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

On 01 Sep 2015, at 16:21 , Avraham Adler <avraham.adler at gmail.com> wrote: > Hello. > > There used to be changelog of sorts for R-devel [1] and R-release [2]. > Neither have been updated since 2015-07-24. Have these moved > elsewhere, or are they no longer being updated? Presumably, something that used to happen daily on the hosting machine (or elsewhere) isn't