I’ve uploaded a new snapshot of Solver up on the usual place. The difference from the last snapshot is that the Solver now uses lp_solve as the backend LP optimizer. lp_solve is quite a robust optimizer currently developed and maintained by Kjell Eikland and Peter Notebaert. It has an excellent track record with users across many industries, so if you have a model that my Solver failed to solve previously, try out this snapshot to see if it will do a better job for you.

Now that the UNO package version of my Solver is finally out after a long 4-month hiatus , my next immediate task is to work on integrating this lp_solve-based Solver into ooo-build. For this, I will take a different integration strategy.

To recap, the strategy I took to implement the lp_solve-based Solver (this snapshot) was to add a UNO layer to lp_solve to turn it into a UNO library, and add a UNO hook to the main Solver component to glue the two separate components. This strategy was necessary despite its over-complexity and obvious overhead because, currently, it is not possible to include a shared library into a UNO package unless it provides a UNO service, or the package registration will simply fail. This is because OO.o expects every library included inside a package to export a certain set of callback functions for component registration, or it will balk at it.

The integration into the build, however, will be much simpler because there is no need for component registration. So I can simply have the Solver core library dynamically link to it and avoid the overhead of UNO. The downside of this is that I have to write additional code for it ;-), but I expect it to take only a minimal amount of effort.

*Related*

## Published by Kohei Yoshida

LibreOffice contributor, spreadsheet nerd, and machine learning beginner.
View all posts by Kohei Yoshida