From: "Tokoro, David" <tokoro@NOSC.MIL>
Subject: Re: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
Date: 1997/03/19
Date: 1997-03-19T00:00:00+00:00 [thread overview]
Message-ID: <c=US%a=_%p=AQUARIUS%l=CYGNUS-970319215244Z-15083@cygnus.nosc.mil> (raw)
Please REMOVE me from this mailing list.
Thanks,
David M.Tokoro
***************************************
Business Systems Branch N318
Phone: (619) 553-2707
E-mail: tokoro@nosc.mil
***************************************
>----------
>From: Automatic digest processor[SMTP:LISTSERV@LISTSERV.NODAK.EDU]
>Sent: Wednesday, March 19, 1997 1:47 PM
>To: Recipients of INFO-ADA digests
>Subject: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>
>There are 26 messages totalling 1002 lines in this issue.
>
>Topics in this special issue:
>
> 1. Tasking In Ada 83 "Question"
> 2. Do I Really Need A Supervisor? (2)
> 3. Access to primitive operations of tagged types
> 4. Papers on the Ariane-5 crash and Design by Contract (6)
> 5. CRC in Ada? (5)
> 6. Static variables?
> 7. UNIX Texteditor for GNAT Ada95 3.07
> 8. floating point problem (2)
> 9. Ada Sockets
> 10. Gnat 3.04a for 95 wierdness
> 11. Random Numbers
> 12. Please do not start a language war (was Re: Papers on the Ariane-5 crash
> and Design by Contract
> 13. Ariane-5: can you clarify? (Re: Please do not start a language war)
> 14. need free compiler
> 15. numerical libraries
>
>----------------------------------------------------------------------
>
>Date: Tue, 18 Mar 1997 19:50:19 -0600
>From: "James A. Squire" <m193884@CSEHP1.MDC.COM>
>Subject: Re: Tasking In Ada 83 "Question"
>
>In article <332F3050.74B8@mccabe.com>,
>Michael Ibarra <ibarra@mccabe.com> wrote:
>>I have a task, and I want to perform some action when I know that my
>>task has terminated. I can't tell when it has terminated. My task
>>looks something like:
>>
>>Task Body timer is
>>begin
>>loop
>> select
>> accept receive_call do
>> null;
>> end receive_call;
>> or
>> terminate;
>> end select;
>>end loop;
>>end timer;
>>
>>My problem is that in order to check the terminated attribute of the
>>task, I need to with the package that is parent/master to the task,
>>therefore preventing it from becoming terminated.
>
>I don't quite understand this statement. If the task is pretty much
>like you have it there, withing it's parent seems to have absolutely
>nothing to do with preventing it from becoming terminated. Or else
>I don't have enough information here.
>
>It seems to me that what prevents this task from terminating is the
>mere fact that the program is still running, since the only way it
>terminates (apart from some other task aborting it or an exception
>being raised from within) is when all other tasks including the main
>task are finished - hence when the program is finished. There is no
>stop entry, and the loop is endless. The terminate statement only
>ensures that the program won't be left hanging if every other task
>is finished.
>
>>This is NEVER true. Is there any way that I can konw when this task
>>has terminated. I wanted to perform some jobs ONLY after this task
>>is terminated.
>
>If you want to do anything after such a task terminates, then you'll
>have to pick some other way for the task to terminate, it seems to
>me. The options I'm aware of are: (1) adding a Stop entry, (2) adding
>some condition that exits the loop, (3) abort the task. It looks like
>(2) is closest to what you are looking for since you are treating
>termination of this task as if it is non-deterministic to the other tasks
>in your program.
>
>Either that or you need to give us more info.
>--
>James Squire mailto:m193884 no junk mail allowed@csehp1.mdc.com
>MDA Avionics Tools & Processes
>McDonnell Douglas Aerospace http://www.mdc.com/
>Opinions expressed here are my own and NOT my company's
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 14:22:59 -0500
>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: Do I Really Need A Supervisor?
>
><<Obviously people have some complaints here. You've only
>responded with a remark aimed (obviously) to intimidate.>>
>
>Well I understand that some people regard the idea of strong management
>as intimidating, and that's fine, different people work in different ways.
>All I am saying is that as far as I am concerned strong management is
>essential to software quality. Even in such a minor aspect as coding
>standards, if you have a bunch of "I don't need no stinkin' supervisor"
>hackers, you will have trouble solving even this trivial problem (of
>requiring consistent surface syntax).
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 23:34:25 GMT
>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>Subject: Re: Access to primitive operations of tagged types
>
>In article <hkbmg5.2h2.ln@localhost> njt@sv1pc161.cs.york.ac.uk (Nigel J.
>Tracey) writes:
>
>> My problem is however that I cannot pass an access to the callback
>> functions when installing the callback routine in X. The Ada RM
>> states that a dereference of an access-to-subprogram value is never
>> a dispatching call.
>
>Make the "access" registered functions non dispatching, make them
>private (or better yet in a body), and have them _call_ their
>appropriate dispatchable operation.
>
>/Jon
>--
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 20:57:14 GMT
>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>In article <5gll90$2qu$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc
>Jezequel)
>writes:
>
>> To answer Jon S Anthony, yes, all that could have been done in Ada using:
>> function Convert ( Horizontal_Bias: Integer ) return Integer is
>> subtype Bias_Constraint is Integer range 0..Maximum_Bias;
>> Require : Bias_Constraint := Horizontal_Bias;
>>
>> Ada's subtype declarations are a kind of contract, that could be
>> documented as such. Design by contract is not specific to
>> Eiffel. You can do it with any language, just because it is a way of
>> designing! Eiffel is, however, one of the few languages that provide
>> built-in support for it.
>
>You miss my point. Which is that this stuff is NOT sufficient to have
>prevented this error. And further, the evidence supports this
>position because the language used in fact _does_ have this capability
>but it was _not_ used. While design by contract is a good first step,
>it _too_ is simply insufficient as currently realized. It in no way
>captures any of the semantic context that scopes the usage scenarios
>that are assumed in the design and implementaion of "components".
>
>
>> Let's finally sum up what I perceive as the most important claims in
>> this paper:
>> - reusing a component without checking its full
>> specification is dangerous, which means that simple minded
>> CORBA-like approaches at building components for mission-critical
>> software are doomed.
>
>Agreed, but this too is simply way too simplistic. If "full
>specification" simply means signatures and their pre and post
>condition requirements, it does not capture the "full" scope of the
>problem. If it does include the various semantic aspects associated
>with "components", it is not and, what is more, _cannot_ be captured
>in signatures and assertions.
>
>
>> - using design by contract is an interesting
>> way to specify the behavior of a component
>
>Yes, but _only_ a rather _limited_ aspect. It is clearly better than
>nothing, but alone it could not prevent the sort of problem being
>discussed.
>
>
>> - at least in the case of
>> Ariane 501, simple assertions (a la Eiffel and other languages)
>> would have been expressive enough to specify the fatal hidden
>> assumption.
>
>This I simply don't believe. And the evidence does not support it
>either.
>
>
>/Jon
>--
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 21:26:00 -0600
>From: Michael & Amy Hartsough <Hartsough@WORLDNET.ATT.NET>
>Subject: Re: CRC in Ada?
>
>Robert Dewar wrote:
>> Michael said
>> <<I instantiated Sequential I/O with an unsigned 8-bit type>>
>>
>> OUCH! Sequential_IO is intended to be used for logical record I/O.
>> I can see that one might be tempted to write non-portable code that
>> (mis)used Sequential_IO in this manner in Ada 83 if you felt compelled
>> to use the Ada 83 IO packages, instead of the more obvious choice of
>> using C packages for a case like this (Ada 83 really lacked stream io,
>> and in a case like this, which is obviously a case for stream io, the
>> proper response in my view is to interface to C, rather than misuse
>> the Ada packages).
>
>I had been directed to implement CRC32 in Ada 83, and test its output against
>the output of a C++ version of the algorithm. As soon as testing was
>completed
>the CRC32 code (sans file I/O) was lifted out of the test program and
>inserted
>into an existing embedded application that reads data from a PCMCIA card.
>
>So yes, I DID feel compelled to use an Ada 83 I/O package. I don't think my
>employer would have much appreciated my spending half a day chasing down
>some C file I/O routines to improve the throughput of my test program.
>
>> It is not at all surprising
>> that you would see the peformance difference, and it says nothing
>> about Ada-vs-C performance.
>
>Certainly not Ada versus C, but definitely one compiler versus another
>compiler.
>Pick your I/O package and your language, and 18 minutes versus 27 seconds to
>read
>the same file certainly tells you something. HIS compiler (which happens to
>be
>C++) has buffered file I/O. MY compiler (which happens to be Ada 83) does not
>buffer file I/O.
>
> Michael
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 21:57:05 -0600
>From: Ray McVay <bmcvay@ARLINGTON.NET>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>John McCabe wrote:
>>
>> Bertrand Meyer <bertrand@eiffel.com> wrote:
>>
>> >The real problem was that the assertion was not part of the software.
>>
>> No - the real problem was that the developers were _not_ provided with
>> Ariane 5 trajectory information which should have been used in the
>> analysis.
>>
>> Best Regards
>> John McCabe <john@assen.demon.co.uk>
>
>Finally! Thank you, sir. It was obvious from reading the report that
>was pointed out several months ago by a post in this newsgroup that this
>was a wonderful example of a failure WAY early in the lifecycle. It had
>nothing to do with design or construction and everything to do with a
>bogus specification. They were in effect designing a control system for
>a completely different rocket than the one in which the system was used!
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 19:49:37 -0800
>From: nasser@APLDBIO.COM
>Subject: Re: Do I Really Need A Supervisor?
>
>In article <332E163F.5EFD@earthlink.net>, antialias@earthlink.net says...
>>
>>Oh, heck, maybe it didn't belong on comp.lang.ada, but this
>>IS the kind of software engineering environment that Ada
>>software is developed in...
>
>it is unfortunate to the Ada language that it happened to be
>mostly used in environments where zillion levels of managements
>and entrenched beaucracy (sp?) is the norm, this environment is a
>turn off for many programmers who would love otherwise to program
>in Ada but are wary of the surrounding working climate where Ada
>is used.
>
>Nasser
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 22:25:11 -0800
>From: nasser@APLDBIO.COM
>Subject: Re: Static variables?
>
>as Dr Dewar mentioned, package variables retain their values
>from the time the package becomes avaliable to the time the
>package life ends (usually the end of the program , but not
>always the case, example, if the package is declared inside
>a block or procedure), may be a picture will help:
>
>
>
> package A interface
> +---------------------+
> | i: integer; -----------> retain its value also
>client <=======> | procedure foo; |
> | ....... |
> +---------------------+
>
> .............................................
>
> package A body
> +---------------------+
> |j: integer; --------------> these variables retain
> | | their values
> | procedure foo is |
> | n: integer; ------------> variables here are auto
> | begin | variables, new copies are
> | .... | created each time foo is
>called
> | end foo; |
> | |
> | begin |
> | .... ----------------> this code execute once when
> | end A; | package is first elaborated.
> | | use this code to init package
> +---------------------+ variables.
>
>
>you can think of variables declared in the package interface as static puplic
>in C++ class terminolgy, and variables declared in the body of the package
>but outside the functions and procedure of the package body as static
>private in C++.
>
>offcourse it is a good idea to try to avoid using variables in the interface
>part of the package.
>
>nasser
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 10:49:11 +0100
>From: Paul Chardon <paul.chardon@AVIONS.AEROSPATIALE.FR>
>Subject: Re: UNIX Texteditor for GNAT Ada95 3.07
>
>Hello William,
>
> I have been using Emacs or Xemacs with Ada-mode for a few months and
>if ind it very good. You've got syntactycal coloring, you've got some
>options to program faster, and then if you're good in lisp (because
>Emacs uses lisp functions), you can increase the customization offered
>by emacs, as I have done. You can also compile, execute and eventually
>debug within Emacs. A lisp file for Emacs Ada-Mode Emacs is normally
>available with the Gnat.
>
> Bye, Paul.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 00:00:30 -0500
>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: floating point problem
>
>Larry asks
>
><<So can anyone give an example for the Intel-challenged regarding how
>one would easily detect this float-challenged hardware at runtime in
>order to issue a nastygram ?>>
>
>The proper code is a little delicate, but is documented in the relevant
>Intel microprocessor manuals. Note that all DX chips, and of course all
>Pentiums have built-in floating-point, so this is really only a concern
>with ancient machines that you cannot purchase any longer.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 00:05:41 -0500
>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: CRC in Ada?
>
>Graham says
>
><<>Sure you can read character by character, but you are paying a
>considerable
>>price, even in C, for doing so!
>
>Actually: virtually none.>>
>
>Well words like considerable and virtually are not very quantitative.
>There definitely is a price in going character by character (even Balter
>thinks this extra price might be dominant in something like "cat").
>
>Every system where I have measured the effect (e.g. the difference in
>a compiler that reads large blocks, or does character by character reads,
>I have seen enough difference to be worth the effort of doing IO in blocks.
>This is especially true if you can put a sentinel at the end of the block
>that will naturally be detected by your processing, e.g. an end-of-file
>mark of some kind in the compiler case, so that you can then process
>character by character with out a test for buffer exhaustion (once you
>commit to using getchar, you do of course have a test on each character
>read for buffer exhuastion, because at that level it is not under
>your control).
>
>GNAT actually works exactly this way, it reads the entire source with
>a single read, and then puts an end of file sentinel at the end of the
>source. This provides noticable speed up over character by character
>processing.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 12:26:09 +0000
>From: NP GOODGAME <goodganp@ASTON.AC.UK>
>Subject: Ada Sockets
>
>Is there a way to program a socket server completely in Ada 95. I'm
>using gnat as my compiler on a Sun Solaris UNIX workstation.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 05:27:55 -0800
>From: Jim Balter <jqb@NETCOM.COM>
>Subject: Re: CRC in Ada?
>
>Robert Dewar wrote:
>>
>> Jim said
>>
>> <<> If you want something equivalent to the macroized get_char, that is
>> > trivially easily programmed in C on top of stream_IO, perhaps it is
>> > a good idea for a standard package
>>
>> Since that was the original point, this whole discussion has been
>> much ado about nothing.
>> >>
>>
>> Actually I mistyped here, what I meant to say was "easily programmed
>> in Ada on top of [Ada] Stream_IO", and that is what would be a good idea
>> for a standard package.
>
>That's what I took you to mean (i.e., I misread you and thereby
>read you properly).
>
>--
><J Q B>
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 05:32:54 GMT
>From: Richard Kaiser <rkaiser@DIMENSIONAL.COM>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>In article <332E8D5D.400F@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk>
>wrote:
>>Richard Kaiser wrote:
>>
>>> The first mistake was to not put the time limit in some human readable
>>> documentation, or if the time limit was documenting then it was not read.
>>> Writing code so it documents itself reduces or eliminates the code
>>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>>> assembly language and FORTRAN. These limits are part of the design
>>> and belong in a Software Requirements/Requirements Verification document
>>> and in the Version Description Document. And these documents must be
>>> reviewed prior to reuse.
>>
>>The difference between writting comments that document code, and
>>writting assertions is simple. The assertions will get tested, your
>>comments will not. I prefer to trust the latter
>
>But this software was Never tested. No end-to-end test with the hardware,
>nor
>even a software only simulation. If the testing is not performed assertions
>will not be executed to detect a problem. With proper testing the simulated
>flight would have failed with or without the assertions.
>
>>> >2) Design. Writting assertions makes design easier. This is a personal
>>> >observation and harder to justify. I find being clear about what
>>> >something does helps clear up what I am doing. Having complex
>>> >preconditions is not a good idea, again you probably don't have the
>>> >right structure.
>>>
>>> The code is going to say "I am not in my original application and may or
>>> will fail?" Assertions are only going to catch problems if there is:
>>>
>>
>>No, the code does what it is contracted to do. If you break the
>>contract, it raises an exception.
>
>But software testing "never re-read the contract".
>
>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>using #include <assert.h> for years? Software engineers have been using
>assert macros to verify program limits are not exceeded.
>
>Richard Kaiser
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 06:03:15 -0800
>From: Jim Balter <jqb@NETCOM.COM>
>Subject: Re: CRC in Ada?
>
>Robert Dewar wrote:
>>
>> Jim said
>>
>> <<It take an unusual degree of intellectual dishonesty to misrepresent
>> one's own point. No more talk here of extra system calls,
>> buffering not being mandated, or the need to go out and empirically
>> check 6 implementations.>>
>>
>> No, sorry, you are confused, go back and check the thread, I never said
>> that there were extra system calls, that was someone else with whom I
>> disagreed!
>
>I have already quoted you as saying that a single I/O call per block
>by the *C library* (not a comment about ADA) is not guaranteed.
>
>> As for buffering being mandated, I am not quite sure what you are talking
>> about here.
>
>Sorry to here that you are having so much trouble following the thread.
>
>--
><J Q B>
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 12:54:29 GMT
>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>Subject: Re: Gnat 3.04a for 95 wierdness
>
>In article <33259a7a.22085949@news.demon.co.uk>, smoore@chowgar.demon.co.uk
>(Simon Moore) writes:
>
>> p.s. Would it be worthwhile for me to download 3.09 or are the updates
>> minimal?
>
>Ignoring Robert Dewar's specific technical response...
>
>...Any software developer will love you more if problem reports
>are from their latest offering.
>
>Even in cases where a product (not just Ada compilers) has two
>supported versions due to known glitches in the latest version,
>it is that latest version which the developer will be moving on
>to future levels, and for which they want the feedback.
>
>An exception, of course, should be made for cases where the
>defect you find has already been acknowledged by the developer
>and anything stronger than "this affects me too" might be noise.
>
>Again, this is a political rather than a technical tactic.
>You make their life easier and they will have more time to
>make your life easier. There are situations where you may
>prefer to pay a developer large amounts of money to support
>old versions, but those are rare.
>
>Larry Kilgallen
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 15:13:36 GMT
>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>Subject: Re: CRC in Ada?
>
>In article <dewar.858095506@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>writes:
>
> > That's a pretty marginal optimization. Maybe Geert makes subtypes
> > Positive_Float, but of all the code we ever had submitted to us,
> > no one ever bothered to do this, they just used Float.
>
> > Still it can go on the list, it's way down there in priority though,
> > there are MANY more important optimizations ahead of it!
>
> Let me put an optimization way ahead of it on the list and see if
>anyone is interested...
>
> The easiest way of dealing with the A.5.1(37-42) requirements in a
>portable manner is the one currently taken by GNAT--explicit code.
>However, most of these requirements will be met by any IEEE conforming
>implementation. So it should be possible to have two versions of the
>elementary functions packages, one which assumes good underlying math
>libraries, and one which does not.
>
> Note that the hard work here can be done completely separately from
>other compiler maintenance and enhancement activities. It involves
>writing some test code and running it on a lot of different
>platforms. (The way I envision this is a set of alternate bodies, and
>a test program which validates the elisions. Of course, the ultimate
>would be a test program that generated a tailored version of the
>bodies which matched the particular hardware.)
>
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 16:00:14 GMT
>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>Subject: Re: Random Numbers
>
>In article <dewar.858098083@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>writes:
>
> > Don't worry, Robert Eachus is a fanatic here (he wrote the random number
> > generator) :-)
>
> A fanatic? A FANATIC? You dare to call ME a FANATIC on the subject?
>
> Well, maybe. ;-)
>
> > The orignal question came from a student writing a simple card playing
> > program, and I think you will find that the random number routines
> > are quite fine for this purpose!
>
> Oh, they are probably fine for this purpose, even if not used
>correctly. But I would hope that a student would think about the
>issues involved, even if the final decision was to ignore them.
>Learning software engineering involves both learning to recognize the
>issues, and learning to decide which potential problems can be ignored
>in the case at hand.
>
> For example, my daughter had a similar assignment involving robots
>moving one of eight directions in a limited field. Her action if the
>random next move was outside the field was to make a recursive call if
>the direction chosen would take the robot out of the field. Nice
>properties from a bias point of view, but... Her answer to the worst
>case scenario was to put in a comment indicating that the risk of
>stack overflow had been considered and deemed acceptable in this
>environment.
>
> If I was the instructor who handed out either problem, I'd care
>whether students were aware of the issues, not whether they wrote
>perfect code for dealing with all the possibilities. (The card
>dealing problem is easy to handle, especially if the game is poker or
>blackjack. In the robot problem, there is a nasty tradeoff between
>required stack size and bias. You set one value and it determines the
>other. Having three generators is a different approach, but now you
>have to insure that they are truly independent.)
>
> More than you probably wanted to know, but as Robert said, I am
>somewhat of a fanatic on the subject. I've never personally gotten
>burned by a bad PRNG, or misuse of one, but I know several people who
>have. Withdrawing published papers is no fun, as happened to a friend
>of mine who used RANDU. Even worse was one case where the engineer
>involved had to go to the NRC and say the nuclear reactor wasn't as
>safe as they thought. (In fact I don't think the Diablo Canyon
>reactor was ever operated. By the time they fixed the problems that
>the wrong simulation had missed, new earthquake faults were found
>running directly under the reactor.)
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 10:02:30 -0800
>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>Subject: Re: Please do not start a language war (was Re: Papers on the
>Ariane-5
> crash and Design by Contract
>
>Jean-Marc Jezequel wrote:
>>
>> In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington
><GarlingtonKE@lmtas.lmco.com> writes:
>>
>> > 2. No one ran a full integration test with realistic flight data,
>> >which would have
>> > alerted them to the mistake made in #1. Particularly for a
>> >distributed mission-
>> > critical system, this should be considered an absolute
>> >requirement.
>>
>> Yes, this is true. But you have to understand that the mere design of the
>>SRI
>> made it very difficult to test it in an other way that performing a launch.
>> This is because of the tight integration of hard-to-fool hardware with
>software
>> in a black box functional unit.
>
>We have exactly the same coupling of inertials to flight controls on a
>current project, and
>we are able to test the coupled system in a black box environment in our
>labs, with pilots in the loop, performing the same flight profiles we
>expect to see in operation.
>
>Interestingly enough, the IRS for the this project is also "reused" from
>a different platform, and there was a proposal to minimize testing of
>the system because it had already
>been "proven." We were able to quash that "cost-savings" measure before
>it gained much
>support. However, in an environment with Cost As an Independent Variable
>(CAIV), I can
>certainly see how easy it would be to adopt such ideas.
>
>> What can be your test strategy for a black box
>> containing an inertial central? If the software had been designed with less
>coupling
>> on this particular hardware, you could have test the software vs. a
>simulation of the
>> hardware and its environment. Here, the launch was the test.
>
>Is this what Aerospatiale told you?
>
>>
>> >Although I like some of Mr. Meyer's columns, I found this particular
>> >column not only wrong,
>> >but dangerous, since it continues the trend of denigrating sound test
>> >strategy and common
>> >sense system engineering in favor of a software-centric approach.
>>
>> I don't see where it denigrates sound testing. IMHO, sound testing *is*
>needed.
>> And testing is effective only if you have a sound test strategy.
>> Even more when you use programming by contract. In the paper,
>> we just recall that you cannot rely on tests only.
>
>Then why in your message on comp.lang.ada, did you say that to a "lesser
>extent"
>this was an integration test problem? Not doing this testing was a
>*critical*
>part of the problem!
>
>Although I think programming by contract is worthwhile, I still contend
>that there
>is no compelling reason to believe it would have avoided *this
>particular problem*, for
>two reasons:
>
>1. There is strong evidence to believe that the Ariane IV SRI team did
>not see this
> as a particularly important assertion to make (otherwise, they would
>not have
> suppressed the check). In the context of what they knew (the Ariane
>IV flight
> profile), their opinion was at least understandable if not
>justifiable.
>
>2. There is some evidence to indicate that the Ariane V team would not
>have considered
> themselves in violation of the assertion, even if it had been
>explictly coded. Apparently,
> they did not challenge the decision of the Ariane IV team to suppress
>the exception
> checks for the unit. Based on my experience in similar situations, it
>is sometimes
> difficult to translate such high-level information as a flight
>profile to the specific
> range of parameters to be passed to a particular unit. Additionally,
>there is no
> evidence that the software team, reading the source code, had
>sufficient systems
> knowledge and experience to detect the violation of the assertion
>strictly from reading
> the code.
>
>Based on my experience with aerospace systems, and in particular
>integrated inertial and
>flight control systems (from the flight controls side), I see this
>scenario as entirely
>possible. In this case, no amount of documentation at the code level
>would have solved
>the problem, and no amount of embedded run-time checks would solve the
>problem in the
>absence of realistic testing.
>>
>> --
>> Jean-Marc Jezequel Tel : +33 2 99847192
>> IRISA/CNRS Fax : +33 2 99847171
>> Campus de Beaulieu e-mail : jezequel@irisa.fr
>> F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html
>
>--
>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>For job listings, other info: http://www.lmtas.com or
>http://www.lmco.com
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 16:16:45 GMT
>From: Fergus Henderson <fjh@MURLIBOBO.CS.MU.OZ.AU>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>rkaiser@dimensional.com (Richard Kaiser) writes:
>
>>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>>using #include <assert.h> for years? Software engineers have been using
>>assert macros to verify program limits are not exceeded.
>
>The major difference between C/C++/Ada assertions and Eiffel style
>design-by-contract is that in the latter, the assertions are part of
>the interface, not just embedded in the implementation.
>
>--
>Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
>WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
>PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 14:53:35 GMT
>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>Subject: Re: floating point problem
>
>In article <dewar.858142750@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
>writes:
>> Larry asks
>>
>> <<So can anyone give an example for the Intel-challenged regarding how
>> one would easily detect this float-challenged hardware at runtime in
>> order to issue a nastygram ?>>
>>
>> The proper code is a little delicate, but is documented in the relevant
>> Intel microprocessor manuals. Note that all DX chips, and of course all
>> Pentiums have built-in floating-point, so this is really only a concern
>> with ancient machines that you cannot purchase any longer.
>
>So I would gather one cannot do this test from Ada.
>
>As to machine models affected, my concern is that when my program is
>put onto the wrong machine (regardless of any documentation I might
>provide) an unambiguous message regarding the nature of the problem
>is issued to the naive user. Support calls cost money.
>
>Larry Kilgallen
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 21:16:55 GMT
>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>Subject: Re: Ariane-5: can you clarify? (Re: Please do not start a language
>war)
>
>In article <01bc3389$46204f70$b280400a@gavinspc> "Gavin Collings"
><gcollings@sperry-sun.com> writes:
>
>> (2) To treat the software as intrinsically more reliable than the
>> hardware seems to go against all experience and indeed against
>> common sense.
>
>Truer words have never been spoken or written in software circles.
>This should be framed and required to be hung on the wall in all such
>circles.
>
>
>/Jon
>--
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 12:41:01 +0000
>From: Nick Leaton <nickle@CALFP.CO.UK>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>Richard Kaiser wrote:
>
>> The first mistake was to not put the time limit in some human readable
>> documentation, or if the time limit was documenting then it was not read.
>> Writing code so it documents itself reduces or eliminates the code
>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>> assembly language and FORTRAN. These limits are part of the design
>> and belong in a Software Requirements/Requirements Verification document
>> and in the Version Description Document. And these documents must be
>> reviewed prior to reuse.
>
>The difference between writting comments that document code, and
>writting assertions is simple. The assertions will get tested, your
>comments will not. I prefer to trust the latter
>
>> >2) Design. Writting assertions makes design easier. This is a personal
>> >observation and harder to justify. I find being clear about what
>> >something does helps clear up what I am doing. Having complex
>> >preconditions is not a good idea, again you probably don't have the
>> >right structure.
>>
>> The code is going to say "I am not in my original application and may or
>> will fail?" Assertions are only going to catch problems if there is:
>>
>
>No, the code does what it is contracted to do. If you break the
>contract, it raises an exception.
>
>--
>
>Nick
>
>------------------------------
>
>Date: Fri, 14 Mar 1997 14:03:57 -0700
>From: Akihito Tanaka <tanaka@CS.BUY.EDU>
>Subject: need free compiler
>
>I am college student and looking for free ada compiler on the web. My
>prof told me to research on ada language and write a code in ada. If
>you know the sites please tell me.
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 10:15:57 -0800
>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>Thomas wrote:
>>
>> Well, what if a lot more money had been budgeted for hardware? Could
>> the space agency have paid the processor manufacturers to come out
>> with a version that was 30% faster (that should have been sufficient
>> to use runtime checks everywhere without changing the design)?
>
>Some problems with doing that:
>
>1. New designs add risk, since there's not a history of use.
>2. Faster usually means more power/cooling required, which reduces
>payload.
>3. Processor manufacturers charge more for small production runs, which
> cuts into the profit margin. Remember that hardware is a recurring
> cost; software (in the absence of maintenance) isn't.
>
>> Another option could have been to add more individual processors and
>> use them in parallel (almost certainly harder than it sounds, but
>> still a possibility).
>
>1. Adds weight, power and cooling requirements (reducing payload).
>2. Costs more (more parts)
>3. Adds complexity to the design, and thus risk.
>
>> Or what about choosing a less ambitious flight
>> trajectory and maybe lower payload so that control required less
>> computation?
>
>Would have made the Ariane V less competitive, and possibly non-viable.
>
>> Of course, none of those would have been easy choices to make. Design
>> by contract and other methodologies are useful, but I still think
>> without a solid foundation of runtime checks in the production code
>> and multiple exception handlers and recovery blocks, no methodology
>> alone is going to give sufficient protection from failure. In fact,
>> Eiffel itself, which has been mentioned here because of its assertion
>> system, is built on a foundation of runtime safety.
>
>However, runtime safety doesn't do much good if either/or (a) you test
>on the ground to see what exceptions are raised; (b) you know how to
>correct from the exception (in some cases, there IS no good response
>to certain exceptions).
>
>
>--
>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>For job listings, other info: http://www.lmtas.com or
>http://www.lmco.com
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 11:04:14 -0600
>From: Robert Oeckl <oeckl@PHENO.PHYSICS.WISC.EDU>
>Subject: numerical libraries
>
>I am looking for an Ada95 (or Ada83 if no compatiblity problems arise)
>numerics library and am specifically interested in the following
>capabilities:
>
>- special functions: specifically the Exponential Integral function and
> related functions
>
>- high accuracy floating point types: I am looking for accuracies of
> let's say 20 or 25 decimal digits. Best would be (almost) arbitrary
> accuracy
>
>- routines to calculate definite integrals
>
>I would greatly appreciate any help.
>
>Thanks in advance,
>Robert
>
>------------------------------------
>
>Robert Oeckl, graduate student
>University of Wisconsin
>Department of Physics
>1150 University Avenue
>Madison WI 53706-1390, USA
>
>phone: +1 (608) 262-8947
>e-mail: oeckl@pheno.physics.wisc.edu
>
>------------------------------
>
>End of INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>*******************************************************************
>
reply other threads:[~1997-03-19 0:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox