Re: gnat310p on NT

Re: gnat310p on NT

[Robert Dewar]

Bob said

<<Anyone using NT gnat? Have a 4400 line package (body) running on Linux and
 wanted to run it on NT. AdaGide croaked big time. Said code was too big and
 to try with "colorizing off". Did this and couldn't save the .ini. It
 locked up and had to use NT Task-Master to kill the Gide process. Cut the
 size of the package down by 1500 lines (just cut them out) to see what
 would happen. Could then scroll and save until I did a compile. Gide locked
 up. Had to kill it. After doing this 4 times, started getting messages
 saying NT thought the source was on a CD drive and door was open. Had to
 reboot. The NT4.0 system has 64Meg ram and 11.5GB disk with Dual PPro/180.
 Task Master shows not running out of memory (44MB reported free when Gide
 loaded). Doesn't appear to be any way to configure AdaGide to allow more
 memory/larger programs. Compiling with listing to a file finally allowed
 ONE (1) complete pass without crashing. Closing the source window also
 killed the Gide. Any clues???
>>

The version of AdaGIDE included in 3.10p is an old version intended only
for use with small student programs. Even a 2900 line package body does
not qualify!

We originally expected AdaGIDE to be restricted to this kind of use, but in
fact have found that customers found it a useful tool even for large
production problems, and the current version of AdaGIDE, which can be
obtained directly from its author, Martin Carlisle, and which is
distributed with the current version of GNAT, can handle much larger
programs.

Note that there is absolutely no requirement to use AdaGIDE with NT GNAT.
You can use EMACS or any other PC editor to prepare files, and then run
GNAT in command line mode (you may find it convenient to use BASH) just
as you would on any Unix system.

Re: gnat310p on NT

[David C. Hoos, Sr.]

bob wrote in message <01bdc744$cef04bc0$0e2915c0@w95>...
>Anyone using NT gnat? Have a 4400 line package (body) running on Linux and
>wanted to run it on NT. AdaGide croaked big time. Said code was too big and
>to try with "colorizing off". Did this and couldn't save the .ini. It
>locked up and had to use NT Task-Master to kill the Gide process. Cut the
>size of the package down by 1500 lines (just cut them out) to see what
>would happen. Could then scroll and save until I did a compile. Gide locked
>up. Had to kill it. After doing this 4 times, started getting messages
>saying NT thought the source was on a CD drive and door was open. Had to
>reboot. The NT4.0 system has 64Meg ram and 11.5GB disk with Dual PPro/180.
>Task Master shows not running out of memory (44MB reported free when Gide
>loaded). Doesn't appear to be any way to configure AdaGide to allow more
>memory/larger programs. Compiling with listing to a file finally allowed
>ONE (1) complete pass without crashing. Closing the source window also
>killed the Gide. Any clues???
>
This is not a gnat problem at all (except to the extent that AdaGIDE is
distributed with gnat), but only with AdaGIDE.  I have experienced the same
problem, but only with code written by others, for I fervently believe that
any code more than a few hundred lines in a file needs to be restructured.

For example, the bodies of subprograms and/or tasks can (should IMHO) be
made separates.

Incidentally, If you haven't done so already, you should get version 6.20 of
AdaGIDE at:
ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/adagide/agide620.zip

If you really want to find out how to increase the capacity of AdaGIDE to
handle larger source files, download the code from:
ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/adagide/agsrc620.zip
and have a go at it.  I'm sure Martin will appreciate the contribution.

Re: gnat310p on NT

[dennison]

In article <0QXRrq2x9GA.123@samson.airnet.net>,

> This is not a gnat problem at all (except to the extent that AdaGIDE is
> distributed with gnat), but only with AdaGIDE.  I have experienced the same
> problem, but only with code written by others, for I fervently believe that
> any code more than a few hundred lines in a file needs to be restructured.

Amen. With that much code, there's bound to be a couple of packages worth of
functionality hidden in there.

> For example, the bodies of subprograms and/or tasks can (should IMHO) be
> made separates.

I thought gnat didn't do separates. Has this changed?

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: gnat310p on NT

[Robert Dewar]

T.E.D. said

<<I thought gnat didn't do separates. Has this changed?
>>

Of course GNAT "does separates". The proper processing of subunits
is required by the RM, and so of course GNAT handles them. Furthermore
GNAT guarantees that, unlike the case with many Ada compilers, there is
never any runtime efficiency penalty from making a subprogram or package
into a subunit.

Re: gnat310p on NT

[Stephen Leake]

dennison@telepath.com wrote:
> 
> 
> I thought gnat didn't do separates. Has this changed?

