Re: [Rd] Rtools and R 4.0.0?
On 02/04/2020 05:35, Kevin Ushey wrote: 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)? Short answer: 'no'. 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 packages) I'd be happy to try and help. It is still under consideration, but resource constraints are biting hard as people's lives get more complicated. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and R 4.0.0?
Hi Kevin, On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey 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 such a place for multiple years) is that many coproprate or otherwise controlled compute environments may not have access to a c++17 compiler on their servers so making it easy for packages to rely on that is not purely beneficial to all parts of the R community. Not saying that should heavily inform this decision, just wanted to throw that out there since the topic came up. Personally if R packages are making the switch all the way up to 17 this soon I have to say i'm glad I got out of the R administration game. I don't have anything to add about the toolchain update discussions , though from what Prof Ripley said I guess they are ongoing. ~G > > Thanks, > Kevin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On Mon, 6 Apr 2020 at 04:59, Paul Murrell wrote: > > Hi > > The R branch ... > > https://svn.r-project.org/R/branches/R-symfam/ > > ... is now set up so that it works "out of the box" on Fedora by setting > the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)' > when grSoftVersion()["pango"] is greater than "1.44". That is awesome, thanks! Will you port this to the R-3-6-branch? -- Iñaki Úcar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and R 4.0.0?
On Mon, Apr 6, 2020 at 9:15 AM Prof Brian Ripley wrote: > > On 02/04/2020 05:35, Kevin Ushey wrote: > > 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)? > > Short answer: 'no'. > > >>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 packages) > > I'd be happy to try and help. > > It is still under consideration, but resource constraints are biting > hard as people's lives get more complicated. Given the amount of work that has gone into this and the importance of an up-to-date toolchain for maintaining well-functioning and current system libraries and R packages, I think it should be considered to delay the R 4.0 release over this until everyone is ready. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and R 4.0.0?
On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker wrote: > > Hi Kevin, > > On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey 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 such a > place for multiple years) is that many coproprate or otherwise controlled > compute environments may not have access to a c++17 compiler on their > servers so making it easy for packages to rely on that is not purely > beneficial to all parts of the R community. No, you're missing an important point here. On Windows, the toolchain version is tied to the version of R and we try to keep supporting at least one or two previous versions of R. So this means we always need to support the legacy toolchain for a while as well. Hence if we switch Windows to gcc-8 for R 4.0, we still rely on gcc-4.9 for continued support of R 3.3-3.6. This lag is what is making the maintenance of windows system libraries painful, and why we need to plan ahead. This is different from Linux where version of the compiler is given by the OS and not tied to the version of R. If we would miss the boat again, and R 4.0 on Windows would stick with gcc-49, this means we need to keep supporting gcc-49 as long as we want to support R-4.0, which is at least 2022 or 2023. This would be pretty bad. Even currently the latest versions of important system libraries used by R packages (e.g. the gdal stack) require recent compilers and cannot be built anymore with gcc-49. As more C++ projects are adopting C++14/17, we can no longer update these system libraries, missing out on all upstream fixes and advances. This would seriously decrement the quality of the R ecosystem. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and R 4.0.0?
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 no c++ code in it at all I believe. Best, ~G On Mon, Apr 6, 2020 at 5:38 AM Jeroen Ooms wrote: > On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker > wrote: > > > > Hi Kevin, > > > > On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey 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 such a > > place for multiple years) is that many coproprate or otherwise controlled > > compute environments may not have access to a c++17 compiler on their > > servers so making it easy for packages to rely on that is not purely > > beneficial to all parts of the R community. > > No, you're missing an important point here. On Windows, the toolchain > version is tied to the version of R and we try to keep supporting at > least one or two previous versions of R. So this means we always need > to support the legacy toolchain for a while as well. > > Hence if we switch Windows to gcc-8 for R 4.0, we still rely on > gcc-4.9 for continued support of R 3.3-3.6. This lag is what is making > the maintenance of windows system libraries painful, and why we need > to plan ahead. This is different from Linux where version of the > compiler is given by the OS and not tied to the version of R. > > If we would miss the boat again, and R 4.0 on Windows would stick with > gcc-49, this means we need to keep supporting gcc-49 as long as we > want to support R-4.0, which is at least 2022 or 2023. This would be > pretty bad. Even currently the latest versions of important system > libraries used by R packages (e.g. the gdal stack) require recent > compilers and cannot be built anymore with gcc-49. As more C++ > projects are adopting C++14/17, we can no longer update these system > libraries, missing out on all upstream fixes and advances. This would > seriously decrement the quality of the R ecosystem. > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On 6/04/20 8:21 pm, Iñaki Ucar wrote: On Mon, 6 Apr 2020 at 04:59, Paul Murrell wrote: Hi The R branch ... https://svn.r-project.org/R/branches/R-symfam/ ... is now set up so that it works "out of the box" on Fedora by setting the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)' when grSoftVersion()["pango"] is greater than "1.44". That is awesome, thanks! Will you port this to the R-3-6-branch? I'll be very pleased if I can get this merged in time for R 4.0.0. I am not sure if there will be any further patch releases in the R 3.6 series. That would require wider discussion within R-core. Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
