Re: Why not gnat Ada in gcc?

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<You're working on free software for the fsf, therefore IMO you ought
to be doing your development in the open if at all possible.  And
clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
not only possible, but not particularly difficult.
>>

Actually from past experiences recently, e.g. with the ia64 port, I have
been struck by how closed the development was. Same thing for gdb5, this
was kept under wraps for a long time. A large company (I won't name names)
that we worked with was essentially operating as though it were under
non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
and it is hard to see how else it could have been done.

My own feeling is that sometimes it is quite appropriate to keep major
developments "under wraps" until they are in reasonable shape for release,
and that's the way we work at Ada Core Technologies for major incremental
development. For example, the new project file support is rapidly changing,
and until it settles down a bit, it would simply cause massive confusion
to have these changes in the open tree (it has not even settled down enough
to put them in *our* development tree yet).

So we agree, that it is definitely desirable to do the development in
the open to the extent possible. But it is not always possible or
desirable to do so.

Our objective at Ada Core Technologies in working to get the GNAT sources
integrated with the main gcc tree is precisely to make it possible for
more development to be done in the open. I am not quite sure what Jeff 
is arguing for here, are you arguing that you would prefer we NOT make
this effort, if so, that seems a bit peculiar.

Robert Dewar

Re: Why not gnat Ada in gcc?

[Daniel Berlin]

dewar@gnat.com (Robert Dewar) writes:

> <<You're working on free software for the fsf, therefore IMO you ought
> to be doing your development in the open if at all possible.  And
> clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
> not only possible, but not particularly difficult.
> >>
> 
> Actually from past experiences recently, e.g. with the ia64 port, I have
> been struck by how closed the development was. Same thing for gdb5, this
> was kept under wraps for a long time. A large company (I won't name names)
> that we worked with was essentially operating as though it were under
> non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
> and it is hard to see how else it could have been done.

What?
gdb5 was not a sudden massive update.
What are you talking about?
Can you point the changelog entry where all of gdb5 suddenly appeared
in?
It looks like a pretty logical progression looking through the
changelogs, starting with april 1999->may 22, 2000.

--Dan

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102025351.6992434DAF@nile.gnat.com >you write:
   > Actually from past experiences recently, e.g. with the ia64 port, I have
  > been struck by how closed the development was.
The development of the ia64 port (IMHO) was severely limited by the NDAs
that were forced on the developers by Intel and others.

  > Same thing for gdb5, this was kept under wraps for a long time.
Yes.  But gdb5 was a lot more open than anything related to Ada has 
ever been and GDB development continues to become more open.

  > A large company (I won't name names)
  > that we worked with was essentially operating as though it were under
  > non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
  > and it is hard to see how else it could have been done.
And if you look at what happened with gdb, you'll find that massive updates
no longer happen because they don't work when you're trying to build a
developer community.  And I think you'll find that ia-64 development will
finally start to move forward with the various NDAs being lifted and hardware
becoming available.

  > My own feeling is that sometimes it is quite appropriate to keep major
  > developments "under wraps" until they are in reasonable shape for release,
  > and that's the way we work at Ada Core Technologies for major incremental
  > development. For example, the new project file support is rapidly changing,
  > and until it settles down a bit, it would simply cause massive confusion
  > to have these changes in the open tree (it has not even settled down enough
  > to put them in *our* development tree yet).
I disagree again.  If you look at the major restructuring changes that have
happened with GCC over the 3 years since its development was opened up, you'll
find that the community was able to deal with rapid development and daily
instability.  Examples would be moving to garbage collection technology in
the compiler, a completely revamped reload pass, massive C++ improvements,
a much more aggressive internal consistency checking system in the compiler,
implementing a real CFG and using it in the optimizers, etc etc.

In fact, I strongly believe that having the development process opened up
allowed us to better design and implement those massive changes and complete
them much more rapidly than would have happened in a closed environment such
as existed with GCC a few years ago or with GNU Ada right now.

  > Our objective at Ada Core Technologies in working to get the GNAT sources
  > integrated with the main gcc tree is precisely to make it possible for
  > more development to be done in the open. I am not quite sure what Jeff 
  > is arguing for here, are you arguing that you would prefer we NOT make
  > this effort, if so, that seems a bit peculiar.
I'm arguing that ACT should contribute work incrementally to the GNU Ada
compiler just like everyone else, ie no massive merges from the ACT internal
tree.  All patches are sent to gcc-patches along with justification for
the changes and that in general ACT employees play by the same rules as
everyone else involved in GCC development.

In short that GNU Ada development fall under the same guidelines as the 
rest of the compiler with no company or individual in a privileged
position in regards to the development process.

jeff

Re: Why not gnat Ada in gcc?

[Geoff Keating]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < 20001102025351.6992434DAF@nile.gnat.com >you write:

>   > Our objective at Ada Core Technologies in working to get the GNAT sources
>   > integrated with the main gcc tree is precisely to make it possible for
>   > more development to be done in the open. I am not quite sure what Jeff 
>   > is arguing for here, are you arguing that you would prefer we NOT make
>   > this effort, if so, that seems a bit peculiar.
> I'm arguing that ACT should contribute work incrementally to the GNU Ada
> compiler just like everyone else, ie no massive merges from the ACT internal
> tree.  All patches are sent to gcc-patches along with justification for
> the changes and that in general ACT employees play by the same rules as
> everyone else involved in GCC development.
> 
> In short that GNU Ada development fall under the same guidelines as the 
> rest of the compiler with no company or individual in a privileged
> position in regards to the development process.

Yes, this is the important thing.

It's not really the business of people outside ACT to say how they
arrange their work.  If ACT wants to wait a year and then merge in
dozens of features in the same week, they can try to do that.  (I
think that this approach won't work, but hey, maybe the ACT people
know something I don't.)

However, I do believe that ACT should follow the same rules as other
developers.  In particular, there's a general policy:

   If you have several unrelated changes, you should check them in
   with separate cvs commit commands.

that each patch, as submitted to gcc-patches and as committed to the
tree, should not include multiple unrelated features or bug fixes.
This makes it possible for those reviewing patches, trying to isolate
a single bug fix, trying to isolate a single bug introduction,
regression testing, or trying to use the CVS history to do this
effectively.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Why not gnat Ada in gcc?

[Stan Shebs]

Robert Dewar wrote:
> 
> <<You're working on free software for the fsf, therefore IMO you ought
> to be doing your development in the open if at all possible.  And
> clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
> not only possible, but not particularly difficult.
> >>
> 
> Actually from past experiences recently, e.g. with the ia64 port, I have
> been struck by how closed the development was. Same thing for gdb5, this
> was kept under wraps for a long time. A large company (I won't name names)
> that we worked with was essentially operating as though it were under
> non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
> and it is hard to see how else it could have been done.

The GDB 5 changes were basically the last gasp of the old way of
working on GDB.  Since we didn't think anybody else cared what we
did with GDB internals, the reasoning went that there wasn't much
point in posting a lot of information externally, since the developers
involved were on Cygnus' internal mailing lists, and the discussion
happened there.  In retrospect, it meant that we missed out on input
from other people who've since become valuable contributors to the
open process, so I wouldn't recommend to anybody that they go the
closed way again, at least for general architectural improvements.

For big projects done openly, branches work pretty well.  If you look
at GCC for the past year, there have been a number of efforts that
used a branch while they were incomplete.  There is also the scaffolding
or configure option approach, such as is being done now for the
integrated preprocessor.  

Now having worked large projects both ways, I must say that I can't see
any technical advantages to closed development.  Closed development
should be a disfavored option, only taken in exchange for an explicit
payoff such as funding for a specific improvement or extension.

Stan

Re: Why not gnat Ada in gcc?

[Daniel Berlin]

Stan Shebs <shebs@apple.com> writes:

> Robert Dewar wrote:
> > 
> > <<You're working on free software for the fsf, therefore IMO you ought
> > to be doing your development in the open if at all possible.  And
> > clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
> > not only possible, but not particularly difficult.
> > >>
> > 
> > Actually from past experiences recently, e.g. with the ia64 port, I have
> > been struck by how closed the development was. Same thing for gdb5, this
> > was kept under wraps for a long time. A large company (I won't name names)
> > that we worked with was essentially operating as though it were under
> > non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
> > and it is hard to see how else it could have been done.
> 
> The GDB 5 changes were basically the last gasp of the old way of
> working on GDB.  Since we didn't think anybody else cared what we
> did with GDB internals, the reasoning went that there wasn't much
> point in posting a lot of information externally, since the developers
> involved were on Cygnus' internal mailing lists, and the discussion
> happened there.  In retrospect, it meant that we missed out on input
> from other people who've since become valuable contributors to the
> open process, so I wouldn't recommend to anybody that they go the
> closed way again, at least for general architectural improvements.
> 

I still don't get what massive gdb 5 changes were done so amazingly privately,
unless the changelogs are wrong or misleading me. They probably are misleading.
I was only submitting C++ patches and a few general improvements at
the time.

I know GDB development wasn't exactly open, but since about january of
2000, everything seemed to being done in the open, which is months
before gdb 5 even branched.


--Dan

Re: Why not gnat Ada in gcc?

[Chris G. Demetriou]

Gah, accidentially sent the message below to gcc-patches, when i meant
to send it to gcc.  *sigh*  Guess my fingers are too used to typing
gcc-patches.  Sorry about that.

cgd@sibyte.com (Chris G. Demetriou) writes:

> dewar@gnat.com (Robert Dewar) writes:
> > <<You're working on free software for the fsf, therefore IMO you ought
> > to be doing your development in the open if at all possible.  And
> > clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
> > not only possible, but not particularly difficult.
> > >>
> > 
> > Actually from past experiences recently, e.g. with the ia64 port, I have
> > been struck by how closed the development was.  [ ... ]
> 
> Eh; development happens in private, patches get submitted, then
> they're public.  I think the point is, _everybody_ can do private
> development and submit patches to the public tree and have them
> included into the public tree.
> 
> Where that breaks down -- and does leave me with a feeling of at least
> somewhat-closed development -- is that it can often times take
> _months_ if not longer for a 'random' third party's (tested) patch to
> be approved and integrated...
> 
> I recognize that people who read these lists and integrate patches do
> so basically as volunteers, and can't fault them for their lack of
> time to do so if that's what slows acceptances down.  However, the end
> result is that there seems to be effectively two classes of patch
> submitters: those on the inside, who get their patches approved
> relatively quickly (or do it themselves, because they have the
> reputation and authority to do so); and those on the outside who have
> to wait who knows how long.
> 
> 
> cgd
> (Not speaking for SiByte, of course.  8-)

Re: Why not gnat Ada in gcc?

[Richard Henderson]

On Wed, Nov 01, 2000 at 09:53:51PM -0500, Robert Dewar wrote:
> Actually from past experiences recently, e.g. with the ia64 port, I have
> been struck by how closed the development was.

I suppose I can see how anyone without Intel NDAs might think that.

The fact of the matter is that the development was very open, at
least to anyone who had proper Intel paperwork.  HP did the initial
gcc and binutils work; Cygnus refined both and began optimization
work; folks from CERN, Intel, IBM, SGI, SuSE, TurboLinux, and VA
were testing new code regularly.

Things were done with as much community involvement as the lawyers
would allow.



r~

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Making RPMs is not part of a GNU maintainer's duties.  Our preferred
version of GNU/Linux is Debian, so we should give Debian developers
full cooperation, but we normally don't tell GNU package maintainers
that they themselves should make the Debian packages (though they can
do that job too if they want to).
>>

OK, that's what I thought. At the same time, making RPM's is definitely
useful, and in fact we are planning to do this for the next release.

<<However, Guerby's message suggested that there are other issues
involved, that this is not just a matter of making packages.
>>

Well there are technical issues as I mentioned (shared libraries working
completely, and Linux threads eing the default).

We have now solved the shared library problems (the GNAT for GNU/Linux
folksw issued shared libraries before they were working fully). We have not
yet got to the stage where
we are sure that it is a good idea to use Linux Threads (always hard to
know how to refer to something like this, if you say GNU/Linux Threads then
people will think you are talking about a different package, since the author 
called this package Linux Threads) by default.

But anyway, there are no issues I know of that are significant.

<<Anyway, would you please ask the people who make RPMs for the various
versions of GNU/Linux to please call their work "GNAT for GNU/Linux"?


I will definitely point this out. It is hard to persuade people to say
Redhat GNU/Linux, since this is really incorfrect, Redhat makes a software
product that has the title "Redhat Linux" and it is not really for others
to unilaterally change the name of another companies product. The important
thing which you certainly can insist on is that people use the phrase
GNU/Linux when they are talking ageneraly about the collection of systems.

Mind you, this is a very indepednet group, and all I can do is to ask, and
explain why I am asking. I know that there is opposition to this naming
from at least some peopel in that group.

I do try to make sure that ACT folks use the phrase GNU/Linux always, and
if you see mistakes from any ACT folks, you may assume that (a) it is a
slipup, and (b) it is fine to remind us.

What I find in practice is that people think that GNU/Linux is a special
version of Linux. I sometimes wonder whether it would be good idea to
simply make this happen ....

Robert

Re: Why not gnat Ada in gcc?

[Arnaud Charlet]

> But anyway, there are no issues I know of that are significant.

Indeed. Actually at this stage the RPMs of GNAT constitute a subset of
what ACT builds and distributes since they have disabled some options like
the alternate run time library.

The package that we generate, whether they are tarballs or RPMs or
.deb will all have the same exact capabilities (including the two run time
as long as we decide to keep both).

Arno

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

RMS wrote:
> However, Guerby's message suggested that there are other issues
> involved, that this is not just a matter of making packages.

The only issue I mentionned (a while ago now) was some minor
performance issues on math functions where on x86 the GNAT NT version
produces faster code than the GNU/Linux version (due to asm inline on
NT, and calling C function on GNU/Linux which introduce a slight
overhead), and I believe this issue is resolved. 

ACT mentionned the other issues (shared lib) have been resolved.

The rest is just a matter of making package for popular distributions,
and testing them properly (we know we can't match ACT testing
here). Debian GNU/Linux packages are available.

RMS wrote:
> Anyway, would you please ask the people who make RPMs for the various
> versions of GNU/Linux to please call their work "GNAT for GNU/Linux"?

The only mention of the world Linux alone AFAIK is in the team name
"Ada for Linux Team" - ALT, all the web pages say GNU/Linux, you can
check at < http://www.gnuada.org/alt.html >.

Robert Dewar wrote:
> We have not yet got to the stage where we are sure that it is a good
> idea to use Linux Threads

The Linux Threads (based on the clone syscall) do not support some of
the optional real-time features (priority scheduling) and may be some
of the core feature (I'm not sure, ACATS testing will tell ;-) of Ada
95, but they offer multiprocessor support and syscall blocking only
one thread, whereas the FSU thread package is a user-space
implementation whith full support for all the real-time features, but
no multiprocessor and a blocking call blocks everything.

The ALT team chose to enable by default the Linux Threads
implementation which is the most used thread implementation and for
now the ACT package enables by default the FSU Threads which allows
for the full Ada 95 feature use. The two packagings allow to change
the thread implementation anyway, this is only a "default" issue.

It looks like priority scheduling use is pretty rare amongst the
GNU/Linux Ada community, I know of no freely available code for
GNU/Linux that depends on it (of course I guess it's pretty common for
the GNU RTOS RTEMS users ;-).

May be future version of Linux Threads will offer the needed features
though.

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

I wrote:
> The two packagings allow to change the thread implementation anyway,
> this is only a "default" issue.

Spoke too fast, the latest ALT packaging no longer includes the FSU
thread implementation.

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Richard Stallman]

    I will definitely point this out. It is hard to persuade people to say
    Redhat GNU/Linux, since this is really incorrect,

"Redhat GNU/Linux" would be incorrect, since that would misrepresent
their name for the product.  In contrast, "Redhat's GNU/Linux system"
is legitimate, since that clearly doesn't present itself as their name
for the product.

"Redhat [GNU/]Linux" is another good option; it clearly states both
what the product really is and what their name for it is.

    What I find in practice is that people think that GNU/Linux is a special
    version of Linux. I sometimes wonder whether it would be good idea to
    simply make this happen ....

We already did sponsor a version of the GNU/Linux system.  It is
called Debian GNU/Linux.  But we want people to know that the versions
distributed by Red Hat and other such companies are also versions of
the GNU system.

Re: Why not gnat Ada in gcc?

[Alexandre Oliva]

On Nov 12, 2000, Richard Stallman <rms@gnu.org> wrote:

> "Redhat [GNU/]Linux" is another good option

Since we're talking about names, I think it's only fair to point out
that the name of the company is Red Hat, not Redhat or RedHat.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Why not gnat Ada in gcc?

[Richard Stallman]

    Since we're talking about names, I think it's only fair to point out
    that the name of the company is Red Hat, not Redhat or RedHat.

Thank you.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<If anything can be done in the GNAT sources to support shared
libraries better on GNU/Linux, I hope the GNAT developers will give it
high priority.  Every GNU package should support GNU/Linux well.
>>

Unfort8unately the reason we are conservative is that we have not solved
the tecnhnical problems associated with the use of shared libraries for
GNARL. The RPM's that are being built by others do not pass our full
regression suite. Now for the informal use for which most people are using
these RPM's the errors are marginal, and probably most people won't run into
them, but we cannot produce RPM's that malfunction. We do not consider
producing flawed software to be "supprting GNU/Linux well". We are
continuing to work on the tecnbical problems here.

The reason we do not default to native (kernel) threads is that there have
been technnical problems of exact compliance between the GNU/Linux native
thread model and the vgery specific requirements of the Ada definition.

We are experimenting now with making the use of GNU/Linux native threads
the default, but there is still work to be done here. Again, for the
informal use to which most people put these RPM's, the differences are
small, and indeed for many purposes, the native threads are preferable.

Until these technical issues are resolved, we recommend that any serious
use of GNU Ada use the binary versions prepared by Ada Core Technologies.
Yes, we are conservative, it is definitely part of our commitment to
high reliability, which after all is what Ada is all about!

Robert Dewar

Re: Why not gnat Ada in gcc?

[Arnaud Charlet]

> Unfort8unately the reason we are conservative is that we have not solved
> the tecnhnical problems associated with the use of shared libraries for
> GNARL.

Actually the technical problems have now been solved, and indeed the ACT
binaries come with a shared GNAT library. The difference with the ALT RPMs
is that by default GNAT will link with static libraries because this is
what most of our customers need to distribute/build their application, but
using the dynamic version of the GNAT library is straightforward, it is
simply a matter of specifying the -shared option to gnatbind.

Incidentally, the problems with the shared GNAT library were indeed related to
GNARL as Robert said, but the use of GNARL in the previous post was misleading.
GNARL is the tasking part of the GNAT run time, it is not the entire run time,
as the poster implied, and as many people believe, so I thought it was worth
making this clarification.

Arno

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Meanwhile, I have to wonder why running GNU Ada on a popular version
of the GNU system needs the attention of a group outside the core
developers of GNU Ada.  Supporting GNU/Linu ought to be one of the
main priorities of the core group.
>>

Once again, is it really the case that the GNU project routinely
prepares Redhat Linux and Suse Linux RPM's (note I somewhat deliberately
am using Linux rather than GNU/Linux in this sentence, since I am quoting
the names of commercial products, and these companies do not use the
term GNU/Linux). We certainly have not seen this as a main priority.
We do see it as a priority to provide standard easily installable
binary releases for GNU/Linux.

Re: Why not gnat Ada in gcc?

[Richard Stallman]

    Once again, is it really the case that the GNU project routinely
    prepares Redhat Linux and Suse Linux RPM's

Making RPMs is not part of a GNU maintainer's duties.  Our preferred
version of GNU/Linux is Debian, so we should give Debian developers
full cooperation, but we normally don't tell GNU package maintainers
that they themselves should make the Debian packages (though they can
do that job too if they want to).

However, Guerby's message suggested that there are other issues
involved, that this is not just a matter of making packages.

Anyway, would you please ask the people who make RPMs for the various
versions of GNU/Linux to please call their work "GNAT for GNU/Linux"?

PS. Please keep in mind that I transfer mail in batches once or twice
a day.  I am always responding to the mail that was sent to me between
24 and 48 hours ago.  So my response to any point you raise will
always be delayed; please don't interpret this delay as making any
assertion about the topic.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<So if there is a need for an outside project to work on GNAT to get it
to work well in GNU/Linux, does that mean the standard GNAT is not
paying enough attention to the system it is part of?
>>

The issue is generating RPM's, which we (ACT) do not provide. Note that
historically most distribution of software in the GNU system has
concentrated on distributing compilable sources, rather than turnkey
binaries. 

ACT does provide binaries in our standard release form, and they work
just fine on GNU/Linux. But some people prefer to use binaries in
RPM form, so we make sure these are available to by working closely
with the GNAT for GNU/Linux team, who are a set of volunteers who
help to make GNAT more useful, especially for casual users under Linux.

Part of the reason that we have not made RPM's available is that it is
not actually easy to do this without introducing some subtle tasking
errors. For casual use, no one cares too much about these errors, but
we have not made RPM's available to our customers pending resolution of
the technical issues here, which are tricky.

But as I say, our binary release for GNU/Linux work just fine, and we
have lots of people, both supported paying customers, and users of the
public binary version, including students, free software developers etc,
who are using our binary release without any problems.

Robert Dewar

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<AFAIK, 3.13p packaged for DOS went out before the Linux version
(gnuada project on sourceforge) and is actively maintained.
>>

Interesting, last I asked, this was a small subset that omitted all
of tasking (the only part that is even slightly non-trivial in
maintaining the port). Laurent, do you know that there is now a
tasking 3.13p DOS version? If so that's nice to hear, since for
a long time, this was not the case.

It is also good to hear that the Linux RPM's are appearing, as I said
earlier, when volunteers are at work, other demands on their time
can take precedence, and one should not assume that people have
lost interest just because you don't see them working away
furiously!

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    Well, that sounds like the solution to the problem, then.  What you've
    got here is a case of people following the rules of the GPL, violating
    their NDA, and not having the NDA enforced against them.  So long as
    no-one enforces the NDA, what's the problem?

None if a company is going to assume that companies such as Intel won't
enforce their NDA!  However, most companies I know of would certainly assume
that Intel *would* enforce their agreement and would severely discipline any
employee that caused them to breach such an agreement.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    But _I_ am not imposing any further restrictions.  You did not sign an
    NDA with me.  As far as I am concerned you can do anything with it
    that you want.

In that case you are violating the NDA!  You can't do this without
violating one or the other.  If you give it to a third party without
saying it's under the NDA ("a further restriction" and thus not permitted
by the GPL), you are violating the NDA.

Re: Why not gnat Ada in gcc?

[John P. Pietrzak]

On Thu, 2 Nov 2000, Richard Kenner wrote:

>     But _I_ am not imposing any further restrictions.  You did not sign an
>     NDA with me.  As far as I am concerned you can do anything with it
>     that you want.
> 
> In that case you are violating the NDA!  You can't do this without
> violating one or the other.  If you give it to a third party without
> saying it's under the NDA ("a further restriction" and thus not permitted
> by the GPL), you are violating the NDA.
> 

Well, that sounds like the solution to the problem, then.  What you've got
here is a case of people following the rules of the GPL, violating their
NDA, and not having the NDA enforced against them.  So long as no-one
enforces the NDA, what's the problem?

--John

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<But all this is way off-topic for this mailing list, I think...
>>

I certainly agree. I thought that this issue had been laid to rest
with the previous discussion, but Jeff Law was interested in continuing
the discussion here. 

My own thought is that the entire thread under the above subject is a 
bit of a tempest in a teapot.

Let us proceed with our work in getting the GNU Ada sources into the
gcc tree, then let us work on helping to maintain them as effectively
as we can -- we are certainly eager to do this, and to do it in a manner
that will be as helpful as possible to the GNU community.

If people don't like what they see, or have suggestions for improvements,
they will make much more sense when made with respect to what is actually
happening, rather than people's imaginations of what might happen.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    As I understand it, the restrictions in the GPL are upon what controls
    the distributor can impose over the person receiving the GPL'd
    product.

Right.

    There is no requirement that either the distributor or the consumer
    _have_ to re-distribute that product to other parties; 

Right.

    I believe there's no restriction upon separate agreements with a third
    party concerning the contents of that material.

That's wrong and is the key.  If such "separate agreements" were permitted,
the GPL would be meaningless.  The section that prohibits such has already
be sent along in this thread.

    Therefore, an NDA holder could potentially distribute GPL'ed material
    to other NDA holders without any problem, 

Nope.  It's actually not even clear if the NDA formally allows that, though
may people do indeed operate as if it does.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Well, it appears that Red Hat and ACT have different policies on this kind
of thing.
jeff
>>

Indeed! ACT insists that all our development on GPL'ed stuff be unencumbered
by NDA's. One advantage of that is that we need to maintain only one
branch of development, and when we distribute to a customer, they get
everything we have at the current date, nothing ever needs to be held back
for NDA reasons.

Actually it sounds like ACT, given this policy, will have an *easier* time
avoiding the problem of big chunks being held back than Redhat, despite
jeff's loud concerns :-)

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<The point was that bulk merges (regardless of where they come from) are a
particularly bad way to sync the official GNU sources with some other
source base.  I was just using the merges you did as an example.  The
bulk merges I used to do from the gcc2 sources before gcc2 deveopment
finally died were just as disruptive.
>>

One clarification that may be useful since it has caused confusion in
at least one previous post, is that there are two issues here.

1. Doing a large bunch of changes at the same time in a coordinated
manner. That can be disruptive certainly, and disruption is to b e
avoided. On the other hand uncoordinated changes done separately
can be even more disruptive. The goal is minimizing disruption, and
generally incremental updates are desirable from this point of view,
no one objects. Indeed we have been maintaining our changes as separate
patches for some time, with the idea that when the GNAT/GNU/Linux folks
put up a tree, we would provide them, but that didn't happen. So now
that will happen in the context of the gcc tree.

2. Combining separate changes into single patches. This is of course
never allowed under any circumstances, and certainly is something we
would expect to avoid unconditionally.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102154028.B37DD34D80@nile.gnat.com >you write:
  > One clarification that may be useful since it has caused confusion in
  > at least one previous post, is that there are two issues here.
[ ... ]
Thanks.  This helps a lot.  
jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Why should it surprise you that one of our customers wanted a completely
revamped ia32 backend which was geared towards supporting PII/PIII cores
in a sane manner and didn't want anyone to know about it before the work
was complete?
>>

As I say, we never ever tolerate NDA's that cover GPL'ed code in any
form, it is one of our strong corporate policies. It is one thing to
have a general agreement that development will not be released till
it is in reasonable shape (something that often makes sense anyway),
and quite another to have a formal NDA prohibiting distribution.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102153715.911A334D82@nile.gnat.com >you write:
  > <<Why should it surprise you that one of our customers wanted a completely
  > revamped ia32 backend which was geared towards supporting PII/PIII cores
  > in a sane manner and didn't want anyone to know about it before the work
  > was complete?
  > >>
  > 
  > As I say, we never ever tolerate NDA's that cover GPL'ed code in any
  > form, it is one of our strong corporate policies. It is one thing to
  > have a general agreement that development will not be released till
  > it is in reasonable shape (something that often makes sense anyway),
  > and quite another to have a formal NDA prohibiting distribution.
Well, it appears that Red Hat and ACT have different policies on this kind
of thing.
jeff
  > 
  > 

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    The point was that bulk merges (regardless of where they come from) are a
    particularly bad way to sync the official GNU sources with some other
    source base.

Yes, but the extent to which they are bad is a strong function of the number
of changes made by others, which is what started this whole thread.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    The fact of the matter is that the development was very open, at
    least to anyone who had proper Intel paperwork.  HP did the initial
    gcc and binutils work; Cygnus refined both and began optimization
    work; folks from CERN, Intel, IBM, SGI, SuSE, TurboLinux, and VA
    were testing new code regularly.

But there's no legal way to restrict GPL'ed material to "those who had the
proper Intel paperwork"!

Re: Why not gnat Ada in gcc?

[John P. Pietrzak]

On Thu, 2 Nov 2000, Richard Kenner wrote:

>     The fact of the matter is that the development was very open, at
>     least to anyone who had proper Intel paperwork.  HP did the initial
>     gcc and binutils work; Cygnus refined both and began optimization
>     work; folks from CERN, Intel, IBM, SGI, SuSE, TurboLinux, and VA
>     were testing new code regularly.
> 
> But there's no legal way to restrict GPL'ed material to "those who had the
> proper Intel paperwork"!
> 

Logically, sure you can.  As I understand it, the restrictions in the GPL
are upon what controls the distributor can impose over the person
receiving the GPL'd product.  There is no requirement that either the
distributor or the consumer _have_ to re-distribute that product to other
parties; and I believe there's no restriction upon separate agreements
with a third party concerning the contents of that material.

Therefore, an NDA holder could potentially distribute GPL'ed material to
other NDA holders without any problem, and this material could
be freely re-distributed under the to non-NDA holders without violating
the GPL, but someone along the line would have to violate their NDA.

But all this is way off-topic for this mailing list, I think...


--John

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<I think that a lot of the "ia32" references have been typos for "ia64".
>>

Indeed, and that was my fault, although the typo did yield the interesting
information that the ia32 work had been done under non-disclosure, which
sure seems very strange to me. As I say, at ACT we have a policy of not
doing any work on GPL'ed software that is restricted by NDA's (we of course
have NDA'
s in place with some companies to protect confidential data, such as
customer code, but this never applies to GPL'ed code).

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102131333.CE6BF34D80@nile.gnat.com >you write:
  > <<I think that a lot of the "ia32" references have been typos for "ia64".
  > >>
  > 
  > Indeed, and that was my fault, although the typo did yield the interesting
  > information that the ia32 work had been done under non-disclosure, which
  > sure seems very strange to me.
Why should it surprise you that one of our customers wanted a completely
revamped ia32 backend which was geared towards supporting PII/PIII cores
in a sane manner and didn't want anyone to know about it before the work
was complete?

jeff

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    Then can you see that if the ACT tree isn't the official GNU Ada tree
    that the official FSF GNU Ada has to be somewhere else?  And that
    somehow you have to manage the process of dealing with changes from
    multiple sources?  And that the burden for managing those changes has
    to fall on ACT, not the other developers?

I'm not aware of anybody that disagrees with *any* of the above statements;
certainly Robert and I don't.  I think you're raising a strawman here.

    ie, let's assume that for some reason I need to make a series of
    changes to the GNU Ada sources due to changes elsewhere in the
    compiler.  It will be ACT's responsibility to make sure those changes
    get into ACT's repository and that ACT does not clobber those changes
    when ACT wants to install some of their changes into the GNU
    repository?

Right, but note that such changes would be in the "gigi" part of GNAT,
not in the main compiler sources (which operate on a Ada-specific node
structure).

    What makes you think the ia32 port came out of the blue?  

I think that a lot of the "ia32" references have been typos for "ia64".

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    <<In fact, the bulk changes from ACT have been one of the biggest
    offenders in the past. >>

    Indeed, the bulk changes here were the result of having to merge two
    very different streams of development, and that was not at all easy to
    do. Hopefully that is done now, and is not something that needs
    repeating in future!

Not only that, but these changes had little to do with ACT.  They were
the result of merging the old gcc2 tree into the (then) EGCS tree.
Sure, some of those changes originated at ACT (or were done by me with
my ACT hat on), but that was not the majority of the changes.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10011021306.AA08093@vlsi1.ultra.nyu.edu >you write:
  >     <<In fact, the bulk changes from ACT have been one of the biggest
  >     offenders in the past. >>
  > 
  >     Indeed, the bulk changes here were the result of having to merge two
  >     very different streams of development, and that was not at all easy to
  >     do. Hopefully that is done now, and is not something that needs
  >     repeating in future!
  > 
  > Not only that, but these changes had little to do with ACT.  They were
  > the result of merging the old gcc2 tree into the (then) EGCS tree.
  > Sure, some of those changes originated at ACT (or were done by me with
  > my ACT hat on), but that was not the majority of the changes.
The point was that bulk merges (regardless of where they come from) are a
particularly bad way to sync the official GNU sources with some other
source base.  I was just using the merges you did as an example.  The
bulk merges I used to do from the gcc2 sources before gcc2 deveopment
finally died were just as disruptive.

jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<According to the regression tester, since inception about 50% of the
test runs (it's continuous, so a test run happens about every three
hours if the flow of patches is sufficiently constant) were full
passes, that is the result was as good as the best previous result.
We seem to be doing marginally better recently, but more 60% not 90%.
This is for one target, other targets probably do worse.
>>

Right, my 90% is indeed across all targets. For any single target,
the figure for us would be more like 98%.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<The GPL says "if you distribute copies ... you must give recipients
all the rights that you have".  Clearly then, if you do not distribute
copies then you need not give out the source either.  Similarly, if you
being under NDA only distribute copies to other parties also under NDA,
the GPL does not release them from their other obligations, which do
in fact prevent them from distributing source _or_ binaries beyond any
who have not signed the proper paperwork.

That's not to say that I enjoy NDAs, but I also do not see them at odds
with the GPL either in spirit or in letter.
>>

Well I must say it is quite interesting to have a direct statrement
from cygnus.com that is it perfectly fine to distribute GPL'ed code
under the restriction of an NDA. I see things very differently, and
indeed distributing GPL'ed code under an NDA seems quite clearly to
violate para 6:

  6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.

An NDA sure sounds like a "further restriction" to me!

Re: Why not gnat Ada in gcc?

[Richard Henderson]

On Thu, Nov 02, 2000 at 07:40:18AM -0500, Robert Dewar wrote:
> An NDA sure sounds like a "further restriction" to me!

But _I_ am not imposing any further restrictions.  You did not sign an
NDA with me.  As far as I am concerned you can do anything with it that
you want.

However, if you the recipient have signed some other document saying
that you will not reveal particular details about a bit of silicon,
and the gcc source contains those details, then as paragraph 7 states
you may not distribute the Program at all.


r~

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<However, I do believe that ACT should follow the same rules as other
developers.  In particular, there's a general policy:

   If you have several unrelated changes, you should check them in
   with separate cvs commit commands.

that each patch, as submitted to gcc-patches and as committed to the
tree, should not include multiple unrelated features or bug fixes.
This makes it possible for those reviewing patches, trying to isolate
a single bug fix, trying to isolate a single bug introduction,
regression testing, or trying to use the CVS history to do this
effectively.
>>

Yes, we are of course perfectly aware of these procedures, what gave you
or anyone else the idea that we planned not to follow them?

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<The fact of the matter is that the development was very open, at
least to anyone who had proper Intel paperwork.  HP did the initial
gcc and binutils work; Cygnus refined both and began optimization
work; folks from CERN, Intel, IBM, SGI, SuSE, TurboLinux, and VA
were testing new code regularly.
>>

I am very aware of the process that was followed, but the issue I
raised here was that these community members who "had done the
proper Intel paperwork" were in some cases exchanging GPL'ed
code under a non-disclosure, which is clearly impermissible
under the GPL.

<<Things were done with as much community involvement as the lawyers
would allow.
>>

But the GPL does not allow community involvement to be limited in 
this manner by lawyers :-)

Re: Why not gnat Ada in gcc?

[Mike Stump]

> To: Mike Stump <mrs@windriver.com>
> Date: Wed, 01 Nov 2000 22:04:31 -0700
> From: Jeffrey A Law <law@cygnus.com>

> Exactly.  In fact, Geoff's automatic regression tester and "email
> the offending parties" is proving quite useful in identifying
> culprits and getting them to fix their problems.

Cool!  I took another look at it, and wow! neat!  Glad to see some CPU
cycles spent like this.  Oh, and after reviewing most of the bitchmail
since July 3rd, 2000, it seems that the qulaity of gcc as measured by
the tester has remained at 0 + epsilon, were epsilon has ranged
between 0 and 11 or so.  So, there you have it, the quality is stable
and good.  The only thing left, is to get everyone running something
like it for all their real targets and systems they are interested in,
and ramp up the data.  I'll make a prediction, the numbers will remain
at 0 + epsilon, for all testing that we do.  If you want performance
to remain good, merely put it in the testsuite.

> Yes, Dewar, if someone breaks the tree, they get a nasty gram about
> it.  In fact, the bulk changes from ACT have been one of the biggest
> offenders in the past.

We need the system to tally up the hate mail stats, and present a
bozos web page of people that like to break and not fix the compiler,
followed by the people that break it and leave it broken the longest.

:-) It is amazing the coercive power I think we can find in such a
system.  Also, systems like this should measure the good side, and
remark when people do good.  (His does.)

So, I have disk and CPU to burn, is there is distribution that has
enough bits to let me pump more data into the process?  I currently
pump only via test summary.  A good start.  If the answer is no, I'd
like to request people consider putting the source in contrib in cvs.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<OK.  Then do you see how to separate your needs as a company from the needs
of the GNU development community and how to resolve those differences in such
a way as to put everyone on equal footing in regards to GNU Ada?  I don't
think so, partly due to this lengthy discussion and partly because you've
never really tried to play this game in the past.
>>

Of course. In fact I don't see a problem here, let's see how things work out.

<<We've never done that.  Sorry if you got that impression.
>>

But that's what you seemed to be saying, and that is all I was questioning.

<<Then can you see that if the ACT tree isn't the official GNU Ada tree
that the official FSF GNU Ada has to be somewhere else?  And that somehow
you have to manage the process of dealing with changes from multiple sources?
And that the burden for managing those changes has to fall on ACT, not the
other developers?
>>

Of course, that's why we are working to put the GNAT sources in the main
gcc tree!

<<We always have a certain amount of ongoing development that we provide to
our customers, then make available to the net.
>>

Again, I see no difference in our plans from what you have been doing
as best I understand it, except that I gather that in some cases you
hold things back because of NDA's and that is something we will not
do as a matter of policy.

<<Where I think we disagree is on the topic of how changes get into the
official GNU tree and how we're going to ensure that all developers are
on equal footing.
>>

I don't really see any substantial disagreement

<<What makes you think the ia32 port came out of the blue?  Oh yea, you haven't
been active in gcc discussions until the last month or so.  You have to rely
on what others told you.  Why don't you go back and see the archives of the
development list where you'll find significant discussions about the new
backend and collaborative work from various sources before it was installed
to the head of the GCC tree.
>>

Oops, my finger typing mistake, sorry for confusion, I was talking about
the ia64 port.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Nope.  I would never suggest that.  That's why Red Hat has a process for
importing code from the external tree and beating it into shape before it
gets exposed to customers.
>>

Jeff, I defintiely think you are worrying too much too early, and that 
in fact things will work out smoothly, why not just wait and see here.
The initial steps of getting the current sources into the tree have
to be done in any case.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<:-) Nope, on a couple of counts.  First, my SOP was to take the time
to sanitize the testcase, and fold it into the testsuite.  Nearly all
of my testcases made the transition from company confidential to
public testcase.  I don't know exactly how many were lost in the
transition to publicness, but my guess is not that many for the g++
testsuite.  (<3%?)  For the gcc testsuite, quite a bit of the content
originated as a public testsuite (c-torture).
>>

Things that can easily be cut down to a simple test case are one thing,
but we find that a very valuable source of stress testing is precisely
large realistic applications with hundreds of thousands of lines of
complex code. The ACVC suite for Ada is fine for the simple test case
kind of testing, but the large scale stress testing is another matter.

Of course it is nice if people can contribute such open stress cases (the
GNAT bootstrap itself has proved a pretty severe test of the code generator
in practice for exmple, and that particular test case will most certainly
be available!

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Actually, you should look at the true history of the new ia32 port.  While the
initial work was done internally under NDA.  Eventually the development was
moved externally onto a branch so that everyone could collaborate in an open
way.  Once the various parties were happy with the state of the work, that
work was moved into the head of the gcc tree.
>>

I know EXACTLY the true history here (for several reasons I am aware of 
this history). Yes, things were fine once the external move was made, but
it is the previous stage, where "various parties" exchanged copies under
NDA that was dubious (I use a gentle word here :-)

Re: Why not gnat Ada in gcc?

[Mike Stump]

> To: dewar@gnat.com, law@redhat.com, mrs@windriver.com
> Cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu, rms@gnu.org, rth@cygnus.com
> Date: Wed,  1 Nov 2000 23:39:41 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> Presumably only Cygnus/Redhat can measure this, since only they have
> the internal test suite that would give the data. 

:-) Nope, on a couple of counts.  First, my SOP was to take the time
to sanitize the testcase, and fold it into the testsuite.  Nearly all
of my testcases made the transition from company confidential to
public testcase.  I don't know exactly how many were lost in the
transition to publicness, but my guess is not that many for the g++
testsuite.  (<3%?)  For the gcc testsuite, quite a bit of the content
originated as a public testsuite (c-torture).

Second, it can still be measured against the public testsuite, even
though some internal testsuites might give slightly better results.

Third, the there is a testresults web page that has the last
information on it ( http://gcc.gnu.org/testresults/ ), you merely have
to mine it out.

And last, _you_ have a testing framework that can tell you about the
quality of gcc.  You merely have to ask it.  (Yes, I know how hard
this is.  I have my own framework as well, complete with ~88 boards),
and I don't yet ask it about public sources.)

> Well I think in the case of Ada it will be a huge help to make the
> official validation (ACATS) tests available and runnable, and that
> is one of our projects (these are openly available tests, but
> setting them up to run is nowhere near trivial).

Should be.  For gcc/g++/g77/objc/libstdc++/libio, the goal is make
check.  That mostly works.  It is mostly easy to run.  If you engineer
them to work from make check, I think they can be made to be trivial.
For example, the Fortran testsuite is so trivial to run, that almost
no one who runs tests doesn't also run it, even though they aren't
typically interested in Fortran.

> Unfortunately the more significant test suites (the ACT internal
> test suite, and the Digital test suite) are full of highly protected
> proprietary code, and cannot be made available for external use.

Can you report the results publicly?  If so, maybe you can give warm
fuzzies, without saying exactly what went wrong.

> It will be interesting to see how stable things stay ...

It'll be 6 months to condition people to understand the results you
feed them, and to condition them to stop breaking it.  After the ramp
up, people should mostly keep it to the quality you expect.  If they
don't, let's talk about it again, then.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Yes, it's true stuff like Plumhall and Perennial are not publicly available
and they provide better coverage than the regression testsuites.  But you can
get a pretty good "sniff test" by running the public testsuites.
>>

Right, and in the case of Ada, the ACATS regression suite, far more
extensive than anything currently publicly available for C or C++,
will be very helpful. One of the great achievments of the Ada
development is that all such artifacts are freely available (as
for example are all the Ada standards documents, which was not
an easy fight with ISO :-)

As I said earlier, the missing link is to make an easy way of runnig
these tests, and that is one of the jobs on our list!

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Exactly.  In fact, Geoff's automatic regression tester and "email the offending
parties" is proving quite useful in identifying culprits and getting them to
fix their problems.  I'm not arguing it's perfect, but it's one step in the
right direction.
>>

Indeed this kind of automatic regression tester is very valuable, it is
exactly how we proceed internally.

<<Yes, Dewar, if someone breaks the tree, they get a nasty gram about it.  In
fact, the bulk changes from ACT have been one of the biggest offenders in the
past.
>>

Can I be Robert, if Geoff is Geoff and you are jeff :-)

Indeed, the bulk changes here were the result of having to merge two
very different streams of development, and that was not at all easy
to do. Hopefully that is done now, and is not something that needs
repeating in future!

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Certainly.  And I think you'll start seeing some of that kind of infrastructure
being built out in the not too distant future.
>>

We will certainly be happy to help in that effort!

Re: Why not gnat Ada in gcc?

[Mike Stump]

> Date: Wed,  1 Nov 2000 23:28:31 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> Well the point is that NDA's and the GPL definitely do not mix well!
> I don't think anyone could argue otherwise.

Well, I've seen it work well for more than half a decade, what's
your experience?  And I'd be happy to argue the point!

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Instead of believing, or guessing, why not measure.  We have a
database of runs.  Tell us what the numbers are.  I know what I am
used to.  I am used to the numbers being fairly stable.  My biggest
>>

Presumably only Cygnus/Redhat can measure this, since only they have
the internal test suite that would give the data. 

<<If you provided the feedback for the public sources, in a sane manner,
I suspect you could get the developers to stop breaking things as
often as you think they do.
>>

Well I think in the case of Ada it will be a huge help to make the
official validation (ACATS) tests available and runnable, and that
is one of our projects (these are openly available tests, but setting
them up to run is nowhere near trivial). Just providing feedback on
these tests will be very helpful.

Unfortunately the more significant test suites (the ACT internal test
suite, and the Digital test suite) are full of highly protected proprietary
code, and cannot be made available for external use.

It will be interesting to see how stable things stay ...

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102043941.B11F734D82@nile.gnat.com >you write:
  > <<Instead of believing, or guessing, why not measure.  We have a
  > database of runs.  Tell us what the numbers are.  I know what I am
  > used to.  I am used to the numbers being fairly stable.  My biggest
  > >>
  > 
  > Presumably only Cygnus/Redhat can measure this, since only they have
  > the internal test suite that would give the data. 
Err, there is a fairly large (and constantly growing) regression testsuite
for gcc, g++ and a small (but growing) regression testsuite for g77 & objc
available to the public.  In fact, it's been available for years and
integrating it with the source tree has proven quite valuable.

Yes, it's true stuff like Plumhall and Perennial are not publicly available
and they provide better coverage than the regression testsuites.  But you can
get a pretty good "sniff test" by running the public testsuites.


jeff

Re: Why not gnat Ada in gcc?

[Mike Stump]

> To: dewar@gnat.com, law@redhat.com
> Cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu, rms@gnu.org, rth@cygnus.com
> Date: Wed,  1 Nov 2000 22:58:41 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> But it is VERY rare for regressions to occur on nightly runs, I
> would say that 90% of the time the nightly builds are completely
> clean and run the entire regression suites completely. I cannot
> believe that this is true of the current gcc open tree (unless the
> test suites are very weak indeed).

Instead of believing, or guessing, why not measure.  We have a
database of runs.  Tell us what the numbers are.  I know what I am
used to.  I am used to the numbers being fairly stable.  My biggest
gripe is that they are not exactly zero.  I run the libio libstdc++
objc fortran and g++ testsuites for a couple of years and guess what,
nearly always zero.  g++ hovered around 25 for a while, then dipped
into the 9 range, where it has been stable for a long time.  I've been
watching the testresults for the past 8 years.  For gcc, it seems to
hover around 26.  Has for a while, will for a long while from now.

My experience is, once you measure, and then provide that measurement
back to the developers in a timely fashion, in a sane format, they
will actually learn to keep the numbers at zero, once they get them
down to zero.  Currently the testing feedback to developers kinda
sucks right now at the FSF, it is better inside of Cygnus, ACT.

If you provided the feedback for the public sources, in a sane manner,
I suspect you could get the developers to stop breaking things as
often as you think they do.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 200011020435.UAA27399@kankakee.wrs.com >you write:
  > > To: dewar@gnat.com, law@redhat.com
  > My experience is, once you measure, and then provide that measurement
  > back to the developers in a timely fashion, in a sane format, they
  > will actually learn to keep the numbers at zero, once they get them
  > down to zero.  Currently the testing feedback to developers kinda
  > sucks right now at the FSF, it is better inside of Cygnus, ACT.
  > 
  > If you provided the feedback for the public sources, in a sane manner,
  > I suspect you could get the developers to stop breaking things as
  > often as you think they do.
Exactly.  In fact, Geoff's automatic regression tester and "email the offending
parties" is proving quite useful in identifying culprits and getting them to
fix their problems.  I'm not arguing it's perfect, but it's one step in the
right direction.

Yes, Dewar, if someone breaks the tree, they get a nasty gram about it.  In
fact, the bulk changes from ACT have been one of the biggest offenders in the
past.

jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Why don't you read the GCC 3.0 release criteria?
>>

By the way, I certainly have read these release criteria. Does everyone
agree that these criteria on their own ensure that the performance issue
is adequately addressed? If so, I certainly don't feel this is something
I can push on my own, but I would be surprised if that were the case.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<First, you don't get to complain, if you haven't contributed a single
testcase that measures performance.  After you donate one, then you
can.  After you show us all how it's done, then we can follow your
lead.  I think it is trivial:
>>

Well I think you need to establish a performance testing framework, and
that's not as easy as it sounds. Constructing individual tests is not
that hard, and indeed in some cases the tests already exist, e.g. the
PIWG tests for Ada, and Spec tests for C.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102043245.C6D5334DAF@nile.gnat.com >you write:
  > <<First, you don't get to complain, if you haven't contributed a single
  > testcase that measures performance.  After you donate one, then you
  > can.  After you show us all how it's done, then we can follow your
  > lead.  I think it is trivial:
  > >>
  > 
  > Well I think you need to establish a performance testing framework, and
  > that's not as easy as it sounds. Constructing individual tests is not
  > that hard, and indeed in some cases the tests already exist, e.g. the
  > PIWG tests for Ada, and Spec tests for C.
Certainly.  And I think you'll start seeing some of that kind of infrastructure
being built out in the not too distant future.

jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Both are fairly irrelevant here.  Both, I have absolutely no control
over.  If you want this to be the case, you have to set up a business
that parallels any business that does that, don't do it, and prove
that it is better.  That is the only real way to affect it.
>>

Well the point is that NDA's and the GPL definitely do not mix well!
I don't think anyone could argue otherwise.

Re: Why not gnat Ada in gcc?

[Richard Henderson]

On Wed, Nov 01, 2000 at 11:28:31PM -0500, Robert Dewar wrote:
> Well the point is that NDA's and the GPL definitely do not mix well!
> I don't think anyone could argue otherwise.

Nonsense.

The GPL says "if you distribute copies ... you must give recipients
all the rights that you have".  Clearly then, if you do not distribute
copies then you need not give out the source either.  Similarly, if you
being under NDA only distribute copies to other parties also under NDA,
the GPL does not release them from their other obligations, which do
in fact prevent them from distributing source _or_ binaries beyond any
who have not signed the proper paperwork.

That's not to say that I enjoy NDAs, but I also do not see them at odds
with the GPL either in spirit or in letter.



r~

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Why don't you read the GCC 3.0 release criteria?
>>

That does not really address what I was talking about, which is not
establishing some gating release criteria, but rather setting up
continued development procedures and testing regimens that ensure that
performance is *always* being considered. Performance is not an
add-on feature :-)

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<< don't know why as many emails about this matter have flown by.  All
he technical problems, have technical solutions.  If your message
oesn't have a technical problem, or a technical solution to a
iscussed problem, let's hold back on those emails.  After Ada is
ntegrated, and chugging away, then we can address the next round of
ssues, like please update more often, please check in code to our
ree first, who is gonna play in my code, why aren't you testing our
ree...  We can't have those problems, until after we get part the
irst one.
>>

