The R package

The R package in question is {ringbp}. The package has two pieces of functionality: 1) to simulate an infectious disease outbreak using a branching process model with non-pharmaceutical interventions; and 2) to calculate the proportion of simulated outbreaks that are contained (i.e. do not cause a large sustained human-to-human epidemic). The utility of the package’s general model framework has been shown by serving as a template for other epidemiological research such as post-exposure prophylaxis, network effects on control (Firth et al. 2020) and the impact of self-reporting and isolation adherence (Davis et al. 2020).

The problem

It is understandable that because {ringbp} was written in haste to produce insights to inform pandemic response it did not adhere to all software best practices. Usability, documentation, testing, code style, and (computational) performance could be improved. Certain aspects of model code, like parameterisations, were hard-coded, not providing users the full flexibility that the model could allow.

Epiverse contribution

In the recent months Epiverse has collaborated with {ringbp} developers Seb Funk (also a member of Epiverse) and Carl Pearson (external collaborator), based at the London School of Hygiene and Tropical Medicine and University of North Carolina, respectively, to try and improve the R package, both internally and from the user-experience. The following sections will give brief summaries of some of the collaborative developments.

scenario_sim(
  n.sim = 5,
  num.initial.cases = 5,
  cap_max_days = 365,
  cap_cases = 2000,
  r0isolated = 0,
  r0community = 2.5,
  disp.iso = 1,
  disp.com = 0.16,
  k = 0.7,
  delay_shape = 2.5,
  delay_scale = 5,
  prop.asym = 0,
  prop.ascertain = 0
)

scenario_sim(
 n = 5,
 initial_cases = 5,
 offspring = offspring_opts(
   community = \(n) rnbinom(n = n, mu = 2.5, size = 0.16),
   isolated = \(n) rnbinom(n = n, mu = 0, size = 1),
   asymptomatic = \(n) rnbinom(n = n, mu = 2.5, size = 0.16)
  ),
 delays = delay_opts(
   incubation_period = \(n) rweibull(n = n, shape = 2.32, scale = 6.49),
   onset_to_isolation = \(n) rweibull(n = n, shape = 2.5, scale = 5)
  ),
 event_probs = event_prob_opts(
   asymptomatic = 0,
   presymptomatic_transmission = 0.3,
   symptomatic_ascertained = 0
  ),
 interventions = intervention_opts(quarantine = TRUE),
 sim = sim_opts(
   cap_max_days = 365,
   cap_cases = 2000
  )
)

The new API gives the user more control over the model’s parameterisation. The incubation period is now specified by the user instead of being set to an estimate for COVID-19. The way offspring and delay distribution functions are specified also means that any distributional or non-parametric form can be supplied, relaxing the assumption that the onset-to-isolation has to be a Weibull distribution.

Users can now specify the proportion of presymptomatic transmission rather than having to understand the skew normal parameterisation used by the simulation model, making it easier to get started with the package for new users.

Lastly on user-facing changes, the naming and style of function arguments has been standardised for consistent use of snakecase style and abbreviations.

@param sim a `list` with class `<ringbp_sim_opts>`: the simulation control
  options for the \pkg{ringbp} model, returned by [sim_opts()]

Conclusion

The {ringbp} R package implements a simple but informative model for infectious disease transmission and interventions. When originally written it included many well-developed aspects, but the time constraints of real-time outbreak response meant several improvements were possible.

Epiverse-TRACE has the opportunity to not only develop new tooling for pandemic preparedness and response, but to contribute to the ecosystem of open-source software in infectious disease epidemiology. We hope that by covering the collaborative developments of {ringbp}, it can illustrate the benefits of bringing software up to date with best practices, and make tools available, accessible and robust when a new epidemic or pandemic occurs, in turn hopefully removing the need for redeveloping similar software in the future.

These efforts are not limited to {ringbp}. Similar contributions have been made to other packages, including EpiNow2, and open source communities such as the epinowcast community, where documentation, testing, and code enhancements have helped strengthen the forecasting and nowcasting software ecosystem in the last couple of years.

Enhancing the accessibility of software for users and developers by improving its documentation and user interface will hopefully provide a gateway for more external contributors to engage with the project. In the public health landscape of temporal surges in capacity and priorities, better enabling community contributions to open-source software should aid software sustainability.

