Re: gnat310p on NT

["bob" <bklungle@badger1.net>]

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
> 
> 
> 
>