<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>The R Blog</title>
    <link>https://blog.r-project.org/</link>
    <description>Recent content on The R Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 17 Jan 2018 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://blog.r-project.org/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>S at 50</title>
      <link>https://blog.r-project.org/2026/05/05/s-at-50/</link>
      <pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2026/05/05/s-at-50/</guid>
      <description>Today marks 50 years since Rick Becker and John Chambers presented a new project to a few of their colleagues in Statistics and Data Analysis research at Bell Labs. John writes:
 It had no name and we were unsure what it was, exactly. A few months later it was named S, initially called an interactive environment. Only a revised version was referred to as a language. (Lately I’ve been labelling it R Version 0.</description>
    </item>
    
    <item>
      <title>Debugging Sensitivity to C math library on Linux</title>
      <link>https://blog.r-project.org/2026/01/30/debugging-sensitivity-to-c-math-library-on-linux/</link>
      <pubDate>Fri, 30 Jan 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2026/01/30/debugging-sensitivity-to-c-math-library-on-linux/</guid>
      <description>C math library functions, such as exp or sin, are not guaranteed to be “precise”. The results might be slightly different on different platforms. A recent change in mingw-w64 v12, which is a core dependency of compilers we use on Windows (both GCC and LLVM), resulted in failures in about 20 CRAN packages. Rtools45 uses mingw-w64 v11, the same version as Rtools44, to allow time for resolving the issues. The change in mingw-w64 v12 switched about 90 math functions from internal implementations to UCRT, the Windows C runtime provided by Microsoft and shipped with the OS.</description>
    </item>
    
    <item>
      <title>Debugging Sensitivity to C math library and mingw-w64 v12</title>
      <link>https://blog.r-project.org/2026/01/06/debugging-sensitivity-to-c-math-library-and-mingw-w64-v12/</link>
      <pubDate>Tue, 06 Jan 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2026/01/06/debugging-sensitivity-to-c-math-library-and-mingw-w64-v12/</guid>
      <description>C math library functions, such as exp or sin, are not guaranteed to be “precise”. The results might be slightly different on different platforms. A recent change in mingw-w64 v12, which is a core dependency of compilers we use on Windows (both GCC and LLVM), resulted in failures in about 20 CRAN packages. Rtools45 uses mingw-w64 v11, the same version as Rtools44, to allow time for resolving the issues. The change in mingw-w64 v12 switched about 90 math functions from internal implementations to UCRT, the Windows C runtime provided by Microsoft and shipped with the OS.</description>
    </item>
    
    <item>
      <title>RSMF: Enabling the Next Generation of Contributors to R</title>
      <link>https://blog.r-project.org/2025/12/17/rsmf-enabling-the-next-generation-of-contributors-to-r/</link>
      <pubDate>Wed, 17 Dec 2025 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2025/12/17/rsmf-enabling-the-next-generation-of-contributors-to-r/</guid>
      <description>The Software Sustainability Institute (UK) has awarded a grant of £500k (~650k USD) under the Research Software Maintenance Fund, to the project Enabling the Next Generation of Contributors to R.
The project is co-led by research software engineers at the University of Birmingham (Heather Turner and Ella Kaye), members of the R Core Team (Simon Urbanek and Peter Dalgaard), and a team of academic/freelance R developers (Gabe Becker, Kylie Bemis, Mikael Jagan, Jeroen Ooms).</description>
    </item>
    
    <item>
      <title>Reducing the Backlog of Open Bug Reports</title>
      <link>https://blog.r-project.org/2025/10/13/reducing-the-backlog-of-open-bug-reports/</link>
      <pubDate>Mon, 13 Oct 2025 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2025/10/13/reducing-the-backlog-of-open-bug-reports/</guid>
      <description>The number of open bug reports in the R bug tracker has been reduced by about 25% during August and September this year. This work has been possible thanks to an investment of the Sovereign Tech Fund.
Urgent bug reports that are easily reproducible, ideally coming with a small reproducible example, are typically resolved quickly. Other bugs, however, can remain open for a long time. As the backlog grows in size, it becomes hard to navigate, even though it still contains some real bugs experienced by users.</description>
    </item>
    
    <item>
      <title>Sensitivity to C math library and mingw-w64 v12 - part 2</title>
      <link>https://blog.r-project.org/2025/05/21/sensitivity-to-c-math-library-and-mingw-w64-v12-part-2/</link>
      <pubDate>Wed, 21 May 2025 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2025/05/21/sensitivity-to-c-math-library-and-mingw-w64-v12-part-2/</guid>
      <description>C math library functions, such as exp or sin, are not guaranteed to be “precise”. The results might be slightly different on different platforms. A recent change in mingw-w64 v12, which is a core dependency of compilers we use on Windows (both GCC and LLVM), resulted in failures in about 20 CRAN packages. Rtools45 uses mingw-w64 v11, the same version as Rtools44, to allow time for resolving the issues. The change in mingw-w64 v12 switched about 90 math functions from internal implementations to UCRT, the Windows C runtime provided by Microsoft and shipped with the OS.</description>
    </item>
    
    <item>
      <title>Sensitivity to C math library and mingw-w64 v12</title>
      <link>https://blog.r-project.org/2025/04/24/sensitivity-to-c-math-library-and-mingw-w64-v12/</link>
      <pubDate>Thu, 24 Apr 2025 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2025/04/24/sensitivity-to-c-math-library-and-mingw-w64-v12/</guid>
      <description>C math library functions, such as exp or sin, are heavily used by R and packages. The C standard doesn’t require these functions to be “precise”. Instead, there is room for performance optimizations causing a reasonable amount of inaccuracy. The results differ between platforms and may change even on a single platform. This happened with mingw-w64 v12, the SDK/runtime used by GCC and LLVM on Windows, which reduced accuracy of many math functions (for performance and maintenance reasons).</description>
    </item>
    
    <item>
      <title>Alternative toolchains on Windows</title>
      <link>https://blog.r-project.org/2025/01/28/alternative-toolchains-on-windows/</link>
      <pubDate>Tue, 28 Jan 2025 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2025/01/28/alternative-toolchains-on-windows/</guid>
      <description>R and R packages on Windows, if they include native code, are built using compiler toolchain and libraries from Rtools. There is always a specific version of Rtools for a given version of R. Rtools44 is used for R 4.4.x, and hence R 4.4.x and packages for that version of R are always built with GCC 13.3 for x86_64 systems and with LLVM 17 for aarch64 systems. This is the case at least since Rtools42 (R 4.</description>
    </item>
    
    <item>
      <title>Problems with iconv on macOS</title>
      <link>https://blog.r-project.org/2024/12/11/problems-with-iconv-on-macos/</link>
      <pubDate>Wed, 11 Dec 2024 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2024/12/11/problems-with-iconv-on-macos/</guid>
      <description>For conversion of strings from a given character encoding to another, R uses iconv, a function defined by POSIX. It is available on Linux and macOS with the operating system and for Windows, R ships with a slightly customized version of win_iconv, which implements the same functionality on top of Windows API.
The differences between iconv implementations, partially allowed by a rather permissive definition of the interface in POSIX, pose a challenge for maintaining R and cause differences between platforms observed by users.</description>
    </item>
    
    <item>
      <title>Faster downloads</title>
      <link>https://blog.r-project.org/2024/12/02/faster-downloads/</link>
      <pubDate>Mon, 02 Dec 2024 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2024/12/02/faster-downloads/</guid>
      <description>Most R users would sometimes install or update R packages and hence are impacted by how long this takes. The parts of package installation that take potentially longest have already been addressed by support for binary packages and parallel installation. A remaining overhead that may be rather surprising, but is easy to reduce, is package download.
The overhead may be noticeable when installing many mostly small packages in parallel, because so far the package download has been sequential even with parallel installation.</description>
    </item>
    
    <item>
      <title>Long input lines</title>
      <link>https://blog.r-project.org/2024/08/30/long-input-lines/</link>
      <pubDate>Fri, 30 Aug 2024 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2024/08/30/long-input-lines/</guid>
      <description>When using R interactively via a console, one edits a line of input, confirms it by pressing ENTER, then R parses the line, evaluates it, prints the output and lets the user enter another line. This is also known as REPL (Read-Eval-Print-Loop).
The maximum length of the input line is sometimes limited. It is essentially impossible that one would run into a limit when typing the commands, but there was a report from a user who pasted generated content to the console and have ran into a limit of 4096 bytes.</description>
    </item>
    
    <item>
      <title>Generalizing Support for Functional OOP in R</title>
      <link>https://blog.r-project.org/2024/05/17/generalizing-support-for-functional-oop-in-r/</link>
      <pubDate>Fri, 17 May 2024 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2024/05/17/generalizing-support-for-functional-oop-in-r/</guid>
      <description>Generalizing Support for Functional OOP in R R has built-in support for two functional Object Oriented Programming (OOP) systems: S3 and S4, corresponding to the third and fourth version of the S language, respectively. The two systems are largely compatible; however, they are two fundamentally distinct systems, two systems for a user to understand, two systems for a developer to contend with when making their package interoperate with another, two systems for R core to maintain.</description>
    </item>
    
    <item>
      <title>Statement on CVE-2024-27322</title>
      <link>https://blog.r-project.org/2024/05/10/statement-on-cve-2024-27322/</link>
      <pubDate>Fri, 10 May 2024 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2024/05/10/statement-on-cve-2024-27322/</guid>
      <description>This is a brief statement on behalf or the R Core Team on the serialization bug recently reported by the cybersecurity form HiddenLayer. The bug has been reported as a vulnerability with id CVE-2024-27322.
R is a full-featured language that includes functions to interface with both the host operating system and the Internet. As with any such language, there are many ways to write code with malicious intent. Users should ensure that they only use R code and data from trusted sources and that the privileges of the account running R are appropriately limited.</description>
    </item>
    
    <item>
      <title>R on 64-bit ARM Windows</title>
      <link>https://blog.r-project.org/2024/04/23/r-on-64-bit-arm-windows/</link>
      <pubDate>Tue, 23 Apr 2024 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2024/04/23/r-on-64-bit-arm-windows/</guid>
      <description>R 4.4.0, to be released tomorrow, comes with experimental native support for 64-bit ARM Windows machines (aarch64, arm64). Rtools44 with native support for the platform has been released at the beginning of March.
The effort to add Windows/aarch64 support to R has been announced in August, 2023.
Installation R for Windows/aarch64 is distributed separately from the primary distribution for x86_64 (64-bit Intel machines). There is a special installer of R for Windows/aarch64.</description>
    </item>
    
    <item>
      <title>Will R Work on 64-bit ARM Windows?</title>
      <link>https://blog.r-project.org/2023/08/23/will-r-work-on-64-bit-arm-windows/</link>
      <pubDate>Wed, 23 Aug 2023 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2023/08/23/will-r-work-on-64-bit-arm-windows/</guid>
      <description>At WWDC 2023 earlier this year, Apple announced it completed transition from Intel to 64-bit ARM processors (Apple Silicon): no new machines with Intel processors will be offered. This was three years after the transition has been announced at WWDC 2020. The work on R support for the platform started the same year and was part of the next R release, R 4.1. See this blog post for details on initial experiments with R on the platform.</description>
    </item>
    
    <item>
      <title>(Not) interrupting background tasks with Ctrl&#43;C</title>
      <link>https://blog.r-project.org/2023/05/23/not-interrupting-background-tasks-with-ctrl-c/</link>
      <pubDate>Tue, 23 May 2023 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2023/05/23/not-interrupting-background-tasks-with-ctrl-c/</guid>
      <description>When using R interactively from the command line, one can interrupt the current computionation using Ctrl+C key combination and enter a new command. This works both on Unix terminal and on Windows console in Rterm. Such computation may be implemented in R or C and may be executing an external command while waiting for the result e.g. via system(,wait=TRUE).
However, in R 4.3 and earlier, Ctrl+C interrupts also background tasks, e.</description>
    </item>
    
    <item>
      <title>Path length limit on Windows</title>
      <link>https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/</link>
      <pubDate>Tue, 07 Mar 2023 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/</guid>
      <description>When testing development versions of Rtools for Windows, I’ve ran into strange failures of several CRAN packages where R could not find, read from or write to some files. The files should have been in temporary directories which get automatically deleted, so it took some effort to find out that actually they existed and were accessible. That didn’t make any sense at first, but eventually I got to this output:</description>
    </item>
    
    <item>
      <title>Issues While Switching R to UTF-8 and UCRT on Windows</title>
      <link>https://blog.r-project.org/2022/11/07/issues-while-switching-r-to-utf-8-and-ucrt-on-windows/</link>
      <pubDate>Mon, 07 Nov 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/11/07/issues-while-switching-r-to-utf-8-and-ucrt-on-windows/</guid>
      <description>From version 4.2.0 released in April 2022, R on Windows uses UTF-8 as the native encoding via UCRT as the new C Windows runtime. The transition for R and its packages has been a non-trivial effort which took several years. This post gives a summary some technical obstacles found on the way, focusing on aspects that may be interesting to other projects.
R specifics R is implemented in C and Fortran (and R).</description>
    </item>
    
    <item>
      <title>Sporadic Rterm Crashes with Completion</title>
      <link>https://blog.r-project.org/2022/11/01/sporadic-rterm-crashes-with-completion/</link>
      <pubDate>Tue, 01 Nov 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/11/01/sporadic-rterm-crashes-with-completion/</guid>
      <description>This post is a story of a bug in Rterm, the console R front-end on Windows, which has been bugging me for several years, but only two weeks ago it showed up unwarily so that I could trace it down and fix.
The terminal sometimes crashed during completion, so after I pressed the tab key, but it was very rare, there seemed to be no way to reproduce the problem, and it was only happening with the mintty terminal (from Msys2, running bash), never with cmd.</description>
    </item>
    
    <item>
      <title>Concordances</title>
      <link>https://blog.r-project.org/2022/10/20/concordances/</link>
      <pubDate>Thu, 20 Oct 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/10/20/concordances/</guid>
      <description>One of the strengths of R is its ability to help in producing documents. Sweave and knitr can work with .Rnw files, evaluating and automatically inserting the results of R code to produce a LaTeX document in a .tex file. We call this “preprocessing”, since the later steps were originally designed with the assumption that the .tex file was directly edited by the user and then processed to produce PDF or other output formats.</description>
    </item>
    
    <item>
      <title>Improvements in handling bytes encoding</title>
      <link>https://blog.r-project.org/2022/10/10/improvements-in-handling-bytes-encoding/</link>
      <pubDate>Mon, 10 Oct 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/10/10/improvements-in-handling-bytes-encoding/</guid>
      <description>In R, a string can be declared to be in bytes encoding. According to ?Encoding, it must be a non-ASCII string which should be manipulated as bytes and never converted to a character encoding (e.g. Latin 1, UTF-8). This text summarizes recent improvements in how R handles bytes encoded strings and provides some of thoughts about what they should and shouldn’t be used for today.
Character vector, string and encoding Particularly for readers not familiar with R, it may be useful to highlight how strings are supported in the language.</description>
    </item>
    
    <item>
      <title>R Can Use Your Help: Translating R Messages</title>
      <link>https://blog.r-project.org/2022/07/25/r-can-use-your-help-translating-r-messages/</link>
      <pubDate>Mon, 25 Jul 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/07/25/r-can-use-your-help-translating-r-messages/</guid>
      <description>If you use R you may have wondered if there are ways you can contribute to making R better. An important feature of R that encourages its use around the world is the support for localization. This enables R’s messages, warnings and errors, as well as menu labels in the Windows and Mac OS GUIs, to be shown in the user’s local language.
Localization relies on translations that are contributed and maintained by volunteer translation teams.</description>
    </item>
    
    <item>
      <title>Speedups in operations with regular expressions</title>
      <link>https://blog.r-project.org/2022/07/12/speedups-in-operations-with-regular-expressions/</link>
      <pubDate>Tue, 12 Jul 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/07/12/speedups-in-operations-with-regular-expressions/</guid>
      <description>Regular expression operations in R, such as grep or gsub, sometimes have significant performance overheads due to encoding conversions.
Some R code tries to mitigate this by ignoring input encodings and pretending it is fine to work on individual bytes (via useBytes=TRUE). This removes such overheads, but produces correct results only in special cases, e.g. for simple regular expressions in UTF-8. With the current implementation of gsub and strsplit in R, this can also silently introduce invalid strings, which may cause invalid results or errors in further processing.</description>
    </item>
    
    <item>
      <title>Moving to blog.r-project.org</title>
      <link>https://blog.r-project.org/2022/06/30/moving-to-blog.r-project.org/</link>
      <pubDate>Thu, 30 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/06/30/moving-to-blog.r-project.org/</guid>
      <description>The R blog moves to https://blog.r-project.org, a more prominent location, after 37 blog posts (some of them perhaps surprisingly detailed) and a bit over 4 years.
This blog site has been started under https://developer.r-project.org in March 2018 as a new communication channel for R developers contributing to the R core implementation. Most of the blog posts cover selected changes in R-devel, the development version of R. They provide a bigger picture for these changes as well as details, ideas, personal experience and opinions of the authors.</description>
    </item>
    
    <item>
      <title>Why to avoid \x in regular expressions</title>
      <link>https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions/</link>
      <pubDate>Mon, 27 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions/</guid>
      <description>Using \x in string literals is almost always a bad idea, but using it in regular expressions is particularly dangerous.
Consider this “don’t do” example in R 4.2.1 or earlier:
text &amp;lt;- &amp;quot;Hello\u00a0R&amp;quot; gsub(&amp;quot;\xa0&amp;quot;, &amp;quot;&amp;quot;, text) a0 is the code point of the Unicode “NO-BREAK SPACE” and the example runs in UTF-8 locale. The intention is to remove the space; a slightly more complicated variant has been discussed on the R-devel mailing list about half a year ago.</description>
    </item>
    
    <item>
      <title>Upcoming Changes in R 4.2.1 on Windows</title>
      <link>https://blog.r-project.org/2022/06/16/upcoming-changes-in-r-4.2.1-on-windows/</link>
      <pubDate>Thu, 16 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/06/16/upcoming-changes-in-r-4.2.1-on-windows/</guid>
      <description>R 4.2.1 is scheduled to be released next week with a number of Windows-specific fixes. All Windows R users currently using R 4.2.0 should upgrade to R 4.2.1. This text has more details on some of the fixes.
R 4.2.0 on Windows came with a significant improvement. It uses UTF-8 as the native encoding and for that it switched to the Universal C Runtime (UCRT). This in turn required creating a new R toolchain for Windows and re-building R, R packages and all (statically linked) dependencies with it (Rtools42, more details on the transition).</description>
    </item>
    
    <item>
      <title>Vectorised Patterns in R Graphics</title>
      <link>https://blog.r-project.org/2022/06/09/vectorised-patterns-in-r-graphics/</link>
      <pubDate>Thu, 09 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/06/09/vectorised-patterns-in-r-graphics/</guid>
      <description>Support for pattern fills was added to the R graphics engine in R version 4.1.0, with an R interface via the ‘grid’ package.
library(grid) For example, the following code defines a linear gradient that varies horizontally from red to white and a tiling pattern that is based on a repeating red circle.
gradcol &amp;lt;- c(palette()[2], &amp;quot;white&amp;quot;) grad &amp;lt;- linearGradient(gradcol, y1=.5, y2=.5) patcol &amp;lt;- 2 pat &amp;lt;- pattern(circleGrob(r=unit(2, &amp;quot;mm&amp;quot;), gp=gpar(col=patcol, fill=patcol)), width=unit(5, &amp;quot;mm&amp;quot;), height=unit(5, &amp;quot;mm&amp;quot;), extend=&amp;quot;repeat&amp;quot;) The next code calls grid.</description>
    </item>
    
    <item>
      <title>Enhancements to HTML Documentation</title>
      <link>https://blog.r-project.org/2022/04/08/enhancements-to-html-documentation/</link>
      <pubDate>Fri, 08 Apr 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2022/04/08/enhancements-to-html-documentation/</guid>
      <description>The upcoming release of R (version 4.2.0) features several enhancements to the HTML help system.
The most noticeable features are that LaTeX-like mathematical equations in help pages are now typeset using either KaTeX or MathJax, and usage and example code are highlighted using Prism. Additionally, the output of examples and demos can now be shown within the browser if the knitr package is installed. This is especially useful if the examples produce graphical output.</description>
    </item>
    
    <item>
      <title>Updating Graphics Devices for R 4.2.0</title>
      <link>https://blog.r-project.org/2021/12/14/updating-graphics-devices-for-r-4.2.0/</link>
      <pubDate>Tue, 14 Dec 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/12/14/updating-graphics-devices-for-r-4.2.0/</guid>
      <description>A number of new graphics features have been added to the R graphics engine in the development version of R (to become version 4.2.0):
groups, compositing operators, affine transformations, stroking and filling paths, and luminance masks. This has consequences for R packages that provide graphics devices, like the ‘ragg’ package.
For users of R packages that provide graphics devices, those packages will need to be reinstalled when updating to R 4.</description>
    </item>
    
    <item>
      <title>Upcoming Changes in R 4.2 on Windows</title>
      <link>https://blog.r-project.org/2021/12/07/upcoming-changes-in-r-4.2-on-windows/</link>
      <pubDate>Tue, 07 Dec 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/12/07/upcoming-changes-in-r-4.2-on-windows/</guid>
      <description>R 4.2 for Windows will support UTF-8 as native encoding, which will be a major improvement in encoding support, allowing Windows R users to work with international text and data.
This new feature will require at least Windows 10 (version 1903) on desktop systems, Windows Server 2022 on long-term support server systems or Windows Server 1903 from the semi-annual channel. Older Windows systems will be able to run R, but with the same limitations in the encoding support as in R 4.</description>
    </item>
    
    <item>
      <title>Groups and Paths and Masks in R Graphics</title>
      <link>https://blog.r-project.org/2021/12/06/groups-and-paths-and-masks-in-r-graphics/</link>
      <pubDate>Mon, 06 Dec 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/12/06/groups-and-paths-and-masks-in-r-graphics/</guid>
      <description>UPDATE: (2023-05-18) The behaviour of compositing operators was modified in R version 4.3.0 (affecting the “clear” and “source” operators). The examples in this post have been updated so that they produce the same output (just using a different operator).
 Support for gradient fills, pattern fills, clipping paths and masks was added to the R graphics engine in R version 4.1.0.
The development version of R (likely to become R version 4.</description>
    </item>
    
    <item>
      <title>R Can Use Your Help: Testing R Before Release</title>
      <link>https://blog.r-project.org/2021/04/28/r-can-use-your-help-testing-r-before-release/</link>
      <pubDate>Wed, 28 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/04/28/r-can-use-your-help-testing-r-before-release/</guid>
      <description>If you use R you may have wondered if there are ways you can contribute to making R better. This is another post on how you might help (Reviewing Bug Reports was the first).
This post is about helping with testing of pre-release versions of R.
Maintaining and improving R unavoidably comes with introducing regressions, that is breaking things which worked before. This also happens when external software changes its behavior (OS, compilers, libraries).</description>
    </item>
    
    <item>
      <title>Improved Multi-byte Support in RTerm</title>
      <link>https://blog.r-project.org/2021/04/17/improved-multi-byte-support-in-rterm/</link>
      <pubDate>Sat, 17 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/04/17/improved-multi-byte-support-in-rterm/</guid>
      <description>Support for multi-byte characters and hence non-European languages in RTerm, the console-based front-end to R on Windows, has been improved. It is now possible to edit text including multi-byte and multi-width characters supported by the current locale, so that e.g. Japanese R users can edit a Japanese text. To appear in R 4.1.
This is a by-product of fixing RTerm to support all Unicode characters when running in UTF-8, which is already possible in experimental UCRT builds of R-devel.</description>
    </item>
    
    <item>
      <title>Virtual Windows machine for checking R packages</title>
      <link>https://blog.r-project.org/2021/03/18/virtual-windows-machine-for-checking-r-packages/</link>
      <pubDate>Thu, 18 Mar 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/03/18/virtual-windows-machine-for-checking-r-packages/</guid>
      <description>Microsoft provides a free Windows 10 virtual machine for testing. Package maintainers working on Linux and MacOS can use it to test their packages on Windows. See instructions on how to set up the machine automatically for checking R packages.
The set up provides SSH access with bash, so that users can perform most of the tasks from their preferred terminal emulator. Command line tools needed to build R and many R packages from source are pre-installed.</description>
    </item>
    
    <item>
      <title>Windows/UTF-8 Toolchain and CRAN Package Checks</title>
      <link>https://blog.r-project.org/2021/03/12/windows/utf-8-toolchain-and-cran-package-checks/</link>
      <pubDate>Fri, 12 Mar 2021 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2021/03/12/windows/utf-8-toolchain-and-cran-package-checks/</guid>
      <description>A new, experimental, build of R for Windows is available, its main aim being to support the UTF-8 encoding and especially non-European languages. Check results for CRAN packages are now available on their CRAN results pages. Please help by reviewing these for your package(s) and if a Windows user by trying the new build, particularly if you use a language written in a non-Latin script.
The new build can be downloaded from [2] and instructions are at [1].</description>
    </item>
    
    <item>
      <title>Will R Work on Apple Silicon?</title>
      <link>https://blog.r-project.org/2020/11/02/will-r-work-on-apple-silicon/</link>
      <pubDate>Mon, 02 Nov 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/11/02/will-r-work-on-apple-silicon/</guid>
      <description>At WWDC 2020 earlier this year, Apple announced a transition from Intel to ARM-based processors in their laptops. This blog is about the prospects of when R will work on that platform, based on experimentation on a developer machine running A12Z, one of the “Apple silicon” processors.
The new platform will include Rosetta 2, a dynamic translation framework which runs binaries built for 64-bit Intel Macs using just-in-time, dynamic translation of binary code.</description>
    </item>
    
    <item>
      <title>Windows/UTF-8 Build of R and CRAN Packages</title>
      <link>https://blog.r-project.org/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/</link>
      <pubDate>Thu, 30 Jul 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/</guid>
      <description>R-devel-win.exe is an experimental installer of R, set up to download experimental binary builds of CRAN packages. It sets UTF-8 as the current default encoding on Windows (Windows 10 November 2019 release or newer). 92% of CRAN packages are supported. Intended as a demonstration of this option to support Unicode characters in R on Windows, not for production use.
To play with this version of R, start cmd.exe, run chcp 65001 (to set UTF-8 code page), go to Properties/Font/Font and select NSimFun (a font with glyphs needed for this example), go to C:\Program Files\R\R-devel\bin (default installation directory of the demo), run R.</description>
    </item>
    
    <item>
      <title>New Features in the R Graphics Engine</title>
      <link>https://blog.r-project.org/2020/07/15/new-features-in-the-r-graphics-engine/</link>
      <pubDate>Wed, 15 Jul 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/07/15/new-features-in-the-r-graphics-engine/</guid>
      <description>Support for gradient fills, pattern fills, clipping paths and masks has been added to the R graphics engine (in the development version of R, which will probably become R version 4.1.0).
An R-level interface for these new features has been added to the ‘grid’ graphics package.
library(grid) For example, the following code fills a circle with a linear gradient.
grid.circle(gp=gpar(col=NA, fill=linearGradient())) The next code fills a rectangle with a radial gradient.</description>
    </item>
    
    <item>
      <title>Improvements to Clipping in the R Graphics Engine</title>
      <link>https://blog.r-project.org/2020/06/08/improvements-to-clipping-in-the-r-graphics-engine/</link>
      <pubDate>Mon, 08 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/06/08/improvements-to-clipping-in-the-r-graphics-engine/</guid>
      <description>UPDATE (2020-11-18): canClip = NA_LOGICAL has been replaced by deviceClip = TRUE
The R graphics engine performs some clipping of output regardless of whether the graphics device it is sending output to can perform clipping itself. For example, output that is sent to the postscript() device, which can do its own clipping, is still clipped by the graphics engine to the edges of the device.
This is useful for devices that cannot clip, e.</description>
    </item>
    
    <item>
      <title>Testing R on Emulated Platforms</title>
      <link>https://blog.r-project.org/2020/05/29/testing-r-on-emulated-platforms/</link>
      <pubDate>Fri, 29 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/05/29/testing-r-on-emulated-platforms/</guid>
      <description>Sometimes it is useful to test R on unusual platforms, even when the expected number of users is not large at the moment. It is better to be ready when a new platform arrives or becomes more widely used, it may be easier to find some bugs on one platform than other, and such testing may reveal code unintentionally too platform specific.
Recently I wanted to test R on 64-bit ARM (Aarch64) and on Power.</description>
    </item>
    
    <item>
      <title>UTF-8 Support on Windows</title>
      <link>https://blog.r-project.org/2020/05/02/utf-8-support-on-windows/</link>
      <pubDate>Sat, 02 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/05/02/utf-8-support-on-windows/</guid>
      <description>R internally allows strings to be represented in the current native encoding, in UTF-8 and in Latin 1. When interacting with the operating system or external libraries, all these representations have to be converted to native encoding. On Linux and macOS today this is not a problem, because the native encoding is UTF-8, so all Unicode characters are supported. On Windows, the native encoding cannot be UTF-8 nor any other that could represent all Unicode characters.</description>
    </item>
    
    <item>
      <title>Changes to Symbol Fonts for Cairo Graphics Devices</title>
      <link>https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/</link>
      <pubDate>Fri, 17 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/</guid>
      <description>The symbol font When drawing text in R graphics, we can specify the font “family” to use, e.g., a generic family like &#34;sans&#34; or a specific family like &#34;Helvetica&#34;, and we can specify the font “face” to use, e.g., plain, bold, or italic. R graphics provides four standard font faces, plain, bold, italic, bold-italic, and one special font face that R calls “symbol”. The following code and output demonstrate the different font faces.</description>
    </item>
    
    <item>
      <title>Changes to &#39;grid&#39; units</title>
      <link>https://blog.r-project.org/2020/04/13/changes-to-grid-units/</link>
      <pubDate>Mon, 13 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/04/13/changes-to-grid-units/</guid>
      <description>One of the main downsides to the ‘grid’ graphics package is that it is slow. And that makes some important packages that depend on ‘grid’, like ‘ggplot2’, slow. For example, the scatterplots shown below are roughly equivalent, but one is drawn using ‘graphics’ and the other using ‘ggplot2’.
The ‘ggplot2’ version takes more than 4 times as long to draw.
(The benchmarks in this post were produced using the ‘bench’ package within a Docker container based on rocker/r-devel, but with R-devel (r77995) built with --enable-memory-profiling and a bunch of R packages installed; the Docker images, pmur002/grid-new-units-r-3.</description>
    </item>
    
    <item>
      <title>Socket Connections Update</title>
      <link>https://blog.r-project.org/2020/03/17/socket-connections-update/</link>
      <pubDate>Tue, 17 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/03/17/socket-connections-update/</guid>
      <description>Starting up a PSOCK cluster is not fast. In R 3.6 on just a few years old laptop with 8 logical cores, running Windows, it takes about 1.7s to start a cluster with 8 nodes:
library(parallel); system.time(cl &amp;lt;- makePSOCKcluster(8)) A good design is to start a cluster only once during an R session and then pass it to computations that can take advantage of it. This is needed so that the end user always has full control over how many cores are used in total.</description>
    </item>
    
    <item>
      <title>stringsAsFactors</title>
      <link>https://blog.r-project.org/2020/02/16/stringsasfactors/</link>
      <pubDate>Sun, 16 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2020/02/16/stringsasfactors/</guid>
      <description>Since its inception, R has, at least by default, converted (character) strings to factors when creating data frames directly with data.frame() or as the result of using read.table() variants to read in tabular data. Quite likely, this will soon change.
In R 0.62 (released 1998), the original internal data frame code was replaced by the interpreted Statlib code contributed by John Chambers, to the effect that data.frame() would always convert strings to factors (unless protected by I()), whereas read.</description>
    </item>
    
    <item>
      <title>Thanks for Reviewing Bug Reports</title>
      <link>https://blog.r-project.org/2019/12/16/thanks-for-reviewing-bug-reports/</link>
      <pubDate>Mon, 16 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/12/16/thanks-for-reviewing-bug-reports/</guid>
      <description>Just a quick update and note of thanks to all who have responded to our blog post on 2019-10-09 and helped with reviewing and resolving bug reports. Thanks to your help the pace at which bugs have been resolved has increased nicely since the date of that post:
Our special thanks to Michael Chirico, Henrik Bengtsson, Suharto Anggono, Hugo Gabriel Eyherabide and Elin Waring, who have contributed most in this period.</description>
    </item>
    
    <item>
      <title>A New palette() for R</title>
      <link>https://blog.r-project.org/2019/11/21/a-new-palette-for-r/</link>
      <pubDate>Thu, 21 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/11/21/a-new-palette-for-r/</guid>
      <description>UPDATE 2019-12-03: Following feedback, the new default palette has been tweaked so that the new “magenta” is a little redder and darker and the new “yellow” is a little lighter and brighter. The former is to improve the discriminability between “blue” and “magenta” for deuteranopes and the latter is to improve the discriminability between “green” and “yellow” for protanopes. We would like to thank those who provided feedback and suggestions on the new palette, in particular Antonio Camargo, Brenton Wiernik, Ken Knoblauch, and Jakub Nowosad.</description>
    </item>
    
    <item>
      <title>When you think `class(.) == *`, think again!</title>
      <link>https://blog.r-project.org/2019/11/09/when-you-think-class.-think-again/</link>
      <pubDate>Sat, 09 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/11/09/when-you-think-class.-think-again/</guid>
      <description>short lines !! -- Historical relict: R matrix is not an array In a recent discussion on the R-devel mailing list, in a thread started on July 8, head.matrix can return 1000s of columns – limit to n or add new argument? Michael Chirico and then Gabe Becker where proposing to generalize the head() and tail() utility functions, and Gabe noted that current (pre R-4.x.y) head() would not treat array specially.</description>
    </item>
    
    <item>
      <title>R Can Use Your Help: Reviewing Bug Reports</title>
      <link>https://blog.r-project.org/2019/10/09/r-can-use-your-help-reviewing-bug-reports/</link>
      <pubDate>Wed, 09 Oct 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/10/09/r-can-use-your-help-reviewing-bug-reports/</guid>
      <description>If you use R you may have wondered if there are ways you can contribute to making R better. This is the first in several posts on how you might help. This post is about helping to review and resolve bugs reported on the R bug tracker.
Urgent bug reports, in particular ones with simple reproducible examples, are generally resolved and closed quickly. But those that are not can sometimes languish for a long time.</description>
    </item>
    
    <item>
      <title>GFortran Issues with LAPACK II</title>
      <link>https://blog.r-project.org/2019/09/25/gfortran-issues-with-lapack-ii/</link>
      <pubDate>Wed, 25 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/09/25/gfortran-issues-with-lapack-ii/</guid>
      <description>This is an update on my previous post from May.
A number of things changed since: GFortran started adopting a fix that by default prevents optimizations which break code calling BLAS/LAPACK functions from C without hidden length arguments. R has been updated to internally add these hidden length arguments (and also in other cases where LTO type mismatch was detected). R has exported macros for use in packages so that they can follow suit when calling BLAS/LAPACK and CRAN has been working with maintainers of the affected packages.</description>
    </item>
    
    <item>
      <title>S3 Method Lookup</title>
      <link>https://blog.r-project.org/2019/08/19/s3-method-lookup/</link>
      <pubDate>Mon, 19 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/08/19/s3-method-lookup/</guid>
      <description>At the core of the S3 object system as introduced in the White Book lies the idea that (S3) methods are ordinary functions that follow the GEN.CLS naming convention (with GEN.default as a final fallback). In the initial R implementation of this object system, these methods were searched for in the environment (and all enclosing environments) from which the generic was called.
With the advent of namespaces (see Tierney (2003), “Name space management for R”, R News, 3(1):2-6) a mechanism for registering S3 methods via S3method() directives in the NAMESPACE file of a package was added.</description>
    </item>
    
    <item>
      <title>GFortran Issues with LAPACK</title>
      <link>https://blog.r-project.org/2019/05/15/gfortran-issues-with-lapack/</link>
      <pubDate>Wed, 15 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/05/15/gfortran-issues-with-lapack/</guid>
      <description>Recent version of the GNU Fortran compiler (7, 8, 9) include optimizations that break interoperability between C and Fortran code with BLAS/LAPACK. The compiled code of BLAS/LAPACK corrupts stack, often resulting in crashes. This impacts R, R packages directly calling into BLAS/LAPACK, and all other applications of BLAS/LAPACK. The work-around is to compile BLAS/LAPACK with -fno-optimize-sibling-calls. This option is now used in R-Devel and R-Patched, so that the reference BLAS and LAPACK included in R are compiled with that option.</description>
    </item>
    
    <item>
      <title>Common PROTECT Errors</title>
      <link>https://blog.r-project.org/2019/04/18/common-protect-errors/</link>
      <pubDate>Thu, 18 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/04/18/common-protect-errors/</guid>
      <description>This post presents the most common PROTECT bugs present in packages, based on manual inspection of ~100 remaining CRAN packages with reports from rchk.
Background Any C/C++ code interacting with R, both inside R itself and in packages, needs to inform the garbage collector about which objects on the R heap are reachable from local variables. Pointers to such objects are kept on the pointer protection stack or the precious list or multi-set, but the most common is the pointer protection stack with PROTECT/UNPROTECT macros.</description>
    </item>
    
    <item>
      <title>HCL-Based Color Palettes in grDevices</title>
      <link>https://blog.r-project.org/2019/04/01/hcl-based-color-palettes-in-grdevices/</link>
      <pubDate>Mon, 01 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/04/01/hcl-based-color-palettes-in-grdevices/</guid>
      <description>Starting with R 3.6.0 a new hcl.colors() function is available in grDevices, providing a wide range of HCL-based color palettes with much better perceptual properties than existing RGB/HSV-based palettes like rainbow(). An accompanying new hcl.pals() function lists available palette names for hcl.colors(). It is a basic and lean implementation of the pre-specified palettes in the colorspace package, closely approximating palettes from many other packages like ColorBrewer, CARTO, viridis, scico, etc.</description>
    </item>
    
    <item>
      <title>Use of C&#43;&#43; in Packages</title>
      <link>https://blog.r-project.org/2019/03/28/use-of-c-in-packages/</link>
      <pubDate>Thu, 28 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/03/28/use-of-c-in-packages/</guid>
      <description>About 20% packages from CRAN and BIOC repositories include some native code and more than a half of those include some code in C++. This number is rather high given that the R API and runtime have been designed for C (or Fortran) and cannot be used reliably from C++, without extensive effort and restrictions. To avoid nasty bugs in such code, one needs to know R internals well, and when following the restrictions, one cannot use much from C++ anyway.</description>
    </item>
    
    <item>
      <title>Managing Search Path Conflicts</title>
      <link>https://blog.r-project.org/2019/03/19/managing-search-path-conflicts/</link>
      <pubDate>Tue, 19 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/03/19/managing-search-path-conflicts/</guid>
      <description>Starting with R 3.6.0 the library() and require() functions allow more control over handling search path conflicts when packages are attached. The policy is controlled by the new conflicts.policy option. This post provides some background and details on this new feature.
Background When loading a package and attaching it to the search path, conflicts can occur between objects defined in the new package and ones already provided by other packages on the search path.</description>
    </item>
    
    <item>
      <title>Staged Install</title>
      <link>https://blog.r-project.org/2019/02/14/staged-install/</link>
      <pubDate>Thu, 14 Feb 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/02/14/staged-install/</guid>
      <description>This text is about a new feature in R, staged installation of packages. It may be of interest to package authors and maintainers, and particularly to those who maintain packages that are affected.
The problem I often have to run checks for all CRAN and BIOC packages to test the impact of my changes to R. This is to find about my own bugs, but often I also wake up existing bugs in packages or R or find out that some packages rely on undocumented API or behavior.</description>
    </item>
    
    <item>
      <title>Parser Speedups</title>
      <link>https://blog.r-project.org/2019/01/07/parser-speedups/</link>
      <pubDate>Mon, 07 Jan 2019 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2019/01/07/parser-speedups/</guid>
      <description>It wasn’t my primary goal to improve parser performance nor to measure it. I’ve been working on optimizations to reduce the runtime overhead of including source reference into packages (this is not done by default due to space and execution time overheads). I’ve added an option to exclude parse data from source references and enabled it by default for packages, as parse data account for most of the runtime overhead of source references while they are rarely needed.</description>
    </item>
    
    <item>
      <title>Unprotecting by Value</title>
      <link>https://blog.r-project.org/2018/12/10/unprotecting-by-value/</link>
      <pubDate>Mon, 10 Dec 2018 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2018/12/10/unprotecting-by-value/</guid>
      <description>In short, UNPROTECT_PTR is dangerous and should not be used. This text describes why and describes how to replace it, including mset-based functions that have been introduced as a substitute for situations when unprotection by value is really needed. This could be of interest to anyone who writes native code to interface with the R heap, and definitely to all who use UNPROTECT_PTR in their code.
Background R provides several functions to protect pointers to R objects held by local C variables (typed SEXP) from the garbage collector.</description>
    </item>
    
    <item>
      <title>Conditions of Length Greater Than One</title>
      <link>https://blog.r-project.org/2018/10/12/conditions-of-length-greater-than-one/</link>
      <pubDate>Fri, 12 Oct 2018 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2018/10/12/conditions-of-length-greater-than-one/</guid>
      <description>Historically R language allows conditions in if and while statements to be vectors (of length greater than one). The first element is used but the remaining elements are ignored, since November 2002 also with a warning (added by Brian Ripley). Following an intuition that such situations would typically arise from a programming error, an option has been added in March 2017 to optionally allow signalling a runtime error, instead (the patch was by Martin Maechler, pinged by a suggestion of Henrik Bengtsson on the R-devel mailing list).</description>
    </item>
    
    <item>
      <title>Maximum Number of DLLs</title>
      <link>https://blog.r-project.org/2018/03/23/maximum-number-of-dlls/</link>
      <pubDate>Fri, 23 Mar 2018 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/2018/03/23/maximum-number-of-dlls/</guid>
      <description>Some packages contain native code, which is linked to R dynamically in the form of dynamically loaded libraries (DLLs). Recently, R users started loading increasing numbers of packages; “workflow documents” are one source of this pattern. This has eventually lead to hitting the DLL limit in R, which materializes as runtime error “maximal number of DLLs reached”.
Limit on the number of open files The DLL limit in R is good for one important reason.</description>
    </item>
    
    <item>
      <title>About</title>
      <link>https://blog.r-project.org/about/</link>
      <pubDate>Wed, 17 Jan 2018 00:00:00 +0000</pubDate>
      
      <guid>https://blog.r-project.org/about/</guid>
      <description>On this blogging site R developers share their experience, ideas and plans related to R core implementation. Technical details presented here might be useful for package developers and interesting for technically-minded R enthusiasts.
The blog posts represent individual opinions of their authors. Unless stated so explicitly, they should not be taken as positions of R Core nor R Foundation.
In the interest of technical quality of the posts, the authors may modify existing posts after publication.</description>
    </item>
    
  </channel>
</rss>