On Jan 17, 12:56 pm, mhampton <hampto...@gmail.com> wrote:
> On Jan 17, 8:36 am, mabshoff <mabsh...@googlemail.com> wrote:
Hi,
> > But the code certainly needs prettying up, i.e. I couldn't find a test
> > suite, the files were all dumped in the same directory and on and on.
> > If upstream is interested I could certainly make some suggestions.
>
> I don't think for such a small program that the directory structure is
> terribly important; I tend to like a flat file structure.
I disagree. Having src, include, test, doc, example make it instantly
understandable what is what.
> There are already some tests for it in the optional code in
> polyhedra.py, and I would be happy to add more. Then we would be
> testing it through sage.
No, this is wrong. Stein's Axiom I: Everything not tested is broken.
I want to be able to run "make check" on the code and not depend on
anything else to verify that the code works. *Every* time we merge
code this way and just assume that Sage's test suite will pick up all
the issues I am the one who is getting screwed with the prime examples
being Symmetrica and SYMPOW debugging on more exotic platforms.
Writing tests for this code should be easy since you already have a
command line mode. And since you can use it from Sage via pexpect it
should be trivial to add a bunch of tests by logging the traffic.
If you look at the Makefile of this code you should clearly see that
it needs cleaning up and rewriting it from scratch in this case might
be easier since only a couple files are involved. On problem right off
the bat is that compiler as well as build flags are hard coded for
each file. So if you do something about that and add tests someone
might as well as put files into proper directories, etc.
And lrs can be build as a library and probably will so be integrated
in Sage in the future. Since there are issues with LLP64 this is not a
fun thing to debug, i.e. anything that can go wrong will lead to a
segfault which isn't fun to debug because it happens *in* Python or
the Sage library, and I wouldn't want to do it via Sage. How things
like this can get screwed up badly (and this is not even a LLP64
issue) is Symmetrica where we see segfaults on Solaris in 32 bit mode
when running some examples. There is a test suite of about 400
examples (at least according to the documentation) and after numerous
attempts to contact the author we still don't have the files. The
author does not reply to emails or bug reports and because of that as
well as the truly horribly nature of the code (worst abuse of the
preprocessor I have *ever* seen) I have lobbied to get the code thrown
it. Without the test suite it is unclear if Symmetrica even works
reliably on all the platforms I am building Sage on. The same case
about upstream who cannot be bothered to even reply to emails from a
variety of Sage devs is the cddlib upstream. We have send a couple
build system improvements to upstream and six months later we haven't
even gotten an acknowledgment. I have gotten code put on the removal
list, i.e. quaddouble, because it did not work cross platform. And I
will make damn sure no other project like that where I have doubts
about quality will get into Sage. lrs also has LLP64 issues which
will become relevant if it is used as a library from Sage as mentioned
above and that is a killer knock out punch for me right there.
All of the above leads me to the following conclusion: If upstream is
not willing to help out with doing fresh releases or making
improvements we ask for the code in question is not meant to be in
Sage. The maintenance in this situation often enough ends up in my lap
and I am sick and tired of it. I am not saying that this is the case
here, but if you want to see how communication about issues in code
should look like I would recommend you look at recent conversations on
the flint-devel mailing list I had with Bill Hart. The fact that lrs
does not have a mailing list, did not have a release since 2006 and so
on does not make me bullish.
Having all said the above I am more than happy to help out fixing
those issues in lrs, but my approval will only happen when I see that
upstream is willing to pitch in. Obviously you might "win" this vote,
but even then I will appeal to the JSage board and argue that the code
quality of lrs is not up to the standard we want. And I am pretty sure
the board members will listen to my arguments.
> That seems like the easiest way to add
> tests, unless David Avis is interested in adding it upstream.
>
> -Marshall
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