All of the changes discussed in this blog post can be found in the {ringbp} news. For details of developments see the pull request history of {ringbp} on GitHub.

Acknowledgements

Thanks to Seb Funk, Carl Pearson and James Azam for helpful feedback when drafting this post and for their collaboration on the {ringbp} project.

Overview of previous blog post on R package licensing

We previously published a post on the Epiverse-TRACE blog discussing the importance of licensing code and data for open source. It covered the differences between open source licenses for code and those that are required for other forms of information, in our case, data. R packages most commonly distribute code, and therefore require an appropriate open source license. Less frequently, R packages are used to bundle and share data, so-called “data packages”, and require an applicable license for reuse and redistribution. We recommend reading the original blog post for a more in-depth explanation of each of these points.

However, since publishing the original post, the last section, Licensing code and data in one R package, has become outdated given our experience submitting the epiparameter package to CRAN with a dual-license. This blog post provides an updated Licensing code and data in one R package section with learnings from epiparameter package development and CRAN submission.

Licensing code and data in one R package

If you are developing an R package that has both code and data as primary objects of (roughly) equal importance, a software license inadequately covers the data, and a data license inadequately covers the code. Dual licensing can help resolve this issue. This means there is one license for code (for example, MIT license) and another license for the included data (for example, Public Domain Dedication).

After conducting an online search, dual licensing for R packages seems rare. An interesting example of dual licensing is the igraphdata package, which contains several licenses: One for each dataset included in the package. Similar to igraphdata, we dual licensed the epiparameter package, which until versus v0.4.0 contained both code and data. We licensed the code using the DESCRIPTION file and used the LICENSE file to license the data under CC0. Concretely, we included this additional text in LICENSE to clarify the dual license and that we recommend citing the original source regardless:

All data included in the epiparameter R package is licensed under CC0 (https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt). This includes the parameter database (extdata/parameters.json) and data in the data/ folder. Please cite the individual parameter entries in the database when used.

However, upon submission of epiparameter to CRAN, the dual licensing approach was rejected. The CRAN package reviewer stated:

A package can only be licensed as a whole. It can have a single license or a set of alternative licenes. If the data have to be licensed differently then the code, you have to provide the data in a separate data package with the other license.

Therefore, we decided to separate the data, originally stored in epiparameter, into a package called epiparameterDB. This package is solely licensed under CC0, and epiparameter can then also be solely licensed under MIT. Both packages are now hosted on CRAN using a single license dedicated to code or data.

When including data in your R package from other sources it is important to check that the license of your package and the data is compatible¹, or that the individual data license is clearly stated, as in igraphdata. For epiparameterDB, we consider model estimates as facts (that is, not copyrightable).

This blogpost provides an addendum to our original post Dual licensing R packages with code and data, providing our experience and outcomes from submitting epiparameter – and the resulting epiparmeterDB package – to CRAN in a conformant manner. In addition to the requirements and benefits of open source licensing of open software and data in the first post, we hope this follow-up post provides practical information that will be of use to other R package developers, or software developers and open data curators more broadly.

Licensing only code in R packages

Given the importance of a license for redistribution, CRAN requires R packages to contain an open-source license.¹ As one of the most important distributors for R packages historically, this rule has become the de facto standard.

An R package is licensed appropriately when the license is stated in the metadata DESCRIPTION file and, if necessary, in the LICENSE file. We recommend including the LICENSE file, with the license year and exact copyright holder (for example, an organization or a specific individual). Some R package developers choose to include a copy of the license but this is not bundled in the R package when it is built. You can find an example of a DESCRIPTION file here and find an example LICENSE here.

Licensing only data in R packages

It can be the case that an R package is primarily used to bundle and share a data set, for example to allow a user to easily download the data and load it into R. For example, gapminder and palmerpenguins. As an aside, some in the R developer community² dissuade the use of R packages used primarily for data, often referred to as “data packages”, and instead advocate to host data online and use the several API packages available in R to access the data.

Software licenses do not apply to data. One piece of data cannot be copyrighted, as facts cannot be copyrighted, but a collection of data in a database can come with rights. In Europe, UK, and Russia, databases can have rights if they are a substantial and original piece of work.³ This is called the “sui generis” database right. The USA and Brazil do not recognize this database right. Data compiled from various databases that themselves are copyrighted would need to follow the licenses of those respective databases.

Data need licenses such as the Public Domain Dedication or the Creative Commons Attribution to maximize redistribution. Such general licenses help minimize differences among countries that do and do not recognize database rights. Given that any copyright limitations (even attribution) mean they only apply when the database right is recognized, we recommend the most minimal option: The Public Domain Dedication. This levels the playing field for reuse and redistribution, no matter the jurisdiction.

Licensing code and data in one R package

But what to do if your R package has both code and data as primary objects of (roughly) equal importance?

In these cases a software license inadequately covers the data, and a data license inadequately covers the code. Dual licensing can help resolve this issue. This means there is one license for code (for example, MIT license) and another license for the included data (for example, Public Domain Dedication).

After conducting an online search, dual licensing for R packages seems rare. An interesting example of dual licensing is the igraphdata package, which contains several licenses: One for each dataset included in the package. Similar to igraphdata, in our own epiparameter package we dual licensed the code and data as well. We licensed the code using the DESCRIPTION file and used the LICENSE file to license the data under CC0. Concretely, we include this additional text in LICENSE to clarify the dual license and that we recommend citing the original source regardless:

All data included in the epiparameter R package is licensed under CC0 (https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt). This includes the parameter database (extdata/parameters.json) and data in the data/ folder. Please cite the individual parameter entries in the database when used.

When including data in your R package from other sources it is important to check that the license of your package and the data is compatible⁴, or that the individual data license is clearly stated, as in igraphdata. For epiparameter, we consider model estimates as facts (that is, not copyrightable).

This blogpost helps explain a pattern of dual licensing rarely seen in the wild, and how to implement it in a CRAN conformant manner. By sharing this, we hope that those cases where people want to license both code and data, have a resource we wish we had while exploring this topic. Whether or not data packages and combined code + data packages should exist, is a question for another day.

Experiment 1: Export an R function by updating the documentation

The first experiment was on the {EpiNow2} R package. An existing Issue #681 was chosen. It was a simple task to evaluate Copilot workspace’s ability to interpret requests that require small changes to the codebase of a package (i.e. can be achieved in a single commit by changing less than 5 lines of code). The issue stated that an internal function, epinow2_cmdstan_model() should be exported, with the issue description explaining this would help users specify custom options for running the models.

Experiment 2: Add a simple epidemic model to an R package that contains more complex models

{epidemics} is an Epiverse-TRACE R package that exports a range of compartmental epidemiological models of varying complexities and applications.

In the second test case, we created an issue in the {epidemics} R package requesting a basic SIR model, with the issue description requesting the model to have no age structure and to use existing functionality in the package to specify a disease intervention. Additionally, the issue requested that the model be solved with the {deSolve} R package, which is a differential equation solver in R. A basic SIR model would have been new to the package, but one of several other compartmental models, and simpler than the models already implemented.

Experiment 3: Conducting a code review on an R package

In the last test case, we requested GitHub copilot workspace to conduct a code review of the entire code base of a package. At Epiverse-TRACE, it is standard practise to conduct a full package review. As any code base develops, including R packages, more commits are added and often the number of lines of code increases. Reviewing all of these changes before releasing a new version of the package is a timely undertaking for package reviewers. If AI tools could review the code base, similar to how static code analysers work, and suggest improvements to, for example, code style, memory efficiency, documentation, unit testing, UX/UI, it would greatly improve efficiency before releasing the code.

Conclusion

Based on our trials we observe that GitHub copilot Workspace may not provide a significant benefit to research software engineers in domain-specific R package development, where problems are complex and bespoke solutions are common. The evidence above suggests there’s still a long way to go before AI-powered tools can produce unsupervised code projects equivalent to that of a research software engineer. One observation is that generative AI is better trained for some purposes than others, biased by the amount of training data/information available. This makes it struggle in niche areas with a relatively smaller public code base to train models with (e.g. R functions for epidemic analysis are much rarer than generic JavaScript functions for web design). A second is that AI models don’t seem to understand how different parts of a codebase link together, so they provide solutions that are inconsistent with the requirements of the codebase (design principles, code style, etc). These models may, however, be more useful for more common tasks, such as building dashboard templates.

