On Wed, May 06, 2020 at 02:26:34PM -0400, Duncan Murdoch wrote:
On 06/05/2020 1:09 p.m., frede...@ofb.net wrote:
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
The custom connections API was specifically introduced to allow packages to
create custom connections back in 2013. Its sole purpose is to allow package
authors to create new connections outside of base R, so I don't see why
packages using it shouldn't be allowed on CRAN. However, it is solely a
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 Bengts
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
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
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 wrote:
>
> The public connection API is defined in
>
> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
>
>
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://gi
On 06/05/2020 1:09 p.m., frede...@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
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
