Brian Ward

We had discussions about automatically adjusting the num_single_draws to prevent this but Steve argued successfully that this would be too magic. Cmdstan got a warning for it in https://github.com/stan-dev/cmdstan/pull/1221

We support both options still. If the model was compiled with `STAN_THREADS` we opt in to using the built-in multichain, otherwise we use the older style of spawning multiple processes.

I am seeing this crop up in a package I maintain where we actually do want write access to our artifact (as an aside, is this very bad practice on...

I'm not sure the level of added complexity here, but cons 2 and 3 listed above could be handled automatically - if the service responds with protocol `p3`, and your...

@andrjohns we also have a jenkins M1 runner available we're not using yet (https://github.com/stan-dev/ci-scripts/issues/35) if that would help

@bgoodri the failures in github actions seem to be unrelated. Do you think this could make it into a CRAN patch in the near future?

Sure. I'm going to try to take another look at the rstanarm issue tomorrow, is there something else with StanHeaders?

Yeah, `g++-13: fatal error: Killed signal terminated program cc1plus` and `make[1]: *** [/home/hornik/tmp/R.check/r-patched-gcc/Work/build/etc/Makeconf:200: stanExports_ctsm.o] Terminated` both point to the program being killed, not encountering an error. Either running out of...

Is the plan to use something like https://crowdin.com/ to manage this?

Yeah, wrapping ffistan in rust is on my to-do list after I finish fleshing out the julia/python/R... but I can also imagine situations where someone would prefer a cmdstan wrapper...