--- Humberto Ortiz Zuazaga <[EMAIL PROTECTED]> wrote: > This means that any gardener's solution for tracking > dependencies has to be better than apt, which is a tall order.
Actually, it's a different level of problem you're talking about. Debian/apt has to do the work of ensuring compatibility between other types of libraries and software - its just in that most cases there is only 1 compiler which has lots of things to compile (gcc for c, g++ for c++, etc.) whereas lisp has as many as five or six DIFFERENT compilers, each with their own entire environment, trying to copmile libraries each of which was probably targeted at (at most) two or three of those environments. And library developers may nor may not update their lisp - sometimes they might see no need to rock the boat, so to speak, particularly in a mission cricitcal situation. > Does anyone have ideas on a system that can track dependencies > between libraries and implementations better than what's > currently in apt? Things like Lisp Critic and especially Paul Dietz's ANSI compliance tests can go a long way toward reducing some of these problems, but the fact is we have both lisp implementations and lisp libraries in constant flux. As for ideas, I have some but they will probably not appeal to too many people: a) For each library of interest, define extensive unit testing as part of the development process. There are a number of frameworks available - we should probably take the best one, grab any extra features from the other ones, and proceed to document and unit test the heck out of every major popular common lisp library, however large or small. b) Once a is in a reasonable state (it will have to be an ongoing thing) have each new release of a lisp distribution (clisp, gcl, cmucl, sbcl, ecl, openmcl, etc.) run the unit tests of all libraries with a unit test set defined. This will spot a rather large subset of problems BEFORE a release is made, and the maintainers (or, failing that, the gardners ;-) move in and fix either the problem with the lisp implementation, or the problem with the library - whatever makes more sense. c) Have part of the install process be to run the full unit test for every library being installed on the target lisp. If the unit test succeeds, there will be a decent chance the library will function as expected. If it fails, it will be obvious where the failure is and there will be an immediately available test condition. This may be overkill in light of b) but it will test different platforms, versions of supporting libraries, and will catch more subtle errors that b) wouldn't catch without being run on a huge, diverse compile farm. If we REALLY want to have some fun, we could generate a massive tree describing dependancies between all parts of libraries and implementations, and any time a release is made anywhere test automatically just the parts depending on the changed areas, but I doubt that would be less CPU power than just running full unit tests. The nature of lisp development today rules out more formal methods, except possibly on code that implements the ANSI spec itself - its in too much flux. So I think the next best thing is to define a massive and highly inclusive unit test web through the lisp world. Of course that can get tricky with graphics libraries, but there is probably some way to proceed. The nice part about this is that it shouldn't be all that hard in theory - unit test frameworks don't take too much time to learn, and then its a case of deciding what relevant tests are for various parts of the code, and writing the definitions. Also useful would be a routine that goes through a library and lists which functions were NOT unit tested. When a test set becomes fairly complete, running this before release will catch new code that has not had tests defined for it yet. In practice, this will be extremely hard because of the need to have good documentation and understanding available for a vast amount of code. However, it might be a perfect task for the newer lispers on the gardners list, as it would offer an opportunity to learn the guts of their favorite library and contribute usefully at the same time. I realize this is a casual proposal for such a far reaching solution, but I don't really know of any other way to proceed. We also have the problem that so many libraries are written specifically for one lisp - FFIs being the classic example, but there are others. This approach may help highlight the nitty gritty that is involved with such issues. I guess we could call it Operation BugHunt - going through the garden leaf by leaf looking for small things eating at the plants, and spraying on unit tests to keep them from coming back ;-). Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
