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
