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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5752ba976f4dad11 X-Google-Attributes: gid103376,public From: jschafer1@iquest.net Subject: Re: GNAT 3.01 Source For OS/2 Date: 1996/05/05 Message-ID: X-Deja-AN: 153117092 sender: news@iquest.net (News Admin) x-nntp-posting-host: ind-000-236-57.iquest.net references: organization: IQuest Internet, Inc. reply-to: jschafer1@iquest.net newsgroups: comp.lang.ada Date: 1996-05-05T00:00:00+00:00 List-Id: > From: dewar@cs.nyu.edu (Robert Dewar) > Newsgroups: comp.lang.ada > Subject: Re: GNAT 3.01 Source For OS/2 > Date: 3 May 1996 14:39:15 -0400 > Message-ID: > References: > > Frankly I did not bother to read this whole diatribe, though I have stashed > it away in case I do later, but I will address one point: > OH. So you simply ignore the issues to the best of your ability. > > In fact we debug and release with checks off and assertions on. Our > assertion approach is very complete, and our experience was that > constraint checks > > a) never found a single real bug > OH. So the improper initialization of a Decriminant_Constraint when deriving tagged types is NOT a real bug ????? > > b) did cause some bombs that were not real bugs in the sense that if > constraint checks were off, the functoinality would be correct. > OH. So the assertion error caused by the inproper initialization of the Discriminant_Constraint field is NOT an error in the program either ???? Since the range check would have caught it, and you don't concider range checking usefull, it must not be a problem that the compiler fails with an assertion error when you DO turn off range checks ???? > > All the cases we found were confusions between Natural and Integer, which > of course are just fixed by using the right subtype. > OH. So you admit your coders where confused about the differences between Natural and Integer and you chose to hide the problem rather then make a simple change in the source code ???? Had these coders ever used Ada in the real world before working on GNAT ???? > > We prefer to test with exactly the same options we use for release, which > is why we tend not to use the constraint checks for internal testing either. > It is true that it would be a good idea to run occasionally to smoke out > problems like this, but they are hardly high priority problems given that > they don't affect user programs! > OH. Croaking programs are NOT a problem ?!?!? > > But just to be clear, the 3.03 releases exactly match the 3.03 sources > if you build in the standard manner, which everyone else seems to have > no trouble doing. > OH. So there is some magical way in which people get informed that the makefile distributed with the 3.03 source has the WRONG switches in it ???? > P.S. the problem with actual subtypes is subtle, not something I would > expect to be easily noticed -- after all this fix was not put on till > later. > OH. So I SHOULDN"T notice a change from 2-3 mins compile time to over 36 hours for the SAME unit ????? I guess it is just rediculous for me to assume that GNAT should be usable on a machine with less than 32-64 Mb of memory ???? > > By the way, the 3.01 sources are and always have been at cs.nyu.edu > as far as I know. Several people emailed me to tell me they were there! > OH. So you make claims without checking it out first !!!!! > > Going back to the constraint error situation, I can actually give the > specific example where this caused trouble. In the 2.04 release, ew > had a problem that certain error messages caused constraint errors. > There weren't any instances of these messages in our regression suite > so we had missed this (now of course there are dozens of instances of > those messages). > > This turned out to be just a matter of natural vs integer. We had turned > on constraint checks for the release to increase the reliability, and > oddly, if had significantly decreased the reliability. That was the point > at which we realized that constraint chceks had never been useful to us > anyway given our assertions (which are pretty extensive, the front end > spends 80-90% of the execution time executing assertion statements), > so we removed them and never put them back. > OH. So you found out that if you make incorrect code the compiler makes it glaringly obvious, so you chose to hide your mistakes !!!! > > Actually in the near future, we may release without the assertion checks. > It is possible that the constraint checks will then prove useful again, > we are currently making some measurements to find out what the best > apporach is. > OH. No doubt to hide the assertion errors generated because you didn't fix the bugs found with range checking. > > As for the unsatisfied customer here, I guess that just goes to show you > cannot make everyone happy. We will be happy to refund what he paid for > GNAT, since he does not think it is worth it :-) > OH. You still can't get it into your head that I don't WANT the executables ACT produces. I prefer to build the compiler from source so I know exactly what I am getting. And your "unstatisfied customer" idea is rediculous. You can claim me as a customer when you get some cash from me. But that's not going to happen anytime soon :-) Joe Schafer jschafer@iquest.net