From j@me@@|@he@ter @end|ng |rom gm@||@com  Thu May  7 15:02:57 2020
From: j@me@@|@he@ter @end|ng |rom gm@||@com (Jim Hester)
Date: Thu, 7 May 2020 09:02:57 -0400
Subject: [Rd] defining r audio connections
In-Reply-To: <CAFDcVCQbGvzovVaN_5TF=aFYxFWAr+=5x0dXw6jXYxRtswVNVw@mail.gmail.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>
 <CAFDcVCQbGvzovVaN_5TF=aFYxFWAr+=5x0dXw6jXYxRtswVNVw@mail.gmail.com>
Message-ID: <CAD6tx94ab9--UdNsRAd2KVxL8P3bmBv-=AYi8+BsdM7f_Rf7_A@mail.gmail.com>

https://github.com/jimhester/archive was not allowed on CRAN when I
submitted it 3 years ago due to this restriction.

Being able to write custom connections is a useful feature for a number of
applications, I would love this policy to be reconsidered.

On Wed, May 6, 2020 at 10:30 PM Henrik Bengtsson <henrik.bengtsson at gmail.com>
wrote:

> 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]]
>
> ______________________________________________
> 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
Jim Hester