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-09 09:17:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? Date: 09 Oct 2003 12:10:55 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) 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: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1065716047 5249 128.183.235.92 (9 Oct 2003 16:14:07 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 9 Oct 2003 16:14:07 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Xref: archiver1.google.com comp.lang.ada:541 Date: 2003-10-09T16:14:07+00:00 List-Id: Stefan Lucks writes: > I like the baby-step proposal. > > However, such a standard library would rather be a collection of different > sublibraries (typically packages), and the interfaces would not always be > consistent. That is unavoidable, Perhaps "really expensive", or "hard to achieve". It is _not_ "unavoidable". I hate all absolutes :). > and most programmers could live with that. (Even e.g. the JAVA > library is not always consistent, though its designers did seriously > try ...) Which is one reason I don't like the Java libraries. But a lot of programmers do live with them. It would be a great selling point if the Ada library did _not_ have that problem! > One problem with any library is that you may be using different > versions on different platforms. Why would that happen? The Gnu tools manage many platforms with no version problems. Well, some poorly-supported platforms may take a while to catch up to the latest version, but "gcc 2.8.1" means the same thing on all platforms. > Another problem is that if you fetch the library from some web site > (which is assumed for the baby-step propoal), you may first want to > check if it runs in your environment at all. Yes, which is why all library packages must come with complete tests. Again, the Gnu tools typically come with tests (well, the compiler doesn't, but the others do). Yes, this is more work, but it is what makes the library usable. > One thing that might significantly improve the acceptance for such a > collection of (sub-)libraries would be to support a *standartised* > *interface* at least for > > 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). > 2. checking the current version number of package We could require each top-level package to provide a Version function, that returns a string. Also follow the Gnu convention of including that string in the tar.gz file name for distributions. > This would help people to actually integrate these library packages into > their stuff, doing automatic unit and integration tests ... yes. Note that SAL (http://www.toadmail.com/~ada_wizard/) does this. So let's all just use SAL :). > Also, this does not seem to hinder the integration of already existing > libraries into the standard library: > > -- Dealing with the version number is trivial, anyway. > > -- Assuming the authors of the already existing library did implement > unit tests for their library at all, writing one additional > procedure for doing the full unit test can't be too difficult. Well, switching from one unit test framework to another is painful. For example, most of the SAL unit tests do _not_ use the Aunit framework, because I discovered that late in the process. The non-Aunit tests write output files, which are diffed (by the Makefile) against known-good output files. It is a _major_ amount of work to change those tests to Aunit style. But as long as the Makefile can return a Pass/Fail status, it doesn't matter too much. More important are things like standard names for common operations; do we "Add" an element to a container, or "Insert" it? That's a major problem for integrating existing code. SAL attempts to do this, but doesn't fully succeed. > Consider you *with'ed* the package "some.weird.package_name" from > the standard library. Without having to look into either source code > or other documentation, I'd like to compile and then run a unit test > by calling: > > 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. 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. > Checking the version number should be done similarly. You can't always > prevent version skew, but can automatically detect potential > problems. Hmm. I guess you mean one package depends on specific versions of other packages, and you want to check that at run-time (or better, compile time). That problem is solved by tools like Redhat Package Manager (rpm); it's a big problem, and we should not try to invent new solutions. Just an example of the kinds of discussions an integrated library committee will be having ... -- -- Stephe