On Sat, Jan 17, 2009 at 6:44 PM, mabshoff <mabsh...@googlemail.com> wrote: > > > > 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.
This is a good measure of code quality, and certainly a good minimum thing to strive for in software engineering. > >> 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. +1 I strongly agree with the above comment. If one is porting Sage to system X, then the more one can break down the testing issues the better, for numerous reasons. It's bad if in order to test and debug a little 200K program, it is important that all of the rest of Sage has been built and is working. > 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. I think you mean "thrown out". I am sympathetic. > 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. I don't think there should even be a vote until you sign off on the platform support. Getting new packages into sage involves two things: (1) a list of minimum requirements about code quality and portability, and (2) sufficient interest and support by the community. IMHO, lrs is in stage (1) right now. Voting should be mainly for stage (2). William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
