From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-10 02:31:03 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!feed.news.nacamar.de!news.belwue.de!news.uni-mannheim.de!th!lucks From: Stefan Lucks Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? Date: Fri, 10 Oct 2003 11:28:51 +0200 Organization: Rechenzentrum Uni-Mannheim Message-ID: References: <3F7F760E.2020901@comcast.net> <3F8035B0.7080902@noplace.com> <3F816A35.4030108@noplace.com> <3F81FBEC.9010103@noplace.com> <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F846B5E.9080502@comcast.net> <3F855460.6020804@noplace.com> NNTP-Posting-Host: th.informatik.uni-mannheim.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: trumpet.uni-mannheim.de 1065778130 15254 134.155.91.85 (10 Oct 2003 09:28:50 GMT) X-Complaints-To: usenet@trumpet.uni-mannheim.de NNTP-Posting-Date: Fri, 10 Oct 2003 09:28:50 +0000 (UTC) In-Reply-To: Xref: archiver1.google.com comp.lang.ada:590 Date: 2003-10-10T11:28:51+02:00 List-Id: On 9 Oct 2003, Stephen Leake wrote: > Stefan Lucks writes: > > 1. a unit test for the package and > > I find Aunit to be a good unit test framework (see > http://savannah.nongnu.org/projects/grace/ for a working example). You missed my point! Think of a "customer" (i.e., any programmer who wants to "with" the library) and call her A. A somehow (perpaps by downloading it from the web site) gets her hands on the source code of some library packages. The very first thing she will (or at least should) do is to ask each package: "Are you okay?" ("Is this package compiling under my compiler and running on my target platform under my target platform's configuration?") The best way to answer this question is to run the entire battery of unit tests which have been used by the author of the library package. I would want to provide A with a simple button to fire the test battery. And this button should be at the same place and have the same shape and color for all packages of the standard library! It is a non-issue for A, which test framework has been used by the author of the library package. > > 2. checking the current version number of package > We could require each top-level package to provide a Version function, > that returns a string. I had been thinking of that. However, natural sting comparison is different from comparing version numbers: "14.3" < "3.14" (Ouch!) > Also follow the Gnu convention of including that string in the tar.gz > file name for distributions. I agree, this is a good convention. But my point is: Allow A to check version numbers automatically, either at compile time or (early) when testing. The Ada compiler is an extremely powerful tool, so use it. > > some.weird.package_name.Full_Self_Test(0); > > The unit test code does _not_ belong in the package itself. If it is, > it would be included in every delivered executable; major waste of > space. It should be in a child package. OK, so use some.weird.package_name.Self_Test.Full_Self_Test(0); instead. (However, I don't quite buy your wast-of-space reason. Any decent linker is able to throw away unused subprograms, right?) > But it's really not reasonable to define unit tests at this level. > Many unit tests require auxiliary packages, which should _not_ be > children (see SAL for examples). Providing a Makefile that runs the > tests and produces a pass/fail is much more reasonable. Didn't Lady Ada free us from using makefiles? :-) And who said that the auxiliary packages should be children? Just "with" them, when implementing your tests. If this does not compile because the "with"ed toolbox is not available, A has no chance to do these tests by herself anyway, even if she'd run make. (I can imagine some special cases and exceptional circumstances, where your test needs external files, system- or platform-specific information, ... This prevents providing the full test battery, i.e. Full_Self_Test can't be implemented. Sometimes, even a reduced test battery could be useful -- call it Main_Self_Test instead of Full_...) > Hmm. I guess you mean one package depends on specific versions of > other packages, I think, you missed my point again. Think as a "customer" A. Consider an application with-ing some library package X version y.z. It has compiled fine, passed all tests, and perhaps it has even passed some code-reviews. Now it is compiled again, either for a different platform, or under a different compiler, or it has been modified/extended, ... There is an implementation of X available, and its version number is v(X). If v(X) = y.z, then fine! If v(X) < y.z, this may indicate great trouble. (However, perhaps A can download and install a more recent version of X.) A's reaction on v(X) > y.z, may depend on her trust in the upward-compatibility of the development of X ... At least for saftety- or security-critical programs (and that is still the area where Ada is best for), it would be prudent to check for things that may be broken by using a version of X which is newer than y.z. The least thing I'd do would be to read the changes-log of X. My point is, I don't want A to *manually* compare y.z with v(X). (There may be many Xs, and thus many pairs (v(X),y.z).) It is much better to do these tests automatically, either at compile time or at least (early) at test time. The Ada compiler is a great tool, so use it to simplify your life! :-) > Just an example of the kinds of discussions an integrated library > committee will be having ... Ackn! -- Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany e-mail: lucks@th.informatik.uni-mannheim.de home: http://th.informatik.uni-mannheim.de/people/lucks/ ------ I love the smell of Cryptanalysis in the morning! ------