Re: Reenabling Ada by default

Re: Reenabling Ada by default

[Richard Kenner]

    Easy.  These are the last four patches sibmitted by Arno submitted
    over the last month.  Note they don't occur on a daily basis as
    previously claimed.

The claim was that they are submitted on a daily basis *when the tree
isn't broken for Ada*.  There were not that many such days in the last month!

    They are all just ChangeLogs and attached gzip files.  There is no
    explanation of what's being changed or why.  This is entirely opaque.

The ChangeLog says what's being changed, as required.

Re: Reenabling Ada by default

[Kaveh R. Ghazi]

 > From: Richard Kenner
 > 
 >     They are all just ChangeLogs and attached gzip files.  There is no
 >     explanation of what's being changed or why.  This is entirely
 >     opaque.
 > 
 > The ChangeLog says what's being changed, as required.

Pointing out one small facet of compliance is irrelevant, there are
*additional* requirements which are not being met.

You are also required to explain IN PROSE what you are doing and WHY.
You are also supposed to reduce your patch to an INDIVIDUAL CHANGE.

This is getting exasperating, see:
http://gcc.gnu.org/contribute.html#patches

Read the last section titled "Submitting patches" and keep rereading
it until you understand those code drops are not in harmony with the
GCC patch policy.  Seriously.  Read it.

Do you now see a difference between the Ada code drops and my counter
example patch posting from rth?  (If not, go back and reread.)  Note
again rth needs no approval to commit, so we're not talking about
commit approval review.

He simply follows the patch rules like everybody else, because the
extra detail he provides and the discrete patch he created has value
above the particular bugfix he installed and we as a community have
decided years ago everyone must do this.  ACT included.  Period.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Reenabling Ada by default

[Per Bothner]

Florian Weimer wrote:

> Can you provide a pointer to a short, high-level documentation of this
> approach?

Tom posted my original design proposal.

> It's probably a standard implementation technique for OO languages,

Not as far as I know, but I don't know the literature that well.
It's possible it's a variant of a published technique, but not
to my knowledge.  I've been wanting to write it up as a paper,
but never got around to it.  It's also
possible that caching techniques may work better with todays
processors, where locality is everything.  Of course caching can
be combined with gcj's indirect dispatch when the cache fails
- if the numbers were to show it makes sense.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Reenabling Ada by default

[Tom Tromey]

>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:

Florian> * Per Bothner:
Per> You might also look at the GCJ way of implementing Java interfaces.
Per> An object reference is a plain pointer, and there are not extra
Per> per-object "vobject" fields as in C++.  Instead we use a kind of
Per> double dispatch using initialization-time-computed indexin, which
Per> yields constant-time dispatch.

Florian> Can you provide a pointer to a short, high-level documentation of this
Florian> approach?

http://gcc.gnu.org/ml/java/1999-q3/msg00377.html

Tom

Re: Reenabling Ada by default

[Robert Dewar]

Florian Weimer wrote:
> * Per Bothner:
> 
> 
>>You might also look at the GCJ way of implementing Java interfaces.
>>An object reference is a plain pointer, and there are not extra
>>per-object "vobject" fields as in C++.  Instead we use a kind of
>>double dispatch using initialization-time-computed indexin, which
>>yields constant-time dispatch.
> 
> 
> Can you provide a pointer to a short, high-level documentation of this
> approach?
> 
> It's probably a standard implementation technique for OO languages,
> but by just looking at the code, I've trouble understanding what's
> going on.

To bring this thread back a little closer to the subject (at least
wrt Ada), we are updating our design document with all the latest
info including useful contributions in this thread, we will then
post that design document as a starting point for discussion on
how interfaces should be implemented in GNAT, since compatibility
with g++ and gcj is indeed of interest.

Re: Reenabling Ada by default

[Florian Weimer]

* Per Bothner:

> You might also look at the GCJ way of implementing Java interfaces.
> An object reference is a plain pointer, and there are not extra
> per-object "vobject" fields as in C++.  Instead we use a kind of
> double dispatch using initialization-time-computed indexin, which
> yields constant-time dispatch.

Can you provide a pointer to a short, high-level documentation of this
approach?

It's probably a standard implementation technique for OO languages,
but by just looking at the code, I've trouble understanding what's
going on.

Re: Reenabling Ada by default

[Andrew Haley]

Per Bothner writes:
 > Florian Weimer wrote:
 > 
 > > By the way, have you already decided on the implementation model for
 > > interfaces?  Do you plan to mirror the C++ ABI (which requires one
 > > word in every object for each interface it implements), a "fat
 > > pointers" model (where access-to-interface types include a pointer to
 > > an interface descriptor and the object), or a hybrid (something based
 > > on hashing, for example)?
 > 
 > You might also look at the GCJ way of implementing Java interfaces.
 > An object reference is a plain pointer, and there are not extra
 > per-object "vobject" fields as in C++.  Instead we use a kind of
 > double dispatch using initialization-time-computed indexin, which
 > yields constant-time dispatch.
 > 
 > The GCJ ABI is changing to support binary compatibility; I don't know
 > how this changes the interface implementation.

Not at all: we've managed to work out how to preserve binary
compatibility while maintaining constant-time interface dispatch.  I
checked in the implementation yesterday.

Andrew.

Re: Reenabling Ada by default

[Per Bothner]

Florian Weimer wrote:

> By the way, have you already decided on the implementation model for
> interfaces?  Do you plan to mirror the C++ ABI (which requires one
> word in every object for each interface it implements), a "fat
> pointers" model (where access-to-interface types include a pointer to
> an interface descriptor and the object), or a hybrid (something based
> on hashing, for example)?

You might also look at the GCJ way of implementing Java interfaces.
An object reference is a plain pointer, and there are not extra
per-object "vobject" fields as in C++.  Instead we use a kind of
double dispatch using initialization-time-computed indexin, which
yields constant-time dispatch.

The GCJ ABI is changing to support binary compatibility; I don't know
how this changes the interface implementation.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Reenabling Ada by default

[Phil Edwards]

On Fri, Sep 10, 2004 at 01:43:35PM -0400, Richard Kenner wrote:
>     | However, the front-end folks are continually 100% busy.
> 
>     Do you believe the GCC C, C++, Java and Fortran front-ends guys are
>     not 100% busy?
> 
> There is a difference between being 100% busy while *already* doing something
> and being 100% busy and *not* already doing it!  In the second case,
> something else has to not be done while in the first that's not an issue.

...just the like the rest of us.


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: Reenabling Ada by default

[Richard Kenner]

    | However, the front-end folks are continually 100% busy.

    Do you believe the GCC C, C++, Java and Fortran front-ends guys are
    not 100% busy?

