Re: THAAD Study on Ada Viability

Re: THAAD Study on Ada Viability

[Singlespeeder]

What I find fustating about ADA is the IDE. I know it was the first language
supposed to have one from the start but frankly working in defense it's
still DEC ada 83 and the DEC LSE while the rest of the world moves on. Even
ADAGIDE is a great improvement (I've even taken to developing on a PC under
ADAGIDE then FTPing back to VMS for final builds, formal testing etc).

Some of us aren't interested in a pure Ada IDE and like the way Microsoft
started to integrate all their languages in Visual Studio. There's no reason
why a third party couldn'e develop Visual Ada to go with the suite. Hey, if
someone's doing it for COBOL...

Then of course ACT looks good, and there's always jGrasp...

Has anyone got any stats on how many errors are down to environment not
language? You know, the kind that an IDE helps you spot as you're writing.

The point is though that the defense industry isn't going to upgrade the
development environment and move their development wholesale onto these
suites. Instead they'll stick with overstretched VAX/VMS machines, and an
environment that may have been hot in 1983 but doesn't cut it in the 21st
century - certainly not when trying to meet their 21st century timescales.

If Ada is dead within the defense industry I believe that it's not the fault
of the language. Rather it's the fault of the IDE, and the unwillingness of
the buyers of defense products to move with the times. Ada has shown itself
to be capable of moving on, the decision makers in the Pentagon who mandated
not just the language but the toolset have not.

Nick Wallis
singlespeeder@32sixteen.com

Re: THAAD Study on Ada Viability

[Ken Garlington]

"Singlespeeder" <singlespeeder@btinternet.com> wrote in message
news:918u24$8ms$1@neptunium.btinternet.com...
: The point is though that the defense industry isn't going to upgrade the
: development environment and move their development wholesale onto these
: suites. Instead they'll stick with overstretched VAX/VMS machines, and an
: environment that may have been hot in 1983 but doesn't cut it in the 21st
: century - certainly not when trying to meet their 21st century timescales.

I dunno... my company (Lockheed Martin Aero) is moving off of VAXen and onto
other platforms as fast as possible (including legacy programs). We are also
using far more IDEs and upper CASE tools than before.

: If Ada is dead within the defense industry I believe that it's not the
fault
: of the language. Rather it's the fault of the IDE, and the unwillingness
of
: the buyers of defense products to move with the times. Ada has shown
itself
: to be capable of moving on, the decision makers in the Pentagon who
mandated
: not just the language but the toolset have not.

To the extent that Ada is no longer being used in the defense industry, I'd
say it was due to the issues originally raised in the NAS study a few years
ago, and generally supported by the THAAD study. In particular, since (at
least for the projects I support) the "decision makers in the Pentagon" have
gotten out of the language/tool mandate (with a few interesting exceptions),
it's hard to blame them for the use of obsolete systems!

Re: THAAD Study on Ada Viability

[Robert Dewar]

In article <dQTZ5.7717$bw.686086@news.flash.net>,
> I dunno... my company (Lockheed Martin Aero) is
> moving off of VAXen and onto
> other platforms as fast as possible (including
> legacy programs). We are also
> using far more IDEs and upper CASE tools than
> before.

Hmmm! If even Ken Garlington's environment is moving
away from Vaxes, that surely is the beginning of the
end for these machines :-)



Sent via Deja.com
http://www.deja.com/

Re: THAAD Study on Ada Viability

[DuckE]

I couldn't find a copy of the official announcement, but I believe Compaq
has stopped producing VAXen altogether.

SteveD

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:91aem6$jhf$1@nnrp1.deja.com...
> In article <dQTZ5.7717$bw.686086@news.flash.net>,
> > I dunno... my company (Lockheed Martin Aero) is
> > moving off of VAXen and onto
> > other platforms as fast as possible (including
> > legacy programs). We are also
> > using far more IDEs and upper CASE tools than
> > before.
>
> Hmmm! If even Ken Garlington's environment is moving
> away from Vaxes, that surely is the beginning of the
> end for these machines :-)
>
>
>
> Sent via Deja.com
> http://www.deja.com/

Re: THAAD Study on Ada Viability

[DuckE]

"DuckE" <nospam_steved94@home.com> wrote in message
news:ZAf_5.149027$U46.4839329@news1.sttls1.wa.home.com...
> I couldn't find a copy of the official announcement, but I believe Compaq
> has stopped producing VAXen altogether.
>
Which, I might add, is why we moved from VAXeln Pascal to Ada95.  It was an
easy move.



> SteveD
>

Re: THAAD Study on Ada Viability

[Robert L. Spooner]

We have been moving from VAXELN/VAXELN Ada (83) on the KAV30 VME VAX
hosted on VAX/VMS to VxWorks/GNAT on 68060 and now/soon PowerPC hosted
on Sun/Solaris for similar reasons.  After years of DEC^H^H^HCompaq
saying "buy from us, you'll have a migration path," they ported neither
the operating system nor the compiler to the alpha and Ada95.  VAXELN
Ada was retired.  We could have gone to an alpha vme board with VxWorks,
but it was only supported under Digital unix and the lab didn't want to
support two versions of unix - we already had Sun workstations here. 
(At least they had GNAT develop a version of Ada 95 for the alpha under
VMS.)  So we went from one cpu and file system for host and target to
separate ones (eventually VxWorks worked with a unix file system through
NFS.)  It made life more difficult.  WindRiver is just now coming out
with an operating system with address space protection - something
VAXELN had over ten years ago.

Bob

DuckE wrote:
> 
> "DuckE" <nospam_steved94@home.com> wrote in message
> news:ZAf_5.149027$U46.4839329@news1.sttls1.wa.home.com...
> > I couldn't find a copy of the official announcement, but I believe Compaq
> > has stopped producing VAXen altogether.
> >
> Which, I might add, is why we moved from VAXeln Pascal to Ada95.  It was an
> easy move.
> 
> > SteveD
> >

-- 
                            Robert L. Spooner
                     Registered Professional Engineer
                       Associate Research Engineer
                  Intelligent Control Systems Department

         Applied Research Laboratory        Phone: (814) 863-4120
         The Pennsylvania State University  FAX:   (814) 863-7841
         P. O. Box 30
         State College, PA 16804-0030       rls19@psu.edu

Re: THAAD Study on Ada Viability

[Robert Dewar]

In article <3A3E6626.E1EB9369@psu.edu>,
  "Robert L. Spooner" <rls19@psu.edu> wrote:

> (At least they had GNAT develop a version of Ada 95 for the
> alpha under VMS.)

Note that the ingrediants for GNAT on Vax/VMS were always in
place, so this would have been a practical port, but neither
DEC nor any actual user was willing to fund such an effort,
so it never happened, and is certainly not going to happen now!


Sent via Deja.com
http://www.deja.com/

Re: THAAD Study on Ada Viability

[Larry Kilgallen]

In article <91o10t$k9$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <3A3E6626.E1EB9369@psu.edu>,
>   "Robert L. Spooner" <rls19@psu.edu> wrote:
> 
>> (At least they had GNAT develop a version of Ada 95 for the
>> alpha under VMS.)
> 
> Note that the ingrediants for GNAT on Vax/VMS were always in
> place, so this would have been a practical port, but neither
> DEC nor any actual user was willing to fund such an effort,
> so it never happened, and is certainly not going to happen now!

This seems to bring up a significant difference between Ada and Java.
The DEC folks backed away from Java on VAX because of a requirement
for IEEE floating point, which is not in the VAX hardware. Experiments
at emulation were S-L-O-O-O-W.

Re: THAAD Study on Ada Viability

[Robert Deininger]

On Thu, Dec 14, 2000 9:45 PM, DuckE <nospam_steved94@home.com> wrote:
>I couldn't find a copy of the official announcement, but I believe Compaq
>has stopped producing VAXen altogether.

CPU production stopped a couple of years ago.  The last order date for new
systems was the end of Sept. 2000, IIRC.  The last delivery date is the end
of this month.

Real development of the VAX CPUs stopped quite a few years ago.  The last
generation of VAX systems were basically new packaging for older CPUs.

Alpha development continues, but for the most part the alpha systems don't
support the hardware that VAXes do. In many cases, embedded systems don't
port
easily from VAX to alpha.


---------------------------
Robert Deininger
rdeininger@mindspring.com

Re: THAAD Study on Ada Viability

[Marin David Condic]

Ken Garlington wrote:

> "Singlespeeder" <singlespeeder@btinternet.com> wrote in message
> news:918u24$8ms$1@neptunium.btinternet.com...
> : The point is though that the defense industry isn't going to upgrade the
> : development environment and move their development wholesale onto these
> : suites. Instead they'll stick with overstretched VAX/VMS machines, and an
> : environment that may have been hot in 1983 but doesn't cut it in the 21st
> : century - certainly not when trying to meet their 21st century timescales.
>
> I dunno... my company (Lockheed Martin Aero) is moving off of VAXen and onto
> other platforms as fast as possible (including legacy programs). We are also
> using far more IDEs and upper CASE tools than before.
>

One of the things to note about defense systems is that they differ dramatically
from similar commercial systems in terms of their longevity. A given missile or
avionics system can easily be around in some stage of development/maintenance
for 20..30 years. (How old is the B52 bomber?) You pick a target processor,
development platform, compiler, toolset, etc. in the year 2000 and you may make
your first production delivery in 2010. You have to live with those choices
because to change over to the latest/greatest technology means a huge cost in
regression testing and re-validating the system.

I don't think defense companies are against moving to modern tools - as your
example of LMA illustrates. I think they just have a harder time doing it than
commercial endeavors might. We kind of know that instinctively because we're
insiders. Those outside the defense community may not be aware of it.

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: THAAD Study on Ada Viability

[David Gillon]

Marin David Condic wrote:

> One of the things to note about defense systems is that they differ dramatically
> from similar commercial systems in terms of their longevity. A given missile or
> avionics system can easily be around in some stage of development/maintenance
> for 20..30 years. (How old is the B52 bomber?) 

The B-52 is the classic example of programme longevity. Design started
'49, first flight '52, entered service '55, production completed '70s,
currently planned retirement date 2040....

-- 

David Gillon
BAE SYSTEMS Avionics
Rochester, Kent, UK

Re: THAAD Study on Ada Viability

[David Botton]

The ACT GUI is GLIDE an e-macs based cross platform IDE that has far more
features and flexability. AdaGIDE is intended more for student use (although
there are many in addition to yourself using it for far more).

David Botton

