similar to: defining r audio connections

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

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

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

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

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;

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.

Dear R Gurus, for some purpose i have to use a socket connection, where i have to read and write both text and binary data (each binary data package will be preceeded by a header line). When experimenting, i encountered some problems (with R-2.0.1 under different Linuxes (SuSE and Gentoo)). Since the default mode for socket connections is non-blocking, i first tried socketSelect() in order to

R-devel: I am encountering a consistency issue using socketConnection and readBin with *non-blocking* connections on Unix and Windows XP (no Vista to test). I am a bit confused by the behavior of *non-blocking* connections under Windows specifically. When calling readBin on a non-blocking connection when there is no data to read on the socket, the connection under Unix will return a vector of

Full_Name: Ken Yap Version: 1.6.1 OS: Linux (SuSE 8.0) Submission from: (NULL) (129.78.64.5) I'm trying to copy a file using readBin and writeBin. (The reason is to be able to pipe PostScript or PDF output to a socket later, this is just an experiment.) I do: zz <- file("foo.ps", "rb") r <- readBin(zz, character(), 1000000) yy <- file("bar.ps",

Hi R-Devel, I've been working on an oscilloscope project using an Arduino microcontroller board. I found that it's quite easy to get realtime updates, e.g. 30+ frames per second, if I read data from the board in a little Rcpp library. I have to use dev.hold() and dev.flush() to keep the plot from flickering, which restricts me to the "cairo" X11 device. I'd like to be able

Hello, I am trying to write some code in R to communicate over sockets via the STOMP protocol (http://stomp.codehaus.org/Protocol). As you can see, a null byte (ASCII 0) is used as the "over" signal. I'd like to be able to do something like this: write.socket(socket, "CONNECT\nlogin: me\npasscode: pass\n\n\000") However, R does not like it when you put "\000"

Hi all, I wrote a function (in R batch mode) which reads binary data, interpolates sometimes and wrote a new binary file of the same size as the input file. Her is a bit of code: while (length( head <- readBin(si, integer(), 64, size=2))) { data <- readBin(si, integer(), head[5], size=2) ## now write head to new file writeBin(head, so, size=2) ## if head[4] is 9 or

To me it seems like writeBin() writes one char/byte more than expected. > con <- file("testbin", "wb") > writeBin("ttccggaa", con) > close(con) > con <- file("testbin", "rb") > readBin(con, what="character") [1] "ttccggaa" > seek(con, what=NA) [1] 9 > close(con) > con <-

Hi Frederik, >>>>> <frederik at ofb.net> >>>>> on Tue, 7 Jun 2016 15:20:05 -0700 writes: > ... I just realized that setGraphicsEventHandlers or > getGraphicsEvent could have an 'onIdle' callback, to be > called somewhere in the polling loop of gevents.c:163 - I > think this would solve my problem #2 in a minimally

Ah, thank you for that explanation. I somehow didn't catch that my Bugzilla account had been disabled by a human. "Common pattern is to post ... something copied from a generic bug report" - that sounds very annoying. Frederick On Sun, Feb 07, 2016 at 11:54:11AM +0100, peter dalgaard wrote: > Unfortunately, the spammers in question appear to be human (of sorts). > >

Hello R devel/help, I ran into this strange behavior: # showstack is supposed to walk through the stack of parent # environments when it is called: showstack = function() { env = environment() for(i in 1:12) { env = do.call(parent.frame, list(), env=env) print(env) } } # a simple chain of functions: g3=function(t) showstack()

Hello R devel/help, I ran into this strange behavior: # showstack is supposed to walk through the stack of parent # environments when it is called: showstack = function() { env = environment() for(i in 1:12) { env = do.call(parent.frame, list(), env=env) print(env) } } # a simple chain of functions: g3=function(t) showstack()

Hi, The latest version of R had some changes to functions "readbin() and writeBin() [which] now support raw vectors as well as filenames and connections.". As a result I am working on retiring "raw2bin" and "bin2raw" functions from "caTools" package which do exactly the same. Thanks to Prof. Ripley for bringing this change to my attention. Which brings me

Hi, The man page for readBin has a small typo: --- a/src/library/base/man/readBin.Rd +++ b/src/library/base/man/readBin.Rd @@ -58,7 +58,7 @@ writeBin(object, con, size = NA, endian \code{readBin} and \code{writeBin} read and write C-style zero-terminated character strings. Input strings are limited to 10000 - characters. \code{\link{readChar}} and \code{\code{writeChar}} +

Thanks Frederick. Mark, if you have any examples to share, they would also be gratefully received. Paul On 14/11/16 14:53, frederik at ofb.net wrote: > Hi Paul, > > OK I tried not to make the examples too fancy. > > Please let me know what you think. They should probably be amended to > support the Windows platform, but I think that task would be much > easier for someone