There is a difference between being 100% busy while *already* doing something
and being 100% busy and *not* already doing it!  In the second case,
something else has to not be done while in the first that's not an issue.

Re: 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

Re: Reenabling Ada by default

[Gabriel Dos Reis]

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

|     I'm looking over the checkin rules, and I see a remarkable lack of
|     "exceptions to the requirement of explainations are made because bugs were
|     found using proprietary data".
| 
|     We all fix bugs using customer data.  We all manage to say what's going
|     on without spilling their secrets.  So can you.
| 
| I was addressing *what* Arno is doing now and what the front end folks
| are doing at this point.
| 
| Of course, it's possible to "manage" to construct sanitized test cases, but
| as somebody else in this thread said, that can often take "great effort".
| Nobody disagrees that in an ideal world, that would be a good thing to do.

We're not talking about ideal world.  We're talking about the
actual practice.

| Please don't create a strawman argument where somebody is claiming that
| wouldn't be a good idea.
| 
| However, the front-end folks are continually 100% busy.

Do you believe the GCC C, C++, Java and Fortran front-ends guys are
not 100% busy?

|  If that "great
| effort" is to take place, it means they will have to do it instead of
| something else they are currenty doing.  The question is, what is that?

That "great effort" has been made by any other people in the GCC
development community; why do you believe you're exempted?
Don't tell me you're busy; so are other people.  Don't telle me it
involved proprietary data; so are the cases for other people.

-- Gaby

Re: Reenabling Ada by default

[Richard Kenner]

    I'm looking over the checkin rules, and I see a remarkable lack of
    "exceptions to the requirement of explainations are made because bugs were
    found using proprietary data".

    We all fix bugs using customer data.  We all manage to say what's going
    on without spilling their secrets.  So can you.

I was addressing *what* Arno is doing now and what the front end folks
are doing at this point.

Of course, it's possible to "manage" to construct sanitized test cases, but
as somebody else in this thread said, that can often take "great effort".
Nobody disagrees that in an ideal world, that would be a good thing to do.
Please don't create a strawman argument where somebody is claiming that
wouldn't be a good idea.

However, the front-end folks are continually 100% busy.  If that "great
effort" is to take place, it means they will have to do it instead of
something else they are currenty doing.  The question is, what is that?

Re: Reenabling Ada by default

[Phil Edwards]

On Fri, Sep 10, 2004 at 01:11:52AM -0400, Richard Kenner wrote:
> 
>     You are also required to explain IN PROSE what you are doing and WHY.
> 
> The WHY gets deleted by Arno's procedure because it references
> customer data.

I'm looking over the checkin rules, and I see a remarkable lack of
"exceptions to the requirement of explainations are made because bugs were
found using proprietary data".

We all fix bugs using customer data.  We all manage to say what's going
on without spilling their secrets.  So can you.


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: Reenabling Ada by default

[Richard Kenner]

    Pointing out one small facet of compliance is irrelevant, there are
    *additional* requirements which are not being met.

Yes, I understand there are some things missing in Arno's procedure.
What I was trying to point out was that it was not as many things
as had been claimed.

    You are also required to explain IN PROSE what you are doing and WHY.

The WHY gets deleted by Arno's procedure because it references
customer data.

Re: Reenabling Ada by default

[Phil Edwards]

On Thu, Sep 09, 2004 at 09:31:17PM -0400, Richard Kenner wrote:
>     For sure, the *only* reason why I learnt GCC enough to submit patches
>     and have them approved is because there was a public gcc-patches list.
> 
> I'm missing your point.  Nobody has suggested taking the Ada patches off
> the gcc-patches list.

<grumble> Ya might as well, they contain no useful explanations or
descriptions.  The body of the patch itself can be extracted from CVS by
someone looking backwards in time.  Correct patches /also/ have explanatory
text that's even more useful to the hypothetical researcher.

I spend a lot of time reading back through gcc-patches, looking for the
discussion that surrounds a change.  Mega-merge patches once a week don't
tell me a damn thing.  Single fixes with "we found a bug, this makes it
better" don't tell me a damn thing.  Why you're magically exempt from
the rule that People Applying Patches Shall Explain What The Hell They're
Doing is beyond me.

</grumble>

-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: Reenabling Ada by default

[Richard Henderson]

On Thu, Sep 09, 2004 at 09:19:06PM -0400, Richard Kenner wrote:
> #3 is the trickier one.  But what's important to realize is that for the vast
> majority of patches, there's no data of that kind anywhere.  Most of the
> patches you do are in the same category: the only "discussion" is within your
> own skull.
> 
> For the small fraction where that's not the case, there is usually an
> additional difficulty in publicizing that discussion that hasn't been
> addressed here yet and it's not just a resource issue.
> 
> A discussion of a bug will, by its nature, refer to the customer test case,
> which cannot be made public.  Sure, it's possible to "sanitize" that test
> case, but usually not until the bug has been understood, which is *after*
> those discussions.  Even when it can be sanitized earlier, requiring it be
> done before the discussions take place in order to allow them to occur in
> public will put an additional item on the critical path for the customer to
> have their bug fixed.  That's a serious problem.
> 
> So can you be a little more specific about what data you are concerned about
> being preserved?

I'm not surprised that you don't seem to understand what I want here,
because YOU YOURSELF almost never do what I want with YOUR OWN patches
to the middle-end.

While I'm ranting, you are the second worst person I know about
explaining your patches.  The honor of the very worst belongs to
H.J. Lu, and I avoid looking at his mail as often as possible now
because of it.

What I want is a rationale for the patch.  I want a high-level
description of the problem.  I want a description of why the 
patch is correct.  If the patch is only mostly correct, i.e.
hacky, I'd like a discussion of the potential pitfalls if known.

I'm not *usually* looking for the blow-by-blow debugging that
you do in your skull over the course of hours or days while
debugging the problem.  I'll only ask for that if I think your
rationale is incorrect, and that the problem may lie elsewhere.

Take, for instance, Roger Sayle's patch,

   http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01280.html

He is solving what amounts to a trivial problem.  And yet,
he includes a concise high-level description of the problem, 
a concise description of what he believes to be the root 
cause, and a short description of his solution.  It is this
attention to detail, this COURTESY, that makes me want to
read Roger's mail first.

You, on the other hand, have not written seven (7) sentences
in support of one of your patches in at least 3 months, which
is as far back as I had patience to verify in the archives.
I would be willing to lay bets that the true answer is never.
Being prodded for information after the fact does not count.

Almost all of the time your entire patch description is
"This fixes a bug that occurred in the ACATS test."  Which is,
frankly, unacceptable.  We've bitched to you about this multiple
times.  If when it comes time to post a patch you can't remember
any more details than that, you should be taking notes.

What I want is something that will be useful to someone in the
future when they encounter a problem in an area touched by the
patch that you're writing today.  I want them to be able to go
back, look at the post containing the changelog entry, see the
rationale and say "Oh, I hadn't thought of that", or "Oh, that
case is handled by the froboz module, which post-dates the patch;
this is probably dead code now".  Or whatever.

What I do NOT want is for them to find the patch with nothing
describing it other than "this fixes a bug in ada".  Or worse,
a mega-merge patch which has not even the one line non-description
of which you are so fond.

> Sure, but that "manner" is significantly different when somebody with
> maintainer privilege on a part of the compiler is doing the patch, as would
> be the case with all ACT folks patching the front end, vs. somebody who
> doesn't have such a privilege.

FALSE.

Global and language maintainers should be following the same rules
as everyone else wrt patch documentation.


r~

Re: Reenabling Ada by default

[Kaveh R. Ghazi]

 > From: Robert Dewar
 > 
 > One thing that might be useful in this discussion is if people
 > chose particular examples of patches to illustrate what they
 > meant, rather than speaking in generalities.

Easy.  These are the last four patches sibmitted by Arno submitted
over the last month.  Note they don't occur on a daily basis as
previously claimed.

They are all just ChangeLogs and attached gzip files.  There is no
explanation of what's being changed or why.  This is entirely opaque.

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00045.html
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01047.html
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00836.html
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00495.html


Contrast that to this patch posting:

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00749.html

Note, the author rth needs commit approval from no one.  Nevertheless,
he creates one small patch to fix one problem.  He provides a
diagnosis and explanation and a reference to a PR in our bug database
which includes a testcase a reduced testcase a recipe for recreating
the bug plus further discussion.

A curious GCC developer can read and learn from this narrowly focused
bugfixing example.  Reading the Ada code drops doesn't even come
close to illuminating what's going on.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Reenabling Ada by default

[Richard Kenner]

    It shouldn't make any difference if the patch submitter has maintainer 
    privileges or not. IMHO patches should always submitted as if someone else 
    was going to review them.

Sure, but that's not what I meant.  What I meant is that there is no prior
"discussion" of those patches, so there is no issue of whether such
non-discussion is "secret" or not.

Re: Reenabling Ada by default

[Richard Kenner]

    For sure, the *only* reason why I learnt GCC enough to submit patches
    and have them approved is because there was a public gcc-patches list.

I'm missing your point.  Nobody has suggested taking the Ada patches off
the gcc-patches list.

Re: Reenabling Ada by default

[Paul Brook]

>     The policy of the gcc community is that patch discussion, approval,
>     and application happens in a particular manner.
>
> Sure, but that "manner" is significantly different when somebody with
> maintainer privilege on a part of the compiler is doing the patch, as would
> be the case with all ACT folks patching the front end, vs. somebody who
> doesn't have such a privilege.  And what Arno is doing is really not all
> that much different than that procedure: basically all that's happening is
> that he's acting as a surrogate for the other people.

It shouldn't make any difference if the patch submitter has maintainer 
privileges or not. IMHO patches should always submitted as if someone else 
was going to review them.

http://gcc.gnu.org/contribute.html specifically says that all the normal patch 
submission rules apply, even if you already have authority to approve and 
apply your own changes.

Paul

Re: Reenabling Ada by default

[Richard Kenner]

    The internet is a large enough place that I expect at least copies
    of gcc and its mail archives to exist until the global apocalypse.
    I do not expect the same to be true for any given corporation.

Sure, but I don't understand what data you are talking about losing.
There are three potential types of data:

(1) patches
(2) test cases
(3) discussions of patches

Patches are available via either CVS or the gcc-patches list whether they
are batched or not.

We've spoken about test cases before.

#3 is the trickier one.  But what's important to realize is that for the vast
majority of patches, there's no data of that kind anywhere.  Most of the
patches you do are in the same category: the only "discussion" is within your
own skull.

For the small fraction where that's not the case, there is usually an
additional difficulty in publicizing that discussion that hasn't been
addressed here yet and it's not just a resource issue.

A discussion of a bug will, by its nature, refer to the customer test case,
which cannot be made public.  Sure, it's possible to "sanitize" that test
case, but usually not until the bug has been understood, which is *after*
those discussions.  Even when it can be sanitized earlier, requiring it be
done before the discussions take place in order to allow them to occur in
public will put an additional item on the critical path for the customer to
have their bug fixed.  That's a serious problem.

So can you be a little more specific about what data you are concerned about
being preserved?

    The policy of the gcc community is that patch discussion, approval,
    and application happens in a particular manner.  

Sure, but that "manner" is significantly different when somebody with
maintainer privilege on a part of the compiler is doing the patch, as would
be the case with all ACT folks patching the front end, vs. somebody who
doesn't have such a privilege.  And what Arno is doing is really not all
that much different than that procedure: basically all that's happening is
that he's acting as a surrogate for the other people.

Re: Reenabling Ada by default

[Giovanni Bajo]

Robert Dewar wrote:

> To me it is not particularly constructive to say that
> the procedure for Ada front end patches must match that
> of the C++ front end, since they are radically different
> cases (in the case of the C++ front end, knowledge of
> C++ is widely spread across the gcc development
> community).

This is false. The number of people knowing the C++ standard *and* the GCC C++
FE well enough to modify it is really a handful. If you watch closely,
contributions to the C++ frontend come from the maintainers (Jason and Mark)
plus maybe 3-4 other people, where Jason & Mark together still do around 90% of
the total contribution.

For sure, the *only* reason why I learnt GCC enough to submit patches and have
them approved is because there was a public gcc-patches list.

Giovanni Bajo

Re: Reenabling Ada by default

[Daniel Jacobowitz]

On Fri, Sep 10, 2004 at 01:05:47AM -0400, Robert Dewar wrote:
> 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.

People choose to learn in different ways.

I may regret sticking my head in, but I'm going to try to make a
constructive suggestion.  I do not think that anyone would object to
any of the ACT employees who produce front-end patches having at least
write-after-approval access to the GCC repository.  I have the
impression (is this right?) that the parts of the front end they modify
are kept fairly well in sync between GCC and ACT's internal
repositories.  Even if much of the internal investigation can't happen
in public, why not have these people commit their patches to HEAD
individually?

All this would entail would be:
  - Merging the patch to HEAD; yes, I realize that this requires manual
    intervention and a certain amount of practice but for the sorts of
    Ada patches I've seen batched up it should be easy.
  - Testing the patch on HEAD; this can be done entirely by automation.
    Have a machine that accepts patches by email, applies them, runs
    ACATS and whatever other internal tests you wish, and returns
    results.

