similar to: Minor inconsistencies in tools:::funAPI()

Hi Ivan Can you please clarify what input files should be used with your proposed function? I tried a few files in r-svn/src/include and one of them gave me an error. > getdecl("~/R/r-svn/src/include/R.h") [1] "R_FlushConsole" "R_ProcessEvents" "R_WaitEvent" > getdecl("~/R/r-svn/src/include/Rdefines.h") Error in regmatches(lines,

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 15 ++++++++++++--- 4 files changed, 30 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 11 ++++++++--- 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

v1 was here: https://www.redhat.com/archives/libguestfs/2017-September/msg00135.html This is a more complete evolution of the earlier patch. It replaces most important uses of Str with PCRE throughout the code. It also extends the bindings with some useful features like case-insensitive regexps. The main places I *didn't* touch are the generator (GObject uses Str extensively); and

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

Hi, Thanks for the quick reply again. > On Thu, Dec 15, 2011 at 1:17 PM, David Fang <fang at csl.cornell.edu> wrote: >> Hi, >> >> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and >> have the following test results to share. >> Summary below, full log at: >>

The advanced voice mail options in RC1 is not providing any functionality except "4 - place outgoing call" and "* - return to mail menu". Below is a sample line from voice mail.conf: 210 => 234,test1,test@dotality.com,,|attach=no|cid=yes|review=yes The is a rew install from the tgz file. No patched have been made to the source code. I did try to apply the advanced10

v1: https://www.redhat.com/archives/libguestfs/2017-September/msg00135.html v2: https://www.redhat.com/archives/libguestfs/2017-September/msg00158.html v3 is almost identical to v2, but I have added 4 extra commits to almost finish the job of replacing Str everywhere possible (note it's not possible to replace Str in common/mlstdutils or the generator because those are pure OCaml). As

I've attached a script I wrote that pulls all the setGeneric definitions out of a set of R files and puts them in a separate file, default allGenerics.R. I thought it might help others who find themselves in a similar situation. The "situation" was that I had to change the order in which files in my package were parsed; the scheme in which the generic definition is in the

Hello, This is what "Writing R extensions" currently says about R_atof and R_strtod: >> Function: void R_atof (const char* str) >> Function: void R_strtod (const char* str, char ** end) >> >> Implementations of the C99/POSIX functions atof and strtod which >> guarantee platform-dependent behaviour, including always using the >> period as the decimal

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

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

I've encountered this note in checking packages with the latest R-devel. Googling finds it only in other package checks; searching the source tree finds in src/library/tools/R/sotools.R , but I'm not sure what it's doing there. 'symbols.rds' shows up in the SVN log here: r58591 | ripley | 2012-03-05 07:25:58 -0500 (Mon, 05 Mar 2012) | 1 line treat non-symbols.rds reports on

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

I ran into an interesting error unserializing a file created with ascii=TRUE: R 3.5.1 (Windows or Linux): > unserialize(serialize(list(raw=as.raw(c(39,41))), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(raw = as.raw(c(39, 41))), NULL, version = 2, : ReadItem: unknown type 29, perhaps written by later version of R The same error happens when the

Hi, I would like to be able to create new environments from package C code. AFAICT, this isn't allowed since both NewEnvironment and R_NewHashedEnv are declared in Defn.R. If exposing this isn't controvertial, I would submit a patch. However, I'm not sure where the declarations should go (Rdefines.h?) and whether they need to change to Rf_*. + seth