similar to: long vector support

>>>>> Will L >>>>> on Fri, 6 Dec 2019 16:02:59 -0500 writes: > All, At first glance, a recent commit to R-devel ( > https://github.com/wch/r-source/commit/2c182014ecc8c2407a89092c9162d86046bd18da) > appears to be related to long vector support. yes, for a very limited case, with a very nice minimal reproducible example and proper R bug

The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy Night") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter

The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy Night") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter

The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy Night") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter

It is not obvious what it is that you are calling "R-patched", nor where there could be an entry for "3.6.2 patched". The prerelease/patched versions are snapshots of R-3-6-branch made at 00:20 so the current one will have been made before the release version run started at 09:00 this morning, and hence the nightly tarball will be of the release candidate. However it will not

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

I am trying to open an existing binary file, seek to a position in the middle, and then write one byte, while keeping the already existing data after that byte. It seems to me that I am unable to open a connection to a binary file in both read and write mode. I can open the "r+b" binary file connection and seek around, but I can't write to the file. And looking at the function

Dear all, I have written a little R program to convert images. See below. Within the loop over j (the filenames) memory consumption grows constantly. rm( ... ) inside the loop did not help. Memory does not grow if I remove the writeBin statements between the two #-------- marks. But obviously this is not solution I want... Thanks for any advice. Manfred Baumstark P.S. As I'm new to R:

Thanks, Kurt. I think I now have enough time to write a patch. What are the steps? I have read https://www.r-project.org/bugs.html#how-to-submit-patches but I do not seem to have permission to create a Bugzilla account at https://bugs.r-project.org/bugzilla/. Will On Mon, Nov 12, 2018 at 2:46 AM Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote: > >>>>> Will L writes: >

To R-devel, In `R CMD build`, the ID of the user is automatically inserted into the DESCRIPTION file, e.g. Packaged: 2018-11-06 14:01:50 UTC; <MY USER ID> This is problematic for those of us who work in corporate settings. We must not divulge our user IDs in the packages we develop and release. Jim Hester pointed out that these two lines in `add_build_stamp_to_description_file()`

Hi, all, I have 2 questions about signal handling in R. Would you pls help give me some suggestions? Many thanks! [How to block the signal in one R function]: If one R function hopes to be running without interrupting, how can we avoid this? To be more specific, for one R function "func1", it will do a loop to send messages to another R process, and receive responses from peers. How

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

AFAIK there is no hashing utility in base R which can create hash digests of arbitrary R objects. However, as also described by Henrik Bengtsson in [1], we have tools::md5sum() which calculates MD5 hashes of files. Calculating hashes of in-memory objects is a very common task in several areas, as demonstrated by the popularity of the 'digest' package (~850.000 downloads/month). Upon

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

Here's an update of my rawConnection() implementation. In addition to providing a raw version of textConnection(), this fixes two existing issues with textConnection(): one is that the current textConnection() implementation carries around unprotected SEXP pointers, the other is a performance problem due to prolific copying of the output buffer as output is accumulated line by line. This new

Is there any way to write (8-bit) bytes to a file which works on all [R] platforms? I have been looking at 1) writeBin 2) writeChar 3) cat and neither of them manage to write arbitrary sequences of bytes (0-255). For instance, I would like to create a binary file of length three containing the bytes 0, 1 and 0. I [R] I have the following vector of bytes: bfr <- c(0,1,0) 1) For

Hi all, I'm having problems trying to export binary arrays from R and importing them into fortran (linux openSUSE 10.3 (x86_64), gfortran compiler, fortran 90/95 program). Let's say the problem can be expressed as: R part ------------ >whini <- runif(1000) >writeBin(whini,"fwhini.dat") f90 part ------------ PROGRAM foo INTEGER, PARAMETER :: DP = KIND(1.0D0) INTEGER ::

On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when adding NA and NaN: > NA_real_ + NaN [1] NaN > NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for

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