What happens to DEC Ada?

What happens to DEC Ada?

[Adrian Hoe]

Hello,

I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
anyone have some info?

Thanks.

Re: What happens to DEC Ada?

[Ted Dennison]

In article <9ff447f2.0107310659.36d01e9@posting.google.com>, Adrian Hoe says...
>I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
>anyone have some info?

COMPAQ does. I believe they still support it to some small extent. But they
aren't updating it to Ada95. I know they will still sell documentation for it,
so I suspect you can probably still buy the compiler too.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: What happens to DEC Ada?

[Larry Kilgallen]

In article <qqA97.12665$ar1.39477@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <9ff447f2.0107310659.36d01e9@posting.google.com>, Adrian Hoe says...
>>I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
>>anyone have some info?
> 
> COMPAQ does. I believe they still support it to some small extent. But they
> aren't updating it to Ada95. I know they will still sell documentation for it,
> so I suspect you can probably still buy the compiler too.

As yet they don't seem to have updated:

	http://www.openvms.compaq.com/commercial/ada/documentation.html

to indicate that the new name is Compaq Ada.  I gather that page is not
visited very often by the naming police.

Re: What happens to DEC Ada?

[Corey Ashford]

DEC turned over the Ada95 work to us (Rational Software) and referred many
of its customers to us.

Rational Apex Ada supports Ada83 and Ada95 on Alpha Tru64 UNIX, but not VMS.

Corey Ashford
Rational Software Corp. (but not speaking for them in any way)


"Ted Dennison" <dennison@telepath.com> wrote in message news:qqA97.12665$ar1.39477@www.newsranger.com...
> In article <9ff447f2.0107310659.36d01e9@posting.google.com>, Adrian Hoe says...
> >I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
> >anyone have some info?
>
> COMPAQ does. I believe they still support it to some small extent. But they
> aren't updating it to Ada95. I know they will still sell documentation for it,
> so I suspect you can probably still buy the compiler too.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: What happens to DEC Ada?

[Ted Dennison]

In article <E166E69A95753648BC398E36BE9A3AB814BF6C60@sus-ma1it06>, Corey Ashford
says...
>
>DEC turned over the Ada95 work to us (Rational Software) and referred many
>of its customers to us.

Interesting. I could have sworn I heard pretty much the same story out of ACT...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: What happens to DEC Ada?

[Larry Kilgallen]

In article <tdja7.15538$ar1.57055@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <E166E69A95753648BC398E36BE9A3AB814BF6C60@sus-ma1it06>, Corey Ashford
> says...
>>
>>DEC turned over the Ada95 work to us (Rational Software) and referred many
>>of its customers to us.

Unix.

> Interesting. I could have sworn I heard pretty much the same story out of ACT...

VMS.

Re: What happens to DEC Ada?

[Ted Dennison]

In article <+3JSU1vR9Zzd@eisner.encompasserve.org>, Larry Kilgallen says...
>
>In article <tdja7.15538$ar1.57055@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
>> In article <E166E69A95753648BC398E36BE9A3AB814BF6C60@sus-ma1it06>, Corey Ashford
>> says...
>>>
>>>DEC turned over the Ada95 work to us (Rational Software) and referred many
>>>of its customers to us.
>
>Unix.
>
>> Interesting. I could have sworn I heard pretty much the same story out of ACT...
>
>VMS.

Ahh. Thanks for the clarification.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: What happens to DEC Ada?

[Charlie McCutcheon]

Ted Dennison wrote:

> In article <E166E69A95753648BC398E36BE9A3AB814BF6C60@sus-ma1it06>, Corey Ashford
> says...
> >
> >DEC turned over the Ada95 work to us (Rational Software) and referred many
> >of its customers to us.
>
> Interesting. I could have sworn I heard pretty much the same story out of ACT...
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

(Then) Digital had a contract to refer customers to Rational for Ada 95 on Digital
Unix.  That contract has expired.

For OpenVMS Alpha, we recommend ACT's gnat for Ada 95.  They also have a Tru64
target.

I believe Compaq's official story is to mention both Rantional and ACT, and let the
customer choose.  More pointers on our web page,
http://www.openvms.compaq.com/commercial/ada/ada_index.html.

Charlie
Compaq Ada project leader

Re: What happens to DEC Ada?

[Charlie McCutcheon]

Ted Dennison wrote:

> In article <9ff447f2.0107310659.36d01e9@posting.google.com>, Adrian Hoe says...
> >I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
> >anyone have some info?
>
> COMPAQ does. I believe they still support it to some small extent. But they
> aren't updating it to Ada95. I know they will still sell documentation for it,
> so I suspect you can probably still buy the compiler too.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Sigh.  I thought I updated this last week from my non-work account.  Now I can't
see the replies I thought I had made...  8-{

Compaq Ada is still supported by Compaq.  We are in maitenance mode, but are still
fixing customer supported problems.

The latest releases are V3.5A for OpenVMS VAX and Alpha.  Tru64 target is retired.

See the Compaq Ada web page,
http://www.openvms.compaq.com/commercial/ada/ada_index.html if you need more
information.

Charlie McCutcheon
Compaq Ada project leader

Re: What happens to DEC Ada?

[Thierry Lelegard]

> I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
> anyone have some info?

The product still exists. The current version is "Compaq Ada V3.5".
It is no longer supported on Digital/Tru64 UNIX. It is still supported
on OpenVMS (both VAX and Alpha) but support will terminate in the next
few years and the product will be abandonned.

DEC Ada is still an Ada83 compiler and will never support Ada95.
For Ada95 on OpenVMS, Compaq recommends GNAT.

-Thierry
____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: What happens to DEC Ada?

[Charlie McCutcheon]

Actually, the latest release is Compaq Ada V3.5A for OpenVMS VAX and Alpha.

We still support it.  For comments on furtures (how long we'll support it),
contact the product manager, Pat.Mulvey@compaq.com

Charlie
Compaq Ada

Thierry Lelegard wrote:

> > I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
> > anyone have some info?
>
> The product still exists. The current version is "Compaq Ada V3.5".
> It is no longer supported on Digital/Tru64 UNIX. It is still supported
> on OpenVMS (both VAX and Alpha) but support will terminate in the next
> few years and the product will be abandonned.
>
> DEC Ada is still an Ada83 compiler and will never support Ada95.
> For Ada95 on OpenVMS, Compaq recommends GNAT.
>
> -Thierry
> ____________________________________________________________________________
>
> Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
> CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
> Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
> ____________________________________________________________________________

Re: What happens to DEC Ada?

[Chris Miller]

On the subject of DEC Ada ...

I seem to recall that it had a very smart recompilation algorithm that could
drastically reduce the set of files that had to be recompiled after a change
had been made. Instead of just using file timestamp and "with" clause
dependencies, it would actually look into the code and deduce that most of
the recompilations were unnecessary. Very fast - great for big projects.

Is this algorithm still patented ?. Are we ever likely to see it in Gnat /
gcc ?

Chris Miller



"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:9ff447f2.0107310659.36d01e9@posting.google.com...
> Hello,
>
> I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
> anyone have some info?
>
> Thanks.

Re: What happens to DEC Ada?

[Gautier]

[smart recompilation]
Chris Miller:
# Are we ever likely to see it in Gnat / gcc ?

A first big step would be to keep a processed form of the .ads files.

G.

Re: What happens to DEC Ada?

[Larry Kilgallen]

In article <%jra7.3545$257.153834@ozemail.com.au>, "Chris Miller" <chrismil@ozemail.com.au> writes:

> I seem to recall that it had a very smart recompilation algorithm that could
> drastically reduce the set of files that had to be recompiled after a change
> had been made. Instead of just using file timestamp and "with" clause
> dependencies, it would actually look into the code and deduce that most of
> the recompilations were unnecessary. Very fast - great for big projects.

It does still use the "Smart Recompilation" feature (if you choose it and
have bought the higher-priced "professional development option").

> Is this algorithm still patented ?. Are we ever likely to see it in Gnat /
> gcc ?

Although I rejoice in, and benefit from, smart recompilation, I think of
it as something related to the "keep a database of previous compilation
results" approach to compilation environment design.  GNAT, and for that
matter AdaMagic, take the "rescan the source each time" approach, so to
implement smart recompilation would seem counter-cultural.

Re: What happens to DEC Ada?

[nicolas]

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

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> a �crit dans le
message news: NKj7nYr7sQCg@eisner.encompasserve.org...
> In article <%jra7.3545$257.153834@ozemail.com.au>, "Chris Miller"
<chrismil@ozemail.com.au> writes:
>
> > I seem to recall that it had a very smart recompilation algorithm that
could
> > drastically reduce the set of files that had to be recompiled after a
change
> > had been made. Instead of just using file timestamp and "with" clause
> > dependencies, it would actually look into the code and deduce that most
of
> > the recompilations were unnecessary. Very fast - great for big projects.

Beside that, the timestamp method cannot always be trusted.
We had problems with gnatmake which doesn't always recompile necessary
files.
The problem occurs when several files in different directories have same
name, same timestamp, and are selected with ADA_INCLUDE_PATH
timestamp and name of the file is checked, they are the sames, gnatmake
doesn't figure out that this is a different file and doesn't recompile it.

Re: What happens to DEC Ada?

[Larry Kilgallen]

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

In article <yYva7.18321$GC4.4165649@nnrp1.proxad.net>, "nicolas" <n.brunot@cadwin.com> writes:
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> a �crit dans le
> message news: NKj7nYr7sQCg@eisner.encompasserve.org...
>> In article <%jra7.3545$257.153834@ozemail.com.au>, "Chris Miller"
> <chrismil@ozemail.com.au> writes:
>>
>> > I seem to recall that it had a very smart recompilation algorithm that
> could
>> > drastically reduce the set of files that had to be recompiled after a
> change
>> > had been made. Instead of just using file timestamp and "with" clause
>> > dependencies, it would actually look into the code and deduce that most
> of
>> > the recompilations were unnecessary. Very fast - great for big projects.
> 
> Beside that, the timestamp method cannot always be trusted.
> We had problems with gnatmake which doesn't always recompile necessary
> files.
> The problem occurs when several files in different directories have same
> name, same timestamp, and are selected with ADA_INCLUDE_PATH
> timestamp and name of the file is checked, they are the sames, gnatmake
> doesn't figure out that this is a different file and doesn't recompile it.

Well that sounds like just an implementation bug rather than a
conceptual flaw.

Re: What happens to DEC Ada?

[nicolas]

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

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> a �crit dans le
message news: jGvPbYAYRtuu@eisner.encompasserve.org...
> > Beside that, the timestamp method cannot always be trusted.
> > We had problems with gnatmake which doesn't always recompile necessary
> > files.
> > The problem occurs when several files in different directories have same
> > name, same timestamp, and are selected with ADA_INCLUDE_PATH
> > timestamp and name of the file is checked, they are the sames, gnatmake
> > doesn't figure out that this is a different file and doesn't recompile
it.
>
> Well that sounds like just an implementation bug rather than a
> conceptual flaw.
>

We recompiled gnatmake with debug messages to see what went wrong actually.
But I'm not sure you can call that an implementation bug.
The flaw is to consider that 2 files with same name and same timestamp have
the same content,
or moreover that the content of a single  file has not changed, if the
timestamp has not changed
A lot of batch, or cvs import, commit or extractions, can generate a lot of
files with same name and same timestamp.

Re: What happens to DEC Ada?

[Larry Kilgallen]

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

In article <nwya7.18388$MB7.4309099@nnrp1.proxad.net>, "nicolas" <n.brunot@cadwin.com> writes:
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> a �crit dans le
> message news: jGvPbYAYRtuu@eisner.encompasserve.org...
>> > Beside that, the timestamp method cannot always be trusted.
>> > We had problems with gnatmake which doesn't always recompile necessary
>> > files.
>> > The problem occurs when several files in different directories have same
>> > name, same timestamp, and are selected with ADA_INCLUDE_PATH
>> > timestamp and name of the file is checked, they are the sames, gnatmake
>> > doesn't figure out that this is a different file and doesn't recompile
> it.
>>
>> Well that sounds like just an implementation bug rather than a
>> conceptual flaw.
>>
> 
> We recompiled gnatmake with debug messages to see what went wrong actually.
> But I'm not sure you can call that an implementation bug.
> The flaw is to consider that 2 files with same name and same timestamp have
> the same content,
> or moreover that the content of a single  file has not changed, if the
> timestamp has not changed
> A lot of batch, or cvs import, commit or extractions, can generate a lot of
> files with same name and same timestamp.

But unless they are the same bits on the disk, they are a different
file.  On VMS you would use the 6 byte file ID and the 64 byte device
ID to determine uniqueness.  I am sure the same construct must exist
on other operating systems.

Granted, someone writing a tool may neglect to consider the situation
you describe, but that is still just an implementation bug.

Re: What happens to DEC Ada?

[nicolas]

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

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> a �crit dans le
message news: b1FHvLfJLJqb@eisner.encompasserve.org...
> But unless they are the same bits on the disk, they are a different
> file.  On VMS you would use the 6 byte file ID and the 64 byte device
> ID to determine uniqueness.  I am sure the same construct must exist
> on other operating systems.
>
> Granted, someone writing a tool may neglect to consider the situation
> you describe, but that is still just an implementation bug.
>

Well we just checked gnamake sources to see what was wrong.
We drop VMS support for our products a few years ago, and we never had to
rely on this kind of file identification.
I don't know if such file ID exists for Windows Unixes or Linux.
It would be interesting to know that.
Timestamps can be changed, checksum can prove file are different, but not
identical.
I wouldn't trust them if safety concerns are involved.

Re: What happens to DEC Ada?

[Robert Dewar]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<b1FHvLfJLJqb@eisner.encompasserve.org>...
> > A lot of batch, or cvs import, commit or extractions, can generate > > a lot of files with same name and same timestamp.

No, this does not need to happen, and should not happen. Remember that
all large C systems are built with make, which uses time stamps in a
crucial manner, so any system like cvs of course properly supports
time stamps. You do need to make sure that you are not misusing the
system (e.g. scripts with cp rather than cp -p in them).

> But unless they are the same bits on the disk, they are a different
> file.  On VMS you would use the 6 byte file ID and the 64 byte device
> ID to determine uniqueness.  I am sure the same construct must exist
> on other operating systems.

But that would be a bad idea, because then you could not move files
around freely, which is really important.

> Granted, someone writing a tool may neglect to consider the situation
> you describe, but that is still just an implementation bug.

Well as I say, in GNAT, we can also use logical checksums on files,
but
in fact most of the C and C++ world expects to use time stamps as the
one principle method of determining what needs to be built (and of
course there is no additional consistency check, so you are *really*
depending on time stamps in a very fundamental manner). 

I do not see any bug here, only a mixture of incorrect procedures and
probably incorrect use of tools by Nicolas.

Re: What happens to DEC Ada?

[Simon Wright]

dewar@gnat.com (Robert Dewar) writes:

> Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<b1FHvLfJLJqb@eisner.encompasserve.org>...
> > > A lot of batch, or cvs import, commit or extractions, can generate > > a lot of files with same name and same timestamp.
> 
> No, this does not need to happen, and should not happen. Remember that
> all large C systems are built with make, which uses time stamps in a
> crucial manner, so any system like cvs of course properly supports
> time stamps.

And systems like PVCS Dimensions do _not_ properly support timestamps :-)

The scenario is

  check a file out
  modify it and compile
  decide to revert; fetch original file contents *and revert to original
    timestamp*
  'make' doesn't see it needs to recompile the file

(well, actually, GNAT (gnatmake) isn't affected because it compares
timestamps for equality)

Re: What happens to DEC Ada?

[Robert Dewar]

"nicolas" <n.brunot@cadwin.com> wrote in message news:<nwya7.18388$MB7.4309099@nnrp1.proxad.net>...

> > > The problem occurs when several files in different directories have same
> > > name, same timestamp, and are selected with ADA_INCLUDE_PATH
> > > timestamp and name of the file is checked, they are the sames, gnatmake
> > > doesn't figure out that this is a different file and doesn't recompile
>  it.

Actually this is a bad description, and Nicolas, perhaps working with
an old version of gnatmake is not correctly describing what happens.
Gnatmake also has the capability of checking logical checksums of
files, and the situation that Nicolas reports can be properly handled.
This is certainly not a problem we have seen from any of our customers,
and a quick test does not show a problem here. 

P.S. the logical checksum facility is what enables the smart
recompilation ....

Re: What happens to DEC Ada?

[Robert Dewar]

"nicolas" <n.brunot@cadwin.com> wrote in message news:<nwya7.18388$MB7.4309099@nnrp1.proxad.net>...

By the way, it seems very odd to have two different versions of the
same file with the same name, created at exactly the same time. most
likely if Nicolas is running into a problem from such a situation,
then there is some kind of glitch in procedures that is losing true
time stamps, and of course if this happens, then time stamps don't
work at all for any kind of make that depends on time stamps.

For example, you need to make sure that archiving, backup etc do not
clobber time stamps.

Re: What happens to DEC Ada?

[brentcarnellis]

On Fri, 03 Aug 2001 11:31:42 GMT, "nicolas" <n.brunot@cadwin.com>
wrote:
>Beside that, the timestamp method cannot always be trusted.
>We had problems with gnatmake which doesn't always recompile necessary
>files.

This so-called problem is a blatant example of fear-mongering ...

>The problem occurs when several files in different directories have same
>name, same timestamp, and are selected with ADA_INCLUDE_PATH
>timestamp and name of the file is checked, they are the sames, gnatmake
>doesn't figure out that this is a different file and doesn't recompile it.
>

... because it looks like the file attributes have been dicked 
around with.  To get similar symptons, I suggest you open the case on
your workstation and pour soy sauce on your circuit boards.

Re: What happens to DEC Ada?

[nicolas]

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

<brentcarnellis@hotmail.com> a �crit dans le message news:
3b6def8c.4410400@news.tc.umn.edu...
> On Fri, 03 Aug 2001 11:31:42 GMT, "nicolas" <n.brunot@cadwin.com>
> wrote:
> >Beside that, the timestamp method cannot always be trusted.
> >We had problems with gnatmake which doesn't always recompile necessary
> >files.
>
> This so-called problem is a blatant example of fear-mongering ...

Hum, is it really necessary to reply to this, I don't think so.


> >The problem occurs when several files in different directories have same
> >name, same timestamp, and are selected with ADA_INCLUDE_PATH
> >timestamp and name of the file is checked, they are the sames, gnatmake
> >doesn't figure out that this is a different file and doesn't recompile
it.
> >
>
> ... because it looks like the file attributes have been dicked
> around with.  To get similar symptons, I suggest you open the case on
> your workstation and pour soy sauce on your circuit boards.
>

A very simple and normal use of cvs without any "dick around" shows the
problem.
Just try ...

Re: What happens to DEC Ada?

[Gautier]

Nicolas:

> A very simple and normal use of cvs without any "dick around" shows the
> problem.
> Just try ...

About your problem: shouldn't you also have different directories
for .ali and .o files corresponding to the different compilations
with these source files having same name and same timestamp ?
I think you should. So, you would have a clean recompilation
for each version without the least doubt of an undesired mixture...
I find it a project management bug to count on smart recompilation
for differenciating source versions. Already mixing compilations with
different options can be a problem.
And instead of playing with ADA_INCLUDE_PATH, it would be safer to
select source directories with the -I option; same for objects and
ADA_OBJECTS_PATH.

G.

Re: What happens to DEC Ada?

[nicolas]

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

"Gautier" <gautier_niouzes@hotmail.com> a �crit dans le message news:
17cd177c.0108060605.3dead633@posting.google.com...
> About your problem: shouldn't you also have different directories
> for .ali and .o files corresponding to the different compilations
> with these source files having same name and same timestamp ?
> I think you should. So, you would have a clean recompilation
> for each version without the least doubt of an undesired mixture...
> I find it a project management bug to count on smart recompilation
> for differenciating source versions. Already mixing compilations with
> different options can be a problem.
> And instead of playing with ADA_INCLUDE_PATH, it would be safer to
> select source directories with the -I option; same for objects and
> ADA_OBJECTS_PATH.

Actually we solve the problem with clean recompilation, and specific checks
to be sure that the expected source was compiled when the program starts.
This is not a big problem, we don't release our softwares with Gnat.

Re: What happens to DEC Ada?

[brentcarnellis]

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

On Mon, 06 Aug 2001 08:12:41 GMT, "nicolas" <n.brunot@cadwin.com>
wrote:
><brentcarnellis@hotmail.com> a �crit dans le message news:
>> On Fri, 03 Aug 2001 11:31:42 GMT, "nicolas" <n.brunot@cadwin.com>
>> wrote:
>> >Beside that, the timestamp method cannot always be trusted.
>> >We had problems with gnatmake which doesn't always recompile necessary
>> >files.
>>
>> This so-called problem is a blatant example of fear-mongering ...
>
>Hum, is it really necessary to reply to this, I don't think so.

Thanks for not digging a deeper hole. I will grant that you may have a
bit of a problem expressing yorself in English, but your earlier
statement does tarnish GNAT's reputation in providing a solid
integrated make facility. What you claim is simply not true.

>
>> >The problem occurs when several files in different directories have same
>> >name, same timestamp, and are selected with ADA_INCLUDE_PATH
>> >timestamp and name of the file is checked, they are the sames, gnatmake
>> >doesn't figure out that this is a different file and doesn't recompile
>it.
>> >
>>
>> ... because it looks like the file attributes have been dicked
>> around with.  To get similar symptons, I suggest you open the case on
>> your workstation and pour soy sauce on your circuit boards.
>>
>
>A very simple and normal use of cvs without any "dick around" shows the
>problem.
>Just try ...
>

I would never be caught using CVS in a closed developement
environment.  Boy, I feel the urge to merge; let's see I will
grab this set of files that my colleague might be working on and
then add some code.  We will merge our way out of any mess we create.

A process that does not trust gnatmake to do a bulletproof build, yet
trusts wing-and-a-prayer merging techniques isn't worth arguing over.

Re: What happens to DEC Ada?

[Robert Dewar]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<NKj7nYr7sQCg@eisner.encompasserve.org>...
> Although I rejoice in, and benefit from, smart recompilation, I think > of it as something related to the "keep a database of previous 
> compilation results" approach to compilation environment design.  
> GNAT, and for that matter AdaMagic, take the "rescan the source each 
> time" approach, so to implement smart recompilation would seem 
> counter-cultural.


Well I guess this can seem counter-cultural if you are not familiar
with GNAT technology, but in fact the notion of smart recompilation
fits perfectly well. Indeed GNAT *has* a (very limited) notion of
smart recompilation (you can use the appropriate option, look in the
documentation, to request a mode in which reformatting, addition or
deletion of comments etc, is ignored and does not cause recompiles).

It would be technically feasible to do more, but simply not technically
worthwhile. Smart recompilation adds basic overhead to all compiles,
so overall it would not be a win. There are of course special cases
where it might help, but overall, our analysis is that it is a loss.

Re: What happens to DEC Ada?

[Marin David Condic]

In my experience, a body of code has to get *pretty large* before a
recompile of the entire thing starts to become painful. (Especially with
today's high speed processors.) It has to get even larger than that before
the customary Gnat timestamp method of determining what needs to be
recompiled becomes painful. IMHO, effort expended to avoid a few more files
that might not actually need to be recompiled isn't worth it. I'd
concentrate on bigger problems and count on hardware to keep pace with the
size of the project. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0108031100.2be1c7d6@posting.google.com...
>
> Well I guess this can seem counter-cultural if you are not familiar
> with GNAT technology, but in fact the notion of smart recompilation
> fits perfectly well. Indeed GNAT *has* a (very limited) notion of
> smart recompilation (you can use the appropriate option, look in the
> documentation, to request a mode in which reformatting, addition or
> deletion of comments etc, is ignored and does not cause recompiles).
>
> It would be technically feasible to do more, but simply not technically
> worthwhile. Smart recompilation adds basic overhead to all compiles,
> so overall it would not be a win. There are of course special cases
> where it might help, but overall, our analysis is that it is a loss.

Re: What happens to DEC Ada?

[Wes Groleau]

> In my experience, a body of code has to get *pretty large* before a
> recompile of the entire thing starts to become painful. (Especially with

We have about 20,000 Ada files, many of them VERY large,
and if ALL are obsolete (forced to be), we can code all
in ten hours on ONE processor with Apex.  Faster with
GNAT.  When only a few hundred are obsolete, Apex takes
longer to figure out which ones than it does to actually
compiler them.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: What happens to DEC Ada?

[Robert Dewar]

Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message news:<3B6B04F0.63E9602B@sparc01.ftw.rsc.raytheon.com>...
> > In my experience, a body of code has to get *pretty large* before a
> > recompile of the entire thing starts to become painful. (Especially with
> 
> We have about 20,000 Ada files, many of them VERY large,
> and if ALL are obsolete (forced to be), we can code all
> in ten hours on ONE processor with Apex.  Faster with
> GNAT.  When only a few hundred are obsolete, Apex takes
> longer to figure out which ones than it does to actually
> compiler them.


Note that one advantage of the very simple compilation model in GNAT
is that it is perfectly straightforward to make full use of multiple
processors. Indeed it often helps to use -j2, to launch two separate
compilation processes even if you have only one processor. I would
expect that your 10 hour compilation would take much less than an
hour on a big SGI multi-processor :-)

Re: What happens to DEC Ada?

[Marin David Condic]

Well, 20,000 files certainly qualifies in my mind as "pretty large". That's
an unusual sized project - I'll bet that of all the Ada projects in all the
world, that may rank in say the top 5%? It certainly isn't center of the
bell curve.

Obviously in a case like that, minimizing recompilation is a noble goal.
However, I'd suspect that there are cases where it takes more time to try to
reduce the number further than to simply take the hit & recompile. Once
you've gone to the effort of scanning the file to determine if it *really*
needs to be recompiled, you probably should just go ahead and recompile it.
(Maybe a smart editor and a project database could spread the load to
edit-time rather than compile-time? But that would start me haranguing on
how wonderful it would be for Ada to have a really spiffy IDE with
seamlessly integrated tools, etc. :-)

And of course usually the less expensive option is to apply faster hardware.
Depends on the environment you work in. I once worked for a defense
contractor in New Jersey that did lots of cost-plus projects. Engineers
spent huge amounts of time in line waiting to xerox stuff because there was
only one available xerox machine. "Buy More" seems the obvious answer.
However, an engineer's time on a cost-plus contract was making money. A
xerox machine was a capital expenditure that couldn't be billed back
entirely to the government. So I could imagine situations in which it would
be more profitable to make the engineers wait for massive recompiles - or
laboriously figure it out by longhand. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3B6B04F0.63E9602B@sparc01.ftw.rsc.raytheon.com...
>
> We have about 20,000 Ada files, many of them VERY large,
> and if ALL are obsolete (forced to be), we can code all
> in ten hours on ONE processor with Apex.  Faster with
> GNAT.  When only a few hundred are obsolete, Apex takes
> longer to figure out which ones than it does to actually
> compiler them.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: What happens to DEC Ada?

[Greg Bek]

The DEC Ada smart compilation mechansim was based on the
research into compilation signatures by W Tichy (spelling?),
of RCS fame.

The mechansims that Rational Apex uses are also based on
that research, although the two different implementations
do differ.

Interestingly in the original paper (my copy has long since
dissapeared) Tichy thought that the technique would be most
appropriate for C and Pascal, he thought that it had little
relevance to Ada (at least that's how I remember it).  The
only two commercial implementations of it that I'm aware of
were the above two Ada compilers.

I'm suprised to find GNAT faster than Apex for a really
large set of source files.  My own experience is that for
a large program Apex is usually 20% - 50% faster to
compile a system from scratch.  Now the definition of "large"
for me is at least 20KSLOC.  Apex is not a very fast compiler
of hello_world.

Our experience is that the stored representation (DIANA) of the 
already compiled units does have a significant impact on 
the compilation performance of units that follow.  But as
people have pointed out, building that representation and
then using imposes an overhead.

And when it comes to recompilation, I'm in no doubt about
the benefit of the DIANA.  Sure it takes time to read, but
the ability of the compiler to compare change sets of the
underlying declaration signatures means that for many dependent 
units the compiler doesn't even need to recompile them.  For some
class of changes to specifications the compilation system
knows that no dependent units could have been affected so
there is no recompilation at all of any dependents.

But situations differ, so the usual "your mileage will vary"
disclaimer applies.

Greg

"Marin David Condic" <dont.bother.mcondic.auntie.spam@acm.org> wrote in message news:<9km9bd$dg7$1@nh.pace.co.uk>...
> Well, 20,000 files certainly qualifies in my mind as "pretty large". That's
> an unusual sized project - I'll bet that of all the Ada projects in all the
> world, that may rank in say the top 5%? It certainly isn't center of the
> bell curve.
> 
> Obviously in a case like that, minimizing recompilation is a noble goal.
> However, I'd suspect that there are cases where it takes more time to try to
> reduce the number further than to simply take the hit & recompile. Once
> you've gone to the effort of scanning the file to determine if it *really*
> needs to be recompiled, you probably should just go ahead and recompile it.
> (Maybe a smart editor and a project database could spread the load to
> edit-time rather than compile-time? But that would start me haranguing on
> how wonderful it would be for Ada to have a really spiffy IDE with
> seamlessly integrated tools, etc. :-)
> 
> And of course usually the less expensive option is to apply faster hardware.
> Depends on the environment you work in. I once worked for a defense
> contractor in New Jersey that did lots of cost-plus projects. Engineers
> spent huge amounts of time in line waiting to xerox stuff because there was
> only one available xerox machine. "Buy More" seems the obvious answer.
> However, an engineer's time on a cost-plus contract was making money. A
> xerox machine was a capital expenditure that couldn't be billed back
> entirely to the government. So I could imagine situations in which it would
> be more profitable to make the engineers wait for massive recompiles - or
> laboriously figure it out by longhand. :-)
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> 
> "Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
> news:3B6B04F0.63E9602B@sparc01.ftw.rsc.raytheon.com...
> >
> > We have about 20,000 Ada files, many of them VERY large,
> > and if ALL are obsolete (forced to be), we can code all
> > in ten hours on ONE processor with Apex.  Faster with
> > GNAT.  When only a few hundred are obsolete, Apex takes
> > longer to figure out which ones than it does to actually
> > compiler them.
> >
> > --
> > Wes Groleau
> > http://freepages.rootsweb.com/~wgroleau

Re: What happens to DEC Ada?

[Robert Dewar]

gab@rational.com (Greg Bek) wrote in message news:<afb6d339.0108081124.4071a24d@posting.google.com>...

> I'm suprised to find GNAT faster than Apex for a really
> large set of source files.  My own experience is that for
> a large program Apex is usually 20% - 50% faster to
> compile a system from scratch.  Now the definition of "large"
> for me is at least 20KSLOC.  Apex is not a very fast compiler
> of hello_world.

Well Greg no doubt knows how to use the Rational compiler to best
advantage :-) and not surprisingly our skill is in the opposite
direction. But we have many customers who have found GNAT to be
faster than APEX when things are done in the most efficient
manner. This is especially true on a large multi-processor. Even
on a single processor, if there are sufficient resources, then
it is often worth using a -j switch to run multiple compilation
processes at the time.

To get a feeling for the speed of GNAT, the GNAT sources, about
300,000 lines compile in under 3 mins on my note book (which is
only 850MHz with a fairly slow disk). In practice that's fast
enough for most purposes. Of course mileage can vary, and a very
large system with very extensive inlining compiled with -gnatN
can take a lot of resources.

Re: What happens to DEC Ada?

[Wes Groleau]

> I'm suprised to find GNAT faster than Apex for a really
> large set of source files.  My own experience is that for

For the "all files" case, GNAT is faster, but not by much,
in SINGLE THREAD mode.

However, because GNAT has no "DIANA" it can easily do many
files in parallel.  Try that with Apex on this big a set of
files (most with LOTS of context clauses) and invariably
there will be a collision on the same file, resulting in
"severe errors" which means a large portion of the job must
be repeated.

When doing _only_ obsolete files and only a small percentage
of the job, Apex does not usually have that problem and we can
work in parallel.  However, even with more than two dozen
processors, the time savings is only 60 percent.  With the
size of our project, Apex takes a long time to figure out
which files are obsolete.

In fact, if NO files are obsolete, Apex takes quite a while
to verify that.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: What happens to DEC Ada?

[Charlie McCutcheon]

DEC Ada became rebranded to Compaq Ada and is still supported for OpenVMS
VAX and Alpha.

See our web page;
http://www.openvms.compaq.com/commercial/ada/ada_index.html for more
information.

Charlie McCutcheon
Compaq Ada project leader

PS - I only get in this conference about once a week at most...

Adrian Hoe wrote:

> Hello,
>
> I wonder what has happened to DEC Ada after COMPAQ acquired DEC. Does
> anyone have some info?
>
> Thanks.

Re: What happens to DEC Ada?

[Gautier Write-only-address]

An interesting and successful way of storing compilation
informtations is how the Borland Pascal compilers do
create and use the "TPU" data. It is certainly the
fastest compilation system - although of course some
points like the non-separation spec/body can be discussed.

A search on the Web shows that a big work has be done
to decrypt and understand these files - and one sees
sometimes even the sources of a Turbo Pascal compiler...
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: Do not answer to sender address, visit the Web site!
    Ne r�pondez pas � l'exp�diteur, visitez le site ouaibe!



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp