RE: Re: Re: Re: octave-glpk MIPGAP

[Tommaso Balercia]

2012/01/20 Jordi Gutiérrez Hermoso

> I wish Tommaso had followed our coding standards... It's very difficult
> for me to know if all of his changes are important or not. I also wish
> I could get an explanation of what the changes are (a commit message). 
> Having to do this work myself makes me lazy and delays pushing this patch.
> A diff would have been preferrable.

Hi Jordi, I'm sorry but I'm in a serious shortage of spare time at the moment.
And I'm afriad I can't be of assistance in trimming the patch.

This said, the commit message could be something in the range of:

'Updated glpk to support all the features offered by GLPK 4.36+'

As for the diff, they are just two files. The diffs can be easily generated 
from the originals in 3.4.3. Just keep a vanilla version of 3.4.3 and one with
the files I attached in the other email and let hg do the magic.

Finally, I would like to say that I adhered to the style used in GLPKMEX, 
the MATLAB counterpart of the patch. Keeping the two pieces of code with
a similar look might make sense, but feel free to manipulate it according
to Octave's guidelines. Maybe using astyle as somebody else suggested in 
another occasion?

> At any rate, it's obviously too late to include this in 3.6. 

No problem. I wrote the patch because I needed it myself. It served its
purpose. If you want to include it, I think others could benefit from the
potentialities it offers. Otherwise, no hard feelings. :-)

> 1) A proper patch
> 2) A commit message
> 3) Reformat to follow Octave's GNU coding standards

See above.

> 4) Properly written tests to show that the changes work (i.e.
>    included as part of the patch, in the glpk.m source file)

If Marcelo agrees, we can use his own code as a test. Additionally we can point
to MIP libs for more elaborate test. GLPKMEX includes my own Python script to 
import MPS files. We can reuse that if you want.

Kind regards,

Tommaso Balercia