----- Original Message -----
From: "Singlespeeder" <singlespeeder@btinternet.com>
> ADAGIDE is a great improvement (I've even taken to developing on a PC
under

> Then of course ACT looks good, and there's always jGrasp...

Re: THAAD Study on Ada Viability

[Robert Dewar]

In article <918u24$8ms$1@neptunium.btinternet.com>,
  "Singlespeeder" <singlespeeder@btinternet.com>
wrote:

> What I find fustating about ADA is the IDE.

This is a little peculiar, *the* IDE? there are of
course many such ...

> I know it was the first language
> supposed to have one from the start

Nope, that's reinventing history. To what are you
referring?

> but frankly working in defense it's
> still DEC ada 83 and the DEC LSE while the rest of
> the world moves on.

Only a small part of the Ada world is still using
DEC Ada 83 and DEC LSE. Yes, a significant part, but
if you have the view that all DoD projects are using
this combination, you have a very narrow view of the
Ada world.

> Even ADAGIDE is a great improvement (I've even
>taken to developing on a PC under
> ADAGIDE then FTPing back to VMS for final builds,
> formal testing etc).

AdaGIDE is a nice tool for students, but there are
many IDE's out there (GLIDE, GRASP, SNIFF, APEX ...)
for serious development use. Sounds like you are
not familiar with any of these.

It really sounds like your problem is not the state
of Ada and its IDE's but rather the state of the
particular development environment you find yourself
in.

> Then of course ACT looks good

Well thanks for the comment, but I have no idea what
it means in this context, are you referring to the
use of GLIDE as your IDE?

> The point is though that the defense industry isn't
> going to upgrade the development environment and
> move their development wholesale onto these suites.
> Instead they'll stick with overstretched VAX/VMS
> machines.

Again, an amazingly narrow viewpoint. You are
assuming that the environment you work in is
the one used throughout the defense industry, but
that's entirely incorrect. Very few defense projects
are still using VAX machines.

> If Ada is dead within the defense industry I
> believe that it's not the fault
> of the language. Rather it's the fault of the IDE,
> and the unwillingness of
> the buyers of defense products to move with the
> times.

*Some* buyers of defense projects, please do not
assume your experience is typical of all projects.

>Ada has shown itself
> to be capable of moving on, the decision makers in
>the Pentagon who mandated
> not just the language but the toolset have not.

Individual programs may have mandated specific tool
sets, but the "Pentagon" never did anything of the
kind. Even early in Ada days, many different
environments, IDE's, architectures, and Ada compilers
were in use, and only a fraction used Vax'es and
DEC Ada 83. Now the fraction using this obsolete
technology is much smaller (yes, of course we know
that Ken Garlington is stuck in such an environment
:-) but he is the first to know that that does not
mean everyone else in defense is similarly stuck.

An interesting indicator here is that it would be
technically quite straighforward to port GNAT and
its IDE to a Vax, but there has never been any
serious commercial interest in doing so, from DEC
or from any user. Whereas there has been interest
in porting GNAT to all kinds of other architectures
in defense contexts, including not only standard
architectures (including OpenVMS/Alpha, which is of
course supported by GNAT) but also non main-stream
architectures such as the 750 and the i960. I am
talking here strictly about interest from the defense
community -- your community :-)


Sent via Deja.com
http://www.deja.com/

Re: THAAD Study on Ada Viability

[John English]

Robert Dewar wrote:
> In article <918u24$8ms$1@neptunium.btinternet.com>,
>   "Singlespeeder" <singlespeeder@btinternet.com>
> wrote:
> > I know it was the first language
> > supposed to have one from the start
> 
> Nope, that's reinventing history. To what are you
> referring?

Presumably the APSE. However, it's not even history -- just a dimly
remembered legend passed down from generation to generation and being
embellished as it goes... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: THAAD Study on Ada Viability

[Marin David Condic]

I remember the APSE from years and years ago. My recollection was that
there were some vague documents trying to lay out requirements without
actually dictating what the system would look like. Way too fuzzy for
anybody to take it seriously. I recall there was at least one command
line interface design presented at some SIGAda - back when we were all
still using glass teletypes. (It had Ada-like syntax and was waaaay too
verbose to be typed at a command line!) I guess the whole thing died from
lack of interest and a realization that human/computer interface designs
were changing way too fast for anything to be standardized.

There are a few things that I wish *were* standardized across all
development environments. Little things like file naming conventions
would be nice. I don't know that the world is any more ready for a common
Ada development environment now than they were back in 83. But some
standardization that made it easy to move a big wad of source code from
one development environment to another would be A Good Thing (tm).

MDC


John English wrote:

> Presumably the APSE. However, it's not even history -- just a dimly
> remembered legend passed down from generation to generation and being
> embellished as it goes... :-)

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: THAAD Study on Ada Viability

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:91aejd$jgr$1@nnrp1.deja.com...

: Individual programs may have mandated specific tool
: sets, but the "Pentagon" never did anything of the
: kind.

Well, IIRC they did try (the Navy with the ALS/N, the Air Force with AIE),
but most program managers wouldn't take on the risk.

: Even early in Ada days, many different
: environments, IDE's, architectures, and Ada compilers
: were in use, and only a fraction used Vax'es and
: DEC Ada 83. Now the fraction using this obsolete
: technology is much smaller (yes, of course we know
: that Ken Garlington is stuck in such an environment
: :-) but he is the first to know that that does not
: mean everyone else in defense is similarly stuck.

Actually, we are gradually getting ourselves "unstuck" (at some cost), in
part because almost no one provides tools for this environment anymore.
Unfortunately, the development environment obsolescence issue has people so
frightened that they want to move away from anything with a "military"
history -- including Ada.

Re: THAAD Study on Ada Viability

[Tarjei T. Jensen]

Ken Garlington wrote
>Actually, we are gradually getting ourselves "unstuck" (at some cost), in
>part because almost no one provides tools for this environment anymore.
>Unfortunately, the development environment obsolescence issue has people so
>frightened that they want to move away from anything with a "military"
>history -- including Ada.

But the civilan stuff is even more frightening with regards to obsolescence.
They frequently do things that requires you to rewrite parts of your software.
The cost is just as horrific and more often.

E.g. powerbuilder, Oracle forms.

I would not like to pay <insert vendor here> to maintain their C++ compiler for
30+ years because some project is using it. In fact, I'm pretty certain that I
would have a hard time getting the vendor to understand the issues and keep
that compiler supported.

If I were into long life projects I would want Ada. I would know that there is
an industry that understands the issues of long life cycles, safety critical
software, etc. To me that means safety and assurance.

Greetings,

Re: THAAD Study on Ada Viability

[Marin David Condic]

"Tarjei T. Jensen" wrote:

> I would not like to pay <insert vendor here> to maintain their C++ compiler for
> 30+ years because some project is using it. In fact, I'm pretty certain that I
> would have a hard time getting the vendor to understand the issues and keep
> that compiler supported.

This is seldom a real problem with any compiler. Presuming you have purchased a
compiler that is beyond being someone's Science Fair Project, you aren't going to
be turning up show-stopping bugs at every turn. By the time most projects are at
some kind of "First Release" phase, in many cases you want to freeze the version of
the compiler anyway (at least for embedded sorts of things this is rather common)
so that from a configuration management and verification viewpoint you can work
from a known quantity and be able to reproduce things properly.

I'd definitely take new releases of a compiler for some time into a 30 year
project, but well before the 30 years were up, I'd have frozen the compiler, the OS
and the rest of the development platform - until some external reality forced me to
move on! :-)

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: THAAD Study on Ada Viability

[Ken Garlington]

"Marin David Condic" <mcondic.nospam@acm.org> wrote in message
news:3A3A1B96.208E7FF2@acm.org...
: "Tarjei T. Jensen" wrote:
:
: I'd definitely take new releases of a compiler for some time into a 30
year
: project, but well before the 30 years were up, I'd have frozen the
compiler, the OS
: and the rest of the development platform - until some external reality
forced me to
: move on! :-)

Yeah, we thought we were going to do that with our VAXen. After all, that's
the approach we had used on every previous program. However, there's some
ugly consequences: (a) it runs at cross-purposes with another popular
corporate trend - standardizing on a single (yet evolving) platform to
reduce cost; (b) it makes it even more difficult to attract quality software
engineers to the project; and (c) it assumes that you're also going to be
able to freeze your target architecture (e.g. MIL-STD-1750, MIL-STD-1553...)
which is also no longer realistic.
:

Re: THAAD Study on Ada Viability

[Marin David Condic]

Maybe those are the "external realities" I alluded to? :-)

Here's the way I see it: The importance of freezing of the environment is in
direct proportion to the cost of verification. If you cobble something together
that computes loan amortization on a Windows platform and basically all you do
is "smoke testing" then hand it off to your customers, there isn't much to worry
about. If you spend millions (billions?) of dollars going through various stages
of testing for an embedded product that *must* work without error, changing the
environment means going back and spending that same millions of $$$ to
re-validate the system if, for example, you change compilers, processors,
communications hardware, etc. Wellllll..... *maybe* you can eliminate *some* of
the testing, reducing it to just demonstrating the same functionality you had
before and lack of errors in the software. But it could still cost *a lot* to
do.

Now sometimes, the economics of it become ridiculus. If your chip maker decides
to shut down production due to lack of interest, what are you going to do? Open
up your own silicon foundry? Guess you're going to have to buy a different
processor and start revalidating your software. :-)

Of course you might freeze versions of a compiler even on fairly short-lived and
non-critical projects just because it is working "good enough" and you don't
want to take the chance of introducing new bugs.

MDC

Ken Garlington wrote:

> Yeah, we thought we were going to do that with our VAXen. After all, that's
> the approach we had used on every previous program. However, there's some
> ugly consequences: (a) it runs at cross-purposes with another popular
> corporate trend - standardizing on a single (yet evolving) platform to
> reduce cost; (b) it makes it even more difficult to attract quality software
> engineers to the project; and (c) it assumes that you're also going to be
> able to freeze your target architecture (e.g. MIL-STD-1750, MIL-STD-1553...)
> which is also no longer realistic.
> :

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: THAAD Study on Ada Viability

[Robert Dewar]

In article <90nq6h$3l9$1@nnrp1.deja.com>,
  n_brunot@my-deja.com wrote:

> Today, NO Ada 95 compiler can fully replace our 5
> year old Ada83 compiler without severe regression.
> This is a fact ... and so compiler availability is
> a real concern.

Well it *might* be a fact, but I doubt you have
the data to support the claim. For example, you
certainly are not a customer of ACT or ACTE, so
your statement certainly does not include GNAT
Professional. Perhaps you are a customer of
OCS, Rational, Greenhills, Aonix, Irvine, DDC/I,
... (sorry if I forgot any), and can thus make a
fully informed statement for other compilers, but I
doubt it :-)

One thing that tends to happen with large legacy
codes is that they have been kicked, tuned, pushed,
and generally molested over the years to work well
with some legacy compiler and to circumnavigate bugs
in the old compiler. Then when you port to
ANY other compiler, you find five things:

1. Errors in the program that were not apparent in
the earlier use -- a very common case for example is
missing pragma Elaborate statements.

2. Implementation dependent stuff that happened to
work in some older compiler and works no longer.

3. Stuff that works only because of bugs in the old
compiler which are corrected in the new compiler.

4. Performance issues. Sometimes these are indeed
significant differences in performance. Other times
they simply reflect the fact that code has been tuned
to meet the particular behavior of another compiler.
One really nasty case we had of performance
degradation turned out to be a program which read the
value of an environment variable in the inner
computational loop of the program -- it read the same
variable over and over again -- and apparently VADS
cached the result so this rather peculiar programming
decision did not have much impact. When we moved the
read out of the loop, all was well again.

5. Finally you may indeed run into some problems and
bugs in the new technology. How much of a problem
that is will depend on how easy it is to work around
these problems, and how easily problems that cannot
be worked around can be fixed. That is of course a
function of the support you get from your vendor.

Certainly there are no bug free Ada 83 compilers.
Even DEC Ada, which I think most people would
consider to be one of the best Ada 83 compilers has
many bugs (we found quite a few serious ones as we
ported GNAT to VMS -- for example, there were some
tests in the DEC test suite that we failed because
the test was expecting the wrong thing :-)

Milage may vary of course, but our general experience
is that in porting large legacy codes at this stage
with GNAT Professional, although we certainly get
some cases of 5 (bugs in GNAT), they are usually
relatively easily dealt with, and the more serious
problems in moving to GNAT are in categories 1 and 2.
(elaboration problems are often very annoying, and
are almost entirely a matter of incorrect code that
happened to work before). Certainly there are some
cases where performance problems and other bugs are
significant and require work, but in most cases, this
is not the most significant porting issue
(although this presumes support from
us, and it is not so much of a surprise that Nicolas
Brunot runs into more troubles trying to do serious
work with the public version of GNAT).

Robert Dewar
Ada Core Technologies


Sent via Deja.com
http://www.deja.com/