similar to: socket problems (maybe bugs?)

R Gurus / Ninjas / Wizards: On both R 2.12 (Windows 7) and R 2.13 (OS X 10.5) I have tried the following: 1. In one instance of R open a socket via: s1 <- socketConnection(server=TRUE, open="a+b", port=31415, blocking=FALSE); 2. And in another instance I do the following: s2 <- socketConnection(open="a+b", port=31415, blocking=FALSE); And so I

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

There's something weird going on for certain non-integer values of argument 'timeout' to base::socketSelect(). For such values, there is no timeout and you effectively end up with an infinite timeout. I can reproduce this on R 3.3.1 on Ubuntu 16.04 and RedHat 6.6, but not on Windows (via Linux Wine). # 1. In R master session > con <- socketConnection('localhost', port

Fixed in 73470 Best, Tomas On 10/05/2017 06:11 AM, Henrik Bengtsson wrote: > I'd like to follow up/bump the attention to this bug causing the > timeout to fail for socketSelect() on Unix. It is still there in R > 3.4.2 and R-devel. I've identified the bug in the R source code - the > bug is due to floating-point precisions and comparison using >=. See > PR17203

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

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

On 2/15/23 01:24, Ben Engbers wrote: > Hi, > > December 27, 2021 I started a thread asking for help troubleshooting > non-blocking sockets. > While developing the RBaseX client, I had issues with the > authentication process. It eventually turned out that a short break > had to be inserted in this process between sending the credentials to > the server and requesting

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

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"

I'd like to follow up/bump the attention to this bug causing the timeout to fail for socketSelect() on Unix. It is still there in R 3.4.2 and R-devel. I've identified the bug in the R source code - the bug is due to floating-point precisions and comparison using >=. See PR17203 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17203) for details and a patch. I've just

Hola: Para el desarrollo del nuevo PluginR de Tiki (para poder ejecutar scripts de R desde Tiki: en páginas Wiki, hojas de cálculo web, etc, http://dev.tiki.org/PluginR ), por ahora estamos usando la lista de funciones que se usaban en el proyecto r-php, y que fueran heredadas por la extensión R de MediaWiki. Como r-php se hizo hace algunos años (2006), me pregunto si alguien sabe si hay

problem of the very large memory require by the Sign extension. --- R-2.5.0.orig/src/main/serialize.c 2007-03-27 01:42:08.000000000 +0900 +++ R-2.5.0/src/main/serialize.c 2007-06-25 00:48:58.000000000 +0900 @@ -1866,7 +1866,7 @@ static void resize_buffer(membuf_t mb, int needed) { - int newsize = 2 * needed; + size_t newsize = 2 * needed; mb->buf = realloc(mb->buf,

Full_Name: Johnny Accot Version: 1.5.1 OS: Linux Submission from: (NULL) (198.4.83.52) Hi. I'm having a problem with the binary read/write functions. I'm writing a device driver in R (why not?) and of course I have to send a couple commands to the device. Typically, I send one byte, receive one acknowledgement byte, send another byte, receive an ACK, and so on. At least this is what

I am writing a function to make a multi-part form request with binary data. I am running R 1.8.1 on Linux ReadHat. The sockectConnection is initialized with open="a+b" and blocking=TRUE. After writing the Post request using writeChar and writeBin and flushing the connection I use socketSelect to check if the socketConnection is availabe for reading. This call consistently takes 15

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}} +

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

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;