Stan loading & parsing issues on CRAN

Developers
1

Hi,

Context

I am maintaining an R package for multiple imputation which has a secondary Bayesian implementation which we have implemented in Stan. As the intended / “main” way of using the package is to not use the Bayesian implementation (and because we didn’t want to have Stan on our imports list nor compile the model at install time in order to reduce the friction for users installing the package) we have Stan on our suggests list. Thus in order to use the model we compile and sample from it on the fly caching the model in the users current R temp directory

Problem

We are getting two R CMD check failures related to rstan on 2 specific machines

  1. r-devel-linux-x86_64-fedora-gcc
── Error ('test-draws.R:144:9'): bayes ─────────────────────────────────────────
  Error in `fit_mcmc(designmat = model_df_scaled[, -1, drop = FALSE], outcome = model_df_scaled[, 
      1, drop = TRUE], group = data2[[vars$group]], visit = data2[[vars$visit]], 
      subjid = data2[[vars$subjid]], method = method, quiet = quiet)`: unable to load shared object '/tmp/RtmpBEQrRR/working_dir/RtmpXQXMbb/file11f85b3c2c931e.so':
    libunwind.so.1: cannot open shared object file: No such file or directory
  1. M1mac
Error in `stanc(file = file, model_code = model_code, model_name = model_name, 
      verbose = verbose, obfuscate_model_name = obfuscate_model_name, 
      allow_undefined = allow_undefined, allow_optimizations = allow_optimizations, 
      standalone_functions = standalone_functions, use_opencl = use_opencl, 
      warn_pedantic = warn_pedantic, warn_uninitialized = warn_uninitialized, 
      isystem = isystem)`: parser failed badly; maybe try installing the V8 package

We have been unable to replicate either of these issues on our local machines nor on CRANs mac builder service and we are a bit of a loss for what could possibly be causing the errors. We were hoping someone here might have some insight or pointers that could help us further diagnose the problem.

Thank you for any help or guidance that you might be able to provide.

For reference we had a similar issue a week or so ago which occured when CRAN removed the g++ libraries from the path on their Clang machine however that appeared to just solve itself once the package was re-tested link

2

This is a long shot, but can you try again after removing the ‘#’ character from your file? RStan has some vestigial processing that gets done to your text when a hash character is present that has some known bugs that sometimes show up as the “parser failed badly” error

3

I take it there’s no way to suggest cmdstanr because it’s not on CRAN?

4

Thank you for this. Though if this was the issue would you expect it to be showing up on all of the CRAN machines / builds or would it be viable for it to only error on 1 specific machine as we are seeing ? Regardless we will make the suggested change anyway just in case thank you !

5

Thank you for the suggestion. This is one of the options we are considering; however we are a little hesitant to go down this route as it means having to disable a bunch of tests on CRAN, adds a layer of friction to the installation process (some users just want to install from CRAN and are uncomfortable with installing/compiling additional CLI tools) and adds internal company process complications (admittedly that last one is more of an “us” problem rather than a true technical problem). Am I also right in thinking that as cmdstanr hasn’t had its 1.0.0 release yet that the API is still regarded as unstable ?

6

It’s as stable as the rest of our R software. I wouldn’t control a nuclear reactor with it.

@Jonah—were you waiting for something to update to version 1.0?

It’s not on CRAN, nor do I know if it ever will be. CRAN’s been a thorn in our side for all the reasons you are now experiencing, plus a whole lot more.

7

Actually there is! This is how brms is able to offer cmdstanr as a backend (in addition to rstan). You need to specify the Additional_repositories field in the package’s DESCRIPTION file:

We need to do the 1.0 release! @Bob_Carpenter is right that it’s stable. And a lot of packages (including popular ones like brms) already use cmdstanr.

@andrjohns we should prioritize the 1.0 release to avoid giving the impression that the API isn’t stable. I’ll open an issue on GitHub so we can move the discussion there to see if there’s anything we want to get in before doing 1.0.

8

Agreed!