Re: GNAT 3.01 Source For OS/2

[jschafer1@iquest.net]

> 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: <dewar.831148051@schonberg>
> References: <DqBxv9.GBL@iquest.net> <dewar.830403010@schonberg> <DqIBno.2E7@iquest.net> <dewar.830619408@schonberg> <DqpIv9.Ku1@iquest.net>
> 
> 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