I acknowledge that this is an extra burden on ACT relative to the
status quo.  It also won't make people completely happy.  But it will
take away one of the largest complaints.  And it will ease some of the
burden on Arnaud at the same time, so the time won't come completely
out of nowhere.

If you are not willing to meet the GCC community at least half way,
you don't belong in it.

-- 
Daniel Jacobowitz

Re: Reenabling Ada by default

[Kaveh R. Ghazi]

 >     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.
 > 
 > "Self-contained" is not nearly as easy as you think.  Ada is a quite
 > large language.  GNAT has been around for over a decade.  Although
 > there are still the occaisional "how did *that* ever work?" sort of
 > bugs, most bugs found are quite subtle and the amount of information
 > needed to make their explanation "self-contained" and understandable
 > to people who aren't Ada experts is large.

"Self-contained" refers to the patch, not the explanation info.  The
patch posting doesn't have to allow someone unfamiliar with the Ada
language and the underlying compiler to understand everything from
zero to guru level in one post.  What the patch should do to be
"self-contained" is address one single issue.  I.e. one kind of bug
fixed or one new feature added, etc.


 > Neither Robert, Arno, or myself are saying this is impossible.  What
 > I'm saying is that the cost-benefit analysis of this is different from
 > the other front ends on both sides.  On the one side, the benefit of
 > doing it is far less because there isn't a set of people out there who
 > are eager to learn all about Ada (it would be nice if there *were*,
 > but let's be realistic!).  On the other, the cost is higher for the
 > reasons I've outlined.

It costs every contributor time and effort to do this.  Everybody else
does it, why do you feel ACT gets a free pass?



 > But the question, from a practical and realistic perspective, is
 > whether this information is really *useful* to the "rest of the
 > world".  Who would want to use it and for what purpose?  Before
 > deciding to commit resources to *produce* information, it's important
 > to be sure there will be *consumers* of that information.  And I don't
 > see that.  The argument "if you make it, they will come" doesn't seem
 > that convincing to me in this case.

I recall the same arguments were made about GCC itself at one point.
Clearly using an open development model has increased the amount of
volunteers capable of contributing.  I believe Ada is not somehow
immune to this effect.


 >     Lot's of contributors work for companies that have customers, none
 >     of these customers use GCC head either.  When their customers
 >     report bugs against older versions of GCC, the patches are
 >     submitted correctly according to our rules and tested on every
 >     branch they are installed.
 > 
 > Arno tests patches with the latest branch. And I test my patches to
 > the C part of the front end with the latest branch as well.  The issue
 > is the cost of having *everybody* who develops front-end patches doing
 > that as well.  You're talking about a dozen people here.


Again, somehow every other contributor/company somehow manages to do
this.  They see it as part of being good citizens of the GCC
community.  There's over 200 contributors listed in the GCC
MAINTAINERS who follow this rule.  I can't feel sorry for "a dozen
people" at ACT having to abide by the same rules.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Reenabling Ada by default

[Robert Dewar]

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.

Re: Reenabling Ada by default

[Richard Henderson]

On Thu, Sep 09, 2004 at 04:33:43PM -0400, Richard Kenner wrote:
> But the question, from a practical and realistic perspective, is whether this
> information is really *useful* to the "rest of the world".  Who would want to
> use it and for what purpose?  Before deciding to commit resources to
> *produce* information, it's important to be sure there will be *consumers* of
> that information.  And I don't see that.  The argument "if you make it, they
> will come" doesn't seem that convincing to me in this case.

The consumer will be whoever decides he wants a hand at maintaining
the Ada front end after ACT has gone out of business.

The internet is a large enough place that I expect at least copies
of gcc and its mail archives to exist until the global apocalypse.
I do not expect the same to be true for any given corporation.

The policy of the gcc community is that patch discussion, approval,
and application happens in a particular manner.  It is not your
prerogative to decide otherwise, whatever you think of your "cost
benefit analysis".


r~

Re: Reenabling Ada by default

[Joseph S. Myers]

On Thu, 9 Sep 2004, James A. Morrison wrote:

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

And as the list membership statistics may not be widely known, here are 
the figures for the active public gcc* lists last week.  These of course 
exclude people reading through the list archives, news gateways or local 
expanders.

                                         # of mail          Digest
List Name                                    notes Members Members
---------                                --------- ------- -------
gcc-announce                                     0    7006      17
gcc-bugs                                       781     236      35
gcc-cvs                                        389      89       6
gcc-cvs-wwwdocs                                 17      22       0
gcc-help                                        68     573     166
gcc                                            487     926     188
gcc-patches                                    830     302      27
gcc-regression                                  24      30       0
gcc-testresults                                284      62       7
gccadmin                                        18       2       0

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Reenabling Ada by default

[James A. Morrison]

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.
> 
> "Self-contained" is not nearly as easy as you think.  Ada is a quite large
> language.  GNAT has been around for over a decade.  Although there are still
> the occaisional "how did *that* ever work?" sort of bugs, most bugs found are
> quite subtle and the amount of information needed to make their explanation
> "self-contained" and understandable to people who aren't Ada experts is
> large.

 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.
 
> Neither Robert, Arno, or myself are saying this is impossible.  What I'm
> saying is that the cost-benefit analysis of this is different from the
> other front ends on both sides.  On the one side, the benefit of doing
> it is far less because there isn't a set of people out there who are
> eager to learn all about Ada (it would be nice if there *were*, but let's
> be realistic!).  On the other, the cost is higher for the reasons
> I've outlined.

 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.

>     Also, "review" doesn't necessarily mean approve or reject.  Someone
>     completely ignorant of Ada might simply catch a spelling mistake in a
>     comment.  
> 
> Sure, but that can be done irrespective of whether they are one patch
> or multiple in a message.

 It's much easier to do one at a time with nice small inlined or test/plain
patches than big gzipped patches.

>     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.
> 
> But the question, from a practical and realistic perspective, is whether this
> information is really *useful* to the "rest of the world".  Who would want to
> use it and for what purpose?  Before deciding to commit resources to
> *produce* information, it's important to be sure there will be *consumers* of
> that information.  And I don't see that.  The argument "if you make it, they
> will come" doesn't seem that convincing to me in this case.

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

>     Lot's of contributors work for companies that have customers, none of
>     these customers use GCC head either.  When their customers report bugs
>     against older versions of GCC, the patches are submitted correctly
>     according to our rules and tested on every branch they are installed.
> 
> Arno tests patches with the latest branch. And I test my patches to the C
> part of the front end with the latest branch as well.  The issue is the cost
> of having *everybody* who develops front-end patches doing that as well.
> You're talking about a dozen people here.

 A dozen people with more resources than a lot of the non-regular gcc
contributors.

-- 
Thanks,
Jim

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

Re: Reenabling Ada by default

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| Eric Christopher wrote:
| 
| >>I would say that this last criterion is clearly impossible. Large sections
| >>of the front end assume intimate familiar with the Ada RM, and understanding
| >>patches for the front end must almost always assume a pretty deep level of
| >>Ada knowledge. However, I am not clear that ZW was making this request.
| >>It would make no sense, so I really did not assume that this was the
| >>intent. For example, any of the patches for implementing Ada 2005
| >>features assumes complete familiarity with the (often very complex)
| >>corresponding AI, and the AI itself generally assumes complete
| >>familiarity with the RM.
| > If it is, as you say, impossible to do public development of ada in
| > the
| > gcc source tree then why don't we remove it?
| 
| First let me say that I quoted these two paragraphs because
| I don't see that the second flows from the first at all.
| Public development of an Ada front end in any context
| requires intimate knowledge of the Ada standard. The same
| can be said for any language front end.

Exactly.  So what is the point?

| People don't work
| on a C++ compiler if they don't know C++ (or at least they
| shouldn't, it seems to me that the price of admission for
| a compiler writer writing a front end for language X is to
| be familiar with language X). So my insistence that if you
| want to play in the front end of the Ada compiler you need
| to know Ada says nothing about whether or not it is possible
| to do public development of Ada in the GCC source tree.

The thing that is puzzling me in your message is that you have aligned
evidence after evidence, without still addressing the main issues or
concerns.  


| 
| In fact if you want to look at any of the front end patches,
| and if you *do* know the Ada standard (and relevant AI's)
| well, you should find them quite easy to understand, since
| they are very well documented. However, the group of people
| that meet this criterion is small (and most of them work
| for AdaCore, and most of the rest work for AdaCore's
| competitors :-)
| 
| But going back to the second para above, even if I don't
| understand it as a response to the quoted paragraph from
| me ...
| 
|  > If it is, as you say, impossible to do public development of ada in the
|  > gcc source tree
| 
| I said nothing of the kind, I merely said that if you want
| to play in the Ada front end arena, you have to know Ada.

Yes, just like for any other language.  How does that exempt for a
public review process of Ada related patches?

[...]

| To me it is not particularly constructive to say that
| the procedure for Ada front end patches must match that
| of the C++ front end, since they are radically different
| cases (in the case of the C++ front end, knowledge of
| C++ is widely spread across the gcc development
| community).

Some people have made the opposite point in recent threads ;-)

| What would be constructive would be to
| understand exactly what is wanted and why.

All other front-ends we have see a public review process.
I strongly disagree with the notion that because you perceive Ada to be
more complicated than, say C++, its review process should be kept
secret. 

-- Gaby

Re: Reenabling Ada by default

[Richard Kenner]

    Form experience and the cases I know of, huge efforts are made to
    identify freely accessible data that could be the base of patch
    reviews or testcases or benchmarcks.  After that, the rest of the
    review process is made public on GCC list.

But that "huge effort" is exactly the point.  The amount of time that
can be justified to put into that effort is a strong function of the
number of people that would benefit from that effort.  And that relates
to the fraction of developers of that part of the compiler who are not
from the organization that developed that patch.  The larger that fraction,
the more work one can justify on making testcases accessible.  And that
fraction is very different for the Ada front end than the rest of GCC.

Re: Reenabling Ada by default

[Wolfgang Bangerth]

Richard Kenner wrote:
> Kaveh Ghazi wrote:
>>    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.
>
> "Self-contained" is not nearly as easy as you think.  Ada is a quite large
> language.  GNAT has been around for over a decade.  Although there are still
> the occaisional "how did *that* ever work?" sort of bugs, most bugs found
> are quite subtle and the amount of information needed to make their
> explanation "self-contained" and understandable to people who aren't Ada
> experts is large.

The argument about the size of the language can also be made for C++. 
Nevertheless, we have a good number of people who know it.


> Neither Robert, Arno, or myself are saying this is impossible.  What I'm
> saying is that the cost-benefit analysis of this is different from the
> other front ends on both sides.  On the one side, the benefit of doing
> it is far less because there isn't a set of people out there who are
> eager to learn all about Ada (it would be nice if there *were*, but let's
> be realistic!).  On the other, the cost is higher for the reasons
> I've outlined.

I think the case Kaveh was making is actually quite powerful: when gcc became 
egcs, with its open development model, it drew in a surprising number of 
people. The possibility to read patches and participate in the development 
seems to be so attractive that the project as a whole benefits. From my own 
experience in the last two years, almost all my co-bugmasters except for me 
have eventually ventured into writing first small patches for small problems, 
but at least two (Giovanni and Andrew) have gone on to tackle larger 
projects. There are also likely people in the gcc project who are not users 
of C++, but over time have acquired enough knowledge of the C++ front end to 
make the occasional change. On the other hand, some of us probably still 
remember that the development model pre-egcs eventually broke down due to 
lack of manpower.

This historical precedent seems to indicate that a more open approach can draw 
in developers. Assume Ada development was more transparent, with smaller and 
more easily understandable patches being sent, and a lively discussion about 
them. Even occasional readers of these messages would gain some knowledge of 
the way the Ada front end works, and they may try to accasionally run the Ada 
testsuite and fix something in it.

Most would agree that Ada is a good language, and I could imagine many would 
play around with it a little if you could get them more interested in it. 
Offer them pieces of information to get hooked, in the form of small patches. 
It may increase the number of people who care about Ada and help out in its 
development. Big bulk patches, on the other hand, are certainly not what gets 
Ada front end beginners drawn in.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Reenabling Ada by default

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

[...]

| The internal review process very often involves proprietary customer
| information, so generally this kind of opening up is not possible.
| Remember that the great majority of bugs that are being fixed by
| AdaCore are from customers with proprietary code.

This is a very slippery slope for the GCC project.  Imagine all GCC
developers start checking things in, with non public review process, on
the basis that that would involves proprietary customers nd
proprietary codes!  

Form experience and the cases I know of, huge efforts are made to
identify freely accessible data that could be the base of patch
reviews or testcases or benchmarcks.  After that, the rest of the
review process is made public on GCC list.

-- Gaby

Re: Reenabling Ada by default

[Duncan Sands]

On Thursday 09 September 2004 23:25, Richard Kenner wrote:
>     There are also bugs in the run-time library.  They are often easier to
>     understand than those in the compiler proper: no great expertise is
>     needed.
> 
> Actually, from my own experience I find it quite the opposite!  The
> RTS implements the trickiest parts of the language.

Hi Richard, this is my experience from the bugs I've uncovered.
Presumably you get to work on bugs I didn't notice! :)  By the way,
thanks for all your work on converting the Ada frontend to work
with tree-ssa.  It is great to see ACT keeping the public gcc tree
up to date.  It used to be that the gcc version was clearly not as
good as 3.15p, but now I use pre-ssa gcc in preference to 3.15p.

All the best,

Duncan.

Re: Reenabling Ada by default

[Robert Dewar]

Duncan Sands wrote:

> There are also bugs in the run-time library.  They are often easier to understand
> than those in the compiler proper: no great expertise is needed.

Well the great majority of these fall under the obvious fix category.
Those that do not, e.g. subtle changes in the tasking support often
require even more specialized expertise than the compiler front end.

One thing that might be useful in this discussion is if people
chose particular examples of patches to illustrate what they
meant, rather than speaking in generalities.

Re: Reenabling Ada by default

[Robert Dewar]

Eric Christopher wrote:

>>I would say that this last criterion is clearly impossible. Large sections
>>of the front end assume intimate familiar with the Ada RM, and understanding
>>patches for the front end must almost always assume a pretty deep level of
>>Ada knowledge. However, I am not clear that ZW was making this request.
>>It would make no sense, so I really did not assume that this was the
>>intent. For example, any of the patches for implementing Ada 2005
>>features assumes complete familiarity with the (often very complex)
>>corresponding AI, and the AI itself generally assumes complete
>>familiarity with the RM.
> 
> 
> If it is, as you say, impossible to do public development of ada in the
> gcc source tree then why don't we remove it?

First let me say that I quoted these two paragraphs because
I don't see that the second flows from the first at all.
Public development of an Ada front end in any context
requires intimate knowledge of the Ada standard. The same
can be said for any language front end. People don't work
on a C++ compiler if they don't know C++ (or at least they
shouldn't, it seems to me that the price of admission for
a compiler writer writing a front end for language X is to
be familiar with language X). So my insistence that if you
want to play in the front end of the Ada compiler you need
to know Ada says nothing about whether or not it is possible
to do public development of Ada in the GCC source tree.

In fact if you want to look at any of the front end patches,
and if you *do* know the Ada standard (and relevant AI's)
well, you should find them quite easy to understand, since
they are very well documented. However, the group of people
that meet this criterion is small (and most of them work
for AdaCore, and most of the rest work for AdaCore's
competitors :-)

But going back to the second para above, even if I don't
understand it as a response to the quoted paragraph from
me ...

 > If it is, as you say, impossible to do public development of ada in the
 > gcc source tree

I said nothing of the kind, I merely said that if you want
to play in the Ada front end arena, you have to know Ada.
By the way, only a few people at AdaCore know enough to
work on the front end, it's a relatively small part of
our overall technology.

 > then why don't we remove it?

Well certainly we could, and probably from a purely commercial
point of view, that would be overall in AdaCore's commercial
interest. However, there are a lot of Ada users who have found
it very valuable to have Ada in the FSF tree, which is why we
make the effort of trying to keep it up to date. Take for
example the Tree-SSA work. We don't anticipate making a customer
release of GNAT Pro with Tree-SSA for a couple of years, since
our release cycle is slow and very conservative, but it is
definitely useful and interesting to the gcc ada community
to have this working, which is why Richard has been treating
it as a much more urgent project.

There are really two issues here

1. Having Ada present certainly carries advantages to Ada
users, and disadvantages to developers who have to worry
about it (the same is true of any front end). Of course
in this list we primarily see the discussion of developers
rather than users, so the proper balance may be tricky
to achieve.

2. With respect to the Ada front end patches, if we want
to keep up to date with the GNAT Pro tree, then we there
is the issue of the form in which these patches are done.
I consider this issue essentially orthogonal to issue 1.
That is, I don't think that the form of the front end
patches has any significant impact on how easy or how
difficult it is to deal with the balances of issue 1.
To me it is not particularly constructive to say that
the procedure for Ada front end patches must match that
of the C++ front end, since they are radically different
cases (in the case of the C++ front end, knowledge of
C++ is widely spread across the gcc development
community). What would be constructive would be to
understand exactly what is wanted and why.

If the front end patches are indeed causing difficulties
for developers, we could simply stop doing these patches
and leave the GNAT front end in its current state, fixing
only selected serious errors, and for example not bother
with the extensive Ada 2005 patches. That's certainly
less drastic than removing the GNAT front end entirely.

Re: Reenabling Ada by default

[Richard Kenner]

    There are also bugs in the run-time library.  They are often easier to
    understand than those in the compiler proper: no great expertise is
    needed.

Actually, from my own experience I find it quite the opposite!  The
RTS implements the trickiest parts of the language.

Re: Reenabling Ada by default

[Duncan Sands]

> "Self-contained" is not nearly as easy as you think.  Ada is a quite large
> language.  GNAT has been around for over a decade.  Although there are still
> the occaisional "how did *that* ever work?" sort of bugs, most bugs found are
> quite subtle and the amount of information needed to make their explanation
> "self-contained" and understandable to people who aren't Ada experts is
> large.

There are also bugs in the run-time library.  They are often easier to understand
than those in the compiler proper: no great expertise is needed.

All the best,

Duncan.

Re: Reenabling Ada by default

[Eric Christopher]

> I would say that this last criterion is clearly impossible. Large sections
> of the front end assume intimate familiar with the Ada RM, and understanding
> patches for the front end must almost always assume a pretty deep level of
> Ada knowledge. However, I am not clear that ZW was making this request.
> It would make no sense, so I really did not assume that this was the
> intent. For example, any of the patches for implementing Ada 2005
> features assumes complete familiarity with the (often very complex)
> corresponding AI, and the AI itself generally assumes complete
> familiarity with the RM.

If it is, as you say, impossible to do public development of ada in the
gcc source tree then why don't we remove it?

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Reenabling Ada by default

[Robert Dewar]

Florian Weimer wrote:

> * Robert Dewar:
> 
> 
>>For example, any of the patches for implementing Ada 2005 features
>>assumes complete familiarity with the (often very complex)
>>corresponding AI, and the AI itself generally assumes complete
>>familiarity with the RM.
> 
> 
> By the way, have you already decided on the implementation model for
> interfaces?  Do you plan to mirror the C++ ABI (which requires one
> word in every object for each interface it implements), a "fat
> pointers" model (where access-to-interface types include a pointer to
> an interface descriptor and the object), or a hybrid (something based
> on hashing, for example)?

It's under discussion now .... actually that is probably a discussion
that can be shared. I will investigate.

Re: Reenabling Ada by default

[Florian Weimer]

* Robert Dewar:

> For example, any of the patches for implementing Ada 2005 features
> assumes complete familiarity with the (often very complex)
> corresponding AI, and the AI itself generally assumes complete
> familiarity with the RM.

By the way, have you already decided on the implementation model for
interfaces?  Do you plan to mirror the C++ ABI (which requires one
word in every object for each interface it implements), a "fat
pointers" model (where access-to-interface types include a pointer to
an interface descriptor and the object), or a hybrid (something based
on hashing, for example)?

Re: Reenabling Ada by default

[Robert Dewar]

Richard Kenner wrote:

> "Self-contained" is not nearly as easy as you think.  Ada is a quite large
> language.  GNAT has been around for over a decade.  Although there are still
> the occaisional "how did *that* ever work?" sort of bugs, most bugs found are
> quite subtle and the amount of information needed to make their explanation
> "self-contained" and understandable to people who aren't Ada experts is
> large.

I would say that this last criterion is clearly impossible. Large sections
of the front end assume intimate familiar with the Ada RM, and understanding
patches for the front end must almost always assume a pretty deep level of
Ada knowledge. However, I am not clear that ZW was making this request.
It would make no sense, so I really did not assume that this was the
intent. For example, any of the patches for implementing Ada 2005
features assumes complete familiarity with the (often very complex)
corresponding AI, and the AI itself generally assumes complete
familiarity with the RM.

Re: Reenabling Ada by default

[Richard Kenner]

    Grr, it's really frustrating that you use lack of expertise as an
    argument for maintaining your behavior.  

    So your argument doesn't wash and I see no reason you should feel
    entitled to behave differently than the rest of the community.

Just to be clear here that the "you" above does not apply to me personally
since I'm not one of the people making patches to the Ada front-end.  I do
work on the C part of the front end and the only reason why I don't check
them in directly is that it makes Arno's job harder when some changes from
the local tree are checked in and some aren't.

    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.

"Self-contained" is not nearly as easy as you think.  Ada is a quite large
language.  GNAT has been around for over a decade.  Although there are still
the occaisional "how did *that* ever work?" sort of bugs, most bugs found are
quite subtle and the amount of information needed to make their explanation
"self-contained" and understandable to people who aren't Ada experts is
large.

Neither Robert, Arno, or myself are saying this is impossible.  What I'm
saying is that the cost-benefit analysis of this is different from the
other front ends on both sides.  On the one side, the benefit of doing
it is far less because there isn't a set of people out there who are
eager to learn all about Ada (it would be nice if there *were*, but let's
be realistic!).  On the other, the cost is higher for the reasons
I've outlined.

    Also, "review" doesn't necessarily mean approve or reject.  Someone
    completely ignorant of Ada might simply catch a spelling mistake in a
    comment.  

Sure, but that can be done irrespective of whether they are one patch
or multiple in a message.

    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.

But the question, from a practical and realistic perspective, is whether this
information is really *useful* to the "rest of the world".  Who would want to
use it and for what purpose?  Before deciding to commit resources to
*produce* information, it's important to be sure there will be *consumers* of
that information.  And I don't see that.  The argument "if you make it, they
will come" doesn't seem that convincing to me in this case.

    Lot's of contributors work for companies that have customers, none of
    these customers use GCC head either.  When their customers report bugs
    against older versions of GCC, the patches are submitted correctly
    according to our rules and tested on every branch they are installed.

Arno tests patches with the latest branch. And I test my patches to the C
part of the front end with the latest branch as well.  The issue is the cost
of having *everybody* who develops front-end patches doing that as well.
You're talking about a dozen people here.

Re: Reenabling Ada by default

[Andrew Haley]

Robert Dewar writes:
 > Zack Weinberg wrote:
 > 
  > > It does not matter how few people are qualified to review patches for
 > > the Ada front end.  The requirement is that patch review occur in
 > > public.  I am assuming that there is an internal review process; all
 > > we are asking is that you do that on an open mailing list so that
 > > others can observe.
 > 
 > The internal review process very often involves proprietary customer
 > information, so generally this kind of opening up is not possible.
 > Remember that the great majority of bugs that are being fixed by
 > AdaCore are from customers with proprietary code.

The same was true when I worked at Cygnus.  We sometimes had to write
independent test cases that would show bugs in order to demonstrate
problems to the rest of the gcc community.

Andrew.

Re: Reenabling Ada by default

[Diego Novillo]

On Thu, 2004-09-09 at 15:17, Robert Dewar wrote:

> The internal review process very often involves proprietary customer
> information, so generally this kind of opening up is not possible.
> Remember that the great majority of bugs that are being fixed by
> AdaCore are from customers with proprietary code.
>
Funny.  The very same thing happens to everyone else.


Diego.

Re: Reenabling Ada by default

[Robert Dewar]

Zack Weinberg wrote:
> [Would you mind trimming down your quotes a bit?]

Always hard to get the right balance, you are the
only person to say I quote too much, but I get
frequent complaints that I don't quote enough.
Hard to satisfy everyone, but I will try to be
sure not to quote too much.

Part of the trouble is that people who use threaded
mailers have radically different requirements in
this respect.

Re: Reenabling Ada by default

[Zack Weinberg]

[Would you mind trimming down your quotes a bit?]

Robert Dewar <dewar@gnat.com> writes:
> Zack Weinberg wrote:
>> Richard Kenner writes:
>>>(1) The set of people who modify it is very localized.  There are
>>>extremely few (perhaps no) people on this list outside of ACT/ACTE
>>>who are knowlegable enough to make Ada front-end modifications
>>>...
>> It does not matter how few people are qualified to review patches for
>> the Ada front end.  The requirement is that patch review occur in
>> public.  I am assuming that there is an internal review process; all
>> we are asking is that you do that on an open mailing list so that
>> others can observe.
>
> The internal review process very often involves proprietary customer
> information, so generally this kind of opening up is not possible.
> Remember that the great majority of bugs that are being fixed by
> AdaCore are from customers with proprietary code.

This is another problem that faces all other corporate-funded
contributors to GCC, too, and guess what?  We all somehow manage to
deal.  Usually by coming up with synthetic non-encumbered test cases.

zw

Re: Reenabling Ada by default

[Kaveh R. Ghazi]

 > It has very different properties in terms of the way work is done on
 > it than any other part of GCC.  There are two major differences (and a
 > bunch of minor ones):
 > 
 > (1) The set of people who modify it is very localized.  There are
 >     extremely few (perhaps no) people on this list outside of ACT/ACTE
 >     who are knowlegable enough to make Ada front-end modifications
 >     (I'm talking here about the Ada part and not including myself in
 >     that set despite being part of ACT).  There would be nothing
 >     gained by making patches available for "review" on this list,
 >     since there are few, if any, people on the list that could review
 >     them.  That's also somewhat true for front ends such as Java and
 >     Fortran, but the number of people working on them is far smaller.

Grr, it's really frustrating that you use lack of expertise as an
argument for maintaining your behavior.  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.

Also, "review" doesn't necessarily mean approve or reject.  Someone
completely ignorant of Ada might simply catch a spelling mistake in a
comment.  If you cooperate, eventually you'll find expertise and
participation increases to the point that code suggestions can be
made.  But this can't happen the way things are done now.

Nor does review mean it happens immediately.  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.  Collaboration means
more than just sharing code in a common repo.


 > (2) Because Ada users are very conservative, they are not using recent
 >     versions of GCC and the front-end developers must do their testing
 >     on the GCC versions being used by the people who report the bugs.
 >     Since committing the patch to the FSF tree requires testing using
 >     the latest version of GCC, that doubles the testing time.  For the
 >     other front-ends, developers mostly use the head version of GCC.

Lot's of contributors work for companies that have customers, none of
these customers use GCC head either.  When their customers report bugs
against older versions of GCC, the patches are submitted correctly
according to our rules and tested on every branch they are installed.
So your argument doesn't wash and I see no reason you should feel
entitled to behave differently than the rest of the community.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Reenabling Ada by default

[Robert Dewar]

Zack Weinberg wrote:

> Richard Kenner writes:
> 
>>Zack Weinberg writes:
>>
>>>ANY kind of batching is unacceptable.  Each individual patch needs to
>>>be submitted for review by its original author, reviewed in public,
>>>and checked in by itself.  This is the commit policy which every other
>>>contributor to GCC adheres to.  I do not see why the Ada front end
>>>should be a special case.
>>
>>It has very different properties in terms of the way work is done on it
>>than any other part of GCC. 
> 
> ...
> 
> 
>>(1) The set of people who modify it is very localized.  There are
>>extremely few (perhaps no) people on this list outside of ACT/ACTE
>>who are knowlegable enough to make Ada front-end modifications (I'm
>>talking here about the Ada part and not including myself in that set
>>despite being part of ACT).  There would be nothing gained by making
>>patches available for "review" on this list, since there are few, if
>>any, people on the list that could review them.
> 
> 
> It does not matter how few people are qualified to review patches for
> the Ada front end.  The requirement is that patch review occur in
> public.  I am assuming that there is an internal review process; all
> we are asking is that you do that on an open mailing list so that
> others can observe.

The internal review process very often involves proprietary customer
information, so generally this kind of opening up is not possible.
Remember that the great majority of bugs that are being fixed by
AdaCore are from customers with proprietary code.
> 
> (I would support the establishment of an ada-patches@gcc.gnu.org
> mailing list so that people who don't care can tune out, as is done
> now for Java and libstdc++.)
> 
> 
>>(2) Because Ada users are very conservative, they are not using
>>recent versions of GCC and the front-end developers must do their
>>testing on the GCC versions being used by the people who report the
>>bugs.  Since committing the patch to the FSF tree requires testing
>>using the latest version of GCC, that doubles the testing time.  For
>>the other front-ends, developers mostly use the head version of GCC.
> 
> 
> This turns out not to be the case.  I can speak here for
> CodeSourcery's customers only - many of them are still using 2.9x era
> GCC for C and C++.  And that does mean we have to test patches against
> the version they're using, then again against mainline, and yes, that
> does double testing time.  We do it, because that's what the community
> expects and requires of us.  The same is expected and required of the
> Ada developers.
> 
> zw

Re: Reenabling Ada by default

[Zack Weinberg]

Richard Kenner writes:
> Zack Weinberg writes:
>> ANY kind of batching is unacceptable.  Each individual patch needs to
>> be submitted for review by its original author, reviewed in public,
>> and checked in by itself.  This is the commit policy which every other
>> contributor to GCC adheres to.  I do not see why the Ada front end
>> should be a special case.
>
> It has very different properties in terms of the way work is done on it
> than any other part of GCC. 
...

> (1) The set of people who modify it is very localized.  There are
> extremely few (perhaps no) people on this list outside of ACT/ACTE
> who are knowlegable enough to make Ada front-end modifications (I'm
> talking here about the Ada part and not including myself in that set
> despite being part of ACT).  There would be nothing gained by making
> patches available for "review" on this list, since there are few, if
> any, people on the list that could review them.

It does not matter how few people are qualified to review patches for
the Ada front end.  The requirement is that patch review occur in
public.  I am assuming that there is an internal review process; all
we are asking is that you do that on an open mailing list so that
others can observe.

(I would support the establishment of an ada-patches@gcc.gnu.org
mailing list so that people who don't care can tune out, as is done
now for Java and libstdc++.)

> (2) Because Ada users are very conservative, they are not using
> recent versions of GCC and the front-end developers must do their
> testing on the GCC versions being used by the people who report the
> bugs.  Since committing the patch to the FSF tree requires testing
> using the latest version of GCC, that doubles the testing time.  For
> the other front-ends, developers mostly use the head version of GCC.

This turns out not to be the case.  I can speak here for
CodeSourcery's customers only - many of them are still using 2.9x era
GCC for C and C++.  And that does mean we have to test patches against
the version they're using, then again against mainline, and yes, that
does double testing time.  We do it, because that's what the community
expects and requires of us.  The same is expected and required of the
Ada developers.

zw

Re: Reenabling Ada by default

[Richard Kenner]

[Moved to GCC from gcc-patches.]

    ANY kind of batching is unacceptable.  Each individual patch needs to
    be submitted for review by its original author, reviewed in public,
    and checked in by itself.  This is the commit policy which every other
    contributor to GCC adheres to.  I do not see why the Ada front end
    should be a special case.

It has very different properties in terms of the way work is done on it
than any other part of GCC.  There are two major differences (and a
bunch of minor ones):

(1) The set of people who modify it is very localized.  There are extremely
few (perhaps no) people on this list outside of ACT/ACTE who are knowlegable
enough to make Ada front-end modifications (I'm talking here about the Ada
part and not including myself in that set despite being part of ACT).  There
would be nothing gained by making patches available for "review" on this
list, since there are few, if any, people on the list that could review them.
That's also somewhat true for front ends such as Java and Fortran, but the
number of people working on them is far smaller.

(2) Because Ada users are very conservative, they are not using recent
versions of GCC and the front-end developers must do their testing on the GCC
versions being used by the people who report the bugs.  Since committing the
patch to the FSF tree requires testing using the latest version of GCC, that
doubles the testing time.  For the other front-ends, developers mostly use the
head version of GCC.