You may be remembering that GNAT (let's get the capitalization right :)
doesn't separately compile separate units (ie, doesn't produce an object
file). But since 'separate' is Ada syntax, GNAT does it - by compiling
the separate body when the parent body is compiled. At the risk of
sounding heretical, think of 'separate' as '#include'.

-- Stephe

Re: gnat310p on NT

[Robert Dewar]

Stephen says

<<You may be remembering that GNAT (let's get the capitalization right :)
doesn't separately compile separate units (ie, doesn't produce an object
file). But since 'separate' is Ada syntax, GNAT does it - by compiling
the separate body when the parent body is compiled. At the risk of
sounding heretical, think of 'separate' as '#include'.
>>


No, that's not right, GNAT can fully compile separates in the sense of
the RM, e.g. checking for all semantic errors, as required by the RM, and
as is most certainly NOT possible for #include as used in C.

What GNAT does is to delay the generation of object code until the
parent is compiled. This delay is an optimization that ensures the
generation of efficient code without any penalty from the use of
separates. In many Ada compilers, the separate generation of code
means that worst case assumptions have to be made (e.g. the parent 
has to assume that tasks *might* be present in a subunit), and 
consequently there is a runtime penalty for the use of subunits.

Robert Dewar
Ada Core Technologies

Re: gnat310p on NT

[Robert Dewar]

David Hoos says

<<This is not a gnat problem at all (except to the extent that AdaGIDE is
distributed with gnat), but only with AdaGIDE.  I have experienced the same
problem, but only with code written by others, for I fervently believe that
any code more than a few hundred lines in a file needs to be restructured.

For example, the bodies of subprograms and/or tasks can (should IMHO) be
made separates.
>>


I see no reason for such small limits on file sizes, and there are often
good reasons for packages being a few thousand lines long. There is really
no need to fragment things into lots of separate files just for the sake of
keeping file sizes small. As long as file sizes are compatible with the
style of development, e.g. don't take too long to compile, are suitable for
editing by one person, and are readable and organized, the fetish that says
that any long file is bad seems as misguided as the fetish that any goto
is misguided.

Note in particular that if you have a large case statement, the language
provides no way of abstracting the strucutre into smaller files anyway


Note also that the point that individual *proicedures* as opposed to files
should be kept short is a separate issue, but here too we run into the issue
of theinability to abstract case statements.

By the way, note that David's rule would mean that a 2 million line program
was committed to being chopped up into some 10,000 files. In my experience,
this kind of level of fragmentation is NOT helpful in large projects.

A good question to ask in response to this position (which is not unusual)
is *why* it is a good idea to keep files this small.

As I say, the conditions vary. In the case of the Realia COBOL compiler,
the code generator was a single 35,000 line file. Not because, contrary
to typical uninformed opinion, COBOL has no nice way of breaking things up
into multiple files, but because only one person ever worked on this file
(me) and it took only 20 seconds to compile on a slowish (386 25 MHz) PC
which was quite acceptable.

But if you have lots of people working on a project, you definitely want to
keep files at an approipriate granularity so people do not step on one
anothers toes too much.

Re: gnat310p on NT

