Oscar Dowson

You should interpolate the type into the string that is being checked against. Instead of `"MOI.ScalarAffineFunction{Float64}"`, use `"$(MOI.ScalarAffineFunction{Float64})"`.

Looks like you need to update these sorts of lines https://github.com/jump-dev/MathOptInterface.jl/blob/e0f8b05682d98ae0d45812e1ca7bb6183053c148/test/Bridges/lazy_bridge_optimizer.jl#L352

I think we can count printing changes as non-breaking (that's what Julia has done between minor versions), so I'm not worried about that. Keeping this as a 1.x item.

@haoxiangyang89 found the likely culprit in https://github.com/odow/SDDP.jl/issues/477: the dual isn't defined at the point of a SecondOrderCone. I'll see if I can reproduce. @adow031 / @drandyphilpott you should add a...

Oh great! I've been struggling to reproduce this. Can you try adding constraints such that ```Julia (p_max[g] - p[g] + sum(alpha[g, i]*mu[i] for i = 1:n_w)) >= 0.001 ``` My...

If you don't include the constraints, what is `value.(max_prod)` and `value.(min_prod)` of the optimal solution?

> This is what I get Interesting. We obviously need to dig a bit deeper to understand what's going on. I don't really have time to do this, unfortunately. cc...

I don't think we want to add a binary dependency just to compute this factorization, and the license issue is a problem. So not sure what is actionable here?

I think this is the wrong fix. The ZeroOne bridge should add `1x in [0, 1]`, instead of `x in [0, 1]`. It's the bridge that is broken, not the...

Sure, this is still pretty expected. Julia 1.8 has a number of fixes for M1, but until it is Tier 1 support, I would stick with Rosetta.