This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reenabling Ada by default


James A. Morrison wrote:

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:


   One of the powerful ways people learn is by reading the patch list,
   *if* the patches follow our rules.  A self-contained patch with an
   explanation (and testcase if appropriate) is much easier to grok than
   a sterile jumbo batch.  You merely help maintain Ada's marginal status
   by keeping everything cloistered and the expertise all within ACT.

Actually I disagree. And I would be interested on hearing from anyone who has looked carefully at the GNAT front end. The GNAT front end is remarkably well documented, and (we have a lot of experience in this), the way people learn the front end of GNAT is by reading the GNAT sources. It's something we routinely ask graduate students to do at NYU, and we have many interns who in a couple of weeks can get pretty fluent.

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*.

 Ok, there are less people wanting to learn every scary bit of Ada than say
C++, but that isn't to say they don't exist.  I took a bit of time and looked
at the dejagnu files in the gcc tree to see if I can add some dg style ada
tests.  Unfortunatly, ada/ali.adb didn't compile during the bootstrap on
ppc-linux.

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.

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.

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.

   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.

Well, producing this information will at least be consumed by people reading
gcc-patches.

I am not quite sure what information you are talking about here. Short concise test cases would definitely be helpful, no argument there, but I don't think they would add any information as such.

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]