[Andi Kleen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
> As I say, the conditions vary. In the case of the Realia COBOL compiler,
> the code generator was a single 35,000 line file. Not because, contrary
> to typical uninformed opinion, COBOL has no nice way of breaking things up
> into multiple files, but because only one person ever worked on this file
> (me) and it took only 20 seconds to compile on a slowish (386 25 MHz) PC
> which was quite acceptable.

You don't want to say with this that the code generator was writen in COBOL?

-Andi

Re: gnat310p on NT

[Robert Dewar]

Andi asks

<<> As I say, the conditions vary. In the case of the Realia COBOL compiler,
> the code generator was a single 35,000 line file. Not because, contrary
> to typical uninformed opinion, COBOL has no nice way of breaking things up
> into multiple files, but because only one person ever worked on this file
> (me) and it took only 20 seconds to compile on a slowish (386 25 MHz) PC
> which was quite acceptable.

You don't want to say with this that the code generator was writen in COBOL?
>>



I am not quite sure of the sense of Andi's question, but yes, the Realia
COBOL compiler is 100% written in COBOL, and so yes of course, the code
generator is written in COBOL.

Re: gnat310p on NT

[Chris Morgan]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> As I say, the conditions vary. In the case of the Realia COBOL compiler,
> the code generator was a single 35,000 line file. Not because, contrary
> to typical uninformed opinion, COBOL has no nice way of breaking things up
> into multiple files, but because only one person ever worked on this file
> (me) and it took only 20 seconds to compile on a slowish (386 25 MHz) PC
> which was quite acceptable.

"When I were a lad" our Ada compiler wouldn't have compiled such a
file as it seemed to have a hard limit of 32767 lines in a source
file. I found this out the hard way. Of course it would spend a long
time thinking about longer files before giving up, but then it was on
a VAX. Twenty seconds wasn't long enough for "hello world" if my
memory serves me correctly. "you tell kids today and they WONT believe
you". ;)

Chris

-- 
Chris Morgan <mihalis at ix.netcom.com> http://www.netcom.com/~mihalis

Re: gnat310p on NT

[Martin C. Carlisle]

In article <0QXRrq2x9GA.123@samson.airnet.net> you write:
>bob wrote in message <01bdc744$cef04bc0$0e2915c0@w95>...
>>Anyone using NT gnat? Have a 4400 line package (body) running on Linux and
>>wanted to run it on NT. AdaGide croaked big time. Said code was too big and
>>to try with "colorizing off". Did this and couldn't save the .ini. It
>>killed the Gide. Any clues???

>For example, the bodies of subprograms and/or tasks can (should IMHO) be
>made separates.

I strongly agree with the above comment.

>Incidentally, If you haven't done so already, you should get version 6.20 of
>AdaGIDE at:
>ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/adagide/agide620.zip

Nonetheless, in deference to people who think 64K as a max file size was
just too small, AdaGIDE 6.20 should support files of size up to 1MB.
In the source, this type of thing is found in limits.ads

In general, if you are tyring to distinguish between a GNAT problem and an
AdaGIDE problem, try doing the compilation from the command line.  If that
succeeds and within AdaGIDE fails, then I would be the right person to
contact.  If you can't compile from the command prompt either, you have
a GNAT configuration problem.  

--Martin
-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.
-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.

Re: gnat310p on NT

[bob]

David C. Hoos, Sr. <david.c.hoos.sr@ada95.com> wrote in article
<0QXRrq2x9GA.123@samson.airnet.net>...
> 
> bob wrote in message <01bdc744$cef04bc0$0e2915c0@w95>...
> >Anyone using NT gnat? Have a 4400 line package (body) running on Linux
and
> >wanted to run it on NT. AdaGide croaked big time. Said code was too big
and
> >to try with "colorizing off". Did this and couldn't save the .ini. It
> >locked up and had to use NT Task-Master to kill the Gide process. Cut
the
> >size of the package down by 1500 lines (just cut them out) to see what
> >would happen. Could then scroll and save until I did a compile. Gide
locked
> >up. Had to kill it. After doing this 4 times, started getting messages
> >saying NT thought the source was on a CD drive and door was open. Had to
> >reboot. The NT4.0 system has 64Meg ram and 11.5GB disk with Dual
PPro/180.
> >Task Master shows not running out of memory (44MB reported free when
Gide
> >loaded). Doesn't appear to be any way to configure AdaGide to allow more
> >memory/larger programs. Compiling with listing to a file finally allowed
> >ONE (1) complete pass without crashing. Closing the source window also
> >killed the Gide. Any clues???
> >
> This is not a gnat problem at all (except to the extent that AdaGIDE is
> distributed with gnat), but only with AdaGIDE.

I didn't mean to imply it was GNAT. I did know that the problem was the
Gide.

> I have experienced the same
> problem, but only with code written by others, for I fervently believe
that
> any code more than a few hundred lines in a file needs to be
restructured.
> 
This code was written by several others.

> For example, the bodies of subprograms and/or tasks can (should IMHO) be
> made separates.
> 
I used to be as fervent about this as you, but about 7 years ago I was
called in to find out why a large system took 6.5 hours to compile. This
was a near production system so I didn't have the option to rewrite it.
After some experimenting, we found that if we pullied all of the separates
back into their parent packages, the compilation time fell to 1.2 hours.
Apparently the time to open and close files is a significant percentage of
compilation time. So now I advocate separates during development, but merge
them as they become completed (through thourough testing). The reduced
number of files to manage also helps out the SCM and T&E people.
In addition we found that the Verdix debugger frequently loses track of
symbol tables when crossing into and out of separates.

> Incidentally, If you haven't done so already, you should get version 6.20
of
> AdaGIDE at:
> ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/adagide/agide620.zip
> 
I have taken your suggestion and downloaded the 6.20. Will check it out.
TKS

> If you really want to find out how to increase the capacity of AdaGIDE to
> handle larger source files, download the code from:
> ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/adagide/agsrc620.zip
> and have a go at it.  I'm sure Martin will appreciate the contribution.

I downloaded the source and will do as you suggest. If I can find "Martins"
address, will send him everything I do. I do have access to the source for
a debugger which works very much like the VC++ debugger. Will try inserting
it. Also will try inserting option of selecting editor of users choice (and
whatever else comes to mind, time permitting).
> 
> 
Again, TKS for your INFO.

bob
> 
> 
> 
> 

Re: gnat310p on NT

[David C. Hoos, Sr.]

bob wrote in message <01bdc7e9$195db180$0f2915c0@wnt>...

>I used to be as fervent about this as you, but about 7 years ago I was
>called in to find out why a large system took 6.5 hours to compile. This
>was a near production system so I didn't have the option to rewrite it.
>After some experimenting, we found that if we pullied all of the separates
>back into their parent packages, the compilation time fell to 1.2 hours.
>Apparently the time to open and close files is a significant percentage of
>compilation time. So now I advocate separates during development, but merge
>them as they become completed (through thourough testing). The reduced
>number of files to manage also helps out the SCM and T&E people.
>In addition we found that the Verdix debugger frequently loses track of
>symbol tables when crossing into and out of separates.
>

Well, I have to admit that Verdix (with which I have many years of unhappy
experience) does have the problems you describe.  But this is more a
function
of the "heavy" library model used by many Ada83 copilers.  Remeb\mber that
Verdix opens at least four (and sometimes many more) files for every source
file.

Gnat, on the other hand will write only one object file and one .ali file
when
compiling a package body, regardless of whether the source is all in one
file
or in separate units.

There is a certain sense in which the Gnat compilation model might at first
seem less efficient because "separates" are not (cannot be) compiled
separately at all, but the code of separates is "included" in the
compilation
stream of its parent unit.

The beauty of the Gnat compilation model is that no compilation order is
imposed, from which it follows that (unlike Verdix, et. al.) it is
impossible to
invalidate compilations by the recompilation of a unit on which other iunits
depend.

Our experience is that not only does Gnat compile faster from the start, but
that far fewer recompilations are needed with gant, given the same source
code change sequences.

>I downloaded the source and will do as you suggest. If I can find "Martins"
>address, will send him everything I do.

Martins address is on the Help->About  box of AdaGIDE -- mcc@cs.usafa.af.mil

> I do have access to the source for
>a debugger which works very much like the VC++ debugger. Will try inserting
>it. Also will try inserting option of selecting editor of users choice (and
>whatever else comes to mind, time permitting).


Have you tried the gdb-tcl/tk debugger for gnat NT?  It's at:
ftp://ftp.cs.nyu.edu/pub/gnat/winnt/gdb-3.10p-nt.exe

As far as IDEs for gnat are concerned, AdaGIDE suffers from one
limitation --
i.e., it is only for the Win32 platform.

There are two Gnat-aware IDEs which are available for UNIX as well
as Win32 platforms, viz.:

Grasp (Graphical Representations of Algorithms, Structures and Processes)
available at:
http://www.eng.auburn.edu/department/cse/research/grasp/grasp.html

and Emacs with ada-mode

Beside the cross-platform advantages, these two also provide additional and
unique capabilities, but while working on Win32 I use AdaGIDE for the bulk
of
my work, it's always good to have a variety of tools in one's "toolbox."

I advise checking them out.

David C. Hoos, Sr.

Re: gnat310p on NT

[Robert Dewar]

Bob said

<<Anyone using NT gnat? Have a 4400 line package (body) running on Linux and
wanted to run it on NT. AdaGide croaked big time. Said code was too big and
to try with "colorizing off". Did this and couldn't save the .ini. It
locked up and had to use NT Task-Master to kill the Gide process. Cut the
size of the package down by 1500 lines (just cut them out) to see what
would happen. Could then scroll and save until I did a compile. Gide locked
up. Had to kill it. After doing this 4 times, started getting messages
saying NT thought the source was on a CD drive and door was open. Had to
reboot. The NT4.0 system has 64Meg ram and 11.5GB disk with Dual PPro/180.
Task Master shows not running out of memory (44MB reported free when Gide
loaded). Doesn't appear to be any way to configure AdaGide to allow more
memory/larger programs. Compiling with listing to a file finally allowed
ONE (1) complete pass without crashing. Closing the source window also
killed the Gide. Any clues???
>>

The version of AdaGIDE included in 3.10p is an old version intended only
for use with small student programs. Even a 2900 line package body does
not qualify!

We originally expected AdaGIDE to be restricted to this kind of use, but in
fact have found that customers found it a useful tool even for large
production problems, and the current version of AdaGIDE, which can be
obtained
directly from its author, Martin Carlisle, and which is used in the latest
version of GNAT