The test cases we experimented with suggest that this tool will not replace, and at times not even enhance development when the task requires a more integrated development than generating a standalone script. These tools are evolving rapidly and we are sure improvements will continue. In the short term tools like GitHub copilot workspace need to be used responsibly with an awareness of their limitations and not a blind trust that the code it writes is always correct. We would caution against relying on generative AI tools alone to develop software with potentially large-scale impacts - scrutiny by trained developers is still key. Research software engineers will play a key part in this as they will ensure that code and software written with and by AI tools meet required standards, are trustworthy, and are not potentially harmful. Where we see generative AI tools being more immediately useful in research software development is in tasks that require sifting through or summarising vast amounts of information; for example, in querying software documentation, or to help get started with a new programming framework or language.

All authors thank Hugo Gruson and Chris Hartgerink for their valuable feedback and contributions to this post.

Adding class support to function inputs via progressive enhancement

The goal here is to allow functions to accept the new classes as inputs, while keeping the old behaviour unchanged for unclassed objects (or with a different class than the new one).

This can conveniently be done in an almost transparent way by converting the old function to the S3 generic, and using the default method to handle the old behaviour. The practical steps, and minor caveats, have been previously described in the post “Convert Your R Function to an S3 Generic: Benefits, Pitfalls & Design Considerations”.

For a different, additional, example, we can consider a function working on patient-level data, which previously only accepted a data.frame as input:

#' Compute length of stay in hospital on a patient-level dataset
#'
#' @param data A data.frame containing patient-level data
#' @param admission_column The name of the column containing the admission date
#' @param discharge_column The name of the column containing the discharge date
#'
#' @returns A numeric vector of hospitalization durations in days
compute_hospitalization_duration <- function(data, admission_column, discharge_column) {

  difftime(
    data[[discharge_column]],
    data[[admission_column]],
    units = "days"
  )

}

We want to add support for linelist objects, as defined in the linelist package. linelist objects inherit from data.frame and contain an additional tags attribute. In particular, linelist objects can have a date_admission and date_discharge tag. This means we can use the tags to automatically detect the columns to use.

But we want the function to keep working for standard data.frames, tibbles, etc. We can follow the steps described in the previous post to convert the function to a generic, and add a default method to handle the old behaviour:

compute_hospitalization_duration <- function(data, ...) {

  UseMethod("compute_hospitalization_duration")

}

compute_hospitalization_duration.default <- function(data, admission_column, discharge_column) {

  difftime(
    data[[discharge_column]],
    data[[admission_column]],
    units = "days"
  )

}

compute_hospitalization_duration.linelist <- function(data, ...) {

  x <- linelist::tags_df(data)

  compute_hospitalization_duration(
    data = x,
    admission_column = "date_admission",
    discharge_column = "date_discharge"
  )

}

If the function was already a generic, then a new method for the new class should be added, leaving everything else unchanged.

Adding class support to function outputs via progressive enhancement

Adding class support to function outputs is often more challenging. A common option is to add a new argument to the function, which would be a boolean indicating whether the output should be of the new class or not. But this doesn’t fit in the view of progressive enhancement, as it would require users to change their code to benefit from the new classes, or to suffer from breaking changes.

While the new argument approach is sometimes indeed the only possible method, there are some situations where we can have an approach truly following the progressive enhancement philosophy.

In particular, this is the case when the old output was already inheriting from the parent of the new class (hence the importance of carefully choosing the parent class). In this situation, the new attributes from the new class should not interfere with existing code for downstream analysis.

In this case, let’s consider a function that was previously returning an unclassed data.frame with patient-level data:

create_patient_dataset <- function(n_patients = 10) {

  data <- data.frame(
    patient_id = seq_len(n_patients),
    age = sample(18:99, n_patients, replace = TRUE)
  )

  return(data)

}

We want to start returning a linelist object. Because linelist objects are data.frames (or tibbles) with an extra attr, it can be done in a transparent way:

create_patient_dataset <- function(n_patients = 10) {

  data <- data.frame(
    patient_id = seq_len(n_patients),
    age = sample(18:99, n_patients, replace = TRUE)
  )

  data <- linelist::make_linelist(
    data,
    id = "patient_id",
    age = "age"
  )

  return(data)

}

inherits(data, "data.frame")

For a more realistic example, you can also see the work in progress to integrate the new contactmatrix standard format for social contact data to the contactdata package.

This is however only true if code in downstream analysis follows good practices in checking for the class of an object ¹. If existing code was testing equality of the class to a certain value, it will break when the new class value is appended. This is described in a post on the R developer blog, when base R was adding a new array class value to matrix objects. Class inheritance should never be tested via class(x) == "some_class". Instead, inherits(x, "some_class") or is(x, "some_class") should be used to future-proof the code and allow appending an additional in the future.

Conclusion

Object oriented programming and S3 classes offer a convenient way to iteratively add interoperability in the ecosystem in a way that is minimally disruptive to users and developers. Newly classed input support can be added via custom methods (after converting the existing function to a generic if necessary). Newly classed output support can be added via progressive enhancement, by ensuring that the new class is a subclass of the old one and that downstream code uses good practices to test class inheritance.

Thanks to James Azam and Tim Taylor for their very valuable feedback on this post.

Common outbreak analytics tasks

Outbreak analytics in the context of the ongoing mpox outbreak involves several tasks that can be handled by existing and emerging R tools. Some of the tasks include estimating the transmission potential, forecasting infection dynamics, estimating severity, and assessing the impact of interventions.

Here, we briefly describe some common tasks, data required, and the ready R tools/packages developed by the Epiverse-TRACE team and the wider community.

Summary

In this post, we have outlined common outbreak analytics tasks relevant to the mpox outbreak, the data required, and R packages/tools that are currently available to facilitate these tasks. The tools described here are being developed by the Epiverse-TRACE team and the wider community, with the aim of ensuring high standards of research software development, and validation from end users, including epidemiologists, clinicians, and policy makers. The tools are designed to be user-friendly and well integrated, enabling one analysis task to easily feed into another. We would therefore be keen to hear from other groups interested in potentially collaborating or contributing on this growing ecosystem of tools.

Thanks to Karim Mane and Chris Hartgerink for their valuable comments on earlier drafts of this post.

Inherit from standard classes

A unique feature of R is the availability and centrality of data.frames in the base language, whereas you need extra libraries for a similar functionality in most other languages (e.g., pandas in Python).

data.frame is one of the first “complex” (in the sense of non-atomic) object most R learners will be exposed to and will develop a familiarity with. A good way to leverage this familiarity is to make your subclass a thin wrapper around data.frames.

This means that not only will users be able to get started with your package faster because of this familiarity, but you will also immediately benefit from the huge ecosystem of functions and packages working on data.frames, such as the tidyverse. If you want some examples, this is what collaborators and I did in the linelist, pavo, scoringutils, epichains, and vaccineff R packages.

In some cases, the output is too complex to fit into a data.frame. Even in this situation, I would recommend inheriting from existing, well-established, classes for the same two reasons: familiarity and ecosystem. For example, for the serofoi R package, we have made the decision to inherit from stanfit objects, rather than a custom structure.

Rely on parent methods as much as possible

A follow up recommendation from inheriting from standard classes is to leverage their methods wherever possible.

