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,FREEMAIL_FROM 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 08:51:33 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc53.POSTED!not-for-mail Message-ID: <3F86D564.3080506@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc53 1065801092 24.34.139.183 (Fri, 10 Oct 2003 15:51:32 GMT) NNTP-Posting-Date: Fri, 10 Oct 2003 15:51:32 GMT Organization: Comcast Online Date: Fri, 10 Oct 2003 15:51:32 GMT Xref: archiver1.google.com comp.lang.ada:610 Date: 2003-10-10T15:51:32+00:00 List-Id: Stephen Leake wrote: > 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. Agreed. I don't think that "built-in" test is necessarily a good idea for all libraries, but I definitely like the idea of having a standalone test program that does the sanity checks and diagnostics. Note that this can't be boolean pass or fail in many cases. Which brings up another point. For many packages a tuning program is just as important as a test procedure. It doesn't need to be as elaborate as ATLAS for BLAS in many cases, but it is often needed. For example, I have a lot of random-number generators that depend on computing X**2 mod N fast for particular values of N. Of course, for most cases a type that is appropriate for storing X mod N, is not going to work for computing the square. (If System.Max_Nonbinary_Modulus is big enough, no problem. Otherwise workarounds are needed.) I've written three or four workarounds, some that are fine if they compile: type Big_Int is range -2**(2*My_Int'Size-1)..2**(2*My_Int'Size-1)-1; Others depend on properties of the floating point types. A program designed to test these workarounds that also does timings would be a great help to people porting the 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. Hmmm. Let me flesh this out a bit. 1) There must be a Version function in the top level package. 2) There may be a Version function in lower level packages. 3) There may be Current_Version string in package specifications. 4) The Version function will normally return a string of the form x{.y{.z}} where x, y, and z are integers, optionally followed by a date. 5) The format of the date, if present, is not specified. But the values shall be such that the String comparison operations ">", etc. return the right results. That last sounds complicated, but all it means is that: "1.2.3 May 3, 2002" and "1.2.4 March 12, 2003" are perfectly fine, but an additional 1.2.4 version such as "1.2.4 April 1, 2003" might not be. The developer of course may have lots of candidate 1.2.4 versions before he releases one. But once he does, it is better if the next version has a new number. Note that even though the Version function is in the package spec, the implementation will be in the body. Which is fine, since the body version can change more frequently. A rule that said that changing the package specification should change the first component of the version might be nice, but I hardly think it is necessary. Now do we encourage the ARG to do the same with Ada, System and Interfaces, and if so what version strings should be returned. ;-) > 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. Um, it is solved for distribution of software in RPM form. But if I post a short program on comp.lang.ada and it depends on a particular revison or later of a library, it would be nice to include the one line check in the soure. If the Version function were more carefully specified that check could be optimized away. Hmmm. Maybe we need two version functions, one that returns a string, and another that returns just an integer reflecting the spec version... > Just an example of the kinds of discussions an integrated library > committee will be having ... Aren't we already having these discussions? -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig