Various issues incl. memory leak - is this repository maintained?

[joeycumines]

Howdy

Just thought I'd ask, are there any maintainers? I quite like the API this module provides, but it's not in a usable state. I'm guessing that the Gurobi implementation is less broken, but (so far) I've found the following issues (in no particular order), while using this as a base to integrate with LPSolve:

• The LPSolve solver (wrapper) implementation attempts to call set_verbose with a NULL value for lp (setting the log level, within Model.Optimize), and subsequently dies
• Neither the Go module or the LPSolve wrapper handles normalising (possibly the wrong word, not sure) constraints, i.e. if you specify the same variable on both sides of the constraints. Supporting this seems very important for usability. The observable issue is it cannot apply affected constraint properly, and (in my testing) silently ignored it.
• Leaks the solution struct (MIPSolution) returned by the solver implementation - it MUST be deleted, so it seems very advisable to copy all the values into Go-managed memory, instead of using it directly
• Possibly not an issue: It'd be great to get confirmation that it's safe to pass in the pointers to slices
• The high level solver abstraction seems nice / fit for purpose, but the way it is currently structured requires depending on all the solvers / building it all together. It seems (to me) like it'd be better to use a Go interface to abstract a Solver backend / implementation (including lifecycle, so perhaps with a SolverFactory or some such), then implement the solvers entirely independently. This would make it possible to avoid the core implementation depending any solvers, and not require building all solvers, if you only need one.
• Deletion of the solver instance (passed into Model.Optimize) is janky, IMO - deletion is deferred after running the solver, which either makes it unsafe to retain the solver instance if it gets that far, or doesn't delete it / leaks it (in practice it is probably ok, but if the abstraction is changing anyway, it'd be great to address this)
• Having to generate code then manually replace the module is painful - I'm sure there are better solutions, though I don't yet have a firm enough grasp on the problem case / common patterns to confidently recommend anything
• Easy to fix but significant usability issue: No way to get the error code w/o string parsing

I've forked this and I'm hoping I've fixed all the bugs, but I don't really intend to maintain my fork, which is hacked together solely for my own use.

Disclaimer: I'm not sure if I've resolved all the memory leaks, and may be misunderstanding some critical bits. I do, however, have it working, for my use case, pending verification of it not kicking my dog.