From henr|k@bengt@@on @end|ng |rom gm@||@com  Thu May  7 04:30:15 2020
From: henr|k@bengt@@on @end|ng |rom gm@||@com (Henrik Bengtsson)
Date: Wed, 6 May 2020 19:30:15 -0700
Subject: [Rd] defining r audio connections
In-Reply-To: <BL0PR04MB6609075FFBD291823005B023F9A40@BL0PR04MB6609.namprd04.prod.outlook.com>
References: <20200506170919.GA34684@localhost>
 <d6158363-d59a-3fa9-7ccd-0a80985094ab@gmail.com>
 <BL0PR04MB6609459170C7D73F98768D17F9A40@BL0PR04MB6609.namprd04.prod.outlook.com>
 <CABtg=Kk+AeZ4TzUFZFD4t5f6RCcs2F0SXF_Cx1TCS2_FnxbYPQ@mail.gmail.com>
 <BL0PR04MB6609075FFBD291823005B023F9A40@BL0PR04MB6609.namprd04.prod.outlook.com>
Message-ID: <CAFDcVCQbGvzovVaN_5TF=aFYxFWAr+=5x0dXw6jXYxRtswVNVw@mail.gmail.com>

What's the gist of the problem of making/having this part of the public
API? Is it security, is it stability, is it that the current API is under
construction, is it a worry about maintenance load for R Core, ...? Do we
know why?

It sounds like it's a feature that is  useful. I think we missed out on
some great enhancements in the past because of it not being part of the
public API.

/Henrik

On Wed, May 6, 2020, 16:26 Martin Morgan <mtmorgan.bioc at gmail.com> wrote:

> yep, you're right, after some initial clean-up and running with or without
> --as-cran R CMD check gives a NOTE
>
>   *  checking compiled code
>   File ?socketeer/libs/socketeer.so?:
>     Found non-API calls to R: ?R_GetConnection?,
>        ?R_new_custom_connection?
>
>   Compiled code should not call non-API entry points in R.
>
>   See 'Writing portable packages' in the 'Writing R Extensions' manual.
>
> Connections in general seem more useful than ad-hoc functions, though
> perhaps for Frederick's use case Duncan's suggestion is sufficient. For
> non-CRAN packages I personally would implement a connection.
>
> (I mistakenly thought this was a more specialized mailing list; I wouldn't
> have posted to R-devel on this topic otherwise)
>
> Martin Morgan
>
> ?On 5/6/20, 4:12 PM, "G?bor Cs?rdi" <csardi.gabor at gmail.com> wrote:
>
>     AFAIK that API is not allowed on CRAN. It triggers a NOTE or a
>     WARNING, and your package will not be published.
>
>     Gabor
>
>     On Wed, May 6, 2020 at 9:04 PM Martin Morgan <mtmorgan.bioc at gmail.com>
> wrote:
>     >
>     > The public connection API is defined in
>     >
>     >
> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
>     >
>     > I'm not sure of a good pedagogic example; people who want to write
> their own connections usually want to do so for complicated reasons!
>     >
>     > This is my own abandoned attempt
> https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192
> where connection_local_client() is called from R and _connection_local()
> creates and populates the appropriate structure. Probably I have done
> things totally wrong (e.g., by not checking the version of the API, as
> advised in the header file!)
>     >
>     > Martin Morgan
>     >
>     > ?On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <
> r-devel-bounces at r-project.org on behalf of murdoch.duncan at gmail.com>
> wrote:
>     >
>     >     On 06/05/2020 1:09 p.m., frederik at ofb.net wrote:
>     >     > Dear R Devel,
>     >     >
>     >     > Since Linux moved away from using a file-system interface for
> audio, I think it is necessary to write special libraries to interface with
> audio hardware from various languages on Linux.
>     >     >
>     >     > In R, it seems like the appropriate datatype for a `snd_pcm_t`
> handle pointing to an open ALSA source or sink would be a "connection".
> Connection types are already defined in R for "file", "url", "pipe",
> "fifo", "socketConnection", etc.
>     >     >
>     >     > Is there a tutorial or an example package where a new type of
> connection is defined, so that I can see how to do this properly in a
> package?
>     >     >
>     >     > I can see from the R source that, for example, `do_gzfile` is
> defined in `connections.c` and referenced in `names.c`. However, I thought
> I should ask here first in case there is a better place to start, than
> trying to copy this code.
>     >     >
>     >     > I only want an object that I can use `readBin` and `writeBin`
> on, to read and write audio data using e.g. `snd_pcm_writei` which is part
> of the `alsa-lib` package.
>     >
>     >     I don't think R supports user-defined connections, but probably
> writing
>     >     readBin and writeBin equivalents specific to your library
> wouldn't be
>     >     any harder than creating a connection.  For those, you will
> probably
>     >     want to work with an "external pointer" (see Writing R
> Extensions).
>     >     Rcpp probably has support for these if you're working in C++.
>     >
>     >     Duncan Murdoch
>     >
>     >     ______________________________________________
>     >     R-devel at r-project.org mailing list
>     >     https://stat.ethz.ch/mailman/listinfo/r-devel
>     > ______________________________________________
>     > R-devel at r-project.org mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



[Rd] defining r audio connections
Henrik Bengtsson