Reenabling Ada by default

[James A. Morrison]

Robert Dewar <dewar@gnat.com> writes:

> James A. Morrison wrote:
> > I wouldn't mind seeing patches with some explanation.  Even if that
> > explanation went way over my head, I may be able a term to two to look up and
> > understand what has actually happened.
> 
> My goodness, ALL the GNAT front end patches come with
> explanation. In fact we won't admit a patch to the sources
> which does not come fully documented. If you think that large
> piles of patches are being submitted that are undocumented,
> I can pretty much guarantee that you have not looked at
> them carefully. Not only do we insist on extensive source
> documentation for all changes, but we also insist on
> extensive revision histories that say *why* a change
> was made, rather than just *what*.

 Good for you.  Are these explainations posted to gcc-patches?

> Well we can routinely build ppc-linux GNAT from the current sources,
> so something strange was going on. If you do want to know about GNAT,
> I think you will find the sources pleasantly easy to get into.

 Current FSF sources? I've filed a bug as PR17399.
 
> Just to give an idea of how our internal review works, I look at
> every modified front end file, and do a visual diff (using GPS).
> I then examine the change and make sure it makes sense, and is
> fully documented. I then check the RH to make sure that it is
> complete. If either criterion is not followed, I "negotiate"
> with the submitter. I then make minor style corrections where
> appropriate. I do that once a day with the collected checkins
> for the day, and it is a relatively easy process, precisely
> because all changes are well documented.

 Why can't this be done on gcc-patches?
 
> > It's much easier to do one at a time with nice small inlined or test/plain
> > patches than big gzipped patches.
> 
> Well as one who does spell checks and style checks every day,
> I disagree, it is much easier to do these on an aggregated set
> of of changes.

 Yes, this would be.  However, an aggregated set can be created by some
automatic means.  It's easier to aggregate patches than to pull them apart.

> >>    Having the proper patch submission helps for posterity in case anyone
> >>    needs to go back and examine it later.  The fact that ACT may have
> >>    this information internally fails to help the rest of the world.
> 
> Actually you can follow the development and updates quite easily.
> All the documentation is definitely available externally. What is
> not available is the internal investigation of the bug, typically
> involving a proprietary test case, but all the time I go back in
> revision histories to understand prior changes.
> 
> I really encourage looking at some of the patches. I think that
> some people are operating here with guesses as to what is there
> that does not correspond to reality.

 I try to follow what is on gcc-patches, but they are really big.

> > A dozen people with more resources than a lot of the non-regular gcc
> > contributors.
> 
> Not really, not in terms of having spare time to do non-customer
> essential stuff. Time is at a premium here at AdaCore. If there
> are other companies where programmers have lots of spare time,
> that's definitely a luxury we do not share.

 Why do programmers have to be at a company?  Resources include machine power
and programmer skill.  It takes me a long time to do any gcc builds for any
patches I try to create.  This is partly because I have slow machines, but also
because I spend a lot of time learning.


-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim