Towards a free GNU Ada
James Rogers
Early in the Ada 9X development effort it became clear that one of
the keys to the future acceptance of Ada was the availability of
a very low cost compiler. This lead to the funding of early
Ada 9X compiler development, resulting in what is now known as
the GNAT compiler.
We can thank the US DoD for the initial funding of GNAT. We
can also thank the entire GNAT team. The product of that team is
a truly impressive compiler.
In late 1994 many members of the GNAT development team realized the
DoD funding was limited. They believed in the viability of Ada and
of GNAT. They also saw an opportunity for a business. As a result
they formed ACT.
ACT has taken on a very large and difficult assignment: to maintain
and improve GNAT, providing high quality code free to the public,
while making a profit. This assignment contains some inherent
contradictions. One cannot make a profit by giving away the fruits
of one's efforts. On the other hand, free versions of GNAT must
not cost more than the cost of the media upon which they are
delivered.
I wish ACT great success. I hope they achieve spectacular profits.
I also still see the need for a free Ada compiler. This compiler
must be of high quality, passing all applicable validation criteria.
It cannot be a subset or crippled compiler suitable only for simple
demonstration of the potentials of the Ada language.
Perhaps it is time to remove some conflict from the ACT charter.
It seems the only way to do this is to either find a continuing
source of funding for development and maintenance of GNAT, or to
find some alternate group to perform maintenance of a public
version of GNAT, effectively creating a separate version from the
product produced by ACT.
I see a list of possible responses to this problem:
* Use gnat3.09 for a long long time
* Form a consortium of GNAT users, with annual dues which will be
paid to ACT to provide public support for GNAT
* Abandon the concept of a free Ada compiler and purchase all our
compilers from AONIX, JANUS, Intermetrics, Rational, ACT, etc
* Organize a distributed group of Ada compiler developers to take
over development of a free Ada compiler, resulting in a second
branch of Gnu Ada development. Such an effort would likely be
haphazard and uncoordinated, resulting in questionable quality
and lack of responsibility for compiler defects.
GNAT has helped fuel a renaissance for Ada. We cannot simply turn
our backs on the newly emerging interest in Ada. We must continue
to find ways to support and encourage the growth of interest in Ada.
--
Jim Rogers
*************************************************************
Team Ada
Robert Dewar
Jim Rogers says
<<ACT has taken on a very large and difficult assignment: to maintain
and improve GNAT, providing high quality code free to the public,
while making a profit. This assignment contains some inherent
contradictions. One cannot make a profit by giving away the fruits
of one's efforts. On the other hand, free versions of GNAT must
not cost more than the cost of the media upon which they are
delivered.>>
Robert replies
I am not quite sure what the reference to cost of media here is. I hope
you are not under the mistaken impression that the GPL requires this.
The fact that free versions of GNAT continue to be available is a result
of ACT's determination to provide free versions, more on this later.
I wish ACT great success. I hope they achieve spectacular profits.
I also still see the need for a free Ada compiler. This compiler
must be of high quality, passing all applicable validation criteria.
It cannot be a subset or crippled compiler suitable only for simple
demonstration of the potentials of the Ada language.
>>
There is a lot of confusion here, which I find surprising. We certainly
do "give away the fruits of [our] efforts" in the sense that we are
committed to distributing all software that we develop. The current
discussion is simply about whether we should wait to publicly distribute
versions of GNAT until we feel that they are in sufficiently good shape
to distribute, given that many or indeed most people will be using these
versions without support. We strongly feel that the premature distribution
of versions of GNAT would be harmful to the Ada community, and from both
the public postings here, and many private email messages I have received,
I have the impression that most people support this position.
Now if you are saying that the problem is that it is not possible for
people to get free support, that is a different matter. Yes, one can
imagine a system in which someone (we will discuss who in a moment)
pays someone (e.g. ACT) to provide completely free support. Note that
this would be a very expensive proposition, since providing support
is expensive and if you want someone to provide this support to what
is a very large community of GNAT users, then you are talking about
a LOT of resources.
We do not need to make "spectacular profits", but we do need to make
a living. The free versions of Ada we distribute are to the best of
our ability, and in the opinion of many of our customers, high
quality, and, as of 3.10, will indeed pass all validation criteria.
Indeed so far, GNAT is the only technology that impleements 100%
of the Ada language, including all the annexes.
At no time do we distribute subset or crippled versions of GNAT. When
we make public distributions, we are distributing the latest version,
which includes our full technology. If you have got some other
impression, you are very much mistaken. As I mention above, the issue
in the current thread has been whether ACT should publicly distribute
versions of GNAT that it does not feel are ready for public release.
We don't think this is a good idea, but do not for a moment get the
impression that we are distributing a subset of our technology. For
example, version 3.09, available publicly on many targets, was at
the time of the distribution the absolute latest version of GNAT.
The same version that was in use in many large scale deployed
commercial programs.
Since you seem to have some rather inaccurate impression of the
state of affairs, I am not quite sure what your possible responses
are responding to, but let's look at them anyway:
* Use gnat3.09 for a long long time
Certainly those using the public version of GNAT who find 3.09
entirely adequate for their purposes can reasonably continue
to do so. I must say I have never understood people who just
have to immediately update to the latest version of everything
just for the same of updating. On the other hand, version 3.10
has a LOT of problems fixed, corresponds to the fully validated
versions, and has many very important functional improvements,
including much better handling of elaboration order issues, and
much better debugging support.
If you need these new features, or if you are having trouble because
of problems that 3.10 fixes, then I don't see any possible advantage
in staying with 3.09. Really the situation with the public versions
of GNAT is not much different from a lot of proprietary software
that you buy in Software Etc, and cannot really get much meaningful
support for. You pay for upgrades in accordance with your needs. The
difference with GNAT is that you do not have to pay.
* Form a consortium of GNAT users, with annual dues which will be
paid to ACT to provide public support for GNAT
To a limited extent this is what happens now, where the consortium
of users is those users who need and pay for commercial support.
However, the support that this generates for public use is limited
to access to these public versions. I really do not see it as viable
to ask customer A to pay for free support for customer B. As I noted
above, the commitment to provide free support for all users of GNAT
would require very large resources.
* Abandon the concept of a free Ada compiler and purchase all our
compilers from AONIX, JANUS, Intermetrics, Rational, ACT, etc
This makes no sense to me at all. If you are willing to pay for
proprietary compilers, then the proper GNAT alternative is to pay
for GNAT suport. I do not see that any of your goals are met by
this suggestion. The fact is that there are thousands of GNAT
users who find the current arrangement in which they can get
their hands on the latest publicly distributed versions of GNAT
at no cost to be higly advantageous, and this suggestion would
eliminate this advantage.
* Organize a distributed group of Ada compiler developers to take
over development of a free Ada compiler, resulting in a second
branch of Gnu Ada development. Such an effort would likely be
haphazard and uncoordinated, resulting in questionable quality
and lack of responsibility for compiler defects.
If your model here is that GNAT can be maintained by an informal
group of volunteers, I don't believe it. ACT has the equivalent
of twelve extremely experienced software engineers working full
time on GNAT. The idea that you can replace this resource with
part time volunteers working in an uncoordinated manner is
simply unrealistic.
Yes, this model can work for simpler software components, particularly
those which can be handled as a labor of love by a single person, but
not for large complex software systems like GNAT together with its
tool chain.
The history of GNAT is that it was funded by the government primarily
to provide a free compiler for academic research purposes. A number
of the proprietary Ada vendors (certainly not all, some supported
the effort) tried hard to kill GNAT early on, because they felt it
was unfair competition. In fact the total amount of funding the
government provided for GNAT (about $3 million to NYU) is considerably
smaller than the support they have provided indirectly and directly
to other Ada vendors, but nevertheless the opposition was intense. As
a result of this opposition the contract deliberately only funded a
subset (omitting for example fixed-point and subunit support). As it
turns out we provided these features on our own time (Ed and I were
both on sabbatical for one year, and as our sabbatical project, filled
in the missing features).
But the pressure from other vendors continued to be intense, and one
consequence was that the government did not want to provide any direct
funding for continuation of the GNAT project past July 1995.
I don't think that is such a bad decision at all. The model where the
serious users of GNAT pay for the continued development of GNAT strikes
me as quite appropriate, and much more consistent with our competitive
environment. The trouble with the government funding a particular Ada
compiler technology is that it means that government users tend to be
pushed to using that technology for other than technical reasons.
I prefer the current situation where for the most part government users,
like any other users, evaluate various Ada technologies, and choose the
one that gives the best value for their money. If GNAT is the right
choice, then GNAT it is. If Rational provides a product that they think
does a better job than GNAT, then Rational it is. The result is fierce
technical competition between the Ada vendors. Great! competition
drives quality. We at ACT certainly feel the competitive pressure
to improve GNAT, and I am sure that other vendors feel the heat from
GNAT. That's the way an efficient market place works.
If you go to a model where GNAT is fully supported say by a single
large government grant, then I am not saying that development would
stop, since a lot of the development is driven by our own enthusiasm,
but the competitive pressure is definitely a positive factor, and for
one thing means that we are driven more by customer needs, and less
by our own fancy, which seems a good thing.
The model does not have to be 100% one way or the other of course.
Recently, the AJPO has initiated a program to directly provide
GNAT support for a limited number of COE users, and that is proving
an effective tool for encouraging the use of Ada 95 in some important
government programs. On the other hand, original plans at the AJPO
to provide completely free blanket support to all COE users was
abandoned (the proposed price, which approached a million dollars,
giving some idea of how you get into real money providing free
support, seemed just too high).
One kind of support program that I have proposed is that at least
some limited support be provided for academic users of GNAT. We do
of course provide free versions of GNAT to universities, as we do
for all GNAT users, and many universties are using GNAT to teach
Ada 95. However, we do not have the resources to provide help for
all the professors and students who are using GNAT. Many of you
have helped provide informal support here on CLA, and on our
chat list (ch...@gnat.com), and that is very welcome, but is not
a complete substitute for full support. However, so far no funding
has been forthcoming for such a venture.
It would also be useful if there could be some support for use of GNAT
by students. Here again, volunteers, for instance Mike Feldman, with
his work on the DOS version, have provided very valuable additions to
the GNAT technology. It is hard to mention all who have contributed
to that effort. Notable are the Brighton and Air Force Academy efforts
to provide simple IDE's for use of the Windows version. The latter
effort is particularly interesting, because the Air Force Academy is
using GNAT despite the fact that they have access to another academic
compiler that is free for them. It is rather remarkable when you get
fierce competition between free products!
The trouble is that the ACT funding model does not work so well for
simplifying student use. One consequence of the funding model is that
we tend to be driven by the large customer requirements, so for example
we are putting resources into the requirement for handling DCE threads
as normal Ada tasks. Very useful to certain large scale users, but not
exactly critical for student use!
My feeling here is that to make the optimal progress in the area of
providing easy student access, direct government funding is necessary,
and it is a pity for example that Mike Feldman's proposal to do simple
snazzy interfaces for the PC and Mac was turned down. Given what he
accomplished with no resources, I think we would have had something
really attractive by now if that project had been funded (it was
turned down incidentally on the grounds that ACT was not a credible
organization for guaranteeing validation (we had guaranteed validation
at our expense, since the government at that stage was set on not
giving one more dollar of support directly for GNAT), which is a bit
ironic, and also odd, given that validation is hardly necessary for
academic use. Oh well, we can all be thankful that Mike has continued
to plug away withou support despite this decision.
<<GNAT has helped fuel a renaissance for Ada. We cannot simply turn
our backs on the newly emerging interest in Ada. We must continue
to find ways to support and encourage the growth of interest in Ada.>>
We strongly agree, and our commitment here is that, although no one
is directly funding this, we will continue to do the work to make
public high quality distributions of GNAT from time to time.
Meanwhile, I think that the public users of GNAT owe a considerable
amount to those who are willing to support the continued development
of GNAT by paying for support, and in particular to those customers
who are willing to invest their resources using early prereleases
of these versions, something that is practical precisely because
they have full support from us.
Robert B.K. Dewar
Ada Core Technologies
Roy T. Fielding
In <33BBB7...@velveeta.apdev.cs.mci.com>
James Rogers <jro...@velveeta.apdev.cs.mci.com> writes:
>Perhaps it is time to remove some conflict from the ACT charter.
>It seems the only way to do this is to either find a continuing
>source of funding for development and maintenance of GNAT, or to
>find some alternate group to perform maintenance of a public
>version of GNAT, effectively creating a separate version from the
>product produced by ACT.
>
>I see a list of possible responses to this problem:
>
>* Use gnat3.09 for a long long time
>
>* Form a consortium of GNAT users, with annual dues which will be
> paid to ACT to provide public support for GNAT
>
>* Abandon the concept of a free Ada compiler and purchase all our
> compilers from AONIX, JANUS, Intermetrics, Rational, ACT, etc
>
>* Organize a distributed group of Ada compiler developers to take
> over development of a free Ada compiler, resulting in a second
> branch of Gnu Ada development. Such an effort would likely be
> haphazard and uncoordinated, resulting in questionable quality
> and lack of responsibility for compiler defects.
I think that is a paper tiger. It is unlikely, given the complexity
of Ada95 as a language, that a separate free Ada compiler could be
developed, and no compiler software (free or commercial) takes
responsibility for compiler defects. The notion that such
an effort would likely be haphazard and uncoordinated is ridiculous;
it would need to be better coordinated and less haphazard than the
existing GNAT development process just to get the project started.
History has shown that community-developed products are consistently
higher quality and more responsive to real user needs than their commercial
counterparts, so the only question is whether the Ada95 community includes
a sufficient core of individuals willing to support a community-based
software project. I'll be testing that in a couple months.
Robert's suggestion that community-based projects are only capable of
supporting small projects is contrary to established fact: Linux,
FreeBSD, Perl, and Apache are all examples of systems that are supported
and developed by a core group of their user community. In fact, such
systems tend to evolve into better, more extensible design architectures
in order to maximize the community input and be more flexible in
meeting the needs of individual users.
If you are concerned about the continued development of GNAT as a
platform for free software (as I am), then I think the most constructive
project would be a public, Web/e-mail problem tracking system for GNAT
that allowed everyone (ACT, customers of ACT, and non-customers) to
see what known bugs exist, to post potential fixes, and provide some
focus for the community. It isn't an easy thing to provide, but it
is certainly a prerequisite to any other Ada95 compiler effort. And,
I think it would help ACT as much as it would the rest of the community.
....Roy
Robert Dewar
Roy says
<<If you are concerned about the continued development of GNAT as a
platform for free software (as I am), then I think the most constructive
project would be a public, Web/e-mail problem tracking system for GNAT
that allowed everyone (ACT, customers of ACT, and non-customers) to
see what known bugs exist, to post potential fixes, and provide some
focus for the community. It isn't an easy thing to provide, but it
is certainly a prerequisite to any other Ada95 compiler effort. And,
I think it would help ACT as much as it would the rest of the community.
>>
RObert replies
This might appeal to the hobbyists in the Ada community who are happy to
fiddle with a stream of uncoordinated and insufficiently tested patches,
but it would be inimical to the interests of the wider Ada community
that needs reliable products. The need for reliability extends both
to paying customers, and perhaps even more to those who rely on free
public versions, which they must use without much support.
Even for those who do know the technology well, formulating a correct
fix to a problem is not easy. We get a stream of suggested fixes from
people who know GNAT pretty well. In nearly every case, the person
has correctly identified a problem, but produced a fix that is either
incomplete or plain incorrect.
I don'q know quite what makes you think that GNAT development is
haphazard, but let me give some idea of how we proceed internally.
If one of the GNAT developers develops a fix for a problem, or an agreed
on enhancement, then the modification is initially developed as a patch
to the current development sources.
This patch is submitted to a mailserver that runs our entire regression
suite (about 4100 diretories, totalling over 25,000 files, and over
two million lines of code). A couple of hours later, a mail message
indicates if the change has caused any regressions. If there are no
regressions, then the change can be checked in.
That night, automatic scripts run on multiple targets, which rebuild the
compiler completely from scratch, with a full bootstrap that starts with
the most recent public release. These scripts test that the bootstrap
succeeds, run the entire ACVC suite, and rerun the regression suite.
In the morning all developers receive a report on these nightly runs,
and if any problems have developed, fixing them is the highest priority.
Only if the nightly run is completely successful, do we qualify the
build as a distributable wavefront. Distributable in this case means
that we will provide it on an extremely limited basis, on request, to
supported customers who need the wavefront to fix an urgent problem.
Note that this kind of regression testing is out of reach of informal
fiddling. For one thing, the great majority of the code in the critical
regression suite is proprietary, for example it includes large chuncks
of the DEC test suite, as well as a lot of customer code, that the
customer has been willing to entrust to us only on the basis that
we will carefully protect it. It is also the case that the configuration
control that is needed requires very strong control and management.
You need to remember that the entire thread here develops from one
individual who is demanding to get a version of GNAT that we do not
think is ready to release. Yes, of course, we all want 3.10 to be
finished and out there as soon as possible. We have a team of people
working full time towards that goal, and all I can say is that we
simply will NOT release 3.10 before we feel it is ready for release,
no matter how loud people yell.
You point to Linux as an example of your model working, but in fact Linux
is a system based on many components, including the GNU software. The
latter is in fact at as carefully controlled as GNAT. You do NOT see the
snapshots du jour of GCC in the Linux sources. Similarly, the kernel itself
is also very carefully controlled, and in addition there are several
companies providing formal support which carefully control what they support.
The sources of GNAT have always been available, and large numbers of
people, particularly the hobbyists build from sources. We are always
delighted when people from the community DO contribute to GNAT, and
indeed in a couple of cases have hired such people (Doug Rupp developed
the DOS port of GNAT, and is now a full time employee of ACT, Geert Bosch
did some very nice work on the OS/2 port, and we hired him as a consultant
to continue the support of this port). However, relatively few people have
achieved a sufficient knowledge of what is going on in this highly complex
system to really have dug in.
It is always nice to receive a bug report together with a fix, and it has
happened a few times for runtime library components, but almost never for
the core of the compiler itself. And this is true despite a very strenuous
effort to make the sources accessible.
The idea of a public tracking system for GNAT bugs is unworkable in
practice. Why? Because the majority of code involved in such reports
is proprietary, and there is no way that the proprieters of such code
will post it. We quite often get bug reports that contains tens or
even hundreds of thousands of lines of such proprietary code.
I think a big difference here is what your view of the community is.
You see the community as a group of energetic hobbyists who want to
play with the latest versions of GNAT, develop and trade patches, etc.
We see the community as a group of serious users who need stability
and reliablity, and are not interested in always trying out the latest
patches and new features. Our customers are often quite reluctant to
switch to new versions, and that makes perfect sense to us.
I do not know if Roy is subscribed to ch...@gnat.com, as far as I can
tell he is not, but I am not sure I am checking the right address. The
idea of ch...@gnat.com is to develop to a small extent some aspects of
this informal community.
In practice, most of our support activity is not in fixing GNAT bugs,
but rather in helping people use the Ada 95 and GNAT technologies
effectively and efficiently in the context of the specific problems
that they are trying to solve. The idea of ch...@gnat.com is to provide
this kind of help, and it does so to some small extent. It would also
be perfectly appropriate to post GNAT patches and fixes here if people
discover such, but that has never happened.
We certainly are not about to participate directly in any such effort
of a central bug registry. For the reasons I give above, this is
impossible, even if it were desirable. We certainly are NOT about
to post our fixes one by one as we develop them. This is a recipe
for a completely out of control mess.
I have been involved in a number of commercial compiler projects, including
Ada 83 compilers, and, while ACT's software process may still not be ideal,
I can say that it is greatly superior to anything I have previously
encountered in the industry.
Sure, I understand the frustration of the enthusiasts who would just love
to get their hands on the development version every day and fiddle, but
I am afraid their interests must take second place to the needs of the
Ada community that is interested in stable and reliable products and
wants to see from each GNAT release not only neat new features, but also
a general improvement in reliability, correctness and robustness.
Robert Dewar
Ada Core Technologies
Chris Morgan
James Rogers wrote:
[SNIP]
> Perhaps it is time to remove some conflict from the ACT charter.
> It seems the only way to do this is to either find a continuing
> source of funding for development and maintenance of GNAT, or to
> find some alternate group to perform maintenance of a public
> version of GNAT, effectively creating a separate version from the
> product produced by ACT.
With respect I think this is a load of nonsense!
You can get a copy of a working GNAT for dozens of platforms including
almost all the important ones. You can even get the source code and
build it yourself. And you are legally allowed to give those items to
anyone else you please. If you find a bug you can report it to the
maintainers and generally any real bug that might affect the paying
customers of ACT gets fixed pretty damn quickly, whilst _all_ bugs are
at least noted. Given all this, the fact that the sofware is actually
still being actively (and if I may say so very rapidly) by a single team
can only be a bonus as far as I'm concerned. I speak as someone who
recently got GNAT authorised for some work at a large British defence
contractor. I've since changed jobs but I understand they're moving to
using it even more widely.
Please don't take any offence at this, and in fact feel free to write me
and discuss it privately, but really until you demonstrate anything
really holding back any unsupported GNAT users you have no case.
Chris
--
Chris Morgan <mihalis @ ix.netcom.com>
"Once upon a midnight dreary, while I pondered, weak and weary,"
James S. Rogers
Chris Morgan wrote:
>
> James Rogers wrote:
>
> [SNIP]
> > Perhaps it is time to remove some conflict from the ACT charter.
> > It seems the only way to do this is to either find a continuing
> > source of funding for development and maintenance of GNAT, or to
> > find some alternate group to perform maintenance of a public
> > version of GNAT, effectively creating a separate version from the
> > product produced by ACT.
> [SNIP]
>
> With respect I think this is a load of nonsense!
After having a private email conversation with Robert Dewar I must
agree.
Having been the misguided soul who started this thread, I also want
to point out how absurd my earlier statement was.
I hope I have learned a valuable netiquette lesson here.
I am not interested in seeing some watered-down version of GNAT.
I am also not interested in demanding the premature release of any
software from ACT, or any other vendor.
ACT is doing the Ada world a great service in their work to develop
and maintain GNAT. It would be a disservice to ACT and to ourselves
to expect or demand the release of any compiler version which is not
yet ready for general public distribution.
As we all know, software support is an expensive service. This puts
an extra burden upon anyone trying to release high quality software
to the public, at no cost to the public. The only way to avoid
support costs is to deliver software with very low support needs.
If some corporation or individual is willing to pay ACT for support
costs we should applaud, not jeer. The entities paying ACT for
support of "early" releases are also paying the costs which will
speed the release of the same software (including many bug fixes in
most cases) to the general public.
Does this put the general public at a disadvantage? Of course not.
Only someone who has gotten used to the Microsoft practice of releasing
products prematurely would even begin to assume that there was any
advantage to getting the earliest versions of any software. It is
always safer to work with proven code than unproven code. The ACVC
does not test all aspects of a compiler's quality or usability.
Much of that sort of testing must be done in real-world situations.
With ACT and GNAT we, the general public, are fortunate to have
a situation where we get high quality compilers at no cost while
others pay the actual development costs.
If one of us really needs newer versions of GNAT ealier, then that
person or company must assume the financial responsibility associated
with access to the newest versions. However, do not think that you
will have exclusive access to a particular version of GNAT, or even
to a particular bug fix. The money you pay will benefit you in by
delivering fixes to you quickly. It will benefit the rest of us by
delivering us high quality code in due time.
Jim Rogers
Colorado Springs, Colorado
--------------------------
Team Ada
Michael F Brenner
The part I agree with is that it would be useful to the entire Ada
community to see bugs tracked in public, along with the programs
that failed. The failed programs are actually more useful, because
they can be used to test other baselines. The hard part is getting
someone to volunteer their network and disk space and time to keep
such a useful information system going. The other hard part is
to have the COMMUNITY test the submissions against all commercial
and free compilers, analysis tools, year 2000 tools, automatic
change tools, language-sensitive text editors, metrics tools,
reverse engineering tools, re-engineering tools, data flow diagrammers,
program flow diagrammers, cohesion tools, and coupling tools. Of
course, the COMMUNITY would then report any thusly discovered bugs
to their respective tools. Kind of like what the validation suite
started out to be, but could not become, because the market
remained too small.
I would personally contribute one hour a week to testing on the
various tools I have on my home PC. Who will donate the network
and disk space? Who will maintain the reporting site? Who else
will volunteer to test against various tools as this accumulated
data grows? Who will update the data as various tools fix their
bugs? Who will close the bugs for each tool when appropriate?
Larry Kilgallen
It seems to me bug reports can only be fully closed by the originator.
Although an independent "consumer reports" activity for Ada tools
would be valuable if it worked, there are plenty of of possible
pitfalls. It seems to me, however, this is a subject much more
worthy of discussion than a volunteer parallel development effort
on GNAT.
Larry Kilgallen
Chris Morgan
James S. Rogers wrote:
>
> > With respect I think this is a load of nonsense!
>
> After having a private email conversation with Robert Dewar I must
> agree.
>
> Having been the misguided soul who started this thread, I also want
> to point out how absurd my earlier statement was.
>
> I hope I have learned a valuable netiquette lesson here.
I don't think you violated netiquette. It's fine to discuss these things
here and in fact in the past many of the discussions have led to useful
developments (e.g. the original discussions on wanting to have a GNAT
mailing list). Your post was thus properly "formed" but had some deeper
problems, it was thus a semantic error not a syntactical one :-)
I too have sometimes wanted GNAT releases before they were public but on
balance it's a good thing ACT do what they do. I spent some time as
technical representative of a project that had fully paid-for ACT
support. I found the ACT support to be better than that of most other
software companies, certainly as good as any other support we ever had.
Now I'm on the outside again sure I'll sometimes think "I wish I could
lay my hands on version x.x" (in fact I'm quite interested in the gdb
improvements and the SPITBOL-like string handling library in 3.10) but I
know that releasing it prematurely could delay 3.11, so on balance I
don't want it until it _is_ ready.
Roy T. Fielding
[regarding the notion of a publically maintained problem tracking system
for GNAT] de...@merv.cs.nyu.edu (Robert Dewar) writes:
>This might appeal to the hobbyists in the Ada community who are happy to
>fiddle with a stream of uncoordinated and insufficiently tested patches,
>but it would be inimical to the interests of the wider Ada community
>that needs reliable products. The need for reliability extends both
>to paying customers, and perhaps even more to those who rely on free
>public versions, which they must use without much support.
>
>Even for those who do know the technology well, formulating a correct
>fix to a problem is not easy. We get a stream of suggested fixes from
>people who know GNAT pretty well. In nearly every case, the person
>has correctly identified a problem, but produced a fix that is either
>incomplete or plain incorrect.
You jump from one assertion to another without any basis. If you classify
myself and my customers as the "hobbyists in the Ada community", then
it might be true that we are capable of fiddling with streams of
uncoordinated and insufficiently tested patches. We are rarely "happy"
to do so, and would obviously prefer coordinated and sufficiently tested
patches, but when the choice is finding and fixing a bug or postponing
a project until ACT makes a public release, the choice should be obvious.
A public tracking system lets us share that work instead of each doing
it individually.
Does this impact reliability? Yes, but only in a positive way.
If the fix is wrong, it will be corrected and the correction attached
to the initial report. That is one of the advantages of a tracking system
over just posting reports and fixes to netnews or a mailing list.
>I don't know quite what makes you think that GNAT development is
>haphazard, but let me give some idea of how we proceed internally.
I didn't say it was. I said that, in order for a separate Ada95
compiler project to succeed, it would need to be less haphazard than the
existing GNAT development process, regardless of whether it was done
by a corporation, a joint support contract, or a community of volunteers.
There is no correlation between community-based development and haphazard
development processes, which is what the poster implied. However, there
is often a correlation between haphazard development processes and the
success of a competing project.
>...
>Note that this kind of regression testing is out of reach of informal
>fiddling. For one thing, the great majority of the code in the critical
>regression suite is proprietary, for example it includes large chuncks
>of the DEC test suite, as well as a lot of customer code, that the
>customer has been willing to entrust to us only on the basis that
>we will carefully protect it. It is also the case that the configuration
>control that is needed requires very strong control and management.
Obviously, someone who was "fiddling" wouldn't be running regression tests
on bugs that they have never encountered. However, there is nothing
stopping a community from building a community-supplied and public
database of test cases that surpassed any private database. It takes
work and real people to support it, but to say that it can't be done is
just foolish.
Besides, there is nothing preventing ACT from testing the provided fixes,
or providing its own patches which have been tested against your private
regression and build process. The choice of whether or not to do so
would depend on whether or not you are interested in supporting the
community beyond mere releases. In any case, such a project would not
be dependent on ACT's support, nor would it be subject to ACT's approval.
>You need to remember that the entire thread here develops from one
>individual who is demanding to get a version of GNAT that we do not
>think is ready to release. Yes, of course, we all want 3.10 to be
>finished and out there as soon as possible. We have a team of people
>working full time towards that goal, and all I can say is that we
>simply will NOT release 3.10 before we feel it is ready for release,
>no matter how loud people yell.
That is, in my opinion, ACT's prerogative. However, I also know that it
is detrimental to my work, and thus negatively impacts my customers.
We are getting a bit tired of telling DARPA and the AJPO that our software
works fine on private versions of GNAT, but has never run under a publically
released version of the GNAT compiler. If the wavefronts were named and
publically released, then we would have a means of tracking changes
to the compiler and running our own build tests, and a means of indicating
to our customers what is necessary to compile our software. It doesn't mean
that we would always run such tests, just that we would have a *choice*.
Furthermore, it would give us (and others) the chance to identify problems
before the stable release.
>The idea of a public tracking system for GNAT bugs is unworkable in
>practice. Why? Because the majority of code involved in such reports
>is proprietary, and there is no way that the proprietors of such code
>will post it. We quite often get bug reports that contains tens or
>even hundreds of thousands of lines of such proprietary code.
Obviously, the code placed in the reports of a public tracking
system would have to be public. There is no requirement that the public
tracking system contain all of the data from your private reports, nor
that it even contain all of the known problems. It doesn't have to be
perfect in order to be useful. What it provides is a focal point,
which is something that ACT doesn't even provide its paying customers.
>I think a big difference here is what your view of the community is.
>You see the community as a group of energetic hobbyists who want to
>play with the latest versions of GNAT, develop and trade patches, etc.
>
>We see the community as a group of serious users who need stability
>and reliablity, and are not interested in always trying out the latest
>patches and new features. Our customers are often quite reluctant to
>switch to new versions, and that makes perfect sense to us.
I see the community as containing both types of users, and would prefer
that both be given the choice of receiving stable releases and unstable
releases. You claim that giving non-customers wavefront releases will
make support impossible, but you don't provide support for non-customers
in any case (even less than most free software projects provide free
support). Instead, you claim to know what is best for us, and thus the
right to choose for us. That is the real source of our disagreement.
>I do not know if Roy is subscribed to ch...@gnat.com, as far as I can
>tell he is not, but I am not sure I am checking the right address. The
>idea of ch...@gnat.com is to develop to a small extent some aspects of
>this informal community.
I read the hypermail archive periodically. Building a community requires
more than just communication; it requires a common purpose and the ability
to contribute to that community, with the tangible results being visible
to the rest of the community on a near-immediate basis. I'm not even sure
that such a community is possible in the Ada95 world (lack of people is
the primary concern), but I do know what is currently making it impossible.
Don't be fooled into thinking that these are just off-hand remarks.
I have been building such communities for the past four years as part of
my research in software engineering. Right now the most significant
difference between the Ada95 world-view and the world-view of languages
such as Java, Perl, and Python is this self-crippling notion that a
secrecy is necessary to control a software project and to provide high
reliability. In my opinion, Ada95 will have no future unless it makes
community-based development *easier* than it already is for other languages.
It needs to be easier because Ada95's language entry-barrier is already
much higher than other languages.
>Sure, I understand the frustration of the enthusiasts who would just love
>to get their hands on the development version every day and fiddle, but
>I am afraid their interests must take second place to the needs of the
>Ada community that is interested in stable and reliable products and
>wants to see from each GNAT release not only neat new features, but also
>a general improvement in reliability, correctness and robustness.
If that is your definition of "enthusiasts", then I'd say I am not one.
My first priority is that the compiler compile, and the real-time system
support, Ada95 as defined by Ada95. After that comes support for debugging,
particularly on multithreaded code. After that would be an easier
installation process, but I understand that is primarily constrained by
the intertwining with GCC. In short, I want reliability, correctness and
robustness, but do not believe the best way to obtain it is through a
closed development process. Proprietary projects have to live with those
shackles; we don't.
Everything I have suggested has been demonstrated to improve reliability,
correctness and robustness on other software projects. It also tends
to improve design for extensibility and portability, and in general
results in more people being actively involved in using the product
and producing related software. These characteristics can be seen in
libwww-*, Apache, Linux, FreeBSD, SSH, etc. If you think you understand
the nature of software engineering and the limitations of software
development processes better than I do, then you can disregard my comments.
However, you have a long way to go before you can understand the needs
of my customers.
...Roy T. Fielding
Department of Information & Computer Science (fiel...@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-1715
http://www.ics.uci.edu/~fielding/
Larry Kilgallen
In article <5ps4eg$b...@kiwi.ics.uci.edu>, fiel...@kiwi.ics.uci.edu (Roy T. Fielding) writes:
> [regarding the notion of a publically maintained problem tracking system
> for GNAT] de...@merv.cs.nyu.edu (Robert Dewar) writes:
>
>>This might appeal to the hobbyists in the Ada community who are happy to
>>fiddle with a stream of uncoordinated and insufficiently tested patches,
>>but it would be inimical to the interests of the wider Ada community
>>that needs reliable products. The need for reliability extends both
>>to paying customers, and perhaps even more to those who rely on free
>>public versions, which they must use without much support.
It seems to me that what you quote from Robert, and what you say in reply,
(mostly not quoted here), goes not to the issue of a "publically maintained
problem tracking system" but rather some sort of volunteer bugfix exchange.
Those two are worlds apart. Please do not tar the notion of a "publically
maintained problem tracking system" with the same brush of practicality
debates as a bugfix exchange. Note that a problem tracking system can
work for multiple Ada products, with no regard to whether sources are
public.
Larry Kilgallen
Robert Dewar
Michael Brenner said
<<Michael Brenner: >>Towards a free GNU Ada 6 Jul 1997 20:06
The part I agree with is that it would be useful to the entire Ada
community to see bugs tracked in public, along with the programs
that failed. The failed programs are actually more useful, because
they can be used to test other baselines. >>
Robert replies
The great majority of programs that we get are proprietary code that
we protect extremely carefully.
Public posting of this code is out of the question.
It would be possible to have some scheme of identifying code that could be posted,
but providing such a public tracking system for all bugs would take a lot
of extra work, and is not somethinfg that we could do unless someone paid for the time involved.
Volunteer help would not useful in this task. Bug tracking requires
very careful management and contro,l, it is not
something that can be done in a haphazard manner.
Roy T. Fielding
In <1997Jul8.071610.1@eisner>
kilg...@eisner.decus.org (Larry Kilgallen) writes:
>It seems to me that what you quote from Robert, and what you say in reply,
>(mostly not quoted here), goes not to the issue of a "publically maintained
>problem tracking system" but rather some sort of volunteer bugfix exchange.
No, I was talking about a problem tracking system -- something that let's
people record a problem and a sequence of replies or fixes to the problem
such that everyone can see the problem report and its status. Not all
reports would result in a bugfix. Mailing lists are sufficient to exchange
bug fixes, but not to track problems.
>Those two are worlds apart. Please do not tar the notion of a "publically
>maintained problem tracking system" with the same brush of practicality
>debates as a bugfix exchange. Note that a problem tracking system can
>work for multiple Ada products, with no regard to whether sources are
>public.
Yes, just as it is possible to fix a problem without providing a patch.
Making a distinction between the two is pointless.
....Roy
Roy T. Fielding
>The part I agree with is that it would be useful to the entire Ada
>community to see bugs tracked in public, along with the programs
>that failed. The failed programs are actually more useful, because
>they can be used to test other baselines. The hard part is getting
>someone to volunteer their network and disk space and time to keep
>such a useful information system going. The other hard part is
>to have the COMMUNITY test the submissions against all commercial
>and free compilers, analysis tools, year 2000 tools, automatic
>change tools, language-sensitive text editors, metrics tools,
>reverse engineering tools, re-engineering tools, data flow diagrammers,
>program flow diagrammers, cohesion tools, and coupling tools. Of
>course, the COMMUNITY would then report any thusly discovered bugs
>to their respective tools. Kind of like what the validation suite
>started out to be, but could not become, because the market
>remained too small.
>
>I would personally contribute one hour a week to testing on the
>various tools I have on my home PC. Who will donate the network
>and disk space? Who will maintain the reporting site? Who else
>will volunteer to test against various tools as this accumulated
>data grows? Who will update the data as various tools fix their
>bugs? Who will close the bugs for each tool when appropriate?
I think you are right on the mark, but it is also important not to
try to do too much at once. The most difficult thing, aside from finding
volunteers, is setting up the archive such that many people can edit
it remotely, and without the pain of remote interaction. That means
setting up a shared repository with the equivalent of remote CVS access,
using something like SSH to enable access via public key, and maintaining
three mailing lists (announcements, discussion, and repository-changes).
I would also add Apache+PTS to provide Web and e-mail interfaces to a
problem tracking system. In essence, this is the same setup required to
run a community-developed software project, which is no surprise given
that an archive is just another form of software.
Someone with a long-term commitment to Ada95 would be needed to
setup and administrate the site. Note, however, that it doesn't
have to be the same person/organization that is maintaining the archive.
....Roy
Ronald Cole
de...@merv.cs.nyu.edu (Robert Dewar) writes:
> The current
> discussion is simply about whether we should wait to publicly distribute
> versions of GNAT until we feel that they are in sufficiently good shape
> to distribute, given that many or indeed most people will be using these
> versions without support. We strongly feel that the premature distribution
> of versions of GNAT would be harmful to the Ada community, and from both
> the public postings here, and many private email messages I have received,
> I have the impression that most people support this position.
> At no time do we distribute subset or crippled versions of GNAT. When
> we make public distributions, we are distributing the latest version,
> which includes our full technology. If you have got some other
> impression, you are very much mistaken.
Gee, I thought you had said that your policy is to only release
stable, well-tested versions of GNAT publicly. Of that I'm not
mistaken!
In fact, you did the HPUX community a great disservice by releasing
3.09 with a "latest-version" gcc-272.dif file that contained patches
that were far from well-tested.
> As I mention above, the issue
> in the current thread has been whether ACT should publicly distribute
> versions of GNAT that it does not feel are ready for public release.
> We don't think this is a good idea.
Neither do I, which is why I bitched in the first place. And as I
stated earlier, I'll reserve further comment until 3.10 is released
publicly.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <ron...@ridgenet.net> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My PGP fingerprint: E9 A8 E3 68 61 88 EF 43 56 2B CE 3E E9 8F 3F 2B
Robert C. Leif, Ph.D.
From: Bob Leif, Ph.D.
To: Robert Dewar, Ph.D., James Rogers, and Comp.Lang.Ada
On Thu, 3 Jul 1997 08:28:20 -0600
James Rogers posted several suggestions on how to improve GNAT's long term
success. I supported and still support his second suggestion:
2. * Form a consortium of GNAT users, with annual dues which will be paid
to ACT to provide public support for GNAT.
Robert Dewar has been critical of my suggestions as to how to increase
ACT's revenues.
I suspect that many of us, at present, who use GNAT would like to
compensate ACT. However, ACT's pricing structure is an example of what I
like to call the human nature boolean type, too much or too little.
Robert Dewar quoted me .
Date: Tue, 8 Jul 1997 10:19:18 -0400
From: Robert Dewar <de...@MERV.CS.NYU.EDU>
Subject: Re: Towards a free GNU Ada
Bob Leif said
<<
"I have only one problem with suggestion 2. I believe that any useful
additions to a compiler that are initially made for GNAT and are NOT funded
by ACT should be copyrighted in a form that they can be used by other Ada
vendors. This includes being incorporated into these vendors commercial
products. The cost to the other Ada vendors should be the same as that
bourn by ACT."
"In short, I believe that we small operators and independent users should
financially reimburse ACT, but at a reasonable price, and in a manner to
maintain competition in the Ada compiler business."
I feel that my comments speak for themselves. I will admit that part of
my reason for trying to find a means to compensate ACT was pure
self-interest. Money talks! ACT, like the vast majority of companies, has
to put most of its energies into supporting its paying customers. In the
past, one of the reasons for Ada not achieving the market share it deserves
was the marketing focus on UNIX rather than DOS and now Windows 95. ACT's
business model appears to be directed to the Work-Station vendors rather
than the mass Windows and, at present, Macintosh market.
I deliberately took my discussion with Professor Dewar off-line. Firstly,
to clarify the facts and secondly there has been more than enough
extraneous material in Comp.Lang.Ada.
My final private question and comment was: "What is the usage of the
different versions of the GPL including the unmodified GPL by the Academic
community? I believe that most of us who have reservations about the
unmodified GPL applaud the work by you and others to promote the use of
modified GPLs."
Now concerning my own code and that of my client. Firstly, I have not
decided what to do with the Generic_Money package which I am creating. I
do not know whether it will work. I created it only because I felt that
the code that had to be prepared in a very short time for Object Magazine
(R. C. Leif, T. Moran, and R. Brukardt, "Ada 95, The Language Speaks for
Itself", Object Magazine, Implementation Languages, 7 (3) pp. 32-39, May
(1997) should be redone in a true object oriented manner.
I am forced to use GNAT because the other Ada vendors for Windows have not
completed the Information Systems Annex. I still believe that one of the
weakest points of all of the Ada compilers that I have used is the error
messages. I applaud Professor Dewar's suggestions about future
improvements and encouraged him concerning their commercial utility. I
suspect that the messages from other languages may be worse than Ada's.
However, because Ada finds errors at compile time, problems with error
messages become obvious.
As for my client, the release of the sources is totally the client's
decision. I actually favor release of source code wherever possible and
have been the most vociferous member of the AdaSage Engineering and
Management Group concerning this subject. It is an excellent business deal
to give your customers the opportunity to fix and improve your product.
One great commercial advantage of Ada is that there is an excellent,
traditional compromise solution. The package specifications can be
published independently of the bodies and these specifications can serve as
a very important part of the documentation.
Robert C. Leif Ph.D.
Vice President Ada_Med, a Division of Newport Instruments
(619)582-0437
Robert Dewar
<<I am forced to use GNAT because the other Ada vendors for Windows have not
completed the Information Systems Annex. I still believe that one of the
weakest points of all of the Ada compilers that I have used is the error
messages. I applaud Professor Dewar's suggestions about future
>>
A very odd comment, we have received almost no input from you commenting
on specific error messages. To me, GNAT's messages are among the best I
have seen from a compiler, and we put a huge amount of effort into them,
aided greatly by users who submit cases where messages could be improved
(special thanks to Mars Gralia here).
Don't just be a non-constructive complainer!
Send along examples where you think messages can be improved!
<<Robert Dewar has been critical of my suggestions as to how to increase
ACT's revenues.
I suspect that many of us, at present, who use GNAT would like to
compensate ACT. However, ACT's pricing structure is an example of what I
like to call the human nature boolean type, too much or too little.
>>
To run a company like ACT costs well over a million dollars a year, running
any small business is not an inexpensive operation. FOr the kind of support
we provide our customers, the prices we charge are highly competitive.
Yes, I know that people would like to think that they could get full GNAT
support for very modest sums (a while ago someone suggested that ACT should
provide a service where bugs would be fixed for $20 a piece -- enough to
pay for about 15 mins of time -- which of course is way off.
<<2. * Form a consortium of GNAT users, with annual dues which will be paid
to ACT to provide public support for GNAT.
>>
This is not an unreasonable proposal, but our guess is that there are not
enough users, and/or they are not willing to contribute enough, for this
to be worth our while (the conversation I referred to, the $20/bug one,
was enthusiastically followed up by lots of people saying, yes that would
be great!)
The other trouble is that we really work by guaranteeing our customers
a level of support that guarantees success. This is not inexpensive, but
it is worth it to those who need it, and the resulting costs are still
mcuh less than many competing technologies. Any kind of partial low level
support would not meet this goal.
There is also a real danger that serious users would try to get by on
this lower cost partial support, run into troubles, and end up frustrated
at GNAT in particular and Ada 95 in general. This is not a desirable outcome
for anyone.
Furthermore, these days, a great deal of our support activities are not
related to bug fixing, but rather answering peoples questions abo0ut how
to use GNAT and how to use Ada 95. In the context of the large applications
that people are developing, this can be a time consuming and costly operation.