That makes good sense to me. And that's what we are aiming at as 
quickly as possible. I think that if Jeff has remaining concerns,
they will make much more sense in the context of what is actually
happening rather than what anyone imagines MIGHT happen :-)

Re: Why not gnat Ada in gcc?

[Mike Stump]

> To: dewar@gnat.com, law@redhat.com
> Date: Wed,  1 Nov 2000 22:43:15 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> NDA's should not be permitted in this environment

I don't think people with purple spots should be allowed to sing in
the bathroom.

Both are fairly irrelevant here.  Both, I have absolutely no control
over.  If you want this to be the case, you have to set up a business
that parallels any business that does that, don't do it, and prove
that it is better.  That is the only real way to affect it.

Re: Why not gnat Ada in gcc?

[Mike Stump]

> To: dewar@gnat.com, law@redhat.com
> Cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu, rms@gnu.org, rth@cygnus.com
> Date: Wed,  1 Nov 2000 22:31:12 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> Yes, but of course you cannot deal with daily instability for actual
> commercial development for large scale customers who depend on
> absolute stability.

There are solutions to this.  First, notice that exporting of work
from such a quality environment to a lesser quality environment
(ACT->FSF) is a no brainer.  Only the forward direction matters.  This
you can `time' anyway you want, depending upon any business reason you
need to.  Further, you can test the source before import, and only
after testing, use it as a base for the import.  Or, alternatively,
you can declare your source dirty (needing testing), run the import
into your environment, and then test and fix it, then after declare it
safe again.


I don't know why as many emails about this matter have flown by.  All
the technical problems, have technical solutions.  If your message
doesn't have a technical problem, or a technical solution to a
discussed problem, let's hold back on those emails.  After Ada is
integrated, and chugging away, then we can address the next round of
issues, like please update more often, please check in code to our
tree first, who is gonna play in my code, why aren't you testing our
tree...  We can't have those problems, until after we get part the
first one.

> Incidentally, one thing that I do NOT think is addressed well enough in
> the GCC development process is performance issues. As far as I can tell
> there is very little systematic performance testing,

First, you don't get to complain, if you haven't contributed a single
testcase that measures performance.  After you donate one, then you
can.  After you show us all how it's done, then we can follow your
lead.  I think it is trivial:

TIME a;
STARTTIME(a);
blabla
ENDTIME(a, importance_factor, "testcase subdescriptor");

...

and then you arrange for these bits to be exposed to the testcases.
ENDTIME does a:

	printf("PERF: %f %s %s\n",
		(endtime-starttime)*importance_factor, TESTCASENAME,
		testcase_subdescriptor);

You then have an analysis package that can do rmses of old-new from
the perf lines, and viola.  I've just not had a minute to donate the
infrastructure and a testcase.

If someone wants to pay for one, I think Mark has lots of free time
(Hi Mark).

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<I know GDB development wasn't exactly open, but since about january of
2000, everything seemed to being done in the open, which is months
before gdb 5 even branched.
>>

Well who knows, I only know what people were telling me ... :-)

Re: Why not gnat Ada in gcc?

[Daniel Berlin]

dewar@gnat.com (Robert Dewar) writes:

> <<I know GDB development wasn't exactly open, but since about january of
> 2000, everything seemed to being done in the open, which is months
> before gdb 5 even branched.
> >>
> 
> Well who knows, I only know what people were telling me ... :-)
Same here, I'm just going by personal recollection.
I'm young, i'm sure things were going on in the background that i had
no idea about.

--Dan

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<> I recognize that people who read these lists and integrate patches do
> so basically as volunteers, and can't fault them for their lack of
> time to do so if that's what slows acceptances down.  However, the end
> result is that there seems to be effectively two classes of patch
> submitters: those on the inside, who get their patches approved
> relatively quickly (or do it themselves, because they have the
> reputation and authority to do so); and those on the outside who have
> to wait who knows how long.
>>

Our experience with GNAT is that almost all patches submitted by
volunteers have been immediately incorporated. Of course once we
have an open tree, this gets to be a more useful statement!

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Ho ho, it's a big problem at Apple.  Almost every day I get to hear
from users about how GCC sucks because it's 10-20x (thats x, not %)
slower than Metrowerks compiling the same code on the same machine.
>>

Well obviously that has to be addressed, what steps are being taken to
address it. Clearly there should be some standard performance suites
run ...

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102040111.B022034DB1@nile.gnat.com >you write:
  > <<Ho ho, it's a big problem at Apple.  Almost every day I get to hear
  > from users about how GCC sucks because it's 10-20x (thats x, not %)
  > slower than Metrowerks compiling the same code on the same machine.
  > >>
  > 
  > Well obviously that has to be addressed, what steps are being taken to
  > address it. Clearly there should be some standard performance suites
  > run ...
Why don't you read the GCC 3.0 release criteria?
jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

That seems a perfectly reasonable proposition, in practice I think we 
will find it works out very smoothly, and people are worrying too much!

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<And that's precisely the procedure you would use if you did a merge from
the external (potentially unstable) tree into your internal tree.  Those
tests will likely find problems, you would fix them and submit the fixes
to the net sources.
>>

But it is VERY rare for regressions to occur on nightly runs, I would
say that 90% of the time the nightly builds are completely clean and
run the entire regression suites completely. I cannot believe that
this is true of the current gcc open tree (unless the test suites
are very weak indeed). 

<<Right.  THe problem is strictly your problem as a business, it is not a
problem for the GNU project.  Thus, you should confine that problem to your
own internal sources and not force it on the official GNU sources.
>>

No one is forcing anything on anyone! Indeed if anything it seems like
Jeff is trying to force some unworkable model here, although it is a little
hard to follow, since in practice, I think the situation with GNAT will
be quite similar to that of gcc, avoiding hopefully the phenomena of
out-of-the-blue major things like the ia32 port.

<<I agree, and it is a problem.
>>

(it = performance problems)

Yes, and it is a problem that absolutely has to be dealt with in 
our environment. As I said, I am quite surprised that this is not
a problem for Redhat and Cygnus (I know it is a significant problem
for other companies trying to make more use of GCC).

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102035841.1C5CB34D82@nile.gnat.com >you write:
  > <<Right.  THe problem is strictly your problem as a business, it is not a
  > problem for the GNU project.  Thus, you should confine that problem to your
  > own internal sources and not force it on the official GNU sources.
  > >>
  > 
  > No one is forcing anything on anyone! Indeed if anything it seems like
  > Jeff is trying to force some unworkable model here, although it is a little
  > hard to follow, since in practice, I think the situation with GNAT will
  > be quite similar to that of gcc, avoiding hopefully the phenomena of
  > out-of-the-blue major things like the ia32 port.
No.  I'm not trying to force an unworkable model here.  I'm trying to make
sure that ACT and anyone else that wants to get involved in GNU Ada development
is on equal footing.

Actually, you should look at the true history of the new ia32 port.  While the
initial work was done internally under NDA.  Eventually the development was
moved externally onto a branch so that everyone could collaborate in an open
way.  Once the various parties were happy with the state of the work, that
work was moved into the head of the gcc tree.

jeff

Re: Why not gnat Ada in gcc?

[Geoff Keating]

dewar@gnat.com (Robert Dewar) writes:

> <<And that's precisely the procedure you would use if you did a merge from
> the external (potentially unstable) tree into your internal tree.  Those
> tests will likely find problems, you would fix them and submit the fixes
> to the net sources.
> >>
> 
> But it is VERY rare for regressions to occur on nightly runs, I would
> say that 90% of the time the nightly builds are completely clean and
> run the entire regression suites completely. I cannot believe that
> this is true of the current gcc open tree (unless the test suites
> are very weak indeed). 

According to the regression tester, since inception about 50% of the
test runs (it's continuous, so a test run happens about every three
hours if the flow of patches is sufficiently constant) were full
passes, that is the result was as good as the best previous result.
We seem to be doing marginally better recently, but more 60% not 90%.
This is for one target, other targets probably do worse.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Yes you can.  Cygnus did it for 10 years.

I can't believe you're using this as an argument that the official sources
for GNU Ada will be in the ACT repository, not gcc.gnu.org and that merges
should happen from the ACT tree into the gcc.gnu.org tree.  I'm dumbfounded.
>>

No one said anything of the kind. What we said is that we cannot possibly
deal with the kind of instability that we see daily in the open gcc tree
as the base for the version we provide to customers. And I must say I
am equally dumbfounded by the claim that Cygnus has always provided to
its customers the current open tree, that's certainly not my understanding!

Noone is saying that the internal ACT build is "the official FSF GNU Ada",
it is simply what we provide for our customers. Indeed one important
service we provide our customers is precisely a guarantee that they
get a very carefully quality assured version of the compiler, even if
they are getting a daily wavefront build.

Patches and major modifications to the open tree will come from whoever
develops such changes. For the immediate future, most such changes will
clearly come from ACT, if and when others contribute, changes will
come from them.

I am completely at a loss to understand what Jeff's concerns here are. He
seems to be fulminating away, objecting to the attempt to make the GNAT
development more open. Well I must say, I think it makes sense to proceed
along these lines anyway, and we certainly intend to do so.

Yes, certainly there may be cases where significant new developments
are done in increments that make sense (the sudden appearence of the
ia32 port was after all a spectacular case of that happening for gcc,
I would certainly hope that we would have *nothing* like that happeniung
in the GNAT case, it seems VERY unfortunate to me to get major out-of-the-
blue changes of this kind, and I think that should be avoided in future.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102035442.3BA9F34D82@nile.gnat.com >you write:
  > No one said anything of the kind. What we said is that we cannot possibly
  > deal with the kind of instability that we see daily in the open gcc tree
  > as the base for the version we provide to customers.
OK.  Then do you see how to separate your needs as a company from the needs
of the GNU development community and how to resolve those differences in such
a way as to put everyone on equal footing in regards to GNU Ada?  I don't
think so, partly due to this lengthy discussion and partly because you've
never really tried to play this game in the past.

  > And I must say I
  > am equally dumbfounded by the claim that Cygnus has always provided to
  > its customers the current open tree, that's certainly not my understanding!
We've never done that.  Sorry if you got that impression.

We always have a certain amount of ongoing development that we provide to
our customers, then make available to the net.

  > Noone is saying that the internal ACT build is "the official FSF GNU Ada",
  > it is simply what we provide for our customers. Indeed one important
  > service we provide our customers is precisely a guarantee that they
  > get a very carefully quality assured version of the compiler, even if
  > they are getting a daily wavefront build.
Then can you see that if the ACT tree isn't the official GNU Ada tree
that the official FSF GNU Ada has to be somewhere else?  And that somehow
you have to manage the process of dealing with changes from multiple sources?
And that the burden for managing those changes has to fall on ACT, not the
other developers?

ie, let's assume that for some reason I need to make a series of changes to
the GNU Ada sources due to changes elsewhere in the compiler.  It will be
ACT's responsibility to make sure those changes get into ACT's repository
and that ACT does not clobber those changes when ACT wants to install some
of their changes into the GNU repository?

  > Patches and major modifications to the open tree will come from whoever
  > develops such changes. For the immediate future, most such changes will
  > clearly come from ACT, if and when others contribute, changes will
  > come from them.
Right.  Good.  I think we're agreed on this, but then again, I don't think
we ever disagreed about this.

Where I think we disagree is on the topic of how changes get into the
official GNU tree and how we're going to ensure that all developers are
on equal footing.

  > Yes, certainly there may be cases where significant new developments
  > are done in increments that make sense (the sudden appearence of the
  > ia32 port was after all a spectacular case of that happening for gcc,
  > I would certainly hope that we would have *nothing* like that happeniung
  > in the GNAT case, it seems VERY unfortunate to me to get major out-of-the-
  > blue changes of this kind, and I think that should be avoided in future.
What makes you think the ia32 port came out of the blue?  Oh yea, you haven't
been active in gcc discussions until the last month or so.  You have to rely
on what others told you.  Why don't you go back and see the archives of the
development list where you'll find significant discussions about the new
backend and collaborative work from various sources before it was installed
to the head of the GCC tree.


jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<The GDB 5 changes were basically the last gasp of the old way of
working on GDB.  Since we didn't think anybody else cared what we
did with GDB internals, the reasoning went that there wasn't much
point in posting a lot of information externally, since the developers
involved were on Cygnus' internal mailing lists, and the discussion
happened there.  In retrospect, it meant that we missed out on input
from other people who've since become valuable contributors to the
open process, so I wouldn't recommend to anybody that they go the
closed way again, at least for general architectural improvements.
>>

At least one large company had access to the GDB 5 development very
early on, long before it was made available to others, that's how I
know about it :-)

<<Now having worked large projects both ways, I must say that I can't see
any technical advantages to closed development.  Closed development
should be a disfavored option, only taken in exchange for an explicit
payoff such as funding for a specific improvement or extension.
>>

For us the issue is quality control and stability, rather than any
funding issues. I think for example that it is likely that it will
still make sense for ACT to build and maintain public binary releases
that are carefully coordinated with the well tested commercial releases
(currently our policy is to always make public binary releases on the
same source bases as the commercial releases). Yes, with the open tree,
people will be able to build intermediate binary versions, and for
experimentation and development purposes that makes sense, but not
for development use. Remember for example, that students using Ada 95
on a PC typically use a binary release of GNAT, something that is
definitely NOT true of beginning classes using C++ on a PC by
comparison, so there are definitely different requirements.

Re: Why not gnat Ada in gcc?

[Stan Shebs]

Robert Dewar wrote:
> 
> At least one large company had access to the GDB 5 development very
> early on, long before it was made available to others, that's how I
> know about it :-)

I'm not quite sure who you're referring to here... We certainly
talked about GDB 5 development ideas to quite a few companies, in
an effort to secure funding for it; I first proposed some of the
ideas in 1995, but the work didn't start until 1998 or so, when
we deliberately carved out some internal funding instead of waiting
forever.  Even after we started, we were still waving around early
versions to possible funders, but the time period for that would have
been short, since the big announcement of the work happened in May 1999.

So the better way to characterize it would be that while we were sure
that prospective customers would be interested, we didn't think that
the net community had anything to add, and so we didn't say
anything publicly.  That was a mistake though.

Stan

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<The development of the ia64 port (IMHO) was severely limited by the NDAs
that were forced on the developers by Intel and others.
>>

NDA's should not be permitted in this environment

<<Yes.  But gdb5 was a lot more open than anything related to Ada has
ever been and GDB development continues to become more open.
>>

Actually I don't think this is true, the period between some of the
developments and them seeing the light of day for gdb5 was comparably
long or longer than the period between GNAT releases.

We actually have no objection to more frequent GNAT releases, the reason
this is not done now is simply that it is a lot of effort. We are assuming
that once there is an open tree, it will be easier for us to provide more
frequent patches, fixes and developments, and easier for others to take
advantage of them.

In particular, the open tree will of course be more source oriented, whereas
most current users of the public version of GNAT are interested in turnkey
packaged binary builds, rather than building for themselves (especially
since most of the interest is on NT, where building is especially tricky).
What would be nice is if we see people building and making binary
releases more frequently, but that's quite an effort, and I am not sure
it is something that will easily happen just through volunteer effort (the
GNAT-for-DOS effort foundered quite a bit).

Anyway, it seems to me that the right steps are to work as quickly as
possible to get the GNAT sources integrated into the gcc tree, and
then try to work towards the goal of keeping the open tree as well
syncrhonized as possible with our internal development.

We are currently working to stabilize the current set of sources to
make a new release, 3.14, and as soon as this is ready for beta release,
which should be very shortly now, we will make these sources available.
We also have to resolve some remaining issues of the integration with
GCC 2.9x, but that work is also coming along very well.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102034315.3D20E34D82@nile.gnat.com >you write:
  > <<The development of the ia64 port (IMHO) was severely limited by the NDAs
  > that were forced on the developers by Intel and others.
  > >>
  > 
  > NDA's should not be permitted in this environment
That's your opinion and it has a lot of merit.  However, as much as I'd 
prefer otherwise, customers often want to ensure that information about
their new chips and the like are not released indirectly via compiler
development before the chip itself hits the market.  It's a part of the
business and Cygnus/Red Hat deals with it as best as we can.

That means that after the NDA is lifted (and there's always clauses in our
contracts which trigger removal of the NDA) we contribute the port (or
whatever work it is).  From that time on additional development to that
code happens in an open way.

However, we also go to great lengths to deal with infrastructure issues
in a very open way by describing issues in generic terms that do not 
violate NDAs and trying to get them resolved openly.  By the time the
NDA'd work is done all that's usually left is one or more new files which
contain the NDA code.  After the NDA is lifted we then submit the formerly
NDA'd code for inclusion in to the official sources.

For radically new development that isn't NDA'd we often set up a branch
so that all developers can collaborate on development in an open way without
affecting folks that do not want to be involved until that radically new
development is approaching stability.  I think the garbage collector
development for GCC is an excellent example of this.

  > In particular, the open tree will of course be more source oriented,
Correct.

  > whereas most current users of the public version of GNAT are interested
  >  in turnkey packaged binary builds, rather than building for themselves
And that's perfectly fine.  In no way do I want to discourage you from doing
this.

In the end, what I want is for anyone who wants to work on GNU Ada to be able
to do so -- with the same rights and privileges as ACT.  I fail to see how that
can possibly happen if ACT does bulk merges from the ACT tree into the
gcc.gnu.org tree.

Or let me put it another way -- would anyone here be comfortable if Red Hat
dumped all its changes for a period of time (say a month) into the tree without
any kind of review or discussion at once as a single large patch?  I doubt
it :-)  Nor do I believe any company or individual should have that kind of
privileges in the source tree.

That doesn't mean you can't do major development -- it does mean that you have
contribute independent hunks of development separately and that the usual daily
fixes need to be submitted & committed independently in a timely fashion.

ie, blasting in a few hundred kbytes of assorted random fixes is not the
way to go, but a few hundred kbytes of a single conceptual change for a
new feature may likely be acceptable as long as you can make a case that
the change is a good one to make.

  > Anyway, it seems to me that the right steps are to work as quickly as
  > possible to get the GNAT sources integrated into the gcc tree,
Yes, absolutely.

  > then try to work towards the goal of keeping the open tree as well
  > syncrhonized as possible with our internal development.
Yup.  But that's a burden that is ACT's burden alone -- anything else puts
ACT in a privileged position.

  > We are currently working to stabilize the current set of sources to
  > make a new release, 3.14, and as soon as this is ready for beta release,
  > which should be very shortly now, we will make these sources available.
  > We also have to resolve some remaining issues of the integration with
  > GCC 2.9x, but that work is also coming along very well.
Excellent.

Again, to reemphasize, in the end what I want is everyone on a level playing
field within GCC development and I fail to see how than can happen if ACT
is doing bulk merges from the ACT repository into the gcc.gnu.org repository.

jeff

Re: Why not gnat Ada in gcc?

[Mike Stump]

> Date: Wed, 1 Nov 00 21:13:30 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: rth@cygnus.com

>     The argument really should be going the other direction.  What
>     reason is so important that you *not* do development in the open?

> The issue is the technical one of how to handle merges.

My recommendation, finish off any internal work, stable and test your
tree, label the bits in your tree (call this A), get those Ada bits
into the FSF tree, get it to build, get it to test as well or near as
well as before, update and repeat and then get those bits checked in
at the FSF (call this B).  That is stage one.

After that is done, I'd recommend an import of all the FSF code into
your tree, preferably the same one as you checked in.

Now, the two trees are at parity.

Next, maintenance.

As work is done at the FSF you want, come up with B' to merge in, do
diffs between B and B', merge them in using patch, update B to be B'.
This is a logical unit and is separate from other work.  The update
interval is set by your for your business needs.  At Cygnus, g++ ran
around once a week, for the rest of the compiler, round once a month
(if I recall right).

As work is done in your tree, and as you want to expose the FSF tree
to that work, you come up with A' (for example, right after a heavy
round of successful testing), and then run the diffs between A and A',
and check that into the FSF, and update A to be A'.  This update
interval can be set by what you have time to offer, if the FSF is
breathing hard for some particular work you've done, and so on.

Notice, I never once said where you `put' work when you develop
patches.  You can put them into the FSF tree, you can put them into
your internal tree.  You can decide on a per patch basis, you can
change your mind.  A master tree is a loose concept.  To me, it is the
one that has the fine grained cvs log messages approching one entry
per changelog entry.  Also, this technique scales well.  It can handle
being done once a minute (if you like fine grained updating), down to
once a year or two, if you don't mind the pain that causes.  I've used
this method in production environments, at both ends of the spectrum.

You alreay do exactly one half of this for the gcc backend already, so
you should be familiar with it.  The one trick is to apply the same
process for the other half.

I find that real live trees for A and B and A' and B' are best,
easiest.  One can then drop in local code into in A and the local
tree, and it will forever stay local.  For any other code, it will
propagate automatically.  Works great if you have unrestricted write
access to the parts so merged.  For me, it was the C++ frontend, and I
had that.

Anyway, I don't know what other issues other than just having a few
minutes to do the work remain.  If you don't see how something might
work, or see problems in what I suggest, let me know, I'd be happy to
to some mental work to get this thing off the ground.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<I disagree again.  If you look at the major restructuring changes that have
happened with GCC over the 3 years since its development was opened up, you'll
find that the community was able to deal with rapid development and daily
instability.  Examples would be moving to garbage collection technology in
the compiler, a completely revamped reload pass, massive C++ improvements,
a much more aggressive internal consistency checking system in the compiler,
implementing a real CFG and using it in the optimizers, etc etc.
>>

Yes, but of course you cannot deal with daily instability for actual
commercial development for large scale customers who depend on absolute
stability.

Our internal development tree always maintains close to absolute stability
(we do not permit even the most minor change to be made without FIRST
running our entire regression suite, and no change can be made if it
causes any regressions at all). Then we run all versions on all targets
every night to absolutely ensure that no regressions have occurred.
This testing depends of course on large volumes of proprietary code
as well as proprietary test suites. We do also use the open ACATS
suite, but that's only a small part of the testing.

I don't think that kind of very controlled development is appropriate
to the open tree, as you say, in this environment people can indeed deal
with daily instability.

It is interesting to note the fuss about Redhat distributing a non-official
release of GCC, where poeple worried about instability. In our internal
environment we distribute daily builds to customers to fix bugs as needed,
because we know that they are completely solid. I don't think anyone
would suggest that daily builds from the open gcc tree could be immediately
be integrated into production environments.

The task is to try to coordinate the stable customer-oriented, extensively
tested internal development with more open development. We will have to
find our way to the best way of doing this. I must say that if the GNAT
front end showed the same kinds of daily instability we see in the open
GCC backend, that will make things much harder, but I think that is
relatively unlikely, simply because I don't see that many people making
changes to the hard parts of the front end. 

Incidentally, one thing that I do NOT think is addressed well enough in
the GCC development process is performance issues. As far as I can tell
there is very little systematic performance testing, and we are somewhat
dismayed to find a significant decrease in not only compile time 
performance, but also runtime performance of GCC 2.9x compared to
GCC 2.8.1. We hope this can be resolved, but right now, this will
make it more difficult to complete the switchover for GNAT, since
certainly our serious customers cannot tolerate even a 5-10% performance
degradation in some cases ... definitely something to worry about.

I am surprised this is not more of a problem for others...

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102033112.E5A9334DAF@nile.gnat.com >you write:
  > Yes, but of course you cannot deal with daily instability for actual
  > commercial development for large scale customers who depend on absolute
  > stability.
Yes you can.  Cygnus did it for 10 years.

I can't believe you're using this as an argument that the official sources
for GNU Ada will be in the ACT repository, not gcc.gnu.org and that merges
should happen from the ACT tree into the gcc.gnu.org tree.  I'm dumbfounded.


  > Our internal development tree always maintains close to absolute stability
  > (we do not permit even the most minor change to be made without FIRST
  > running our entire regression suite, and no change can be made if it
  > causes any regressions at all). Then we run all versions on all targets
  > every night to absolutely ensure that no regressions have occurred.
  > This testing depends of course on large volumes of proprietary code
  > as well as proprietary test suites. We do also use the open ACATS
  > suite, but that's only a small part of the testing.
And that's precisely the procedure you would use if you did a merge from
the external (potentially unstable) tree into your internal tree.  Those
tests will likely find problems, you would fix them and submit the fixes
to the net sources.

That is *precisely* how Cygnus managed to deal with this issue for the last
10 years and how Red Hat will continue to do so in the future.

  > I don't think that kind of very controlled development is appropriate
  > to the open tree, as you say, in this environment people can indeed deal
  > with daily instability.
Right.  THe problem is strictly your problem as a business, it is not a
problem for the GNU project.  Thus, you should confine that problem to your
own internal sources and not force it on the official GNU sources.

  > Incidentally, one thing that I do NOT think is addressed well enough in
  > the GCC development process is performance issues.
I agree, and it is a problem.

jeff

Re: Why not gnat Ada in gcc?

[Stan Shebs]

Robert Dewar wrote:
> 
> Incidentally, one thing that I do NOT think is addressed well enough in
> the GCC development process is performance issues. [...]
> 
> I am surprised this is not more of a problem for others...

Ho ho, it's a big problem at Apple.  Almost every day I get to hear
from users about how GCC sucks because it's 10-20x (thats x, not %)
slower than Metrowerks compiling the same code on the same machine.

Stan

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102033112.E5A9334DAF@nile.gnat.com >you write:
  > Yes, but of course you cannot deal with daily instability for actual
  > commercial development for large scale customers who depend on absolute
  > stability.
Correct.  But these issues can (and should) be handled internally within
ACT, Red Hat and whomever else is trying to build commercial products based
on GCC.

This was one of the major problems with GCC2 development if you recall --
the stability needs of a particular company basically brought new development
to a standstill.

  > Our internal development tree always maintains close to absolute stability
  > (we do not permit even the most minor change to be made without FIRST
  > running our entire regression suite, and no change can be made if it
  > causes any regressions at all). Then we run all versions on all targets
  > every night to absolutely ensure that no regressions have occurred.
  > This testing depends of course on large volumes of proprietary code
  > as well as proprietary test suites. We do also use the open ACATS
  > suite, but that's only a small part of the testing.
Fine.  But that doesn't (and shouldn't) have *ANY* affect on the external
tree.

  > I don't think that kind of very controlled development is appropriate
  > to the open tree, as you say, in this environment people can indeed deal
  > with daily instability.
Right.  That's why when you import code from the open tree you have to
beat it into an acceptable state.  That's part of playing the open source
development game.


  > It is interesting to note the fuss about Redhat distributing a non-official
  > release of GCC, where poeple worried about instability.
Particularly when they aren't aware of how much that code was tested, debugged
and fixed.

  > In our internal
  > environment we distribute daily builds to customers to fix bugs as needed,
  > because we know that they are completely solid. I don't think anyone
  > would suggest that daily builds from the open gcc tree could be immediately
  > be integrated into production environments.
Nope.  I would never suggest that.  That's why Red Hat has a process for
importing code from the external tree and beating it into shape before it
gets exposed to customers.

jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<No, we actually work very closely with this group, and they have direct
access to anything they want, the reason being to expedite the release of
the RPM's for a new GNAT release. Like any group of volunteers, the time
they can spend on this goes up and down, it is not a first priority for
any of that group, quite understandably, whereas of course GNAT *is*
a first priority for the 35 or so people working at ACT and ACT/Europe.
>>

Just to be a bit clearer, what we were doing in working with the 
GNAT for GNU/Linux folks was precisely trying to give them the
same kind of environment to work with that will now be possible
for them and others with an open tree as part of the GCC sources,
and for one release it was quite successful, but people had less
time available a year later for whatever reasons.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<I disagree about the complexity keeping the number of developers small.
We have more active C++ developers now than ever, most have become active
since GCC development was opened up.  Similarly for the rest of the compiler.
>>

But the number of people making changes to the core of the front end of
g++ is quite small, indeed no larger than the group making changes to
GNAT. And that I think is quite expected.

Re: Why not gnat Ada in gcc?

[Gerald Pfeifer]

On Wed, 1 Nov 2000, Robert Dewar wrote:
> But the number of people making changes to the core of the front end of
> g++ is quite small, indeed no larger than the group making changes to
> GNAT. And that I think is quite expected.

I beg to disagree.

% grep @ $GCC/gcc/gcc/cp/ChangeLog | sed -e 's/.*<\(.*\)>/\1/g' |sort -u |wc -l
      72

With about 10 duplicate entries due to varying e-mail addresses that makes
more than 60 code contributors this year alone!


Plus, there is a significant point I'm missing in this discussion:

As soon as any change to the C++ frontend of GCC happens, everyone on
this planet (with Internet access) immediately can test that with his
projects/on his platforms.

This has proved incredibly useful in the past, and let's not forget that
the GNU project not only consists of developers, but also of users!

pfeifer@dbai.tuwien.ac.at does not appear in cp/ChangeLog, but I am
tempted to believe that I have contributed a non-negligible amount of
time and effort in performing tests, generating test cases, and filing
and following bug reports!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<And as long as you continue to keep putting ACT in a privileged position
with GNU Ada developers are extremely unlikely to emerge.
>>

Once the sources are maintained in open form, anyone will be able to make
changes, as Richard said, it will be surprising but welcome to find
others making contributions.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Is it possible that they lost interest because they don't think they're going
even playing field with ACT?
>>

No, we actually work very closely with this group, and they have direct
access to anything they want, the reason being to expedite the release of
the RPM's for a new GNAT release. Like any group of volunteers, the time
they can spend on this goes up and down, it is not a first priority for
any of that group, quite understandably, whereas of course GNAT *is*
a first priority for the 35 or so people working at ACT and ACT/Europe.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<There's always the GNAT for DOS people.
>>

Yes, and that's actually an interesting example. The original DOS port
was done by a volunteer (Doug Rupp, who now works full time for ACT).
It was quite a tricky port, but once done, the work to update it to
new versions of the GNAT sources is quite straightforward. However,
disappointingly the DOS version has not really kept up with current
development, let alone contributed development input of its own.

I think a more promising source of energy is the GNAT/GNU/Linux cooperation
which has for example generated RPM's for each new release of GNAT, and 
usually quite quickly, although the latest 3.13p release has not yet got
RPM's available.

I actually guess that the most likely source of useful contributions to 
GNAT technology will come from new tools, new libraries, and new bindings.
And these are always welcome, and pretty much independent of the continued
development of the front end.

The front ends for modern compilers are remarkably complex, so it is not
surprising that in both the case of GNAT and g++ the number of significant
contributors to the front end will remain small.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001102025839.62E9B34DAF@nile.gnat.com >you write:
 > The front ends for modern compilers are remarkably complex, so it is not
  > surprising that in both the case of GNAT and g++ the number of significant
  > contributors to the front end will remain small.
I disagree about the complexity keeping the number of developers small.
We have more active C++ developers now than ever, most have become active
since GCC development was opened up.  Similarly for the rest of the compiler.



jeff

Re: Why not gnat Ada in gcc?

[Toon Moene]

Jeffrey A Law wrote:
> 
>   In message < 20001102025839.62E9B34DAF@nile.gnat.com >you write:
>  > The front ends for modern compilers are remarkably complex, so it is not
>   > surprising that in both the case of GNAT and g++ the number of significant
>   > contributors to the front end will remain small.
> I disagree about the complexity keeping the number of developers small.
> We have more active C++ developers now than ever, most have become active
> since GCC development was opened up.  Similarly for the rest of the compiler.

I'm sorry but I have to agree with Jeff here (Well, OK, perhaps I'm not
really sorry :-)

GNU Fortran 95 is certainly a "complex frontend" but the contributions
on the sourceforge mailing list (see URL below) are lively, even though
intermittent, and the number of people contributing is steadily
climbing.

Of course, it helps that its development is completely open, not in the
least because no one has a vested interest in keeping changes "hidden".

Cheers,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

Roberty Dewar wrote:
> Yes, and that's actually an interesting example. The original DOS port
> was done by a volunteer (Doug Rupp, who now works full time for ACT).
> It was quite a tricky port, but once done, the work to update it to
> new versions of the GNAT sources is quite straightforward. However,
> disappointingly the DOS version has not really kept up with current
> development, let alone contributed development input of its own.

AFAIK, 3.13p packaged for DOS went out before the Linux version
(gnuada project on sourceforge) and is actively maintained.

On the topic of "volunteer ... who now works full time for ACT" I
think it is fair that ACT has put on its payroll a lot of the people
interested in contributing to GNAT as part of the company growth, and
that is a very good thing for the GNU project IMHO, I wouldn't dare to
say that it has sucked all the available GNU Ada workforce ;-) ;-).

> I think a more promising source of energy is the GNAT/GNU/Linux cooperation
> which has for example generated RPM's for each new release of GNAT, and 
> usually quite quickly, although the latest 3.13p release has not yet got
> RPM's available.

The Linux x86 RPMs (RH 6.x, 7.0, Mandrake 7.1, SuSE 7.0) for 3.13p are
available but have been announced only to some mailing lists to iron
out the install process on various distributions by active beta
testers, the full announcement will come soon. Note that the ALT team
provides synchronized RPMs of GNAT, ASIS, GLADE, JGNAT, Florist and
more than a dozen of other useful Ada packages, URL
< http://www.gnuada.org/alt.html >.

The debian GNU/Linux packages for 3.13p are also available from
< http://www.debian.org >.

Hopefully the ALT team will be able to leave the packaging burden to
distributors once GNAT is a first-class citizen in the GCC project.

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Richard Stallman]

    AFAIK, 3.13p packaged for DOS went out before the Linux version
    (gnuada project on sourceforge) and is actively maintained.

Would you please call it the GNU/Linux version?  Linux is the kernel;
the whole system is GNU/Linux.  This version of GNU Ada probably has
little to do with the kernel in particular, so it is a GNU/Linux
version, not a Linux version.

See http://www.gnu.org/gnu/linux-and-gnu.html for more explanation.

    The Linux x86 RPMs (RH 6.x, 7.0, Mandrake 7.1, SuSE 7.0) for 3.13p are

Please call them GNU/Linux RPMs, because once again you're referring
to the whole GNU/Linux system, not the kernel in particular.

When companies such as Red Hat, Mandrake and SuSE call our system
"Linux", the result is that we (the GNU Project) don't get credit for
the work we have done.  That reduces our ability to do further work
today (see http://www.gnu.org/gnu/why-gnu-linux.html ).  Please call
the system GNU/Linux, to help us inform the users where it really came
from.

Meanwhile, I have to wonder why running GNU Ada on a popular version
of the GNU system needs the attention of a group outside the core
developers of GNU Ada.  Supporting GNU/Linu ought to be one of the
main priorities of the core group.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    Is it possible that they lost interest because they don't think
    they're going even playing field with ACT?

No.  They weren't planning on doing GNAT development, but merely
working on integration issues.  They seemed eager to start, and were
encouraged to do so, but the level of interest seemed to be waning.  A
number of people associated with ACT Europe were also associated with
them, so they had an "inside track", but it didn't seem to help.

This is why I view with skepticism the belief that other developers will
somehow appear.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    Not really for GDB.  I can count the number of external contributors on one
    hand that existed before we made a repository available on sourceware.

Are you counting the number of people doing development work on GDB
during that period or the number of those who made attempts to merge
their changes back?  I agree the number of the latter were small, but
the number of the former was far larger (and included a lot of large
"players", such as Wind River and HP).  With Ada, there's no evidence
that there are people working on it at all at this point.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10011020241.AA06270@vlsi1.ultra.nyu.edu >you write:
  >     Not really for GDB.  I can count the number of external contributors on
  >  one
  >     hand that existed before we made a repository available on sourceware.
  > 
  > Are you counting the number of people doing development work on GDB
  > during that period or the number of those who made attempts to merge
  > their changes back?
The number of people trying to do development.

  > I agree the number of the latter were small, but
  > the number of the former was far larger (and included a lot of large
  > "players", such as Wind River and HP).
Err, no.  WRS was not active, nor was HP at the time.  HP has become somewhat
more active, but mostly working strictly on their own internal sources.  Go
to gdb-patches and see how many posts are coming out of WRS or HP.  You'll
still find depressingly few from those two companies given how many developers
they have.

  > With Ada, there's no evidence
  > that there are people working on it at all at this point.
And as long as you continue to keep putting ACT in a privileged position
with GNU Ada developers are extremely unlikely to emerge.

jeff

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    And the GNAT for Linux folks.

Who were originally supposed to assist in the work of tree merging, but
now seem to have lost interest.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10011020238.AA06237@vlsi1.ultra.nyu.edu >you write:
  >     And the GNAT for Linux folks.
  > 
  > Who were originally supposed to assist in the work of tree merging, but
  > now seem to have lost interest.
Is it possible that they lost interest because they don't think they're going
even playing field with ACT?

I can say from personal experience I lost interest in GCC development when
put in a very similar position and that when we opened up development that
I became very interested in GCC development again.

jeff

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    There's always the GNAT for DOS people.

Yes, but they are working on the library, which is why I was careful to make
the distinction I did.  Also, I don't think they are very active at the
moment anyway.

There have indeed been a number of groups that have worked on
packaging and library issues (some of the numerics library was
contributed), but so far none on the compiler itself.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    Funny, that's not unlike the argument originally made for GDB.  And
    gee whiz, the developers we never knew of did start coming out of the
    blue to do development.  Similarly with GCC when we opened up its
    development via egcs -- lots of folks started contibuting that had
    never contributed before.

Yes, but in both cases there were *some* contributors before.  Look, I wish
you're right, that somehow because the sources will be just a little more
available (remember: they've been available for over six years) that folks
will magically appear who want to work on them.  I'm just not that optimistic.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10011020224.AA06122@vlsi1.ultra.nyu.edu >you write:
  >     Funny, that's not unlike the argument originally made for GDB.  And
  >     gee whiz, the developers we never knew of did start coming out of the
  >     blue to do development.  Similarly with GCC when we opened up its
  >     development via egcs -- lots of folks started contibuting that had
  >     never contributed before.
  > 
  > Yes, but in both cases there were *some* contributors before. 
Not really for GDB.  I can count the number of external contributors on one
hand that existed before we made a repository available on sourceware.

jeff

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    The argument really should be going the other direction.  What
    reason is so important that you *not* do development in the open?

Nobody is arguing against doing development in the open.  The issue is
the technical one of how to handle merges.  If there were to be a lot
of external developers the easiest way to do it is different than if
there weren't.  The point that Laurent Guerby originally made (and
which I support) is that it's wasteful to make that decision until we
see whether there actually *are* such developers, especially when
there's significant evidence (the past six years) that there aren't.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

In message < 10011020213.AA06066@vlsi1.ultra.nyu.edu >you write:
  > Nobody is arguing against doing development in the open.  The issue is
  > the technical one of how to handle merges.  If there were to be a lot
  > of external developers the easiest way to do it is different than if
  > there weren't.  The point that Laurent Guerby originally made (and
  > which I support) is that it's wasteful to make that decision until we
  > see whether there actually *are* such developers, especially when
  > there's significant evidence (the past six years) that there aren't.
Funny, that's not unlike the argument originally made for GDB.  And gee
whiz, the developers we never knew of did start coming out of the blue to
do development.  Similarly with GCC when we opened up its development via
egcs -- lots of folks started contibuting that had never contributed before.



jeff

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    With GCC the policy was the external tree was the master and Cygnus
    did merges from the external tree to its internal tree.  If folks made
    changes to the internal tree, they were responsible for either getting
    them into a state suitable for the external tree, or maintaining them
    for internal use.

    That strongly encouraged development to happen in a more open way on
    the external tree with input from external contributors.  It also
    leveled the playing field a lot for external contributors.

I agree with your comments, but the question remains for GNAT (at
least in the case of the compiler itself), whether there *are* any
"external contributors".  The sources of GNAT have been available
(albeit not in a CVS tree) for over six years and I can't think of
*one* external contribution to the compiler itself.  Perhaps Robert
may know of one. 

I don't see a point in investing effort up front to establish
procedures to deal with lots of external developers until we actually
see evidence that there *will be* any.

    I disagree.  For the playing field to be level for all GNU Ada
    developers, the tree on gcc.gnu.org has to be the master with no bulk
    merges -- or all GNU Ada developers have to have the ability to do
    bulk merges.

Yes, but again, this is only relevent if there *are* a set of "GNU Ada
developers".  I don't see any evidence of such a group at this point.
Sure, when the sources are in the GCC tree, it will encourage such,
but I don't expect that to make any difference whatsoever.

Are you aware of any GNU Ada developers "in the wings" out there?

Re: Why not gnat Ada in gcc?

[Richard Henderson]

On Wed, Nov 01, 2000 at 08:39:38PM -0500, Richard Kenner wrote:
> Are you aware of any GNU Ada developers "in the wings" out there?

The argument really should be going the other direction.  What
reason is so important that you *not* do development in the open?

You're working on free software for the fsf, therefore IMO you ought
to be doing your development in the open if at all possible.  And
clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
not only possible, but not particularly difficult.


r~

Re: Why not gnat Ada in gcc?

[David Starner]

On Wed, Nov 01, 2000 at 08:54:07PM -0500, Richard Kenner wrote:
> Yes, but again, this is only relevent if there *are* a set of "GNU Ada
> developers".  I don't see any evidence of such a group at this point.
> Sure, when the sources are in the GCC tree, it will encourage such,
> but I don't expect that to make any difference whatsoever.
> 
> Are you aware of any GNU Ada developers "in the wings" out there?

There's always the GNAT for DOS people.

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001101200846.A28532@x8b4e516e.dhcp.okstate.edu >you write:
  > On Wed, Nov 01, 2000 at 08:54:07PM -0500, Richard Kenner wrote:
  > > Yes, but again, this is only relevent if there *are* a set of "GNU Ada
  > > developers".  I don't see any evidence of such a group at this point.
  > > Sure, when the sources are in the GCC tree, it will encourage such,
  > > but I don't expect that to make any difference whatsoever.
  > > 
  > > Are you aware of any GNU Ada developers "in the wings" out there?
  > 
  > There's always the GNAT for DOS people.
And the GNAT for Linux folks.
jeff

Re: Why not gnat Ada in gcc?

[Richard Stallman]

    And the GNAT for Linux folks.

What an ironic name for a project.  When they say "Linux", they must
really mean the GNU/Linux system.  But GNAT itself is supposed to
exist *for* the GNU system (which includes GNU/Linux).

So if there is a need for an outside project to work on GNAT to get it
to work well in GNU/Linux, does that mean the standard GNAT is not
paying enough attention to the system it is part of?

Re: Why not gnat Ada in gcc?

[Florian Weimer]

Richard Stallman <rms@gnu.org> writes:

>     And the GNAT for Linux folks.
> 
> What an ironic name for a project.  When they say "Linux", they must
> really mean the GNU/Linux system.  But GNAT itself is supposed to
> exist *for* the GNU system (which includes GNU/Linux).

Actually, it's more or less a "GNAT for Red Hat and SuSE Linux"
project.  As far as I can tell, only RPMs tested with those systems
are distributed.  The GNAT packages for Debian GNU/Linux are
maintained in an entirely separate manner.

> So if there is a need for an outside project to work on GNAT to get it
> to work well in GNU/Linux, does that mean the standard GNAT is not
> paying enough attention to the system it is part of?

Currently available versions of GNAT are based on gcc 2.8.1.  Most
distributions of the GNU/Linux system have now moved to GCC 2.95.x or
later, and especially the C++ front end is essential for building more
recent programs.  As a result, the "gcc" driver program for the GNAT
compiler is named "gnatgcc", to avoid conflicts.  GNAT tools such as
"gnatmake" have been adjusted to this.  (The ACT distribution doesn't
do this, "gcc" is called "gcc" there.)  The RPM distribution provides
an additional directory which is searched for Ada source packages (it
is intended to make this directory part of the Filesystem Hierarchy
Standard, I think).  In addition, both the Debian and RPM distribution
use shared libraries for GNARL (the GNU Ada Runtime Library) and
default to native (kernel) threads.  In contrast, the ACT distribution
is quite conservative about shared libraries (I don't know if they are
supported in the precompiled version, support for building them was
added in the source distribution, however), and the ACT binary
distribution uses FSU Threads (userspace implementation of kernel
threads) in order to be able to meet the requirements of the Ada
Reference Manual.  As a result of all this, unfortunately,
applications linked against a shared GNARL library were not binary
compatible across different distributions of the GNAT compiler until
recently (I don't know if this has changed).

The integration of GNAT into the official GCC will hopefully resolve
this issues.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Why not gnat Ada in gcc?

[Richard Stallman]

      In addition, both the Debian and RPM distribution
    use shared libraries for GNARL (the GNU Ada Runtime Library) and
    default to native (kernel) threads.  In contrast, the ACT distribution
    is quite conservative about shared libraries

If anything can be done in the GNAT sources to support shared
libraries better on GNU/Linux, I hope the GNAT developers will give it
high priority.  Every GNU package should support GNU/Linux well.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

By the way, one thing I should say here is that I wear two hats, one
as president of ACT, and the other as the maintainer of GNAT for the GNU
project. 

Let me talk with the second hat on :-)

The whole point of the discussion here is to make a step forward in
getting the GNAT sources properly integrated into the gcc tree. There
are many advantages on all sides in this, which is why 

Switch to other hat

Ada Core Technologies will be happy to contribute the sources to the
gcc tree and help to maintain this tree

switching back to the GNU hat

And I will be trying to make sure that this is done in a manner that
is most effective for the GNU project, balancing the many factors
involved.

Robert Dewar

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<Creating JGNAT once (or every few years) should be sufficient.
>>

All we ever test is building version N using version N-1 as the base.
It is not that it would necessarily not work to use an earlier version,
but for sure it has not been tested.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

<<Configure GNAT to produce java byte code and let it compile itself:
JGNAT.

This (and any binary produced by JGNAT) can be executed in a JVM or
directly on the host using GCC´s java front end:
>>

This might work with a lot of fiddling, certainly no one has tried it,
but more straightforward is to pick up an initial binary from cs.nyu.edu
(or some mirror site), and then bootstrap, or do a cross compile, 
depending on the environnment.

It is interesting that initially we were worried about the issue of
GNAT needing GNAT to compile, but in fact the impressive capabilities
for building cross compilers in gcc has meant that it is in practice
very easy for us and for others to move gcc to other machines (quite
a few ports were done by volunteers with no help from us, including
Mac, DOS, Amiga, NetBSD, FreeBSD, and others).

Robert Dewar

Re: Why not gnat Ada in gcc?

[Corey Minyard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

dewar@gnat.com (Robert Dewar) writes:

> <<Configure GNAT to produce java byte code and let it compile itself:
> JGNAT.
> 
> This (and any binary produced by JGNAT) can be executed in a JVM or
> directly on the host using GCC´s java front end:
> >>
> 
> This might work with a lot of fiddling, certainly no one has tried it,
> but more straightforward is to pick up an initial binary from cs.nyu.edu
> (or some mirror site), and then bootstrap, or do a cross compile, 
> depending on the environnment.
> 
> It is interesting that initially we were worried about the issue of
> GNAT needing GNAT to compile, but in fact the impressive capabilities
> for building cross compilers in gcc has meant that it is in practice
> very easy for us and for others to move gcc to other machines (quite
> a few ports were done by volunteers with no help from us, including
> Mac, DOS, Amiga, NetBSD, FreeBSD, and others).
> 

Indeed this is true.  I did a cross-compile from Linux x86 to LinuxPPC
a few years back.  It was a small pain, but it really wasn't that bad
and it only has to be done once.  Unfortunately, current LinuxPPC is
unable to use the older compilers that GNAT is currently supported on,
so I no longer have a working compiler on my machine.  So another
cross-compile will be required.  But I'm willing to do it when the
time comes.

Corey

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    The way to manage this is to test the hell out of the tree when you
    bring in changes from the net *before* you check those changes into
    your internal repositories.  

All I was doing was explaining to those who don't already know why there
*have* to be internal respositories.  There was a suggestion that ACT should
use the public tree for its internal development purposes and I was pointing
out why that can't work.

    Please keep in mind that those issues are ACT's problems and should not be
    a consideration for how to manage the GNU Ada repository.

Of course.  Again, I was just explaining why any commercial company will need
their own internal tree and why merges are needed.  This is obvious to you,
but not to others.

    Any bulk merges need to be from the net sources to your internal
    sources.  Any other method would put ACT into a privileged position in
    regards to installing changes into GNU Ada.

I think the method of merges that will end up being the most appropriate will
strongly depend on the extent of changes being made in the net sources.  As I
say, a major difference between the Ada front end and that others is that
it's *far* less likely there will any other people who will end up making
changes.

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

Jeff wrote:
> From my experience it's a lot easier to deal with the merge policy
> at the same time you move the bits into the tree since it has major
> impacts on the development policy.

I for sure do not have your experience on this subject, but from what
I know about the Ada community right now, this is a non issue for at
least one year (major changes being made).

May be you have this opinion because you managed "high pressure" or
multi-contributors projects to go in public CVS for which I agree that
policy must be set strictly otherwise chaos will occur much to the
detriment of the GNU community.

> [...] Please keep in mind that those issues are ACT's problems and
> should not be a consideration for how to manage the GNU Ada
> repository. [...]  Any bulk merges need to be from the net sources
> to your internal sources.  Any other method would put ACT into a
> privileged position in regards to installing changes into GNU Ada.

In the long run and if other GNU Ada companies do emerge, yes I agree
that what you say is true. I assume such companies or individuals will
contact this list when appropriate, and that a fair policy will be set
up and inforced by the GCC steering committe in answer to such
requests.

In the short term I do think that arguing the merge policy is just
delaying the inclusion of the Ada front-end in the GCC CVS repository
(which is major work contributed/being contributed by ACT), and is of
no (or negative) benefit to the GNU (Ada & other) community.

Richard Kenner wrote: 
> I think the method of merges that will end up being the most
> appropriate will strongly depend on the extent of changes being made
> in the net sources.

Agreed. 

And if one big change from the net becomes a nightmare to merge for
ACT (problem of scope, not of quality of course) because of
significant changes made internally by ACT and not made available
publically, I assume the right thing will happen.  

It's even better actually if some collaboration takes place before
such change begin to be developped at first and I hope the scenario I
described won't happen (good candidate for README material anyway).

> As I say, a major difference between the Ada front end and that
> others is that it's *far* less likely there will any other people
> who will end up making changes.

I disagree, but it's not significant to the problem at hand.  Let's be
historians in a few years, and not speculators right now ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message <200010141017.MAA01686@ulmo>you write:
  > Jeff wrote:
  > > From my experience it's a lot easier to deal with the merge policy
  > > at the same time you move the bits into the tree since it has major
  > > impacts on the development policy.
  > 
  > I for sure do not have your experience on this subject, but from what
  > I know about the Ada community right now, this is a non issue for at
  > least one year (major changes being made).
  > 
  > May be you have this opinion because you managed "high pressure" or
  > multi-contributors projects to go in public CVS for which I agree that
  > policy must be set strictly otherwise chaos will occur much to the
  > detriment of the GNU community.
It was mostly from watching how development actually worked in both merge
scenarios.

With GCC the policy was the external tree was the master and Cygnus did
merges from the external tree to its internal tree.  If folks made changes
to the internal tree, they were responsible for either getting them
into a state suitable for the external tree, or maintaining them for
internal use (with markers to point out local changes).  Any difference
between the internal & external trees had to have a marker in the
internal tree or the change was removed when we did merges.

That strongly encouraged development to happen in a more open way on the
external tree with input from external contributors.  It also leveled the
playing field a lot for external contributors.


GDB started out the opposite way -- the internal Cygnus tree was the master
and a "sanitization" process would remove local code to produce a "clean"
tree which would then be used to merge into the external tree.

That process did nothing to encourage open development and it was eventually
changed to work like GCC.  This was somewhat painful for everyone (internally
and externally).


  > Richard Kenner wrote: 
  > > I think the method of merges that will end up being the most
  > > appropriate will strongly depend on the extent of changes being made
  > > in the net sources.
  > 
  > Agreed. 
I disagree.  For the playing field to be level for all GNU Ada developers,
the tree on gcc.gnu.org has to be the master with no bulk merges -- or
all GNU Ada developers have to have the ability to do bulk merges.

Bulk merges are inherently bad for development -- that badness shouldn't
be imposed on the official GNU sources.

jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

Just so people know, I am definitely watching this entire interchange,
so if I do not reply to any particular message, it is because I think
nothing will be gained by doing so!

Robert Dewar
Ada Core Technologies

Re: Why not gnat Ada in gcc?

[Mike Stump]

[ be sure to read to the end for a 10 Mbps dedicated colo offer ]

> Date: Thu, 12 Oct 2000 16:40:49 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> To: law@cygnus.com
> CC: guerby@acm.org, dewar@gnat.com, gcc@gcc.gnu.org

> But it is unreasonable to ask ACT to put its repository onto a machine
> run by Cygnus, and associated by the public with Cygnus.

I'd be more curious if ACT has a problem with this.

> That is nice, but the problems we should solve by moving the
> repository are not a matter of to network bandwidth.  Increasing
> bandwidth to the repository, while not a bad thing, won't help the
> GNU Project in any of the larger ways.

I think the issue of control can be mitigated by ensuring there is
enough non-redhat people in the decision making process.  I think what
was done with the steering committee is a fine example of how to do it
correctly.  I'd leave the decision about who runs/owns and where the
machine is to be determined by the steering committee with input from
all.  I think we can trust them to make the right decision.  I think
who makes sure it it powered isn't all that important (as long as it
is powered).  The factors I consider important are, who can decide
what is on our web page, who can decide who can have write access into
the cvs repository, who sets policy as to what mailing list software
we run, who decides list policies, who decides what name the web
server will have, who determins what advertising the site can have,
who determines who can mirror, who determines who can have accounts
and so on.  As long as that appears to be fair, I think we are in a
pretty good position.

A few years ago, before having history with the currect site, I
worried about the server.  I wanted to make use of gcc in a critical
way at my new company, and to do this, I needed slightly more
guarantees about the cvs respository than I had.  I solved the problem
by asking for an account on the cvs machine and mirroring the whole
cvs repository.  That was the main thing I had to have a hard
guarantee about, and by mirroring it, I had what I needed.


To throw in addition possibilities into the mix, I can offer a
dedicated 10 Mbps connection that is of `excellent quality'.  The site
has a 622 connection to the Internet currently, so we aren't talking
about an overloaded connection.  Think, the type of quality you would
need to run the busiest root name server on the Internet, in fact,
that is where I am thinking.  The only problem with this, it would be
in RedWood city, and touching the machine, should it be necessary
would be harder than it is now.  If we want more network bandwidth,
that is an excellent way to go.  To see the new digs, run a traceroute
to f.root-servers.net, www.xfree86.org or www.netbsd.org.  The last
two took up a similar offer of connectivity.  We could talk with them
to find out their actual experience and issues, if we wanted to.

A couple of beefy traceroutes from my site:

bash$ t -q 200 -Q www.netbsd.org
traceroute to nbwww.isc.org (204.152.186.171), 30 hops max, 40 byte packets
 1  cr1-hfc4.cstvl1.sfba.home.net (24.1.125.1)  (17.3 ms/21.7 ms(+-1.7 ms)/141.2 ms) 200/200 (0.00%)
 2  r1-ge1-0-1000bt.frmt1.sfba.home.net (24.1.80.1)  (6.1 ms/14.7 ms(+-1.1 ms)/34.4 ms) 200/200 (0.00%)
 3  10.0.255.109 (10.0.255.109)  (6.2 ms/13.6 ms(+-1.0 ms)/31.8 ms) 200/200 (0.00%)
 4  c1-pos6-1.snjsca1.home.net (24.7.74.61)  (7.8 ms/13.8 ms(+-1.0 ms)/32.0 ms) 200/200 (0.00%)
 5  bb2-pos1-0.paix.nap.home.net (24.7.74.170)  (7.2 ms/13.2 ms(+-1.0 ms)/33.4 ms) 200/200 (0.00%)
 6  paix2a.head2.pla.mibh.net (198.32.175.4)  (6.7 ms/15.5 ms(+-1.2 ms)/52.2 ms) 200/200 (0.00%)
 7  pla1b.head4.pla.mibh.net (204.152.184.214)  (8.0 ms/14.1 ms(+-1.0 ms)/42.9 ms) 200/200 (0.00%)
 8  head1.rwc.mibh.net (128.177.255.7)  (8.4 ms/14.8 ms(+-1.1 ms)/38.5 ms) 200/200 (0.00%)
 9  nbwww.isc.org (204.152.186.171)  (7.9 ms/16.6 ms(+-1.3 ms)/61.0 ms) 200/200 (0.00%)

bash$ t -q 200 -Q gcc.gnu.org
traceroute to gcc.gnu.org (205.180.83.71), 30 hops max, 40 byte packets
 1  cr1-hfc4.cstvl1.sfba.home.net (24.1.125.1)  (11.1 ms/24.7 ms(+-1.9 ms)/65.3 ms) 200/200 (0.00%)
 2  r1-ge1-0-1000bt.frmt1.sfba.home.net (24.1.80.1)  (9.0 ms/18.6 ms(+-1.4 ms)/44.3 ms) 200/200 (0.00%)
 3  10.0.255.109 (10.0.255.109)  (7.1 ms/18.8 ms(+-1.5 ms)/63.0 ms) 200/200 (0.00%)
 4  c1-pos6-1.snjsca1.home.net (24.7.74.61)  (7.4 ms/20.8 ms(+-1.6 ms)/61.6 ms) 200/200 (0.00%)
 5  24.7.70.138 (24.7.70.138)  (6.9 ms/15.5 ms(+-1.2 ms)/61.5 ms) 200/200 (0.00%)
 6  p6-0.paloalto-nbr1.bbnplanet.net (4.0.6.97)  (8.5 ms/15.0 ms(+-1.1 ms)/44.0 ms) 200/200 (0.00%)
 7  p1-0.paloalto-cr1.bbnplanet.net (4.0.6.74)  (7.7 ms/14.9 ms(+-1.1 ms)/48.4 ms) 200/200 (0.00%)
 8  p1-0-0.paloalto-cr13.bbnplanet.net (4.0.2.222)  (7.9 ms/14.9 ms(+-1.1 ms)/40.7 ms) 200/200 (0.00%)
 9  s0.cygnus3.bbnplanet.net (4.1.120.86)  (102.8 ms/234.6 ms(+-16.9 ms)/346.8 ms) 200/200 (0.00%)
10  sourceware.cygnus.com (205.180.83.71)  (52.5 ms/220.9 ms(+-18.4 ms)/555.7 ms) 156/200 (22.00%)

The latency for me is 13x better on average, and 9x better worst case,
6x better best case.  During the day, the numbers will be even better.
During a cygwin release, the numbers improve yet some more.

Re: Why not gnat Ada in gcc?

[David O'Brien]

On Thu, Oct 12, 2000 at 11:52:11PM -0700, Mike Stump wrote:
> A few years ago, before having history with the currect site, I
> worried about the server.  I wanted to make use of gcc in a critical
> way at my new company, and to do this, I needed slightly more
> guarantees about the cvs respository than I had.  I solved the problem
> by asking for an account on the cvs machine and mirroring the whole
> cvs repository.  That was the main thing I had to have a hard
> guarantee about, and by mirroring it, I had what I needed.

I am working with Jeff Law to setup a public CVSup mirror of the CVS
repository.  This will make it easy for many to mirror it (and use it on
laptops while traveling).

Once the CVS repo is available outside of sourceware.cygnus.com, I'll
probably also mirror it at ftp://ftp.freesoftware.com:/pub/sourceware/

-- 
-- David    (obrien@FreeBSD.org)

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    > Ada is a very complex language and one which is understood to that
    > extent by very few people and those few people nearly all work for Ada
    > compiler vendors.  So I don't accept that putting GNAT sources in the
    > repository will magically make such expertese appear.
    
    I don't agree with this.  After programming for 10 years in C, and
    learning both Ada and C++, I found Ada easy to learn and not very
    complex.  Certainly much less complex than C++.  Don't re-enforce the
    FUD.

I'm talking about the complexity of a *compiler* for the language, not the
difficulty in programming in it: these are very different things and require
a different level of knowlege.  Ada is at least as complex as C++, mostly
because some things that are left undefined in C++ are defined in Ada.

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<I don't agree with this.  After programming for 10 years in C, and
learning both Ada and C++, I found Ada easy to learn and not very
complex.  Certainly much less complex than C++.  Don't re-enforce the
FUD.
>>

YOu missed the point entirely, Richard was saying that the language is
very complex to implement, not to use!

Indeed, it is fair to compare it to C++ in this respect (I do not think
it is right to say that it is less complex than C++ from an implementation
point of view, I would say it is comparable in terms of the front end,
comparable in terms of the back end, and Ada is far more complex to
implement at runtime, especially if you include all the annexes.

Note that in practice there is not a huge number of people who make
subtle changes to the g++ front end.

Our experience is that we have had quite a few contributions over the
years from third parties, almost all in the tools and runtime, almost
none in the front end, and none at all in the complex parts of the
front end.

Re: Why not gnat Ada in gcc?

[Richard Kenner]

      > But I don't think we're here yet or anytime in less than a year, so I
      > don't think it is useful to argue on the source merging process right
      > now.

    I would claim the opposite.  We need this to happen sooner, not later.
    The longer we wait, the more difficult our work becomes and the longer
    we have to deal with the problem of developers making changes, but 
    being unable to test that they haven't broken Ada.

Sorry, I don't follow.  You comment certainly argues in favor of putting into
the tree soon, which everybody already agrees on, but how does it argue in
favor of deciding on a merge policy soon, which is what Laurent was talking
about?

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10010121139.AA01770@vlsi1.ultra.nyu.edu >you write:
  >       > But I don't think we're here yet or anytime in less than a year, so
  >  I
  >       > don't think it is useful to argue on the source merging process rig
  > ht
  >       > now.
  > 
  >     I would claim the opposite.  We need this to happen sooner, not later.
  >     The longer we wait, the more difficult our work becomes and the longer
  >     we have to deal with the problem of developers making changes, but 
  >     being unable to test that they haven't broken Ada.
  > 
  > Sorry, I don't follow.  You comment certainly argues in favor of putting in
  > the tree soon, which everybody already agrees on, but how does it argue in
  > favor of deciding on a merge policy soon, which is what Laurent was talking
  > about?
From my experience it's a lot easier to deal with the merge policy at the same
time you move the bits into the tree since it has major impacts on the
development policy.

jeff

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    But it would make it possible for folks to build & test it over time.  ie
    you'll be able to say "oh, that change addressed an Ada bug that is in the
    regression testsuite", so before you twiddle that code any further make
    sure that your change doesn't regress the Ada compiler.

Sure.  I don't think anybody (certainly not me) is arguing against putting
GNAT in the tree, among other reasons for the one you mention.  I'm just
pointing out that I think it's highly unlikely that putting it there will
somehow bring lots of potential GNAT-modifiers out of the woodwork.

    And fundamentally ACT policy of having *exclusive* access to the GNAT
    sources is counter to the principles of open development of free
    software IMHO.

That's also a strawman, since nobody has proposed that either.

    *BUT* we didn't do bulk merges *into* the official sources.  That
    *IS* what ACT does with the GNAT tree.

I don't understand your tense here.  Since no procedure has been set up yet,
nothing can be in present tense and any guesses as to the future are
speculation since nothing has been decided.

For those who don't understand what I was getting at, the main reason that
somebody offering commerical support for GNU software needs their own private
tree has to do with changes done by others.  These affect both QA issues and
timing.  For example, one service ACT provides to its customers is a
"wavefront" compiler which incorporates a fix to a critical bug that a
customer reported.  That means it needs to be able to ensure that a given
night's build meets QA.  It's reasonable for ACT to ask its developers to
avoid non-critical checkins from time to time, but not for it to prohibit
such in a public tree.

There are also occasional issues the other way.  Sometimes, meeting a
customer need and deadline requires making a change that isn't "ready for
prime time" and that will get cleaned up later.  Such changes should not be
placed into the poublic tree until they are.

Given that two trees are needed, there will always be the issue of merges.
Whether they are done with periodical bulk merges or change-by-change, it
takes significant resources to do them.  Which of these takes the most work
is a strong function of how many changes are made by others.  If others makes
lots of changes (like the GCC case), the most efficient way is to merge
change-by-change.  If there are very few changes made by others, the most
efficient is to do periodic bulks merges.  So the comparison with the way
Cygnus used to do it is not as relevant as it might seem.

I think what Laurent was trying to say was that it's best to not make that
decision now, but instead to put the tree out there and *see* how many people
make changes over a period of time and let that strongly influence the
decision of what the best policy is.  I agree with that approaach.

    Cygnus/Red Hat has the same kind of access anyone else does as far as
    GCC is concerned.  That is definitely not true for GNAT development.

Again, that has tense problems since GNAT has not been put into the tree yet.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10010121135.AA01748@vlsi1.ultra.nyu.edu >you write:
  >     But it would make it possible for folks to build & test it over time.  
  > ie
  >     you'll be able to say "oh, that change addressed an Ada bug that is in 
  > the
  >     regression testsuite", so before you twiddle that code any further make
  >     sure that your change doesn't regress the Ada compiler.
  > 
  > Sure.  I don't think anybody (certainly not me) is arguing against putting
  > GNAT in the tree, among other reasons for the one you mention.  I'm just
  > pointing out that I think it's highly unlikely that putting it there will
  > somehow bring lots of potential GNAT-modifiers out of the woodwork.
True, but keeping it locked away at ACT virtually guarantees that you never
get any contributors at all.  That's how things have been since the GNU Ada
project started.

  >     And fundamentally ACT policy of having *exclusive* access to the GNAT
  >     sources is counter to the principles of open development of free
  >     software IMHO.
  > 
  > That's also a strawman, since nobody has proposed that either.
It's not a proposal, it's current reality.  ACT employees have exclusive
access to the GNU Ada sources.  


  > timing.  For example, one service ACT provides to its customers is a
  > "wavefront" compiler which incorporates a fix to a critical bug that a
  > customer reported.  That means it needs to be able to ensure that a given
  > night's build meets QA.  It's reasonable for ACT to ask its developers to
  > avoid non-critical checkins from time to time, but not for it to prohibit
  > such in a public tree.
The way to manage this is to test the hell out of the tree when you bring in
changes from the net *before* you check those changes into your internal
repositories.  That's what Cygnus and later Red Hat has done for years.

  > There are also occasional issues the other way.  Sometimes, meeting a
  > customer need and deadline requires making a change that isn't "ready for
  > prime time" and that will get cleaned up later.  Such changes should not be
  > placed into the poublic tree until they are.
Then you need to build policies and procedures for keeping some code local,
again, Cygnus/Red Hat has used various procedures to manage this for a long
time.  I'm more than happy to describe our policies and procedures if you are
interested.

Please keep in mind that those issues are ACT's problems and should not be
a consideration for how to manage the GNU Ada repository.

  > Given that two trees are needed, there will always be the issue of merges.
  > Whether they are done with periodical bulk merges or change-by-change, it
  > takes significant resources to do them.  Which of these takes the most work
  > is a strong function of how many changes are made by others.  If others mak
  > es
  > lots of changes (like the GCC case), the most efficient way is to merge
  > change-by-change.  If there are very few changes made by others, the most
  > efficient is to do periodic bulks merges.  So the comparison with the way
  > Cygnus used to do it is not as relevant as it might seem.
Any bulk merges need to be from the net sources to your internal sources.
Any other method would put ACT into a privileged position in regards to
installing changes into GNU Ada.

jeff

Re: Why not gnat Ada in gcc?

[Robert Dewar]

<<I would claim the opposite.  We need this to happen sooner, not later.
The longer we wait, the more difficult our work becomes and the longer
we have to deal with the problem of developers making changes, but
being unable to test that they haven't broken Ada.
>>

Well the main burden of testing has to remain with ACT, because only we
have the full test suite. This test suite cannot be made available publicly
because it contains millions of lines of proprietary code. However, we can
make the ACVC (now ACATS test suite available), since that suite is public,
and this will go a long way to solving such problems. There is also a small
amount of additional (but useful) test program material that ACT will be
able to supply for this purpose. 

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    The model proposed by Robert Dewar is the right one to start with, and
    it will put the merging burden on ACT if some contributions are indeed
    made by people having write access to the GNAT sources. If this
    becomes significant, I assume the natural thing will happen (move of
    the master source to the FSF CVS repository).

I think that is indeed the issue: to what extent are there likely to
*be* significant contributions from the FSF community?

Ada is a very complex language and one which is understood to that
extent by very few people and those few people nearly all work for Ada
compiler vendors.  So I don't accept that putting GNAT sources in the
repository will magically make such expertese appear.

In any event, it will *always* be the case that merges are necessary
since ACT can't use the GCC repository copy as its main development
compiler for the same reasons that Cygnus couldn't do it for GCC.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 10010120018.AA00642@vlsi1.ultra.nyu.edu >you write:
  > Ada is a very complex language and one which is understood to that
  > extent by very few people and those few people nearly all work for Ada
  > compiler vendors.  So I don't accept that putting GNAT sources in the
  > repository will magically make such expertese appear.
But it would make it possible for folks to build & test it over time.  ie
you'll be able to say "oh, that change addressed an Ada bug that is in the
regression testsuite", so before you twiddle that code any further make
sure that your change doesn't regress the Ada compiler.

And fundamentally ACT policy of having *exclusive* access to the GNAT
sources is counter to the principles of open development of free
software IMHO.

  > In any event, it will *always* be the case that merges are necessary
  > since ACT can't use the GCC repository copy as its main development
  > compiler for the same reasons that Cygnus couldn't do it for GCC.
*BUT* we didn't do bulk merges *into* the official sources.  That
*IS* what ACT does with the GNAT tree.

Cygnus/Red Hat has the same kind of access anyone else does as far as
GCC is concerned.  That is definitely not true for GNAT development.

jeff

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

I wrote:
> I don't think it is useful to argue on the source merging process right now.
Jeff wrote in reply:
> I would claim the opposite.  We need this to happen sooner, not later.
> The longer we wait, the more difficult our work becomes and the longer
> we have to deal with the problem of developers making changes, but 
> being unable to test that they haven't broken Ada. [...]

Hmmm, it looks like the issues you mention your last sentence are
solved by the mere inclusion of compilable GNAT sources in the CVS
repository (*), and I fail to see how this problem is affected by the
update policy once the sources are there. 

If a GCC developper is making a tree API change affecting Ada, either
he or she commits the Ada bits (in Gigi) that make the Ada compiler
happy and ACT will merge the changes in their own tree, or someone in
ACT followed the API change and will provide/suggest the needed bits.

(*) plus of course a test suite to help out non Ada developpers
working on the back-end or tree interface to see how they change
impact Ada, and to have Ada test cases for things in the back-end that
happens only from Ada code. That is why I proposed to work on getting
an Ada test suite up as a first step after inclusion of the
sources. This won't be an exciting new feature of GNAT (since ACT has
already lots of testing done, and big chunks of this is customer
proprietary code so it will never be public), but it will at least
make the Ada stuff GCC development process friendly.

Richard Kenner wrote:
> [...] I'm just pointing out that I think it's highly unlikely that putting
> it there will somehow bring lots of potential GNAT-modifiers out of
> the woodwork. [...]

In the short term of course no. The only thing is that with private
development sources and one source release per year, you're just
making sure that "potential GNAT-modifiers" stay "in their woodwork"
;-). 

Since people already working in the industry probably won't have time
to enter the front-end, I'm hoping students will do and this will take
a few years (I went this route ;-).

The compiler is not the only target for improvements, there's also the
runtime, which is a bit more accessible. For example, the tasking
stuff currently uses a POSIX thread adapter and works above that with
well known "semantic impedence mismatch" problems, however on
GNU/Linux the POSIX thread is already a layer above the clone system
call. Linus does not like that much the POSIX thread stuff ("broken by
design" ;-) but he recently introduced some bits in the kernel and a
challenge to the POSIX guyes to take advantage of it. May be the GNAT
tasking runtime could be adapted to use clone and a few other bits so
as to be more efficient and/or elegant on GNU/Linux. This is something
ACT has no big commercial incentive to do, but that would be helpful
to the GNU community. Small bits, the cos/sin/log/exp functions are
slower on GNAT/Linux than on GNAT/NT because the NT runtime has
inlined asm (from glibc!), and the GNU/Linux one doesn't. Etc...

There are lots of small improvements that ACT has no resource to do
that will probably happen reasonably early, the big stuff will
probably come much later (measured in years). I assume GCC/C
and GCC/C++ did not benefit from massive changes right after
the first source releases either.

> [...] I think what Laurent was trying to say was that it's best to
> not make that decision now, but instead to put the tree out there
> and *see* how many people make changes over a period of time and let
> that strongly influence the decision of what the best policy is.  I
> agree with that approaach. [...]

Good that we agree on this ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Corey Minyard]

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

>     The model proposed by Robert Dewar is the right one to start with, and
>     it will put the merging burden on ACT if some contributions are indeed
>     made by people having write access to the GNAT sources. If this
>     becomes significant, I assume the natural thing will happen (move of
>     the master source to the FSF CVS repository).
> 
> I think that is indeed the issue: to what extent are there likely to
> *be* significant contributions from the FSF community?

I would contribute.  I have contributed to GNAT in the past.  The
number of people I know that would contribute are likely not a
numerous as for C or C++, but they probably number several dozen
active contributers.

> Ada is a very complex language and one which is understood to that
> extent by very few people and those few people nearly all work for Ada
> compiler vendors.  So I don't accept that putting GNAT sources in the
> repository will magically make such expertese appear.

I don't agree with this.  After programming for 10 years in C, and
learning both Ada and C++, I found Ada easy to learn and not very
complex.  Certainly much less complex than C++.  Don't re-enforce the
FUD.

I think you are saying that people will break things (violate the
reference manual) because they don't understand it well enough.
That's true.  But you can say the same for C, Java, and C++.
Especially Java.  People break it all the time.  Java itself is not
that complex, but the libaries are fairly vast.  But at least Ada has
a well-defined validation suite and I know ACT has a very extensive
test suite.  So if people break it, finding the breaks should be
easier.  Plus, GNAT is very well written and easy to follow.

And if the ease of entry gets lowered to using Ada, maybe people will
start using it.  Maybe they won't.  But if it is part of GCC, it's
much more likely that Redhat, SuSE, etc. will build it into the
standard distribution.  And if they do, the effort for entry is
greatly lowered.  I think the main reason C became so popular was the
low effort to use it (it came on everything) and the portability (it
worked pretty much the same on everything).

> In any event, it will *always* be the case that merges are necessary
> since ACT can't use the GCC repository copy as its main development
> compiler for the same reasons that Cygnus couldn't do it for GCC.

You are right, merges are always necessary.  But there is a vast
difference between the ACT development model and the Cygnus model.
Cygnus puts changes out quite often, allows experiments to go on in
the public release.  ACT holds all changes until one massive release.
I don't like the ACT model very much, I would like to see a much more
free and open interworking with the user community.  And if GNAT goes
into the GCC distibution, with their current model ACT will have to
work very hard to coordinate their releases to make sure they work in
the standard releases of GCC from the FSF.  Otherwise, GNAT will
always be broken.

I agree with Mr. Stallman about the neutral repository.  I think it
would be better to host the FSF sources in a neutral location.
Although I think Redhat/Cygnus is doing a fairly good job of remaining
neutral, it still makes other businesses a little nervous, I think.
And the point it to avoid squelching cooperation and innovation.  If I
had an OC-3 and a bunch machines, I'd host it.  But maybe I'm not
neutral :-).

Corey

Re: Why not gnat Ada in gcc?

[Robert Dewar]

Laurent Guerby asks

<<I don't know if ACT has debated the issue, but assuming the GNAT
sources end up in the GCC CVS repository what will be the updating
policy between the ACT tree and the public GCC one? One massive update
from ACT per public GNAT version? Minor updates when GCC backend
interface changes are made that break the compilation of the Ada
frontend? Or more frequent updates?
>>

Certainly new releases of GNAT always have major additions, which will
result in a fairly massive update to the tree (as has happened with
other GNU tools when major updates are made). We will also provide minor
updates and patches as we go along to correct significant problems or
deal with interface changes.

<<If some people want to develop non trivial patches to GNU Ada
(affecting multiple files), how should they proceed (I assume by first
contacting ACT, but then)?
>>

These patches should be submitted to someone with write access to the
tree in the usual manner. Ada Core Technologies will of course follow
any such patches, and incorporate them where appropriate (or correct
them where this is needed).

<<PS: I promised on this list I would package a test suite and a
performance test suite if the GNAT sources go in the GCC CVS tree.
>>

That would certainly be helpful, in particular, packaging the latest
ACVC test suite will be very useful.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 20001001153500.5FBCB34D84@nile.gnat.com >you write:
  > Laurent Guerby asks
  > 
  > <<I don't know if ACT has debated the issue, but assuming the GNAT
  > sources end up in the GCC CVS repository what will be the updating
  > policy between the ACT tree and the public GCC one? One massive update
  > from ACT per public GNAT version? Minor updates when GCC backend
  > interface changes are made that break the compilation of the Ada
  > frontend? Or more frequent updates?
  > >>
  > 
  > Certainly new releases of GNAT always have major additions, which will
  > result in a fairly massive update to the tree (as has happened with
  > other GNU tools when major updates are made). We will also provide minor
  > updates and patches as we go along to correct significant problems or
  > deal with interface changes.
I think that's the wrong model.  Dumping in massive changes like that makes
it nearly impossible for others outside ACT to be involved with development.  

I would much rather see the GCC CVS sources become the master sources and
GNU Ada work happen in that source tree on an incremental basis just like
the other parts of the GNU compiler suite.

Basically the whole GNAT development process is closed to developers outside
ACT.  That is terribly unfortunate.

jeff

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

Disclaimer: I worked for ACT but I no longer do, I'm on the support client side now.

jeff wrote:
> I think that's the wrong model.  Dumping in massive changes like that makes
> it nearly impossible for others outside ACT to be involved with development.  
>
> I would much rather see the GCC CVS sources become the master sources and
> GNU Ada work happen in that source tree on an incremental basis just like
> the other parts of the GNU compiler suite.
>
> Basically the whole GNAT development process is closed to developers outside
> ACT.  That is terribly unfortunate.

IMHO, the problem we're trying to correct now is to get past the chicken-and-egg
bootstrap problem, no available GCC compatible source means no contribution
which means no incentive to provide public up to date sources...

If ACT provides sources compatible with the current GCC in CVS and the
GCC steering committee accepts it, that's a HUGE progress in the right
direction. So far, nothing has been decided (at least not publically
on this list) on the topic of the inclusion of the Ada sources in the
FSF GCC CVS repository.

The model proposed by Robert Dewar is the right one to start with, and
it will put the merging burden on ACT if some contributions are indeed
made by people having write access to the GNAT sources. If this
becomes significant, I assume the natural thing will happen (move of
the master source to the FSF CVS repository).

But I don't think we're here yet or anytime in less than a year, so I
don't think it is useful to argue on the source merging process right
now.

Up to now, GNAT source releases have been made something like every
year, so we have plenty of time ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 200010111937.VAA01637@ulmo >you write:
  > Disclaimer: I worked for ACT but I no longer do, I'm on the support client 
  > side now.
Understood.

  > IMHO, the problem we're trying to correct now is to get past the chicken-an
  > d-egg
  > bootstrap problem, no available GCC compatible source means no contribution
  > which means no incentive to provide public up to date sources...
We can get the compiler bootstrapped.  It's not the most pleasant thing
to do, but nor is it a terrible thing to do.  And it only has to be done
once and you can then use that compiler to bootstrap later versions.

  > If ACT provides sources compatible with the current GCC in CVS and the
  > GCC steering committee accepts it, that's a HUGE progress in the right
  > direction. So far, nothing has been decided (at least not publically
  > on this list) on the topic of the inclusion of the Ada sources in the
  > FSF GCC CVS repository.
I'd very much like to see it in the repo.  That's the first step, move
development into the open where others can contribute in whatever way
is most appropriate for them.

  > 
  > The model proposed by Robert Dewar is the right one to start with, and
  > it will put the merging burden on ACT if some contributions are indeed
  > made by people having write access to the GNAT sources. If this
  > becomes significant, I assume the natural thing will happen (move of
  > the master source to the FSF CVS repository).
But that's there the burden belongs -- on ACT.  Cygnus has dealt with
this burden for 10 years -- it's the price (IMHO) for wanting to be in
the business of supporting and custom development for tools you do not
own/control.  I'm more than happy to give ACT some pointers on how to
manage the process.


  > But I don't think we're here yet or anytime in less than a year, so I
  > don't think it is useful to argue on the source merging process right
  > now.
I would claim the opposite.  We need this to happen sooner, not later.
The longer we wait, the more difficult our work becomes and the longer
we have to deal with the problem of developers making changes, but 
being unable to test that they haven't broken Ada.

Jeff

Re: Why not gnat Ada in gcc?

[Richard Stallman]

I agree with your arguments that the Ada sources should be included in
the main GCC repository, and I would like to see this done soon.

But it is unreasonable to ask ACT to put its repository onto a machine
run by Cygnus, and associated by the public with Cygnus.  If we want
to say to ACT that using the GCC repository is the only right thing to
do, we need to move the GCC repository to a neutral GNU site first.

    Also note that I've got the financial committement from Red Hat I need
    to co-locate the existing box at an AT&T site which should provide a huge
    increase in network bandwidth.

That is nice, but the problems we should solve by moving the
repository are not a matter of to network bandwidth.  Increasing
bandwidth to the repository, while not a bad thing, won't help the GNU
Project in any of the larger ways.

Re: Why not gnat Ada in gcc?

[Jeffrey A Law]

  In message < 200010122240.QAA09837@wijiji.santafe.edu >you write:
  > I agree with your arguments that the Ada sources should be included in
  > the main GCC repository, and I would like to see this done soon.
Good.


  > But it is unreasonable to ask ACT to put its repository onto a machine
  > run by Cygnus, and associated by the public with Cygnus.  If we want
  > to say to ACT that using the GCC repository is the only right thing to
  > do, we need to move the GCC repository to a neutral GNU site first.
This is awful funny in a sick sort of way.

Red Hat (and formerly Cygnus) has bent over backwards to open up the GCC
development environment and try to put all developers on a level playing
field.    Yet, we have to do even more before you'll encourage a company
(ACT) that has de-facto stranglehold on GNU Ada development to open up
development of GNU Ada and put all developers on a level playing field.

Isn't that somewhat of a double standard?

Yes, the machine is physically at Red Hat's Sunnyvale site (Cygnus as a
corporate entity no longer exists), but everyone is encouraged to use
gcc.gnu.org and with a few exceptions gcc.gnu.org is logically out of
the redhat.com/cygnus.com domains.

Yes, there has been some content on sources.redhat.com which could be
mis-leading in terms of implying control over GCC, GDB or binutils.  But
as I've always maintained if there is something on that site that is 
objectionable and gives the wrong impression that we'll fix it.

jeff

Re: Why not gnat Ada in gcc?

[Hartmut Schirmer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On Wed, 11 Oct 2000, Laurent Guerby wrote:
>IMHO, the problem we're trying to correct now is to get past the chicken-and-egg
>bootstrap problem, no available GCC compatible source means no contribution
>which means no incentive to provide public up to date sources...

Configure GNAT to produce java byte code and let it compile itself:
JGNAT.

This (and any binary produced by JGNAT) can be executed in a JVM or
directly on the host using GCC´s java front end:

         JGNAT               gcj
Sources -------> byte code -------> hosted GNAT (stage0)


Creating JGNAT once (or every few years) should be sufficient.

This scheme may work for other self implemented languages as well.

Hartmut

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

I wrote:
> IMHO, the problem we're trying to correct now is to get past the chicken-and-egg
> bootstrap problem, no available GCC compatible source means no contribution
> which means no incentive to provide public up to date sources...

The use of "bootstrap" here was unfortunate, but well...

Harmut wrote:
> Configure GNAT to produce java byte code and let it compile itself:

I'm not sure it would work since JGNAT might not support at this point
some Ada features used by the GNAT code itself (parts of it are fairly
low level and might not work on JVM IIRC). But definitely an
interesting thing to look at ;-).

-- 
Laurent Guerby <guerby@acm.org>

Why not gnat Ada in gcc?

[Robert Dewar]

Gene Montgomery <g.montgomery@gte.net> wrote:

 >It is a wonderment to me that the Ada 95 compilation system,
 >originally built with public funds, called GNAT (for
 >GNU Ada Translator, IIRC), and organized according to some
 >consultation by RMS, has not been taken under the wing
 >of the gnu crew.  I have not found Ada Core Technologies (ACT)
 >particularly user-friendly, and have wondered why the gnu crew
 >would not have decided to add Ada to the already substantial
 >capabilities of GCC.  ACT just doesn't keep it up - my
 >gcc libraries are never in sync with the gnat libraries. If
 >gnat were to be just another mode of operation of the gcc
 >package, these kinds of issues would be solved by the gnu crew.

It has always been our intention that GNAT would be integrated into the
GNU standard distribution in one manner or another. What delayed this
for quite a while was the split of the FSF and EGCS trees. Since the
major reason for the integration for many people was to get better
GNAT/g++ coordination, it became clear that the best path to achieving
this goal was to work on getting GNAT to be compatible with the latest
merged FSF sources.

This involves two significant tasks.

1. Installing bugfixes to GCC that were developed after the 2.8.1 release
but had not been installed in the EGCS tree and fixing a number bugs in
the GCC development tree that were more visible with Ada than with C,
though test cases in C could be contructed for some of them.  In addition,
some of the infrastructure changes that were made to GCC during the EGCS
work were refined, both as a cleanup for GCC and to make them more usable
for Ada. 

2. Updating GNAT to be compatible with the new frontend/backend interface
specifications, which have changed significantly from GCC 2.8.1.

The current status of this work is that 1. is largely complete, as any of
you know who have followed the gcc status, Richard Kenner has completed
the checkin of thousands of lines of patches to gcc to meet this requirement.
Many of these checkins are generally beneficial in that they improve
performance or correct bugs in multiple languages, others correct bugs
that are relevant (at the current time) only to GNAT.

The work on 2 is also largely complete, we now have a bootstrapped version
that passes the entire ACVC suite, but we have not yet run our internal
regression suite, and that is the next step before we release the new
version of GNAT (and the new version in general has to go through our
quality assurance procedures). We hope to complete these steps in the
near future, and at that stage, the integration of Ada into the GCC
release is both practical and desirable. 

So far, this work has only been checked out on a handful of targets (the
ACVC testing only on one target, the bootstrap on three). For the most
part we expect the support of other targets to be straigntforward, in
that most issues are target independent, but there are always some
target dependent issues.

Concerning GDB, each successive version has required major additions
in order to support Ada properly.  In the past we have developed
these Ada specific additions for GDB versions 4.16 and 4.17.
We are in the process of developing the patches for 5.0.
This is not just a matter of applying an existing patch file
since there is quite a bit of specialized work. Again, this is a
high priority project for us, and we are making good progress, and
the Ada aware GDB 5.0 is now starting to work on some targets.
The changes will be integrated into the public GDB tree as soon
as they are in reasonable shape.

Ada Core Technologies will continue to make new versions available 
publicly as it has always done in the past (funded now incidentally
wholly by paying customers, there has been no government support for
many years, so at this stage only a small fraction of the development
has been government funded, perhaps about 25% of the total). In addition,
in the Linux environment, there is an active group that is interested
in helping to maintain GNAT-for-Linux (these are the people who 
realistically form the volunteer group that will do interesting things
with GNAT). Ada Core Technologies and ACT Europe work closely with the
GNAT-Linux group.

Finally, just a note, GNAT never stood for GNU Ada Translator. It
originally stood for GNU NYU Ada Translator, but since it no longer
has anything to do with NYU, and since it is not a translator in the
usual sense, but rather a real compiler, the acronym was long ago
abandoned, and we refer simply to GNAT (not an acronym) or GNU Ada,
the latter designation being useful in the GNU context to identify
what this beast is :-)

Robert Dewar
Ada Core Technologies

[Robert is also the FSF appointed maintainer for GNU Ada]

Re: Why not gnat Ada in gcc?

[Laurent Guerby]

Hi Robert,

I don't know if ACT has debated the issue, but assuming the GNAT
sources end up in the GCC CVS repository what will be the updating
policy between the ACT tree and the public GCC one? One massive update
from ACT per public GNAT version? Minor updates when GCC backend
interface changes are made that break the compilation of the Ada
frontend? Or more frequent updates?

If some people want to develop non trivial patches to GNU Ada
(affecting multiple files), how should they proceed (I assume by first
contacting ACT, but then)?

PS: I promised on this list I would package a test suite and a
performance test suite if the GNAT sources go in the GCC CVS tree.

-- 
Laurent Guerby <guerby@acm.org>

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    Who is still programming in Ada? and why?

This is *really* off topic, but basically Ada is the language of choice for
safety-critical applications.  Much Ada programming nowadays in done in
companies such as Boeing, Lockheed Martin, and Rockwell.  It is used
for such applications as avionics, air traffic control, and military
software.  Typical Ada applications are millions of lines of code.

Re: Why not gnat Ada in gcc?

[Stan Shebs]

Richard Kenner wrote:
> 
>     Who is still programming in Ada? and why?
> 
> This is *really* off topic, but basically Ada is the language of choice for
> safety-critical applications.  Much Ada programming nowadays in done in
> companies such as Boeing, Lockheed Martin, and Rockwell.  It is used
> for such applications as avionics, air traffic control, and military
> software.  Typical Ada applications are millions of lines of code.

It's worthwhile to remind the callow youths that the world does not actually
revolve around GCC bootstraps and recompilation of the Linux kernel. :-)

I'm for including GNAT sources in the repository, so that it can
act as a reminder that it's part of the Gnu Compiler Collection too.
If it's too onerous for a default checkout, it's always an option to
create appropriate modules for subsets.

Stan

Re: Why not gnat Ada in gcc?

[jfm2]

> 
> Richard Kenner wrote:
> > 
> >     Who is still programming in Ada? and why?
> > 
> > This is *really* off topic, but basically Ada is the language of choice for
> > safety-critical applications.  Much Ada programming nowadays in done in
> > companies such as Boeing, Lockheed Martin, and Rockwell.  It is used
> > for such applications as avionics, air traffic control, and military
> > software.  Typical Ada applications are millions of lines of code.
> 
> It's worthwhile to remind the callow youths that the world does not actually
> revolve around GCC bootstraps and recompilation of the Linux kernel. :-)
> 

It's worthwhile to remind the callow youths that it is not because
something is standatrd in Unix that it is the best in world.  C became
the standard in Unix mailnly because for a time it was the only
language available.  By the time other languages became available it
was too late: using another language would have meant retraining
programmers and rewriting many libraries.  C is quite adequate for
writing kernels (its original purpose) but it is too low level for
application programming, makes programmers reinvent wheels (each
reinvented wheel is a potential bug) and has several architectural
flaws: it is far easier to get buffer overruns when you are handling
pointers to a zone of memory teminated by a \0 that when a string is a
zone of memory preceeded by a counter telling size since in the later
case the compiler or the runtime environment can tell you there is
something wrong.

I feel far better when nuclear plant software is not written in C/C++.

-- 
			Jean Francois Martinez

RE: Why not gnat Ada in gcc?

[Richard Kenner]

    but gcj is also a large project and it it's in GCC, isn't-it?

If it is, I don't see it.

GNAT is 1800 files for a total of 41 MB.

Re: Why not gnat Ada in gcc?

[Geoff Keating]

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

>     but gcj is also a large project and it it's in GCC, isn't-it?
> 
> If it is, I don't see it.
> 
> GNAT is 1800 files for a total of 41 MB.

The C and C++ combined tree is currently 26420 files at Cygnus and
200MB.  I don't think compared to that 41MB is a significant problem,
especially considering how large the combined tree gets if you add in
Java.  There's lots of diskspace left on sourceware (the entire CVS
repository is using 1.2G of an 8.1G disk).

-- 
- Geoffrey Keating <geoffk@cygnus.com>

RE: Why not gnat Ada in gcc?

[William Gacquer]

but gcj is also a large project and it it's in GCC, isn't-it?
and ( I am not sure of that ) GNAT is able to export bytecode compatible
with Java bytecode : I wonder why GCC could not benefit from that too.


> -----Original Message-----
> From: kenner@vlsi1.ultra.nyu.edu [ mailto:kenner@vlsi1.ultra.nyu.edu ]
> Sent: lundi 18 septembre 2000 18:47
> To: aoliva@redhat.com
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why not gnat Ada in gcc?
> 
> 
>     > have wondered why the gnu crew would not have decided 
> to add Ada to
>     > the already substantial capabilities of GCC
> 
>     AFAIK, it's because part of GNAT is written in Ada, so 
> you'd need an
>     Ada compiler to bootstrap it, and few people have one handy.
> 
> That's half the reason.  The other half is that it's a *lot* of large
> files and there's still the question of whether it makes sense to put
> it into the main repository.
> 

Re: Why not gnat Ada in gcc?

[Alexandre Oliva]

On Sep 18, 2000, William Gacquer <wgacquer@ubisoft.fr> wrote:

> but gcj is also a large project and it it's in GCC, isn't-it?

Only the compiler, which is quite small, compared with the size of the
Java library, that still lives in a separate CVS tree.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Why not gnat Ada in gcc?

[Richard Kenner]

    > have wondered why the gnu crew would not have decided to add Ada to
    > the already substantial capabilities of GCC

    AFAIK, it's because part of GNAT is written in Ada, so you'd need an
    Ada compiler to bootstrap it, and few people have one handy.

That's half the reason.  The other half is that it's a *lot* of large
files and there's still the question of whether it makes sense to put
it into the main repository.

Why not gnat Ada in gcc?

[Gene Montgomery]

It is a wonderment to me that the Ada 95 compilation system,
originally built with public funds, called GNAT (for
GNU Ada Translator, IIRC), and organized according to some
consultation by RMS, has not been taken under the wing
of the gnu crew.  I have not found Ada Core Technologies (ACT)
particularly user-friendly, and have wondered why the gnu crew
would not have decided to add Ada to the already substantial
capabilities of GCC.  ACT just doesn't keep it up - my
gcc libraries are never in sync with the gnat libraries. If
gnat were to be just another mode of operation of the gcc
package, these kinds of issues would be solved by the gnu crew.

I like Ada, and know of a number of other folks who think
it is an excellent language.  I submit that it is at least
as popular as chill or objective-C.  

Gene Montgomery, retired software developer.
begin:vcard 
n:Montgomery;Gene
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:g.montgomery@gte.net
note;quoted-printable:-- =0D=0APursuant to U.S. code,title 47, Chapter 5, Subchapter II, Section 227,=0D=0Aand consistent with Oregon State Law, any and all nonsolicited commercial=0D=0AE-mail sent to this address is subject to a consulting fee of $500.00 U.S.=0D=0AE-Mailing denotes acceptance of these terms.=0D=0AConsult < http://www.law.cornell.edu/uscode/47/227.html > for details.
x-mozilla-cpt:;11168
fn:Gene Montgomery
end:vcard

Re: Why not gnat Ada in gcc?

[Alexandre Oliva]

On Sep 18, 2000, Gene Montgomery <g.montgomery@gte.net> wrote:

> have wondered why the gnu crew would not have decided to add Ada to
> the already substantial capabilities of GCC

AFAIK, it's because part of GNAT is written in Ada, so you'd need an
Ada compiler to bootstrap it, and few people have one handy.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Why not gnat Ada in gcc?

[reedkotler]

There used to be a book called "How to Make Yourself Miserable".
Once suggestion was "Using the tip of your tongue,  try and make your
gums bleed".

I would say programming in Ada in the year 2000 is a similar thing.

Who is still programming in Ada? and why?

You should get some governement agency to pay for that if it's
still important or else some Ada guy can.

Why would some C/C++ programmer want to do that?

reed

----- Original Message ----- 
From: "Gene Montgomery" <g.montgomery@gte.net>
To: <gcc@gcc.gnu.org>
Sent: Monday, September 18, 2000 8:36 AM
Subject: Why not gnat Ada in gcc?


> It is a wonderment to me that the Ada 95 compilation system,
> originally built with public funds, called GNAT (for
> GNU Ada Translator, IIRC), and organized according to some
> consultation by RMS, has not been taken under the wing
> of the gnu crew.  I have not found Ada Core Technologies (ACT)
> particularly user-friendly, and have wondered why the gnu crew
> would not have decided to add Ada to the already substantial
> capabilities of GCC.  ACT just doesn't keep it up - my
> gcc libraries are never in sync with the gnat libraries. If
> gnat were to be just another mode of operation of the gcc
> package, these kinds of issues would be solved by the gnu crew.
> 
> I like Ada, and know of a number of other folks who think
> it is an excellent language.  I submit that it is at least
> as popular as chill or objective-C.
> 
> Gene Montgomery, retired software developer.