David Widmann

(Generally, I also think it would be good to aim for consistency in the Turing ecosystem and move to a more unified AD experience. I think I've mentioned before that...

> So I think it's really AdvancedVI.jl that needs its own solution. Could we at least share a common user interface for specifying the AD backend (i.e., `ADTypes` or something...

This is a longstanding issue and should be improved. The main reason for why currently not the progress of individual samples is shown is that it is a bit challenging...

Related: https://github.com/JuliaLogging/ProgressLogging.jl/issues/27, https://github.com/JuliaLogging/ProgressLogging.jl/issues/33, https://github.com/JuliaLogging/ProgressLogging.jl/issues/37, https://github.com/JuliaLogging/ProgressLogging.jl/issues/38

I thought about injecting a callback, and maybe it's the best solution. But there's a major problem: we don't call `mcmcsample` but `sample` since users/developers don't have to use the...

That's exactly what's done currently, but maybe you mean something else? You just have to write a `sample` method for a single chain or implement the next layer interface if...

> fit should always default to MLE (if it doesn't, that's a bug), No, that's not correct. Usually it's MLE but it does not have to be (stated also in...

Why was this PR merged?

To explain: I'm not per se against the changes (as commented above) but IMO it is absolutely not OK to merge your own PRs in a repo not owned by...

Given that there are no constraints or specifications on fields, parameters, and constructors I don't think any such implementation will generally work. The cleanest approach would be to implement https://github.com/JuliaGPU/Adapt.jl...