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