On 11/25/10 8:49 AM, Sam Steingold wrote:
>> * Fred Cohen <sp@...> [2010-11-24 08:53:43 -0800]:
> CLISP has 3 test suites:
> 1. "the original" clisp test suite in tests/
> 2. the SACLA tests in sacla-tests
> 3. the ANSI CL test suite (downloaded separately) from
> Which ones do you want to distribute with clisp?
All of them? Why not include them? If it's just a bot more disk space,
> At any rate, I see no point in distributing the self-test suites for the
> core of clisp as a part of the main clisp binary distribution (you are,
> of course, welcome to develop the clisp-test package and convince the
> major linux distributors to distribute it - actually, I think the
> ansi-cl test suite might already be available).
Not burned into the binary - as a loadable module that is always present
(by default) and installed, etc. (by default) so that they can be
readily loaded by anyone at any time to run the tests.
> I can imagine some use for distributing the external module test suites
> (because these might discover subtle incompatibilities between the
> interface built for one version of the external library and the actually
> installed library).
For higher surety environments, legal settings, etc. it is particularly
useful to have self-tests readily available as an added assurance that
the software is operating as intended just before and after the actual
critical action is done. For example, if you are going to run a lisp
program to do a statistical analysis of a collection of data, you would
run standard statistical tests against known values just before and
after running the actual analysis, and be able to confirm (or refute)
that the tests themselves were working as intended. This is particularly
useful in cases where the thing you are testing gets destroyed in the
process of testing, or when the operation performed based on the program
run are potentially harmful, irreversible, etc.
I also very much like the notion that at runtime things may not be
working as intended and such tests might detect them. For example, if
file access to the disk in question is flaky, space is near the edge,
etc. proper testing just before use and after might demonstrate that the
system is not functioning as intended and prevent mistakes.
>> As an aside, on the makefile thing, I would like to see the default
>> "make" be the one that produces the everything works and nothing else to
>> do result - so that:
>> make install
>> by default produces the full up everything we need to do everything is
>> installed and ready to go, rather than doing this and then finding out
>> that I needed to go and download some library from somewhere and do the
>> same process for it before restarting the clisp build process. But
>> that's a different matter...
> I can see this as being useful, but I am not sure this is _always_ what
> _all_ people want.
I agree that there will be limits - but the things that are normally
expected, like sigsegv and command line editing, but that are different
on different platforms, are a problem every time. It just seems like the
kind of thing that could be automated in make and eliminate the vast
majority of wasted time and effort.
> E.g., if you specifically want the postgresql module, the above will not
> detect that postgresql-dev is not installed and will build clisp without
> the postgresql module.
-This communication is confidential to the parties I intend it to serve-
Fred Cohen & Associates tel/fax: 925-454-0171
http://all.net/ 572 Leona Drive Livermore, CA 94550
Join http://groups.google.com/group/fca-announce for our mailing list