GNAT 3.01 Source For OS/2

GNAT 3.01 Source For OS/2

[jschafer1]

I have been recently working with the source code for GNAT 3.03 on OS/2. I
have found SEVERAL problems with this code.  In fact I have Ada units that
compiled on the older 3.01 compiler but will now not compile on he 3.03
compiler.

Does anyone know where to get a copy of the 3.01 source for GNAT ????  I
need it to figure out what changes where placed into 3.03 that now make it
unusable.

I wouldn't have to make this request if ACT would get it's ACT together.  50
days now we have been waiting for an update from ACT.  WHERE IS IT ???
The problem is CLEAR.  If the 3.03 executables on cs.nyu.edu came from the
source code at the same site, THEY DO NOT WORK !!!!  If they DO work then
the 3.03 source on cs.nyu.edu was NOT used to produces them (i.e. They made
changes to get the executables and then didn't release the corrected source).

The reality is simple.  The GNAT 3.03 source code WILL NOT WORK.  There
are several cases of braindead code that causes Constraint_Errors in the
compiler.  In addition, there are other places where the code does not
initialize fields in the abstract syntax tree.  To make matters worse,  there
are several places where the code will not even pass it's own assertion
checks.  And several times it has died with segment violations, but if the
same unit is immediately recompiled, it compiles fine.

But the thing that irritates me the worst is the amount of memory the 3.03
version requires.  The 3.03 version creates literally hundreds of thousands 
of duplicate subtype declarations durring the expansion of the Ada code.  The
3.01 version compiles the unit fine WITHOUT these extra declarations and uses
less than 15 Mb of virtual space to store the nessisary 90,000 tree nodes. 
However on the 3.03 version, the same unit will require some 500,000 tree
nodes and uses upwards of 60 Mb of virtual space.

The thing that is really rediculous about all these extra nodes it that within
a given subprogram, THEY ARE ALL DUPLICATES OF EACH OTHER !!!!

But, enough ranting and raving.  I would really appreciate any help getting
hold of a copy of GNAT 3.01 source.  Even better if someone knew where a
copy of the source used to produce the GNAT 3.01 executables for OS/2 on
cs.nyu.edu could be found !!!!

Thanks In Advance !!!

Joe Schafer
jschafer@iquest.net

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

"jshafer1 said

"I have been recently working with the source code for GNAT 3.03 on OS/2. I
have found SEVERAL problems with this code.  In fact I have Ada units that
compiled on the older 3.01 compiler but will now not compile on he 3.03
compiler."

Sounds like you probably did not manage to build 3.03 correctly. That's
not surprising, it is tricky to do right. Certainly we have not experienced
the kind of symptoms you report (with either the OS/2 or other versions
of 3.03 and later development versions). Most likely they are artifacts
of an incorrect build. The best thing if you can would be to try out your
program on some other build of 3.03 and see if the problems persist. If
so, by all means report them to report@gnat.com.

We are hoping to get 3.04 out very soon, and as soon as it is out for
the major supported targets, then we will try to get an OS/2 version
out as soon as possible thereafter.

As I have explained before, the (actually rather surprising) lack of
interest in the OS/2 version from our customer base means that new OS/2
versions are not at the top of our priority list. There will be a new
version soon, because I am using it (as I said beore, if I ever decide
to switch from OS/2, that will be unfortunate :-)

It is certainly possible to find programs that will compile on 3.01, and
not on 3.03. We have a few reports of such regressions, and all have been
fixed at this stage, although undoubtedly there are some we have not
run into yet. Our testing process, which I described recently, minimizes,
but does not eliminate all possibilities of regressions.

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

"   It's not my job to go out and find bugs for YOU.  Ada Core Technology
simply screwed up 3.03.  Your 3.03 source on cs.nyu.edu WILL NOT WORK.
If you want me to go as far as specifing the exact lines of code that
are wrong I can do that !!!!  Do you REALLY want me to PROVE to the
open public that your 3.03 release is broken and CANNOT work ????
"

Well that makes it clear that something is very strange with what you
are doing. Of course all 3.03 releases are built with the 3.03 sources,
and of course they all compile their own libraries. Probably you are
just building in what for us is a non-standard way (for example it
is possible that you use different switches -- your example with the
Natural and -1 is clearly such an example, since the library is designe
to be compiled with checks off. Of course this is a (minor, not affecting
functionality) bug, which should be fixed. If you want to send us details,
we will be happy to look at it.

Regardng the actual subtypes, you are treadng in a very difficult area of
the compiler. IN general the additional actual subtypes are ESSENTIAL to
fix a number of critical bugs -- so your changes will cause a lot of
serious regressions. It is true that certain programs can generate
more code as a result. For us more code is less of a problem than wrong
code! In fact in 3.04, we have largely, but not completely eliminated
this impact, while retaining the proper functionality, which was not
easy to do.

It is certainly true that there were some regressions with 3.03. We know
of no way to guarantee that there will be no regressions, but we had
very few reproted, and for most people, the large number of bug fixes
and extra functoinality from 3.01 to 3.03 was desirable!

I think you would do better to report the bugs you find in a calm and
collected manner, rather than flail around trying to fix them yourself
when you don't fully understand the semantic implications of what you
are doing. The "ideots" [sic] at ACT might just possibly understand
some of the issues better than you do!

Regarding difs, we could certainly do this. They are large, probably
3.02 to 3.03 would be 10,000 lines of difs, many of them coming simply
from reformatting, comment changes etc. as well as technical changes.

You actually seem to understand a lot about the tehnology of GNAT. TOo
bad you can't operate in a more constructive mode, like many of the
other volunteers who help improve the technology. In particular, it
really would be helpful to have detailed bug reports, rather than
vague complaints. If you think you have a fix, by all means send it
along to us. Many people send us proposed fixes. Often they are not
quite right, but they are very helpful in pointing to the right fix.
Sometimes they are indeed right. The difficulty is that many things
interact subtly. Especially if you are not thoroughly familiar with
GNAT, and with Ada 95 semantics, then what seems like a simple fix
can in fact turn out to have subtle interactoins, as is the case with
the actual subtype stuff.

By the way, ACT always provies full source releases with binary releases.
We do not provide FTP access direct to ACT for other than our customers,
but the releases are on many public FTP sites, and they are certainly
free to keep old sources around. It certainly seems like it would be a good
idea if one of these sites would keep old sources around. Disk space is
not infinite at NYU, so this is probably not the best choice, but it is
hard to believe that some of the other sites that keep copies of GNAT
around do not have the disk space to keep old copies of the sources.

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

Jerry said

"   It's not my job to go out and find bugs for YOU.  Ada Core Technology
simply screwed up 3.03.  Your 3.03 source on cs.nyu.edu WILL NOT WORK.
If you want me to go as far as specifing the exact lines of code that
are wrong I can do that !!!!  Do you REALLY want me to PROVE to the
open public that your 3.03 release is broken and CANNOT work ????

   When I do that, the clear implication will be that ACT is NOT providing
the Configuration Management and Version Control that one would expect from
ANY Ada developer.  I will be proving that the 3.03 source and executable on
cs.nyu.edu DO NOT match."

"specifying the exact lines of code" that you think are wrong would of
course be helpful. Can you please send a copy of this to report@gnat.com,
where it is most helpful since then it is sure to get to the right person.

As for your claim that the 3.03 source and executables do not match. This
is quite wrong. I have no idea what leads you to this incorrect conclusion,
but all 3.03 versions are built EXACTLY from the 3.03 sources as 
distributed, and all compile their own libraries.

If you are having trouble duplicating this build, most likely you are
just not doing the build the same way we are. For instance, our stndard
options for compiling the compiler are -gnatap (assertions on, range
checking off). We turn range checking off because it is our experience
that with assertions on, the range checking does not find additional
real errors, but has been known to cause problems (as appears to be
the case in your build). Of course the case you found should be fixed,
but as you have undoubtedly found out, the issue here is one of choosing
right subtypes, not a functoinality issue, i.e. the 3.03 compiler behaves
fine as we build it in this respect. It is possible that some of your
other problems with the build come from similar cases, or not. Hard
to say without more details.

The OS/2 compiler does get completely built at least once a day. The
problem in getting releases out is packaging and testing. In the future,
we are going to release the OS/2 directly from my working version, which
should make it easier to get OS/2 releases out. Before we were rebuilding
a referene version on another machine for the release, and this is teh
step that was taking time, and not getting done due to its low priority.
The disadvantage of this approach is that we are less likely to track
changes in EMX, since there is no point for me to update EMX versions
if my development version is working fine. Of course if some volunteer
can help with putting things together with the latest EMX, we would
be more than happy to work with them.

Re: GNAT 3.01 Source For OS/2

[jschafer1]

Mr. Dewar,

   No YOU miss the point COMPLETELY.  There ARE extreemly basic
problems in the 3.03 code.  You have cases of functions that
return natural values and then your code attempts to return a -1
value.  It will die with a constraint error on ANY Ada compiler
unless you turn off range checking.

   Now since we are talking about the 3.03 source AND executables
on cs.nyu.edu.  I am saying that those executable did NOT come
from that source.  Saying that here is a 3.03 executable implies
if came from the 3.03 source !!!!  There is only 3 possiblities
here:

   1. Those executables DON'T work.  They pull the constraint error
        that WILL happen if the 3.03 source was used.

   2. Those executables DO work.  You patched the code and didn't
        release the changed code.

   3. Those executable Do work.  You compiled the compiler with
        range checks suppressed.

   But it's worse than that.  Once you get the compiler built and able
to compile code (by fixing the previous bug), you find out that it
cannot even compile it's own libraries.

   This time it turns out to be a problem of handling derived abstract
types.  Here some ideot decided that if the parent of the derived does
not have a discriminant constraint, there is no need to initialize the
discriminant constraint list on the derived type.  Needless to say this
leads to another constraint_error.

   The screwed up thing about this one is that the exact same unit (in
the Gnat library) compiles fine on the 3.01 compiler.  Somebody added
the "Present" check in 3.03 and made the compiler fail.  If this bug
was not fixed in 3.03 executables on cs.nyu.edu, you didn't compile 
the libraries with those programs.  This ain't some abstract problem.
3.03 can't even compile it's OWN LIBRARY.  This is pretty poor to say
the least.

   However it get's worse.  Some other ideot decided to have the 3.03
code generate subtype declarations for selected components of
unconstrained descriminated records.  It appears to have something to
do with getting an actual subtype instead of the nominal subtype.  The
problem with this braindead move is that it causes 3.03 to use FIVE TIMES
more memory for some units.

   The thing that is irritating is that simply replacing a call to
Get_Actual_Subtype in Analyze_Selected_Component with the code from the
same place in the 2.04 source fixes the problem and the compiler then
works fine.

   Now to address your reply to my Posting:

dewar.830403010@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>
>Sounds like you probably did not manage to build 3.03 correctly. That's
>not surprising, it is tricky to do right. Certainly we have not experienced
>the kind of symptoms you report (with either the OS/2 or other versions
>of 3.03 and later development versions). Most likely they are artifacts
>of an incorrect build. The best thing if you can would be to try out your
>program on some other build of 3.03 and see if the problems persist. If
>so, by all means report them to report@gnat.com.
>

    BULLSHIT.  The compiler is simple to compile.  If you think it's 
difficult to get 3.03 built you haven't worked on any large projects
before.  It took less than a day to get setup to compile GNAT it then
took 2 weeks to debug problems in YOUR code.

   It's not my job to go out and find bugs for YOU.  Ada Core Technology
simply screwed up 3.03.  Your 3.03 source on cs.nyu.edu WILL NOT WORK.
If you want me to go as far as specifing the exact lines of code that
are wrong I can do that !!!!  Do you REALLY want me to PROVE to the 
open public that your 3.03 release is broken and CANNOT work ????

   When I do that, the clear implication will be that ACT is NOT providing
the Configuration Management and Version Control that one would expect from
ANY Ada developer.  I will be proving that the 3.03 source and executable on
cs.nyu.edu DO NOT match.

   Insulting my intelligence by claiming that I built the compiler wrong
is only asking for trouble.  I am bring up the question of how appropriate
it is for a company that sells a validated ADA compiler on a limited
number of platforms to be the maintainer of GNU software on a large number
of platforms.

   I find it strange that the 3.03 compiler doesn't even work as good as
the 3.01 compiler.  I also find it strange that 3.03 requires a great deal
more memory than the 3.01 compiler.  Sounds like the quality of the freeware
version is going downhill.

>
>We are hoping to get 3.04 out very soon, and as soon as it is out for
>the major supported targets, then we will try to get an OS/2 version
>out as soon as possible thereafter.
>

    Yea I have heard this for a long time now.  I notice the "Try" in
the sentence about getting an OS/2 version out.  You said you would be
having releases for other platforms in the near future in the README file
on cs.nyu.edu.  But it's been 52 days now and you are talking about another
version.  You didn't even finish the job for 3.03.

    Are you ever going to start producing diff files to show us the 
difference between each version of your code.  MIT does this with GCC,
Is there some reason ACT can't even live up to MIT's standards ???

    Look, the WHOLE REASON for the original posting was to get 3.01 source
so I could pin down what changes you made to 3.01 to turn it into 3.03.  I
was tring to get ACT's buggy code to work.  But for some reason, after ACT
took over GNAT older versions of executables and source where removed from
the cs.nyu.edu immediately after the 3.03 code was there.  Is ACT just to
cheep to pay for the disk or is there some OTHER reason we can't get the
older versions of source anymore.  

   In fact to fix your memory problem I had to go to a CD-ROM in Belgium and
get a copy of 2.04 source.  Then I was able to get your compiler to work by 
removing code that was added somewhere between 3.01 and 3.03.

   So once AGAIN. Directed directly are you Mr Dewar,  WHERE can I get a copy
of 3.01 source so I can find the set of changes YOUR company made to the GNAT
source ??????   Or is there something you are tring to hide ??????

>
>As I have explained before, the (actually rather surprising) lack of
>interest in the OS/2 version from our customer base means that new OS/2
>versions are not at the top of our priority list. There will be a new
>version soon, because I am using it (as I said beore, if I ever decide
>to switch from OS/2, that will be unfortunate :-)
>

   So I am suppost to be impressed by the fact you use OS/2 ????  SO WHAT.
I do too.  So do a lot of people.  You sound like you are running a business.
Big deal.  Running a business and maintaining freeware code are two totally
incompatable things my friend.  My biggest complaint is about the dis-service
the Ada community is getting with ACT maintaining GNAT.

>
>It is certainly possible to find programs that will compile on 3.01, and
>not on 3.03. We have a few reports of such regressions, and all have been
>fixed at this stage, although undoubtedly there are some we have not
>run into yet. Our testing process, which I described recently, minimizes,
>but does not eliminate all possibilities of regressions.
>

   If your quality controls result in 3 count 'em 3 show stopper bugs
introduced by moving from 3.01 to 3.03, I guess we should feel LUCKY
that 3.03 only introduced 3 bugs.  I'm just saying the quality of your
quality controls are extreemly lacking.

   And the "certainly possible to find program" line of your reply is
laughable.  Try looking at your own libraries for GNAT !!!!  Or is it
that you have been working with a patched version of 3.03 since you 
released the 3.03 source and haven't been kind enough to release the 
patched version to the rest of the Ada world ????

Joe Schafer 
jschafer@iquest.net

P.S. Just so you are INFORMED, I now have a functioning 3.03 compiler on OS/2.
     It is built on Emx 09b and so far has passed all my testing.  If people
     begin to ask for it, I WILL be giving it to them along with EXACT
     specifications of how ACT screwed up.  Or did you not notice the off
     hand comment about ACT getting it's ACT together in my first posting ???

     Once you get the 3.04 source out, I will compile it to get an OS/2 copy
     I could care less if ACT maintains the OS/2 version of GNAT.  But if I
     have to hassle with your 3.04 code like your 3.03 code, The whole Ada
     community is going to hear about it !!!!  As you MIGHT have guessed, I
     am not really happy with ACT at the momment.  I SURELY would NOT buy
     any of your products !!!!  Big Big quality control issues are not resolved.

Re: GNAT 3.01 Source For OS/2

[Dale Pontius]

In article <DqIBno.2E7@iquest.net>,
        jschafer1@iquest.net writes:
>
>(many things)
>
I tried once to send this to you by mail, but iquest.net bounced it
back to me, saying:

|------------------------- Message log follows: -------------------------|
 no valid recipients were found for this message
|------------------------- Failed addresses follow: ---------------------|
 <jschafer1@iquest.net> ... unknown user
|------------------------- Message text follows: ------------------------|

So I'm not sure how to say this to you, privately. Then I was going
to let the whole thing slide by. But now I'm in the reluctant position
of donning the 'net police' hat, which I don't feel qualified or
selected for. Attempted mailing follows:

In article <DqBxv9.GBL@iquest.net>,
        jschafer1@iquest.net writes:
>I have been recently working with the source code for GNAT 3.03 on OS/2. I
>have found SEVERAL problems with this code.  In fact I have Ada units that
>compiled on the older 3.01 compiler but will now not compile on he 3.03
>compiler.
>
etc...

Please, tone it down just a little. OS/2 users have gotten quite a
name for being 'rabid', and if we want more respect we have to stop
it. Your post is not one of the eyeball-frying variety that I've
seen elsewhere, but IMHO it does come on just a little strong. I've
no gripes with what you're saying or the legitimacy of your gripe,
I just ask that you say it in a more reserved fashion.

(Chronologically, this follows Robert Dewar's response...)

Robert Dewar has said that he has OS/2 GNAT 3.04 running on his
machine for some time. Hopefully it will get released sometime soon.
In the meantime, there are NO paying GNAT OS/2 customers, so we get
our 'nearly timely' ports by his good graces. I had planned to look
into becoming a paying customer after my current chip design is
submitted to fabrication, but with the recent fall in DRAM prices
our management has again tightened the purse strings. Oh well, prices
are supposed to rebound in the second half of the year. Maybe then.
This is an amusing situation for me, as both a producer and consumer
of DRAM. I hardly know what to wish for.

Dale Pontius
(NOT speaking for IBM)

Re: GNAT 3.01 Source For OS/2

[-Laurent Gasser]

In article 830621366@schonberg, dewar@cs.nyu.edu (Robert Dewar) writes:
> ... For instance, our standard
> options for compiling the compiler are -gnatap (assertions on, range
> checking off). We turn range checking off because it is our experience
> that with assertions on, the range checking does not find additional
> real errors, but has been known to cause problems (as appears to be
> the case in your build).

I am quite surprised to hear it.  To me, Ada meant higher quality in code
due to more internal checking.  And you purposely turn these checks out!

Could it be possible to apply to GNAT the very rules we are all trying to 
defend in favor of Ada? (Higher safety due to more automatic checkings.)

Laurent Gasser (lga@sma.ch)
Computers do not solve problems, they execute solutions.

Re: GNAT 3.01 Source For OS/2

[jschafer1]

On 27 Apl 1996 12:19:57 -0400 dewar@cs.nyu.edu (Robert Dewar) wrote:

> If you are having trouble duplicating this build, most likely you are
> just not doing the build the same way we are. For instance, our stndard
> options for compiling the compiler are -gnatap (assertions on, range
> checking off). We turn range checking off because it is our experience
> that with assertions on, the range checking does not find additional
> real errors, but has been known to cause problems (as appears to be
> the case in your build). Of course the case you found should be fixed,
> but as you have undoubtedly found out, the issue here is one of choosing
> right subtypes, not a functoinality issue, i.e. the 3.03 compiler behaves
> fine as we build it in this respect. It is possible that some of your
> other problems with the build come from similar cases, or not. Hard
> to say without more details.

  I won't even go into the STUPIDITY of building with range checks off.  What
I WILL ask is: "So how did ACT programmers get so God-like that they have
deemed that a MAJOR feature of Ada just gets in the way so it won't get used" ??
By any chance did your staff learn Ada as a second language after learning
high level assember (i.e. C or C++) ????  ACT is the first group I have ever
seen in the Ada community that ballsy enough to admit that thier code worked
with range checkes off and failed with them turned on !!!!!

  But to hit the nail on the head, explain why your Makefile in the 3.03 source
is setup to use "-gnata -gnatg" ????   Was the "-gnatap" some secret that an
ass like me needs to beat out of you ????  It does explain a few things
however.

  Now I guess the emphisis must shift to tring to convince you that the code
should compile and work correctly reguardless of the settings for the
range checking.  Normally for most Ada people, this means that when you
turn off range checks, the code still works.  The argument I may need to
pursue is the converse argument: When the checks are turned ON the code
should continue to work too.

  The only possible argument for REQUIRING range checks off is due to dweeb
coders who make fundamental mistakes like using Constraint checks to see if
a value is in range or not.  You can eliminate this problem by removing range
checking.  But it's a rather drastic thing to do when a little coder training
would be MUCH more cost effective.

> The OS/2 compiler does get completely built at least once a day. The
> problem in getting releases out is packaging and testing. In the future,
> we are going to release the OS/2 directly from my working version, which
> should make it easier to get OS/2 releases out. Before we were rebuilding
> a referene version on another machine for the release, and this is teh
> step that was taking time, and not getting done due to its low priority.
> The disadvantage of this approach is that we are less likely to track
> changes in EMX, since there is no point for me to update EMX versions
> if my development version is working fine. Of course if some volunteer
> can help with putting things together with the latest EMX, we would
> be more than happy to work with them.

  Try installing EMX09b's minimum set.  Then install GNAT 3.01 but be carefull
NOT to overwrite the gcc.exe executable or the gcc.a file.  The ones in the
GNAT 3.01 executables for OS/2 are specific to EMX09a.  And luckily, Eberhard
Mattes is kind enough to provide a gcc.exe in EMX09b that supports GNAT.  After
you build the 3.03 version, you MAY want to use the newly created gcc.exe
however.

   About the only other problem you will run into is building the GCC parts of
the compiler.  I started with the original GCC 2.7.2 source and Binutils from
MIT and your 3.03 source.  Then by applying the EMX patches to the sources
I was easily able to build the GCC compiler to get the .o files needed for the
backend of GNAT.  Building GAS was nearly effortless.

  I excluded the bounds checking for C but that could be added easily.  All
GNAT would need was an extra .o file or two when building gnat1.

  The only outstanding problem with EMX has to do with a resource locking 
problem.  It doesn't stop the compiler from working it just stops the user
from running two copies of the same physical executable at the same time.  I
will be researching this as time allows, but it is not a real problem on
a single user system like OS/2.

   I am beginning work on testing an optimized version of GNAT 3.03.  Earlier
tests has problems.  We'll see what happens.  I'll let you know what I run
into.

   What do you need to move up to EMX09b?  I currently have 3.03 working on
OS/2 Warp with EMX09b.  Of course, you haven't convinced me that the subtype
declaration issue is resolved, so my version does NOT eat as much memory as
a standard GNAT 3.03.  I don't see anything broken because the extra subtype
declarations are not there.

   I could sure use an explanation that defines specifically why these subtype
declarations are needed.  And of course, as always, at the title of the
thread states, "A copy of the 3.01 source would be REALLY nice".

Joe Schafer
jschafer@iquest.net   

Re: GNAT 3.01 Source For OS/2

[jschafer1]

On: 27 Apl 1996 11:53:09 -400 dewar@cs.nyu.edu (Robert Dewar) wrote:

> Well that makes it clear that something is very strange with what you
> are doing. Of course all 3.03 releases are built with the 3.03 sources,
> and of course they all compile their own libraries. Probably you are
> just building in what for us is a non-standard way (for example it
> is possible that you use different switches -- your example with the
> Natural and -1 is clearly such an example, since the library is designe
> to be compiled with checks off. Of course this is a (minor, not affecting
> functionality) bug, which should be fixed. If you want to send us details,
> we will be happy to look at it.

   O.K.  You asked for it.  First of all the return a value out of range
problem.  This problem is in the compiler itself.  Take a look at the 
Table package.  The generic parameters ask for an index range for the
table and an low bounds for the array.  Inside the package this type is
ignored and an integer value is used to keep track of the low bounds and 
number of elements currently used in the table.  When the package is
elaborated the internal variable "Min" is initialized to
Int (Table_Low_Bound).  When a table gets initialized, the "Last_Val" 
variable gets initialized to "Min - 1".

   Now for the problem.  Concider what happens when the "Last" operation
is called immediately after a table is initialized.  It returns the value
"Table_Index_Type (Last_Val)".   But since Min is equal to Table_Low_Bound
and Last_Val is one less, by DEFINITION, the call to the "Last" operation
MUST FAIL !!!!!

   Since I have defined the problem, I better tell you where it is a killer.
Now look at the instantiation of the Table generic in the errout package 
named "Warnings".  Because it's range is Natural and it's low bound is 0
this is a potential problem.  Where it becomes a REAL problem is at the
end of reading the source code for a file, when any warnings are turned on
again.  Take a look at the call to Set_Warnings_Mode_On in the procedure
Par.Ch10.P_Compilation_Unit.  "Set_Warnings_Mode_On" makes a call to
"Warnings.Last" !!!!

   So if there has been no warning pragmas encountered the table has been 
initialized and never added to so the call to Set_Warnings_Mode_On kills
the compiler ITSELF !!!!

   This is my FIRST example of why I say the 3.03 executables you are putting
out DON't match the 3.03 source.  If they did and checking was turned on when
the compiler was compiled, EVERY single 3.03 executable on cs.nyu.edu would
not work !!!!  Another possiblity is that you patched the code you used to 
make the 3.03 executables.  If that is true I am correct without argument.

    The only other possibility is that ACT compiles the compiler with checks
turned off when it produces its executables.  The problem here has to do with
the obvious implication that ACT is in the habit of TESTING thier compilers
with checks TURNED OFF.

    The problem here once again goes back to a quality assurance issue.  If
ACT isn't willing to use the basic features of the language to help enforce
a stable level of quality controls in its maintenance of GNAT,  How can you
expect me to believe anything except: "GNAT is Free and Still Costs Too
Much" ???

> Regardng the actual subtypes, you are treadng in a very difficult area of
> the compiler. IN general the additional actual subtypes are ESSENTIAL to
> fix a number of critical bugs -- so your changes will cause a lot of
> serious regressions. It is true that certain programs can generate
> more code as a result. For us more code is less of a problem than wrong
> code! In fact in 3.04, we have largely, but not completely eliminated
> this impact, while retaining the proper functionality, which was not
> easy to do.

    O.K. once again you talk in general terms.  WHAT bugs where fixed.  Where
is the actual subtype information "ESSENTIAL".  So why is it that whenever 
there is a selected component that selects a field from a variant, we MUST
generate an complete subtype declaration ????  To make matters worse, the
semantic analysis of these quote "NESSISARY" subtype declarations causes
the entity list for all the fields of the original record type to be
duplicated.  Since a single entity takes up 4 times the room of a normal node,
a record with say 32 fields in it will require 128 nodes worth of memory to
hold this field list in the quote "expanded" subtype declaration.

   Now go back to when this happens !!!  At Every SELECTED COMPONENT !!!!
Potentially a VAST number of location even in a small piece of code.  In my
simple test case, there was a FIVE times increase in the number of nodes
created by the compiler, I didn't say anything about how big the generated
object code is.

   The problem here is that a unit, of about 3600 lines, that compiled fine
on the 3.01 compiler with 15 Mb of memory being used.  On the 3.03 compiler
the same piece of code REQUIRES 75 Mb of memory.  On my little 20 Mb of
physical RAM 468/66 once the compiler allocates more than about 50 Mb of
memory the machine begins to thrash and the job runs and runs and runs.

   In fact on the 3.01 compiler the unit compiles in about 2-3 mins.  With the
3.03 compiler, it takes over 36 HOURS !!!!!  Clearly this is NOT acceptable.
Strangely enough, when I simply stop generating those subtype declarations,
everything works fine, and it takes 2-3 mins again.

   I find it hard to swallow that the "ENHANCEMENT" of adding these subtype
declarations which forces me to go BUY memory to max out my older machine at
32 Mb.  But then that will most likely NOT be enough memory so I will be
forced to go out and BUY a new Pentium or at least a newer motherboard and
even MORE memory.

   The thing I find most rediculous about this problem is how the current 3.03
design produces literally thousands of DUPLICATE subtype declarations.
Concider a simple situation where we are using a case statement to comb thru
one of serveral variants of a record.  The case expression would be a selected
component that names the discriminant of the record.  This selected component
generates a new subtype declaration.

   After that in the arms of the case statement, one of the most inevitable
things to do is to use more selected components that work with the fields in
the variants of the record.  However each of these selected components ALSO
generates a subtype declaration.  But each of these is an EXACT DUPLICATE of
the one generated in the case expression !!!!!

   This is not only braindead, it is wastfull and very sloppy coding !!!!

> It is certainly true that there were some regressions with 3.03. We know
> of no way to guarantee that there will be no regressions, but we had
> very few reproted, and for most people, the large number of bug fixes
> and extra functoinality from 3.01 to 3.03 was desirable!

   This brings up problem 3 the derivation of tagged types.  Take a look
at the package sem_ch3.adb in the procedure Build_Derived_Tagged_Type.  Pay
perticular attention to the "Present" check on line 7541.  The original code
set the discriminant constraint on the derived type equal to the one on the
parent type, but ONLY if the parent type HAD a discriminant constrant.  In
cases where the parent did NOT have a discriminant constraint, the derived
type's discriminant constrant was not initialized (i.e. Elist6 remains
initialized with a value of 0 not a value of 100,000,000)  Later when this 
field gets referenced as an enitity list the compiler croaks with a 
Constraint_Error.

   As far as regessions try the package Ada.Finalization.  It has a derived
type in it's private part named "Controlled".  It is derived from the
Root_Controlled type of System.Finalization_Root, which in turn is derived
from the abstract tagged type Empty_Root_Controlled.

   With this bug, since the original type Empty_Root_Controlled has no
discriminants it's discriminant_constraint field (elist6) gets a value of
No_Elist.  However when it is derived into Root_Controlled, the
discriminant_constraint field is NOT initialized and so keeps the illegal
value of 0.  Then when Ada.Finalization.Controlled is derived from
Root_Controlled this SAME check for "Present" will raise a Constraint_Error.

   So we have ANOTHER case where at a minimum, ACT tested 3.03 with the
executables for 3.03 compiled with at least constraint checking turned off.
Since you must explicitly tell the compiler to not generate the checks, ACT
must have make a conscious decision to turn off checking when they compiled
the code they tested.  If the excuse for doing this is "So we could test the
exact executable we deliver", this begs the question, "Still, why is it that
ACT didn't even compile the compiler with checks on at least ONCE" ????

   The first problem with the instantiation of the Table package will stop
the building of the compiler when you attempt to build the stage 2 version 
of the compiler.  Once you fix that problem, you can complete the building
of the stage 2 compiler, but now you run into a problem with the stage 2
compiler not being able to compile GNAT's own libraries.

   There could not be any more obvious piece of code to use for regression
testing that the source for GNAT and it's own library.  If just ONCE
somebody had compiled the compiler with checking turned on, these 2
problems would have been found before 3.03 source went out.

> I think you would do better to report the bugs you find in a calm and
> collected manner, rather than flail around trying to fix them yourself
> when you don't fully understand the semantic implications of what you
> are doing. The "ideots" [sic] at ACT might just possibly understand
> some of the issues better than you do!

   I am NOT making bug reports !!!!  I am making some general observations
known about things I have found in the GNAT source code.  I'm sorry you
don't like my politically incorrect presentation.  Would "Real World Ada
Experience Challanged" be better ???

   Speaking of which, take a look at the Init routine in the Table package.
the code says:

      Max    := Min - Table_Initial - 1;
      Length := Max - Min + 1;

   Why Not ???

      Max    := Min - Table_Initial - 1;
      Length := Table_Initial;

   Are you just EXTREEMLY confident in the GCC code generators or was this 
a typical mistake made by a coder new to Ada ????  Look at the related first
bug.  It was caused by a similar newbe misunderstanding that the 'Last of
a null slice can SOMETIMES not be in the range of the index subtype.

   Dealing with 'First, 'Last, 'Length with arrays and understanding the
relationships between them is Ada 101 stuff.  I expect these kinds of problems
to typically be found in code produced by coders with less that 3 years of
real world Ada programming experience.

   I would HOPE I could expect some higher level of experience in a compiler
maintainer/vendor !!!!

> Regarding difs, we could certainly do this. They are large, probably
> 3.02 to 3.03 would be 10,000 lines of difs, many of them coming simply
> from reformatting, comment changes etc. as well as technical changes.

   This would be GREAT !!!!  At least we could then externally track what ACT
is doing to the compiler.  It would also be helpfull if you would release
versions of source code EVEN if you don't provide executables.  I never saw any
3.02 executables or source, but you talk like it existed !!!!

   Go out to MIT's GNU FTP site.  Take a look at how they handle GCC.  Why
not the same thing for the source of GNAT ???? 2 or 3 versions with diff's
in between.  WHO cares if you provide executables.  From what I have seen
I will need to build the compiler myself ANYWAY just so I can know EXACTLY
what I have in front of me.

   It sure wouldn't hurt if ACT would provide some REAL documentation on the
compiler like:

    1. A general overview of the workings of the compiler
        GCC has great documentation included with the source.

    2. Document what to use and how to regenerate atree, sinfo, einfo etc.
        GCC at least includes info on using bison to produce compiler code.

    3. When your README says "rename this file to" at LEAST have the file.
        GCC is rather complete.

> You actually seem to understand a lot about the tehnology of GNAT. TOo
> bad you can't operate in a more constructive mode, like many of the
> other volunteers who help improve the technology. In particular, it
> really would be helpful to have detailed bug reports, rather than
> vague complaints. If you think you have a fix, by all means send it
> along to us. Many people send us proposed fixes. Often they are not
> quite right, but they are very helpful in pointing to the right fix.
> Sometimes they are indeed right. The difficulty is that many things
> interact subtly. Especially if you are not thoroughly familiar with
> GNAT, and with Ada 95 semantics, then what seems like a simple fix
> can in fact turn out to have subtle interactoins, as is the case with
> the actual subtype stuff.

   Once again, I am not tring to help you fix your compiler.  If I was doing 
that you would have seen this as a bug report thru normal channels.  This
is being posted on the Usenet to highlight some problems I was having with
code from ACT.

   Since GNAT was always intended to be the core piece of a project to help
spur on the growth of Ada, I felt that such basic problems with the GNAT code
should be brought to the public's attention.

   Every person involved in Ada work should be concerned.  Ada has suffered
because of compiler vendors that have jacked the price of a decent Ada
compiler up to the level where only Government institutions are able to really
afford it.  To make matters worse they only added features to the compiler
when the government was willing to pay for it.  As a result, very few
organizations outside the government have adopted Ada.

   Kind of reminds me of Beta verse VHS.  Beta was clearly a better system,
but that additional cost of Bete wiped it out.  Bought any Beta tapes lately:-)
Or should I start working with C++ (yuck, curse, vomit, bite my tongue) :-)

> By the way, ACT always provies full source releases with binary releases.
> We do not provide FTP access direct to ACT for other than our customers,
> but the releases are on many public FTP sites, and they are certainly
> free to keep old sources around. It certainly seems like it would be a good
> idea if one of these sites would keep old sources around. Disk space is
> not infinite at NYU, so this is probably not the best choice, but it is
> hard to believe that some of the other sites that keep copies of GNAT
> around do not have the disk space to keep old copies of the sources.

   Back to the appropriateness of selling a validated compiler and maintaining
a piece of freeware.  An FTP site for "Customers Only" ???  Sounds like you
have things there that didn't make it to the public sites.  Like maybe the
3.02 source and the documentation ????

   Since you haven't updated your homepage since 2/9/96 and it's all screwed up
anyway I don't find it strange that you don't seem to understand how your code
is mirrored around the world.

   When you delete a file from cs.nyu.edu, it get's deleted on EVERY OTHER
MACHINE.  That's why they call them mirrors !!!!  If ACT's definition of how
to distribute GNAT is to HOPE somebody out there keeps older copies because of
lack of space, Then I am here to say: "When it comes to disk space and old
copies of the GNAT source, the Emperor HAS No Clothes" !!!!

Joe Schafer
jschafer@iquest.net

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

Frankly I did not bother to read this whole diatribe, though I have stashed
it away in case I do later, but I will address one point:

"   This is my FIRST example of why I say the 3.03 executables you are putting
out DON't match the 3.03 source.  If they did and checking was turned on when
the compiler was compiled, EVERY single 3.03 executable on cs.nyu.edu would
not work !!!!  Another possiblity is that you patched the code you used to
make the 3.03 executables.  If that is true I am correct without argument.

    The only other possibility is that ACT compiles the compiler with checks
turned off when it produces its executables.  The problem here has to do with
the obvious implication that ACT is in the habit of TESTING thier compilers
with checks TURNED OFF."

In fact we debug and release with checks off and assertions on. Our 
assertion approach is very complete, and our experience was that
constraint checks

a) never found a single real bug

b) did cause some bombs that were not real bugs in the sense that if
constraint checks were off, the functoinality would be correct.

All the cases we found were confusions between Natural and Integer, which
of course are just fixed by using the right subtype.

We prefer to test with exactly the same options we use for release, which
is why we tend not to use the constraint checks for internal testing either.
It is true that it would be a good idea to run occasionally to smoke out
problems like this, but they are hardly high priority problems given that
they don't affect user programs! 

But just to be clear, the 3.03 releases exactly match the 3.03 sources
if you build in the standard manner, which everyone else seems to have
no trouble doing.

P.S. the problem with actual subtypes is subtle, not something I would
expect to be easily noticed -- after all this fix was not put on till
later.

By the way, the 3.01 sources are and always have been at cs.nyu.edu
as far as I know. Several people emailed me to tell me they were there!

Going back to the constraint error situation, I can actually give the 
specific example where this caused trouble. In the 2.04 release, ew
had a problem that certain error messages caused constraint errors.
There weren't any instances of these messages in our regression suite
so we had missed this (now of course there are dozens of instances of
those messages).

This turned out to be just a matter of natural vs integer. We had turned
on constraint checks for the release to increase the reliability, and
oddly, if had significantly decreased the reliability. That was the point
at which we realized that constraint chceks had never been useful to us
anyway given our assertions (which are pretty extensive, the front end
spends 80-90% of the execution time executing assertion statements),
so we removed them and never put them back.

Actually in the near future, we may release without the assertion checks.
It is possible that the constraint checks will then prove useful again,
we are currently making some measurements to find out what the best
apporach is.

As for the unsatisfied customer here, I guess that just goes to show you
cannot make everyone happy. We will be happy to refund what he paid for
GNAT, since he does not think it is worth it :-)

P.S. we just froze the sources for 3.04. We will be doing a few days of
final beta testing (there should be a word like gamma testing), and then
we will rlease the public SGI and Solaris versions at least in a few
days,
with other ports to follow along, including the DOS 3.04 with full tasking.

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

By the way Joe, I just asked someone to check.

The 3.01 sources are and always have been in the pub/gnat/private/old
directory. The readme specifically mentions this location. I do not
know if it is on other sites or not.

Perhaps more careful reading of documentation and less fulminating
might be more profitable :-)

Re: GNAT 3.01 Source For OS/2

[jschafer1]

> From: dewar@cs.nyu.edu (Robert Dewar)
> Newsgroups: comp.lang.ada
> Subject: Re: GNAT 3.01 Source For OS/2
> Date: 3 May 1996 14:39:15 -0400
> Message-ID: <dewar.831148051@schonberg>
> References: <DqBxv9.GBL@iquest.net> <dewar.830403010@schonberg> <DqIBno.2E7@iquest.net> <dewar.830619408@schonberg> <DqpIv9.Ku1@iquest.net>
> 
> Frankly I did not bother to read this whole diatribe, though I have stashed
> it away in case I do later, but I will address one point:
> 

   OH.  So you simply ignore the issues to the best of your ability.

>
> In fact we debug and release with checks off and assertions on. Our 
> assertion approach is very complete, and our experience was that
> constraint checks
> 
> a) never found a single real bug
> 

   OH.  So the improper initialization of a Decriminant_Constraint when
deriving tagged types is NOT a real bug ?????

> 
> b) did cause some bombs that were not real bugs in the sense that if
> constraint checks were off, the functoinality would be correct.
>

   OH.  So the assertion error caused by the inproper initialization of
the Discriminant_Constraint field is NOT an error in the program either ????
Since the range check would have caught it, and you don't concider range
checking usefull, it must not be a problem that the compiler fails with
an assertion error when you DO turn off range checks ????

> 
> All the cases we found were confusions between Natural and Integer, which
> of course are just fixed by using the right subtype.
> 

   OH.  So you admit your coders where confused about the differences between
Natural and Integer and you chose to hide the problem rather then make a
simple change in the source code ????  Had these coders ever used Ada in the
real world before working on GNAT ????

>
> We prefer to test with exactly the same options we use for release, which
> is why we tend not to use the constraint checks for internal testing either.
> It is true that it would be a good idea to run occasionally to smoke out
> problems like this, but they are hardly high priority problems given that
> they don't affect user programs! 
> 

  OH.  Croaking programs are NOT a problem ?!?!?

>
> But just to be clear, the 3.03 releases exactly match the 3.03 sources
> if you build in the standard manner, which everyone else seems to have
> no trouble doing.
> 

  OH.  So there is some magical way in which people get informed that the
makefile distributed with the 3.03 source has the WRONG switches in it ????


> P.S. the problem with actual subtypes is subtle, not something I would
> expect to be easily noticed -- after all this fix was not put on till
> later.
>

  OH.  So I SHOULDN"T notice a change from 2-3 mins compile time to over
36 hours for the SAME unit ?????   I guess it is just rediculous for me
to assume that GNAT should be usable on a machine with less than 32-64 Mb
of memory ????

> 
> By the way, the 3.01 sources are and always have been at cs.nyu.edu
> as far as I know. Several people emailed me to tell me they were there!
> 

  OH.  So you make claims without checking it out first !!!!!

>
> Going back to the constraint error situation, I can actually give the 
> specific example where this caused trouble. In the 2.04 release, ew
> had a problem that certain error messages caused constraint errors.
> There weren't any instances of these messages in our regression suite
> so we had missed this (now of course there are dozens of instances of
> those messages).
> 
> This turned out to be just a matter of natural vs integer. We had turned
> on constraint checks for the release to increase the reliability, and
> oddly, if had significantly decreased the reliability. That was the point
> at which we realized that constraint chceks had never been useful to us
> anyway given our assertions (which are pretty extensive, the front end
> spends 80-90% of the execution time executing assertion statements),
> so we removed them and never put them back.
>

   OH.  So you found out that if you make incorrect code the compiler makes
it glaringly obvious, so you chose to hide your mistakes !!!!

> 
> Actually in the near future, we may release without the assertion checks.
> It is possible that the constraint checks will then prove useful again,
> we are currently making some measurements to find out what the best
> apporach is.
> 

   OH.  No doubt to hide the assertion errors generated because you didn't
fix the bugs found with range checking.

>
> As for the unsatisfied customer here, I guess that just goes to show you
> cannot make everyone happy. We will be happy to refund what he paid for
> GNAT, since he does not think it is worth it :-)
> 

   OH.  You still can't get it into your head that I don't WANT the 
executables ACT produces.  I prefer to build the compiler from source so
I know exactly what I am getting.  And your "unstatisfied customer" idea is 
rediculous.  You can claim me as a customer when you get some cash from me.
But that's not going to happen anytime soon  :-)


Joe Schafer
jschafer@iquest.net

Re: GNAT 3.01 Source For OS/2

[jschafer1]

> From: dewar@cs.nyu.edu (Robert Dewar)
> Newsgroups: comp.lang.ada
> Subject: Re: GNAT 3.01 Source For OS/2
> Date: 3 May 1996 14:44:49 -0400
> Message-ID: <dewar.831148903@schonberg>
> References: <DqBxv9.GBL@iquest.net> <dewar.830403010@schonberg> <DqIBno.2E7@iquest.net> <dewar.830619408@schonberg> <DqpIv9.Ku1@iquest.net>
> 
> By the way Joe, I just asked someone to check.
>

   Well you BETTER learn to check yourself.

> 
> The 3.01 sources are and always have been in the pub/gnat/private/old
> directory. The readme specifically mentions this location. I do not
> know if it is on other sites or not.
>

   Why don't you go and look ????   There is nothing in the pub/gnat/private
directory.  You may be right about the README, but there still ain't nothin
where YOU said there would be !!!!

> 
> Perhaps more careful reading of documentation and less fulminating
> might be more profitable :-)
>

   Maybe a more careful checking of the facts before you make statements
would not be a bad suggestion TOO !!!!   If you can't get your facts right
how do you expect to be profitable ????

Joe Schafer
jschafer@iquest.net

Re: GNAT 3.01 Source For OS/2

[Kevin D. Heatwole]

In article <dewar.831148051@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:
> Going back to the constraint error situation, I can actually give the 
> specific example where this caused trouble. In the 2.04 release, ew
> had a problem that certain error messages caused constraint errors.
> There weren't any instances of these messages in our regression suite
> so we had missed this (now of course there are dozens of instances of
> those messages).
> 
> This turned out to be just a matter of natural vs integer. We had turned
> on constraint checks for the release to increase the reliability, and
> oddly, if had significantly decreased the reliability. That was the point
> at which we realized that constraint chceks had never been useful to us
> anyway given our assertions (which are pretty extensive, the front end
> spends 80-90% of the execution time executing assertion statements),
> so we removed them and never put them back.
> 
> Actually in the near future, we may release without the assertion checks.
> It is possible that the constraint checks will then prove useful again,
> we are currently making some measurements to find out what the best
> apporach is.

This is actually an interesting topic.  

Do constraint_error checks in Ada actually decrease reliability for programs?

I don't know the answer since I am just a lowly Ada programmer.  I know
that since I have been working on Ada compilers since 1983 (and currently
work for OC Systems), that in the compiler domain, these constraint_errors
often are the problems that users of a compiler will report.  They are
also problems that sometimes contribute to the user thinking that the 
compiler is crap.

I agree that often these violations of subtype ranges don't represent
serious problems (but sometimes they do).  I have always felt that the
more errors caught by the language (even if these errors are not caught
until runtime), the better it is for the stability of the program (in the
long run).  Do the C people have it right?  Is it sufficient to rely on
the programmer to place appropriate assertion checks to ensure reliability
and that automatic range checking actually hurts?

As an aside, I will note that some early compiler vendors expected that
real programs would be deployed with all checks suppressed.  This was because
it was perceived that the overhead of making the checks would be too high
in the operational environment.  They expected the users to use exception
checking during development/testing to weed out the problems and then
remove them sometime during the development cycle.  (It appears that
ACT may be doing just the opposite - suppressing the checks early on and 
turing them on late in the cycle).  Anyway, as a result, several early
compiler vendors did not spend a lot of effort trying to minimize the
number of exception checks emitted by their compilers (kind of a self 
fulfilling prophecy since the more redundant exception checks left in the
operational code, the more likely that users would find reason to suppress 
them for performance).  Around 1988 or so, things seemed to change and most
user programs are deployed with full exception checking (at least, the
ones I have worked with).

Kevin Heatwole
OC Systems, Inc.

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

As far as I can tell (Joe's ramblings are a little hard to interpret, and
generally we can only process bug reports sent to report@gnat.com as has
often been mentioned here), there are no functionality bugs that Joe
refers to that are not already fixed in GNAT 3.04, which is prerelease
status now.

(the prerelease looks good so far from preliminary reports, so the 3.04
release should occur at the end of this coming week if all continues
to go smoothly in the testing process).

In particular we some time ago found an approach to the actual subtypes
problem that fixes the problems without the compilation time hit (although
none of our users ever saw anything as extreme as the case that Joe refers
to -- but did not submit as a bug report).

Incidentally, we certainly understand that many people want to build from
source -- many of our users, both supported and unsupported, do so, and
have generally been quite successful in doing so (occaisionally a note to
report@gnat.com has been needed to sort out some confusion, but most of
our users have built from source by following our directions).

It *is* important to read the documentatoin and follow the directions.
I guess, but don't know, that Joe may have missed some elements of the
directions (he certainly missed the very obvious paragraph in the README
file that says where the old sources are).

Generally I am not the one to help with installation and build problems.
The folks at ACT who know those details don't bother to read comp.lang.ada
any more (actually it seems that more and more people in the Ada community
are deficing that CLA is not worth the trouble any more, which is a pity!)
Anyway, that's why it is important to always follow the documentation,
and send questions etc to report@gnat.com (assuming that you actually
want some assistance -- comp.lang.ada is and remains the more appropriate
place for letting off steam :-)

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

Robert Dewar said:

  > The 3.01 sources are and always have been in the pub/gnat/private/old
  > directory. The readme specifically mentions this location. I do not
  > know if it is on other sites or not.

Joe said

  > Why don't you go and look ????   There is nothing in the pub/gnat/private
  > directory.  You may be right about the README, but there still ain't nothin
  > where YOU said there would be !!!!

Robert replies

Umm, can you learn to read just a ltitle more carefully, my message
(and the README file!) says pub/gnat/private/old, not pub/gnat/private.
I just looked there and found:

  gnat-3.01-sparc-sun-solaris2.3-bin.tar.gz
  gnat-3.01-sparc-sun-sunos4.1.3-bin.tar.gz
  gnat-3.01-alpha-dec-osf2.0-bin.tar.gz
  gnat-3.01-mips-sgi-irix5.3-bin.tar.gz
  gnat-3.01-src.tar.gz
  gnat-3.01-linux+elf.readme
  gnat-3.01-linux+elf.tar.gz
  gnat-3.01-dos-bin-disk1.zip
  gnat-3.01-dos-bin-disk2.zip
  gnat-3.01-dos-bin-disk3.zip
  gnat-3.01-i386-unknown-solaris2.4-bin.tar.gz
  gnat-3.01-i386-unknown-solaris2.4-readme
  tar-winnt.exe.gz
  gzip-winnt.exe

Looks like gnat-3.01-src.tar.gz might just be what you are looking for.
I know we try hard to hide this, by putting clear documentation in the
README file, which indeed points to where stuff is, but others have
somehow managed to find the items anyway :-)

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

Joe said

"   Well you BETTER learn to check yourself."

On the contrary, that's not part of what I know about particularly. If you
want help from ACT, always send email to report@gnat.com. You can copy
CLA if you like, but to reach the people at ACT who can answer your
questions, send email to report@gnat.com. I read CLA, but I am not the
expert in all aspects of GNAT and GNAT distribution!

Joe, why not just give it a try (sending email to report@gnat.com, as
requested in the documentatoin). It might just work! It has for others!

Re: GNAT 3.01 Source For OS/2

[Robert Dewar]

Keith said:

 >it will give you an empty listing, as if there were nothing there.
 >If, however, you do this:
 >
 >   cd /pub/gnat/private/old
 >   dir
 >
 >Robert: it might be a good idea to put the "old" directory directly under
 >"/pub/gnat" rather than "hiding" it in "private".

Yes, of course that is how private directories work, and this is why
the directions *quite clearly* say to go to /pub/gnat/private/old:
This is from the README:

  Old source and binaries of GNAT have been moved to pub/gnat/private/old
  on cs.nyu.edu in order not to clutter up the main pub/gnat directory and
  not to be picked up by mirror sites. If for some reason you need to
  retrieve any of these old versions, that is where they can be found.

This is because many of the mirror sites have limited space, and we felt
that a single generally accessible copy of the old sources is sufficient.
Sorry for "hiding" the information in the documentation like this, I know
that's not fair to those who really don't want to read documentation :-)

Re: GNAT 3.01 Source For OS/2

[Keith Thompson]

In <dewar.831309275@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
> Joe said
> 
>   > Why don't you go and look ????   There is nothing in the
>   > pub/gnat/private directory.  You may be right about the README,
>   > but there still ain't nothin where YOU said there would be !!!!
> 
> Robert replies
> 
> Umm, can you learn to read just a ltitle more carefully, my message
> (and the README file!) says pub/gnat/private/old, not pub/gnat/private.

The source of the confusion, I think, is that the permissions on the
pub/gnat/private directory are set to "rwx--x--x" (711).  This allows
users to access files and directories under that directory if they already
know their names, but not to get a directory listing.  (There may well
be things other than "old" in there, but I can't tell.)  It's a common
way to hide things on a public ftp site while still allowing access for
those who know what they're looking for.

So, from within the ftp program, if you do this:

    cd /pub/gnat/private
    dir

it will give you an empty listing, as if there were nothing there.
If, however, you do this:

    cd /pub/gnat/private/old
    dir

you'll get a listing of all the files there.  You can't get to
/pub/gnat/private/old by traversing one directory at a time, but you
can get there directly.

It's arguably a bug in ftp that the "dir" command doesn't visibly
distinguish between empty and non-readable directories.

Robert: it might be a good idea to put the "old" directory directly under
"/pub/gnat" rather than "hiding" it in "private".

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
This sig uses the word "Exon" in violation of the Communications Decency Act.

Re: GNAT 3.01 Source For OS/2

[Tore Joergensen]

Keith Thompson (kst@thomsoft.com) wrote:
: If, however, you do this:

:     cd /pub/gnat/private/old
:     dir

: you'll get a listing of all the files there.  You can't get to
: /pub/gnat/private/old by traversing one directory at a time, but you
: can get there directly.

You can get there a directory at the time, but you don't get any help
since the directory-listing in private looks empty. If you type
'cd old' when you are in private, you get to /pub/gnat/private/old however.
-- 
+-------------------------+-------------------------------------------+
| Tore B. Joergensen      | e-mail : tore@lis.pitt.edu                |
| Centre Court Villa      | web    : http://www.pitt.edu/~tojst1      |
| 5535 Centre Avenue # 6  |                                           |
| Pgh, PA 15232, USA      | Norwegian MSIS-student at Univ. of Pgh.   |
+-------------------------+-------------------------------------------+

Re: GNAT 3.01 Source For OS/2

[Joerg Rodemann]

jschafer1@iquest.net wrote:
> > 
> > The 3.01 sources are and always have been in the pub/gnat/private/old
> > directory. The readme specifically mentions this location. I do not
> > know if it is on other sites or not.
> >
>    Why don't you go and look ????   There is nothing in the pub/gnat/private
> directory.  You may be right about the README, but there still ain't nothin
> where YOU said there would be !!!!

Dear Mr. Schafer,

I really do not see, where your problem with the 3.01 sources is. I checked
it up right this moment using my netscape (perhaps it keeps a private copy
of the sources... *smile*) and the url

   ftp://cs.nyu.edu/pub/gnat/private/old/

The directory listing shows an entry "gnat-3.01-src.tar.gz" with a length
of 2127 kB. 

Besides that your manners are quite repulsive. Maybe you are able to
write in a more proper style...or haven't you ever heard about politeness?

Just thinking

George
--
Joerg 'George' Rodemann                      Erhard-Groezinger-Strasse 82
Department of Physics                                   D-89134 Blaustein
University of Ulm                                      Tel. (0731) 553319
e-mail:                                    rodemann@mathematik.uni-ulm.de