Displaying 4 results from an estimated 4 matches for "apifun".
Did you mean:
apifunc
2024 Oct 08
1
WRE about R_strtod
...n no conversion
is performed (including for the "NA" string, *end == str)?
Index: doc/manual/R-exts.texi
===================================================================
--- doc/manual/R-exts.texi (revision 87211)
+++ doc/manual/R-exts.texi (working copy)
@@ -16482,12 +16482,12 @@
@apifun R_atof
@apifun R_strtod
- at deftypefun void R_atof (const char* @var{str})
- at deftypefunx void R_strtod (const char* @var{str}, char ** @var{end})
+ at deftypefun double R_atof (const char* @var{str})
+ at deftypefunx double R_strtod (const char* @var{str}, char ** @var{end})
Implementations o...
2024 Jul 15
1
Minor inconsistencies in tools:::funAPI()
...reprocessor macros, not functions. I also see that
installTrChar is not explicitly marked.
Are we allowed to call tools:::unmap(tools:::funAPI()$name) and
consider the return value to be the list of all unmapped APIs, despite,
e.g., installTrChar not being explicitly marked?
- Should R_PV be an @apifun if it's currently caught by checks in
sotools.R?
- Should R_FindSymbol be commented /* Not API */ if it's marked as
@apifun in WRE and not caught by sotools.R? It is currently used by 8
CRAN packages.
- The names 'select', 'delztg' from R_ext/Lapack.h are functi...
2024 Jul 29
1
Minor inconsistencies in tools:::funAPI()
.... I also see that
> installTrChar is not explicitly marked.
>
> Are we allowed to call tools:::unmap(tools:::funAPI()$name) and
> consider the return value to be the list of all unmapped APIs, despite,
> e.g., installTrChar not being explicitly marked?
>
> - Should R_PV be an @apifun if it's currently caught by checks in
> sotools.R?
>
> - Should R_FindSymbol be commented /* Not API */ if it's marked as
> @apifun in WRE and not caught by sotools.R? It is currently used by 8
> CRAN packages.
>
> - The names 'select', 'delztg...
2024 Apr 25
1
[External] Re: Is ALTREP "non-API"?
On Thu, Apr 25, 2024 at 4:24?AM Ivan Krylov via R-devel
<r-devel at r-project.org> wrote:
>
> On Wed, 24 Apr 2024 15:31:39 -0500 (CDT)
> luke-tierney--- via R-devel <r-devel at r-project.org> wrote:
>
> > We would be better off (in my view, not necessarily shared by others
> > in R-core) if we could get to a point where:
> >
> > all entry points