similar to: Rtools and R 4.0.0?

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

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

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

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

Jeroen, Sorry, I was unclear. I'm not arguing against switching tot the new windows tool chain. Without being involved or knowing the details of any remaining difficulties, I am de facto for that. I was specifically responding to the prospect of R packages moving to directly rely on c++17 this quickly, which Kevin brought up. R itself obviously won't be relying on c++17 since there is

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 > easier for CRAN packages to depend on the newer C++ standard. > One thing to keep in mind (having been the R installation owner in

Thanks Jeroen! > On Tue, Apr 7, 2020 at 6:07 PM Kevin Ushey <kevinushey at gmail.com> wrote: >> >> Regardless, I would like to thank R core, CRAN, and Jeroen for all of >> the time that has gone into creating and validating this new >> toolchain. This is arduous work at an especially arduous time, so I'd >> like to voice my appreciation for all the time

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

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, If I am not mistaken, all Rtools 4.2 (and 4.3) revisions have the same ARP [1] entries, i.e. all report version 4.2.0.1 (or 4.3.0.1). This makes it difficult to determine the installed version (is it possible to determine the installed revision?) and impossible for tools like winget [2] to update Rtools to the latest revision, AFAICT. Would it be possible to track the version in the

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

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

Is there a way to get the status code of a pipe() command? The documentation suggests that it might be returned by close, however this does not seem to be the case. con <- pipe("cat /etc/passwd", "r") stream <- readLines(con, n = 10) err <- close(con) print(err)

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

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 >

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