One of the first changes I made when becoming maintainer of the linelist package was to remove the rename.linelist() and select.linelist() methods. Indeed, they were, or could easily be, behaving identically as the parent rename.data.frame() and select.data.frame() methods. Rather than burdening the codebase and maintenance with an extra unnecessary method, it is much simpler and more robust to rely on the well-tested parent method. In fact, the dplyr documentation explicitly recommends only writing methods for a couple of standard functions (including [.subclass() and names<-.subclass()), which will enable the use of parent methods directly, rather than writing custom methods for each dplyr function.

Similarly, many developers have the reflex to write a custom print.subclass() method as part of the method implementation. While it may be justified in some cases, it is sometimes unnecessary. My recommendation would be to evaluate carefully what benefits the custom method brings over the default parent method.

Enable conversion to standard classes

If after careful consideration, extra metadata makes it too difficult to fit your new class into an existing class, you may sometimes have to define your own class from “scratch” (i.e., often list() in R).

But even in this case, you can still apply some of the ideas proposed earlier. As much as possible, you should provide helpers or methods to enable the streamlined conversion of your method to a standard class.

A good example here is the epiparameter package, which provides a complex S3 class built on lists, including extensive metadata about probability distribution of epidemiological parameters. As such, this custom class cannot be used out of the box in most functions from other packages. But an as.function() method is conveniently provided to enable the conversion of this probability distribution parameters into a density distribution, which can then be used in functions which expect a function object.

Conclusion

In summary, I recommend relying on well-established parent classes such as data.frames or at least providing direct conversion functions to these standard classes, and using parent methods wherever possible rather than writing custom dedicated methods. This should help produce a package:

• more easily accessible for users because it uses objects that feel familiar
• more maintainable because a lot of method writing is offloaded to the parent class
• more likely to be interoperable because standard classes are a good way to pass data between functions or packages

Thanks to Chris Hartgerink, James Azam and Josh Lambert, for their very valuable feedback on this post.

Binaries vs building from source

Software, including R packages, can generally be delivered in two forms: as binaries or as source code. If you are building from the source code, you may in some case need a compilation toolchain on your computer. If that toolchain is missing, it can lead to errors such as:

ld: warning: search path '/opt/gfortran/lib' not found
ld: library 'gfortran' not found

Most of the time, regular users of R will not see these errors because they are installing binaries. Indeed, CRAN provides pre-compiled binaries for Windows and macOS for the last version of the package and R.

With renv, you often want to install older versions of the packages, which won’t be available as binaries from CRAN. This means you are more likely to have to compile the package yourself and see this kind of errors, even though renv is not causing them.

Beyond renv scope: incompatibility with system dependency versions

We discussed previously the topic of system dependencies, and dependencies on specific R versions. These special dependencies can also be a source of headaches when using renv.

The heart of the issue is that renv provides a simplified solution to reproducibility: it focuses on R packages and their versions. But other sources of non-reproducibility are outside its scope. In many cases, this will not be a problem, as the main source of non-reproducibility, especially in the relatively short-term, will be R package versions.

But sometimes, it is possible that the renv.lock lockfile requires such an old version of an R package that it was written with a syntax that is no longer supported by recent R versions or modern compilers.

For example, a recent project (from 2023) was trying to install the version 0.60.1 of the matrixStats package (from 2021). This lead to this compilation error:

error: ‘DOUBLE_XMAX’ undeclared (first use in this function); did you mean ‘DBL_MAX’?

! Error installing package 'matrixStats':
=======================================

* installing *source* package ‘matrixStats’ ...
** package ‘matrixStats’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
using C compiler: ‘gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0’
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c 000.init.c -o 000.init.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c allocMatrix2.c -o allocMatrix2.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c anyMissing.c -o anyMissing.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c binCounts.c -o binCounts.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c binMeans.c -o binMeans.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c colCounts.c -o colCounts.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c colOrderStats.c -o colOrderStats.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c colRanges.c -o colRanges.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c diff2.c -o diff2.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c indexByRow.c -o indexByRow.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c logSumExp.c -o logSumExp.o
gcc -I"/usr/share/R/include" -DNDEBUG       -fpic  -g -O2 -ffile-prefix-map=/build/r-base-H0vbME/r-base-4.3.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c mean2.c -o mean2.o
In file included from mean2_lowlevel.h:14,
                 from mean2.c:9:
mean2_lowlevel_template.h: In function ‘mean2_int’:
mean2_lowlevel_template.h:59:13: error: ‘DOUBLE_XMAX’ undeclared (first use in this function); did you mean ‘DBL_MAX’?
   59 |   if (sum > DOUBLE_XMAX) {
      |             ^~~~~~~~~~~
      |             DBL_MAX
mean2_lowlevel_template.h:59:13: note: each undeclared identifier is reported only once for each function it appears in
In file included from mean2_lowlevel.h:18,
                 from mean2.c:9:
mean2_lowlevel_template.h: In function ‘mean2_dbl’:
mean2_lowlevel_template.h:59:13: error: ‘DOUBLE_XMAX’ undeclared (first use in this function); did you mean ‘DBL_MAX’?
   59 |   if (sum > DOUBLE_XMAX) {
      |             ^~~~~~~~~~~
      |             DBL_MAX
make: *** [/usr/lib/R/etc/Makeconf:191: mean2.o] Error 1
ERROR: compilation failed for package ‘matrixStats’

The explanation for this error can be found in the matrixStats release notes, specifically the section for matrixStats 0.63.0:

• Updated native code to use the C99 constant DBL_MAX instead of legacy S constant DOUBLE_XMAX, which is planned to be unsupported in R (>= 4.2.0).

Some solutions