Re: Updating glpk binding to GLPK 4.15

[address@hidden]

And is anything known about binding to lp_solve?
Octave 2.9.9 says "not implemented yet"
However, in their sourseforge download page there is already something
related to Octave
https://sourceforge.net/project/showfiles.php?group_id=145213&package_id=159735
And: is it possible to avoid 2 (it seems to me) very unconvinient things (as
far as I saw in Python wrapper):
1) replace maximizing (default) by minimizing
2) avoid default lb=[0 0 0 ... 0]?
Thank you in advance for your responce,
Dmitrey


Rafael Laboissiere wrote:
> 
> GLPK 4.15 has been released on February 18.  The code is essentially the
> same as in 4.14, the difference being that this new version has libtool
> support and can generate shared libraries.
> 
> Anyway, __glpk__.cc was already broken for 4.14, as it has already been
> posted in this mailing list ten days ago.  The reasons for the failure
> are:
> 
> 1) Neither lib_set_print_hook (or lib_print_hook) nor lib_set_fault_hook
> (or
>    lib_fault_hook) are part of the official API.
> 
> 2) The macro "insist" is not available anymore (it is defined in the
> header
>    file glplib.h, which is no more installed by GLPK in the standard
> place).
> 
> 3) The function lib_env_ptr is not part of the API anymore.  Besides, it
>    accesses the LIBENV structure (which is not part of the API neither).
>    Even worse, the code in __glpk__.cc tries to access the mem_tpeak
> member
>    of LIBENV, which is a structure, by casting it to a double, which is
>    impossible.
> 
> I discussed these issues with Andrew Makhorin, the author of GLPK, and he
> suggested the patch attached below, which I am currently applying to the
> Debian package.  Notice that this patch will not work for versions of GLPK
> prior to 4.14.  To limit Octave to this version or later, the test in
> configure.in should be changed to check only for _glp_lpx_simplex.
> 
> Andrew told me that he will implement a workaround to avoid the direct
> call
> to the _glp_lib_print_hook and _glp_lib_fault_hook functions, which are
> private but accessible from libglpk.so.  Also, notice that the value
> returned in EXTRA.mem is always zero.  I do not now whether it will be
> possible to access, through the public API, the amount of used memory in
> the
> future.
> 
> -- 
> Rafael
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Updating-glpk-binding-to-GLPK-4.15-tf3250570.html#a9039748
Sent from the Octave - Maintainers mailing list archive at Nabble.com.