objectada for GREAT programs ?

objectada for GREAT programs ?

[Walter Leidenfrost]

Are there any experiences with Objectada for winNT,
as far as handling of real HUGE sources (all in all approx. 7MB) are
concerned ? Compilation times, etc ?


ThanX for any tips,
Walter Leidenfrost
(Alcatel Austria)

Re: objectada for GREAT programs ?

[Kevin Radke]

In article <326E457E.41C67EA6@aut.alcatel.at>, Walter Leidenfrost
<leidenfr@aut.alcatel.at> wrote:

> Are there any experiences with Objectada for winNT,
> as far as handling of real HUGE sources (all in all approx. 7MB) are
> concerned ? Compilation times, etc ?

I (re)compile 200k+ lines of code on a regular basis.  Code alone is
at least 20Mb, with the largest executable almost 10meg in size.  Total
build directory size is well over 200Mb.  The whole thing usually
takes around 2.5 hours to build from scratch on a P120
with 32Mb of memory.  Would do better with more memory and
a fast SCSI drive instead of IDE...

Kevin

-- 
/\/\Under Construction/\/\ kmradke@inav.net

Re: objectada for GREAT programs ?

[Robert A Duff]

In article <kmradke-2410961946480001@dip22.inav.net>,
Kevin Radke <kmradke@inav.net> wrote:
>I (re)compile 200k+ lines of code on a regular basis.  Code alone is
>at least 20Mb, with the largest executable almost 10meg in size.

Are you saying your source code is 200K lines, and 20Mb?  That's an
average of 100 characters per line.  Most Ada code I've seen is around
30 characters per line, on average.  Am I misunderstanding your figures?
Or is there a typo somewhere there?

>...  Total
>build directory size is well over 200Mb.  The whole thing usually
>takes around 2.5 hours to build from scratch on a P120
>with 32Mb of memory.  Would do better with more memory and
>a fast SCSI drive instead of IDE...

- Bob

Re: objectada for GREAT programs ?

[Kevin Radke]

In article <Dzu7H9.323@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

> In article <kmradke-2410961946480001@dip22.inav.net>,
> Kevin Radke <kmradke@inav.net> wrote:
> >I (re)compile 200k+ lines of code on a regular basis.  Code alone is
> >at least 20Mb, with the largest executable almost 10meg in size.
> 
> Are you saying your source code is 200K lines, and 20Mb?  That's an
> average of 100 characters per line.  Most Ada code I've seen is around
> 30 characters per line, on average.  Am I misunderstanding your figures?
> Or is there a typo somewhere there?

I suppose confusion of terminology.  My lines of code does NOT count
comments, and this code is HEAVILY commented.  The actual lines of
code counting comments is at least double the original amount.
(The 20Mb is a rough guess too.  That includes some extra junk
that isn't truely ada source.)

Kevin

-- 
/\/\Under Construction/\/\ kmradke@inav.net

Re: objectada for GREAT programs ? - SLOC phys vs logical?

[Robert S. White]

In article <kmradke-2610961017440001@dip24.inav.net>, kmradke@inav.net says...
...snip...
>I suppose confusion of terminology.  My lines of code does NOT count
>comments, and this code is HEAVILY commented.  The actual lines of
>code counting comments is at least double the original amount.

  Come on!  This seems like a perfect troll to get into a long thread
about physical SLOC (ugh!) versus logical SLOC (yah!) software metic
data collection/effort estimating.  Sigh...it seems that the OFFICIAL
channels have dictated that physical SLOC be used.  When I and most of my
co-workers estimate a software task, a mental image of the amount of
logical SLOC comes to mind.  Now if we only had a HUGE database of 
physical SLOC metrics for EXACTLY similar tasks to drawn on...

  But SEI/CMM practices will make this better eventually...hope...hope...
_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer
WhiteR@CRPL.Cedar-Rapids.lib.IA.US --long/cheap alternate I-net address

Re: objectada for GREAT programs ? - SLOC phys vs logical?

[David Weller]

In article <551f60$rig@flood.weeg.uiowa.edu>,
Robert S. White <WhiteR@CRPL.Cedar-Rapids.lib.IA.US> wrote:
>In article <kmradke-2610961017440001@dip24.inav.net>, kmradke@inav.net says...
>...snip...
>>I suppose confusion of terminology.  My lines of code does NOT count
>>comments, and this code is HEAVILY commented.  The actual lines of
>>code counting comments is at least double the original amount.
>
>  Come on!  This seems like a perfect troll to get into a long thread
>about physical SLOC (ugh!) versus logical SLOC (yah!) software metic
>data collection/effort estimating.  Sigh...it seems that the OFFICIAL
>channels have dictated that physical SLOC be used.  When I and most of my
>co-workers estimate a software task, a mental image of the amount of
>logical SLOC comes to mind.  Now if we only had a HUGE database of 
>physical SLOC metrics for EXACTLY similar tasks to drawn on...
>
>  But SEI/CMM practices will make this better eventually...hope...hope...

Just don't hope it's done the NASA way.  On the Space Station program,
they've managed to micromanage the definition of SLOC into about 20
different definitions, each one sensitive to the exact context in a
given time (meaning you can call it one thing if you're a programmer,
and another thing if you're an accountant).

It's an absolute nightmare when you get into the realm of using SLOCs
as a cost-estimation method (and if you decide to follow up this
thread, PLEASE post to comp.software-eng).  

Of course, using physical lines, IMHO, gives a very good
rough-order-of-magnitude feel for what you'll be dealing with.  In any
case, you must still understand the project development rules (do you
have to wade through 20 pages of comments embedded by the trusty CM
system that explains exactly who touched it?), the writing pattern of
the author (do they follow common style?  Is their background more
likely to yield Fortran-looking code? etc), and the given complexity
of the module (a real time scheduler, or a 3-d coordinate conversion
system, mayhave a higher complexity density than, say, a program that
declares edit fields for string processing).

Of course, it would also appear I'm going to be guilty of perpetuating
this thread in an inappropriate newsgroup :-)

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
     This is not your father's Ada -- www.adahome.com <== Note new URL!