Oscar Dowson

This is unrelated. It's probably a bug in OptimizationMOI.jl. Do you have a stack trace of the segfault?

I don't know what the return type of `hess_prototype = similar(hess, Float64)` is, but yes, you need to use a sparsity structure that is valid for _all_ x, including values...

I don't know what we can or should do here. Calling into C is dangerous, especially calling symbols which don't exist.

It feels like a few of these cones could be kept in Hypatia for now? Or some "ConicExtensions.jl" package? We're adding cones that only one (unreleased) solver supports.

Is this still important? What solvers support it?

Closing for now as out-of-scope. Let's wait until we have someone ask for the modeling capability and/or a few solvers natively support it.

This came up in https://github.com/jump-dev/MiniZinc.jl. I'd like to be able to use `MiniZinc.Optimizer{Int}(MiniZinc.Chuffed())` and have all coefficients converted to `Int`, and throw an appropriate error if they can't be converted....

I still think the fix for this issue is https://github.com/jump-dev/MathOptInterface.jl/pull/1879.

Hmmmmmm. I don't know if we've ever classified `RelativeGap` as a settable attribute. It's not solver-independent because every solver implements it differently.

Yeah so the difference is: * `ModelAttribute`s are typically part of the solution information. In this case, `is_set_by_optimize(::RelativeGap) = true`: https://github.com/jump-dev/MathOptInterface.jl/blob/bcc869f09bc3916683c6d296237ba5bfe25aa6f9/src/attributes.jl#L1968 * `OptimizerAttribute`s are things like solver parameters. So `RelativeGap`...