similar to: Reading exit code of pipe()

The difference in the return value of close(pipeConnectionObject) seems to depend on whether the pipe connection was opened via the pipe() or open() functions (close() returns NULL) > con <- pipe("ls") > open(con, "r") > readLines(con, n=1) [1] "1032.R" > print(close(con)) NULL > con <- pipe("ls", "r")

>>>>> Jeroen Ooms <jeroenooms at gmail.com> >>>>> on Wed, 20 Jul 2016 10:26:19 +0200 writes: > On Tue, Jul 19, 2016 at 6:46 PM, Kevin Ushey <kevinushey at gmail.com> wrote: >> R fails to install a package from source over a pre-existing package >> when the path to that package is a symlink, rather than a directory.

Hevr? told me that people from Bioconductor and possibly others are keeping an eye on this thread so it would be good to post a note here too. As of version 4.0.0, the official R for Windows and binary packages provided via CRAN are built with gcc-8.3.0 from rtools40, as shown in the CRAN check table: https://cran.r-project.org/web/checks/check_flavors.html Instructions and installers for

On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker <gabembecker at gmail.com> wrote: > > Hi Kevin, > > On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey <kevinushey at gmail.com> wrote: > > > Hello, > > > > FWIW, I'm excited at the prospect at seeing a new toolchain for > > Windows, since it would imply support for C++17 and so it would become > >

R fails to install a package from source over a pre-existing package when the path to that package is a symlink, rather than a directory. A reproducible example to illustrate (using MASS as an example): # create a temporary R library in tempdir library <- tempfile() if (!dir.exists(library)) dir.create(library) # symlink MASS from system library to temporary library MASS

On Thu, Feb 15, 2018 at 11:19 AM, Kevin Ushey <kevinushey at gmail.com> wrote: > I suspect your UTF-8 string is being stripped of its encoding before > write, and so assumed to be in the system native encoding, and then > re-encoded as UTF-8 when written to the file. You can see something > similar with: > > > tmp <- '?' > > tmp <- iconv(tmp,

Huge thanks to you (Jeroen) and R-core for doing this. I wasn't involved with this directly but I know it was a pretty seriously heavy list so well done all around! ~G On Tue, Apr 28, 2020, 11:04 AM Herv? Pag?s <hpages at fredhutch.org> wrote: > Thanks Jeroen! > > > On Tue, Apr 7, 2020 at 6:07 PM Kevin Ushey <kevinushey at gmail.com> wrote: > >> >

Of course, right after writing this e-mail I tested on my Windows machine and did not see what I expected: > charToRaw(before) [1] c3 a9 > charToRaw(after) [1] e9 so obviously I'm misunderstanding something as well. Best, Kevin On Sat, Feb 17, 2018 at 2:19 PM, Kevin Ushey <kevinushey at gmail.com> wrote: > From my understanding, translation is implied in this line of ?file

There appears to have been some progress on this matter: -Note that @command{g++} 4.9.x (as used for @R{} on Windows up to 3.6.x) +Note that @command{g++} 4.9.x (as used on Windows prior to @R{} 4.0.0) See SVN commit r78169 titled 'anticipate change in Windows toolchain', or the mirrored git commit at https://github.com/wch/r-source/commit/bd674e2b76b2384169424e3d899fbfb5ac174978 Dirk

On Sat, 13 Apr 2019 at 03:51, Kevin Ushey <kevinushey at gmail.com> wrote: > > I think it's worth saying that mclapply() works as documented Mostly, yes. But it says nothing about fork's copy-on-write and memory overcommitment, and that this means that it may work nicely or fail spectacularly depending on whether, e.g., you operate on a long vector. -- I?aki ?car

Hello, Has a decision been made yet as to whether R 4.0.0 on Windows is going to be built using the new gcc8 toolchain (described at https://cran.r-project.org/bin/windows/testing/rtools40.html)? >From the sidelines, I can see that the toolchain is being used to build and test packages on CRAN; if there are any remaining issues that I can help to try and run down (either in R or any CRAN

I should add one more item that may be related here -- calling 'methods:::.requirePackage' returns a different result based on whether the package namespace is already loaded or not. If the package namespace is not loaded, the package is loaded and attached, and the package environment is returned: > methods:::.requirePackage("digest") Loading required package:

(Just returning from the "wilds" of Canada, so not able to comment on the specifics, but ...) There is a basic point about generic functions that may be related to the "private" class question and my earlier remarks that Martin alluded to. R (and S4 before it) allows packages to define methods for a generic function in another package. Say, for plot() in graphics. The

In fact, this does reproduce on R-devel: > options(download.file.method = "libcurl") > options(repos = c(CRAN = "https://cran.rstudio.com/", CRANextra = + "http://www.stats.ox.ac.uk/pub/RWin")) > install.packages("lattice") ## could be any package Installing package into ?/Users/kevinushey/Library/R/3.3/library? (as ?lib? is

One other solution that's only a little crazy: you could have a R function within your package that generates the appropriate (portable) Makevars, and within the package `configure` script call that function. For example" R --vanilla --slave -e "source('R/makevars.R'); makevars()" And that 'makevars()' function could generate portable

Hi, (sorry for the wall of text; the issue here appears to be rather complicated) I'm seeing a somewhat strange case where checking whether an S4 object inherits from a parent class defined from another package with 'inherits' fails if that object is materialized through a call to 'load'. That's a mouthful, so I've put together a relatively small reproducible example

Hi Martin, Indeed it does (and I should have confirmed myself with R-patched and R-devel before posting...) Thanks, and sorry for the noise. Kevin On Tue, Aug 25, 2015, 13:11 Martin Morgan <mtmorgan at fredhutch.org> wrote: > On 08/25/2015 12:54 PM, Kevin Ushey wrote: > > Hi all, > > > > The following fails for me (on OS X, although I imagine it's the same >

On Mon, 15 Apr 2019 at 08:44, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 4/13/19 12:05 PM, I?aki Ucar wrote: > > On Sat, 13 Apr 2019 at 03:51, Kevin Ushey <kevinushey at gmail.com> wrote: > >> I think it's worth saying that mclapply() works as documented > > Mostly, yes. But it says nothing about fork's copy-on-write and memory >

Bugzilla issue 16101 describes another first-list-name-printed-differently oddity with the Windows GUI version of R: > a <- "One is \u043E\u0434\u0438\u043D\nTwo is \u0434\u0432\u0430\n" > Encoding(a) # expect "UTF-8" [1] "UTF-8" > sapply(strsplit(a, "\n")[[1]], charToRaw)[c(1,1,2)] $`One is ????` [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0 [13] b8

IMHO, if base R were to include a pipe operator, I think it should be much simpler than the magrittr pipe. It should satisfy the property that: x |> f(...) is equivalent to f(x, ...) Except, perhaps, in terms of when the promise for 'x' gets forced. We shouldn't need to mess with bindings in environments to make that work. My understanding is that the '.'