How to debug an Ada program

How to debug an Ada program

[mauricio]

Hi all, I used to program with C, but now I'm switching to Ada95 in 
linux debian with gnat. How do I trace a program line by line? Thanks in 
advance


--
Mauricio Tellez
Mexico

Re: How to debug an Ada program

[Preben Randhol]

mauricio@solucioninformatica.com wrote:
> Hi all, I used to program with C, but now I'm switching to Ada95 in 
> linux debian with gnat. How do I trace a program line by line? Thanks in 
> advance

You must use an Ada-aware GDB. You find one here:

   http://libre.act-europe.fr/GDB/

You also find the excellent GDB frontend (which you also can use for C)
here:

   http://libre.act-europe.fr/gvd/

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: How to debug an Ada program

[Pascal Obry]

mauricio@solucioninformatica.com writes:

> Hi all, I used to program with C, but now I'm switching to Ada95 in 
> linux debian with gnat. How do I trace a program line by line? Thanks in 
> advance

Preben has pointed you to gdb and gvd, these are indeed nice but with Ada95
you will probably very rarely have a need for a debugger, lot less than in C
for sure.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: How to debug an Ada program

[Cephus�]

Pascal Obry wrote:
> mauricio@solucioninformatica.com writes:
>
>> Hi all, I used to program with C, but now I'm switching to Ada95 in
>> linux debian with gnat. How do I trace a program line by line?
>> Thanks in advance
>
> Preben has pointed you to gdb and gvd, these are indeed nice but with
> Ada95 you will probably very rarely have a need for a debugger, lot
> less than in C for sure.
>
> Pascal.

debugger is for the programmer, not the language my friend...

Beau

Re: How to debug an Ada program

[Robert I. Eachus]

Cephus� wrote:

> debugger is for the programmer, not the language my friend...

Welcome to Ada.  I just dashed off a small Ada program, compiled it and 
executed it.  As it happened I did not have any typos, so it compiled 
the first time.  I wouldn't have been surprized if I had made a typing 
mistake.  It also printed out the data I wanted when I ran it.  I would 
have been shocked if I had neeed to do any debugging, and actually 
needing a debugger is almost unimaginable.

Ada is different, but you will get used to it.
-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: How to debug an Ada program

[Cephus�]

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



Robert I. Eachus wrote:
> Cephus� wrote:
>
>> debugger is for the programmer, not the language my friend...
>
> Welcome to Ada.  I just dashed off a small Ada program, compiled it
> and executed it.  As it happened I did not have any typos, so it
> compiled the first time.  I wouldn't have been surprized if I had
> made a typing mistake.  It also printed out the data I wanted when I
> ran it.  I would have been shocked if I had neeed to do any
> debugging, and actually needing a debugger is almost unimaginable.
>
> Ada is different, but you will get used to it.

What I was saying is that the debugger is for the programmer to use at
his/her discretion. Anyone can have a logic error somewhere and instead of
desk checking themselves, just use the debugger. You can have logical errors
in Ada, C, Java, APL, Pascal, etc....  and you can use the debugger to sort
through it...

It does help a lot in compilation errors, but I usually only use it when I
am having a logical error...not everyone is perfect and thier thought
process isn't perfect everytime :)
Beau

Re: How to debug an Ada program

[Robert I. Eachus]

Cephus� wrote:

> What I was saying is that the debugger is for the programmer to use at
> his/her discretion. Anyone can have a logic error somewhere and instead of
> desk checking themselves, just use the debugger. You can have logical errors
> in Ada, C, Java, APL, Pascal, etc....  and you can use the debugger to sort
> through it...
> 
> It does help a lot in compilation errors, but I usually only use it when I
> am having a logical error...not everyone is perfect and thier thought
> process isn't perfect everytime :)

As I said, welcome to Ada.  You will be pleasantly surprised at how soon 
you forget how to use the debugger.  By the way, if you are not sure of 
something, in GNAT it is very easy to use pragma Debug and pragma 
Assert, along with -gnata to turn the extra checks and messages on.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: How to debug an Ada program

[Preben Randhol]

Pascal Obry wrote:
> 
> mauricio@solucioninformatica.com writes:
> 
>> Hi all, I used to program with C, but now I'm switching to Ada95 in 
>> linux debian with gnat. How do I trace a program line by line? Thanks in 
>> advance
> 
> Preben has pointed you to gdb and gvd, these are indeed nice but with Ada95
> you will probably very rarely have a need for a debugger, lot less than in C
> for sure.

Yes I agree with this. I rarely use gdb or gvd myself with Ada. Best way
to trace a program line by line is reading the source :-) Sometimes when
trying to get an understanding somebody else's program it can go a bit
faster if you use a debugger to clear up some things though.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: How to debug an Ada program

[mauricio]

On Thu, Jul 10, 2003 at 07:25:26AM +0000, Preben Randhol wrote:
> Pascal Obry wrote:
> > 
> > mauricio@solucioninformatica.com writes:
> > 
> >> Hi all, I used to program with C, but now I'm switching to Ada95 in 
> >> linux debian with gnat. How do I trace a program line by line? Thanks in 
> >> advance
> > 
> > Preben has pointed you to gdb and gvd, these are indeed nice but with Ada95
> > you will probably very rarely have a need for a debugger, lot less than in C
> > for sure.
> 
> Yes I agree with this. I rarely use gdb or gvd myself with Ada. Best way
> to trace a program line by line is reading the source :-) Sometimes when
> trying to get an understanding somebody else's program it can go a bit
> faster if you use a debugger to clear up some things though.

exactly! As I said before I'm new to ada, so I type a program I found in 
a web page, and download the source code either, but the result is not 
the same, I already found some mistakes in my code without see the other 
source code, but I think a debuggger to trace the code would be great 
for learn how Ada do some stuff. Thanks.

> 
> -- 
> Ada95 is good for you.
> http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada

Debugger Rant (was Re: How to debug an Ada program)

[Marc A. Criley]

> Preben has pointed you to gdb and gvd, these are indeed nice but with Ada95
> you will probably very rarely have a need for a debugger, lot less than in C
> for sure.

<RANT>
I repeatedly read this kind of thing in this newsgroup, that once you
move to Ada you'll "rarely need a debugger", you can "throw your
debugger away", you'll "forget how to use a debugger", etc.

In twenty years of professional programming (with Ada all along) I've
found that a debugger is one of the most powerful tools in the Ada
programmer's arsenal.

Sure, if I write a small Ada program I can usually expect it to
compile quickly and run right; but airplanes don't fly and missiles
aren't launched by small programs.

I read code all the time, but there's nothing as concrete as seeing
how it's actually running in the computer, devoid of any programmer
oversights or misunderstandings.

It's frequently put forward that one can quickly debug their Ada
program by putting in a few Put_Lines, and/or using pragmas Debug,
Assert, and so on.  Adding these of course all require a recompile to
incorporate.  There are many environments where putting an
instrumented executble on the target platform requires making the
change, compiling, and linking it; copying it onto a tape or disk;
filling out some paperwork to authorize loading it on the test system;
tracking down a CM person to bring the media into the lab and load it
onto the machine; cycle the test system, which can require several
minutes to bring down and then back up.

  versus...

go to the lab and bring the sytem up in the debugger.


You may discover that your Put_Lines may not be dumping all the items
you need to debug the problem, but if it did, now you need to go add
more in other places to further isolate the cause.  Either way, that
takes care of today's lab reservation!

  versus...

Look at anything you please in the debugger.

Based on my experience helping other developers debug their code, I've
found a disconcertedly common trend when it comes to using debuggers. 
Very few know how to use one effectively--and this goes not just for
Ada programmers, but programmers in general.  The most common
perception of a debugger I've seen held by programmers is that it's
for single-stepping through code and setting breakpoints; and for the
advanced user, examining variables.  On several occasions when
assisting other developers I've opened up the raw memory display
window, or even (gasp!) the register or disassembly windows, and the
look on the programmer's face is utter incomprehension (which may also
be saying something about the state of software development education,
but that's another rant :-).

With the aid of a debugger I've tracked down numerous data alignment
problems, stack overflows, tasking deadlocks, and just plain silly
coding errors.

Telling me that some Put_Lines and pragma Asserts are just as
effective as gdb with a good front end (like gvd) I find laughable.

I can hear someone muttering that a debugger is a crutch that a
competent Ada programmer wouldn't find themselves needing.  Hmm,
substitute "strong typing" for "a debugger" and drop "Ada" and where
have we heard that before?

Considering a debugger to be superfluous to Ada programming deprives
one of a very powerful tool.  Unless all you're ever going to do is
whip out quick little one-page Ada programs, learn how to _use_ a
debugger.  Counts, conditional expressions, memory dumps, display
options, disassembly (know enough to basically follow what's going
on), task and thread management, etc.

A lot of effort has gone into making debuggers like gdb and gvd
effective, take advantage of it!
</RANT>

Marc A. Criley

Re: Debugger Rant (was Re: How to debug an Ada program)

[Preben Randhol]

Marc A. Criley wrote:
><RANT>
[Cut a rant I agree mostly with]
></RANT>

I agree. I recently used gvd extensively to get a fast introduction of
how a not so large, but rather complicated piece of software worked
which was not programmed by me. But I find that I use a debugger more to
learn the flow of a program than to actually hunt down bugs. Especially
when you have several pages of source-code and you have to jump back and
forth to see what functions does etc... Of course one can use a tool
like gnathtml or adadoc, but it is also valuable to use a debugger.

I don't say you shouldn't use a debugger, of course not, but what most
people point out is that you don't need it so much as a common bug
hunting tool as you do need in more weakly typed languages.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Debugger Rant (was Re: How to debug an Ada program)

[Dmitry A. Kazakov]

On Fri, 11 Jul 2003 13:26:19 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:

>I don't say you shouldn't use a debugger, of course not, but what most
>people point out is that you don't need it so much as a common bug
>hunting tool as you do need in more weakly typed languages.

I think that a good visual debugger (in a good IDE) is essential to
make Ada popular. There always could be semantic bugs, which no
language can catch, and no programmer can avoid. But more important is
that to become popular means that Ada would be used by masses of
*uexperienced* [and even uneducated (:-))] users. One cannot expect
them writting bug-free algorithms or much thinking about what their
program is supposed to do. I wonder if popularity of a language is
directly reflected by the overal percentage of bad code written in the
language. The higher is the percentage, the more popular is the
language. And what does one with bad code? Debug it!

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Debugger Rant (was Re: How to debug an Ada program)

[Jerry Petrey]

"Marc A. Criley" wrote (with deletions):

> I repeatedly read this kind of thing in this newsgroup, that once you
> move to Ada you'll "rarely need a debugger", you can "throw your
> debugger away", you'll "forget how to use a debugger", etc.
>
> In twenty years of professional programming (with Ada all along) I've
> found that a debugger is one of the most powerful tools in the Ada
> programmer's arsenal.
>
>
>
> Marc A. Criley

I certainly agree with you Marc.  While a debugger may not be needed as much in
Ada (and certainly not as much for the simpler problems) as in other languages, it
is an indispensable tool in complex Ada applications, especially in the real-time,
embedded world.

Jerry

--
---------------------------------------------------------------------------------
-- Jerry Petrey
-- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply
---------------------------------------------------------------------------------

Re: Debugger Rant (was Re: How to debug an Ada program)

[Robert I. Eachus]

Jerry Petrey wrote:

> I certainly agree with you Marc.  While a debugger may not be needed as much in
> Ada (and certainly not as much for the simpler problems) as in other languages, it
> is an indispensable tool in complex Ada applications, especially in the real-time,
> embedded world.

Shurg!  I guess I have internalized a style of programming once known as 
  "Design to test."  In other words, all (formal) requirements are 
testable, and you design and code from day one to make passing those 
tests as easy as possible.

I was recently working on a bug in Ada.Text_IO.Editing in GNAT.  I 
didn't use a debugger, and couldn't imagine the pain of trying to.  The 
issue of course, was that any changes to make "#*#" recognized as 
invalid had to leave the behavior on hundreds of test cases unchanged. 
I needed automated testing that did not depend on the debugger.  (In 
fact several times I got fixes bounced because I wasn't using as many 
test cases as ACT.)

Even if you want to consider Ada.Text_IO.Editing as separate from GNAT, 
and Ada.Text_IO, it has about 3000 lines including two parsers...

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Debugger Rant (was Re: How to debug an Ada program)

[Wesley Groleau]

Marc A. Criley wrote:
> Based on my experience helping other developers debug their code, I've
> found a disconcertedly common trend when it comes to using debuggers. 
> Very few know how to use one effectively--and this goes not just for
> Ada programmers, but programmers in general.  The most common
> perception of a debugger I've seen held by programmers is that it's
> for single-stepping through code and setting breakpoints; and for the
> advanced user, examining variables.  On several occasions when
> assisting other developers I've opened up the raw memory display
> window, or even (gasp!) the register or disassembly windows, and the
> look on the programmer's face is utter incomprehension (which may also

Well, I could say all of the same things, BUT I can also say
there have been numerous occasions where a description of
the symptoms and a glance at the source code have enabled me
to identify the problem.  There are just so many more things
that can go wrong in a C program that won't happen in Ada.

And there have been more than a few occasions where invoking
the debugger makes the problem go away!

And there have been occasions where the debugger added a problem
or deceived us by not telling the truth about the value of an entity,
or getting the address wrong on an interactive assignment.

> Considering a debugger to be superfluous to Ada programming deprives
> one of a very powerful tool.  Unless all you're ever going to do is

True.

Re: Debugger Rant (was Re: How to debug an Ada program)

[Preben Randhol]

Wesley Groleau wrote:
> And there have been more than a few occasions where invoking
> the debugger makes the problem go away!

Arn't there a special name for these kinds of bugs? Heisenberg? Think I
heard it mentioned at some point.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Debugger Rant (was Re: How to debug an Ada program)

[Wesley Groleau]

Preben Randhol wrote:
> Wesley Groleau wrote:
>>And there have been more than a few occasions where invoking
>>the debugger makes the problem go away!
> 
> Arn't there a special name for these kinds of bugs? Heisenberg? Think I
> heard it mentioned at some point.

Heisenbugs

Re: Debugger Rant (was Re: How to debug an Ada program)

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> > While a debugger may not be needed as much in
> > Ada (and certainly not as much for the simpler problems) as in other languages, it
> > is an indispensable tool in complex Ada applications, especially in the real-time,
> > embedded world.

> Shurg!  I guess I have internalized a style of programming once known as 
> "Design to test."  In other words, all (formal) requirements are 
> testable, and you design and code from day one to make passing those 
> tests as easy as possible.

While being absolutely true, this is surprisingly hard to remember.
Every time when I read this position I wholeheartly agree with it;
moreover, several times I tried it (at least partially) in practice,
and in each case a reward was excellent... and nevertheless, I'm unable
to keep it in mind and apply regularly. And I know well that I'm not
alone with this strange kind of "disability". Why it is happened, and
how one can "internalize this style of programming" (using your words) ?


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

PS. After writing above words, one fantastic vision occured to me - I imagined
Web-based master class - yours, "Programming using Ada". Why not? You have
tremendous experience, rock solid skills and views, you are alive to hidden
errors and potentially dangerous solutions, you are apparently willing to
share your knowledge, and you don't like to write books and articles
(I searched the Net and found only one your article, and it was on quite
specific issue). This is extremely suitable combination for a master class
instructor. Well, I understand that one more component is needed - there
should be example problems, and it isn't a simple/pleasant task to collect
good ones. But my vision included even this side - in the form of real-world
examples from several first chapters of the book "Problem Frames: Analyzing
and Structuring Software Development Problems" by Michael Jackson.

Re: Debugger Rant (was Re: How to debug an Ada program)

[Brian Catlin]

"Marc A. Criley" <mcq95@earthlink.net> wrote in message
news:254c16a.0307110505.463b1cc0@posting.google.com...
> > Preben has pointed you to gdb and gvd, these are indeed nice but with Ada95
> > you will probably very rarely have a need for a debugger, lot less than in C
> > for sure.
>
> <RANT>
[...snip...]
> </RANT>

I might be way off here, but it seems to me that you're using the debugger to
debug your understanding of the problem/program, rather than writing
specifications to figure out what you're really trying to do ahead of time.
Granted, that in today's environment, it is hard for management to accept
writing specs before coding, every study I've ever seen has shown that writing
specs ahead of time improves the development process and the quality of the code
produced

 -Brian

Re: How to debug an Ada program

[Richard Riehle]

Preben Randhol wrote:

> Yes I agree with this. I rarely use gdb or gvd myself with Ada. Best way
> to trace a program line by line is reading the source :-) Sometimes when
> trying to get an understanding somebody else's program it can go a bit
> faster if you use a debugger to clear up some things though.

Debuggers are  not always  for finding bugs.   Sometimes, especially
for embedded systems,  a debugger is useful for discovering just that
little bit more about the program you plan to deploy.    HP used to have
a great little tool for the 1750A called the HP 65000 that   served well
in this role.

Richard Riehle

Re: How to debug an Ada program

[James Rogers]

Richard Riehle <richard@adaworks.com> wrote in 
news:3F1356DB.D9032D0@adaworks.com:

> Preben Randhol wrote:
> 
>> Yes I agree with this. I rarely use gdb or gvd myself with Ada. Best way
>> to trace a program line by line is reading the source :-) Sometimes when
>> trying to get an understanding somebody else's program it can go a bit
>> faster if you use a debugger to clear up some things though.
> 
> Debuggers are  not always  for finding bugs.   Sometimes, especially
> for embedded systems,  a debugger is useful for discovering just that
> little bit more about the program you plan to deploy.    HP used to have
> a great little tool for the 1750A called the HP 65000 that   served well
> in this role.
> 
>

The HP 64000 was an in-circuit emulator with a decent debugger. One of the
nice features of this tool was its use of dual-ported memory so that 
program trace data could be collected while the program was running at full
speed. This allowed very accurate determination of full speed timing
issues.

The HP 64000 was available for a wide range of processors, mostly from
Intel and Motorola. 

I first learned Ada while supporting the HP 64000 debugger. The debugger
was primarily targeted to C, but also provided some Ada support. My job
was to test the debug information produced by compilers and determine if
they were correct. If a problem was found with the debugger I had to
determine if the problem was a fault in the debug information or a fault
in the compiler logic.

The debug formats such as IEEE 695, contained a lot of data modes needed 
by C which could not be created by an Ada compiler. One that comes to
mind is an incomplete forward reference. The Ada equivalent, which 
would not compile might be:

package example is
   type forward;
   type forward_Access is access forward;
end example;

Note that type forward is never completed. Ada compilers will not 
generate code containing such problems. They will instead provide
error messages and no object file. C compilers may produce a
warning, but they will also produce an object file.

When using the Aonix compiler several years ago I encountered a
programmer who was very familiar with the Microsoft Visual C++
environment. The Aonix compiler produces debug data compatible
with the Microsoft Visual debugger. The programmer learned Ada
in about a week. He then customized his Visual Development
Studio to work with Ada. He insisted that the Microsoft
debugger worked better with the Aonix product than it did with
the Microsoft Visual C++. One example was that he could see
the elements of an array in Ada, while he could only see the
address of the array using C++.

Jim Rogers

Re: How to debug an Ada program

[Marin David Condic]

Perhaps a distinction is in order? In embedded systems it is not 
uncommon to build in a "monitor" capability that can serve in part for 
debugging purposes, but is often used to support verification, adjust 
the software by modifying constants, serve as a boot loader and in 
general allow the developers to gain insight into how their system 
operates. When you don't have a screen on which to display things and/or 
  your interaction with the world is not in some human-viewable form, 
you need some means of watching what goes on for purposes beyond what 
most would consider traditional "debugging".

MDC



Richard Riehle wrote:
> 
> Debuggers are  not always  for finding bugs.   Sometimes, especially
> for embedded systems,  a debugger is useful for discovering just that
> little bit more about the program you plan to deploy.    HP used to have
> a great little tool for the 1750A called the HP 65000 that   served well
> in this role.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Debugger Rant (was Re: How to debug an Ada program)

[Robert I. Eachus]

Alexander Kopilovitch wrote:

>>Shrug!  I guess I have internalized a style of programming once known as 
>>"Design to test."  In other words, all (formal) requirements are 
>>testable, and you design and code from day one to make passing those 
>>tests as easy as possible.

> While being absolutely true, this is surprisingly hard to remember.
> Every time when I read this position I wholeheartly agree with it;
> moreover, several times I tried it (at least partially) in practice,
> and in each case a reward was excellent... and nevertheless, I'm unable
> to keep it in mind and apply regularly. And I know well that I'm not
> alone with this strange kind of "disability". Why it is happened, and
> how one can "internalize this style of programming" (using your words) ?

The answer to that is easy.  When I sit down to write even a short 
program, I take out a piece of paper, or open Notepad, or whatever, and 
start doing requirements.  All it takes to internalize design to test is 
to recognize that even when you are doing a ten line example, THIS is 
faster, THIS is better, THIS is much more likely to be bug free, and 
THIS is much less stressful.  That time with the (real or virtual) 
notepad, often both, IS painful.  And a lot of stuff gets scribbled out 
as you realize that THIS IS A REQUIREMENT and you can't test it. But 
what you do end up with is a design where each component has an 
associated test, and that mapping eventually means that all sorts of if 
and case statements go away, or only get tested in one place.

Fortunately by now, when I don't do this, I stop after about twenty 
lines of code and go back and do it right. I'm too old to do things the 
hard way.

When I do this, I can knock out over a thousand lines of tested code a 
week.  (Not counting test programs, but counting some documentation.) 
Comparing my work with the sort of work done by government contractors, 
my block comment headers are much smaller, I use more whitespace, and I 
accomplish about ten times as much per line of code!  At first I thought 
this was crazy, then I took some existing code I hadn't examined, plus 
the requirements document--which I knew well--and rewrote a couple of 
units.  The big difference, and it was HUGE, was that I moved a lot of 
checking into the interfaces (including data types), while functional 
decomposition propagates it down into the leaves (subprograms).

> PS. After writing above words, one fantastic vision occured to me - I imagined
> Web-based master class - yours, "Programming using Ada". Why not? You have
> tremendous experience, rock solid skills and views, you are alive to hidden
> errors and potentially dangerous solutions, you are apparently willing to
> share your knowledge, and you don't like to write books and articles
> (I searched the Net and found only one your article, and it was on quite
> specific issue). This is extremely suitable combination for a master class
> instructor. Well, I understand that one more component is needed - there
> should be example problems, and it isn't a simple/pleasant task to collect
> good ones. But my vision included even this side - in the form of real-world
> examples from several first chapters of the book "Problem Frames: Analyzing
> and Structuring Software Development Problems" by Michael Jackson.

I have significant parts of the book written, some of it was presented 
as lectures around 1986.  However, I have been seriously disabled for a 
while now.  Right now I am up to using the computer (and up to thinking, 
which is more important), so I may be able to finish that book and a 
couple of others.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Debugger Rant (was Re: How to debug an Ada program)

[Robert I. Eachus]

Brian Catlin wrote:

> I might be way off here, but it seems to me that you're using the debugger to
> debug your understanding of the problem/program, rather than writing
> specifications to figure out what you're really trying to do ahead of time.
> Granted, that in today's environment, it is hard for management to accept
> writing specs before coding, every study I've ever seen has shown that writing
> specs ahead of time improves the development process and the quality of the code
> produced.

Amen!  I just finished another post to the same effect.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Debugger Rant

[Marc A. Criley]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F148F80.1000708@attbi.com>...
> Brian Catlin wrote:
> 
> > I might be way off here, but it seems to me that you're using the debugger to
> > debug your understanding of the problem/program, rather than writing
> > specifications to figure out what you're really trying to do ahead of time.
> > Granted, that in today's environment, it is hard for management to accept
> > writing specs before coding, every study I've ever seen has shown that writing
> > specs ahead of time improves the development process and the quality of the code
> > produced.
> 
> Amen!  I just finished another post to the same effect.

Brian is way off here.

Where Bob uses Notepad or a sheet of paper, I use a whiteboard for the
same purpose.  I've got a good track record of bringing software in on
time that meets its requirements.

A debugger, like a whiteboard, is a powerful software development
tool, and I would fiercely oppose giving up either of them, or having
someone level at me the notion that they were simply a crutch.

After several years of reading the occasional response to an Ada
newbie that they'll virtually never need a debugger when programming
in Ada (as well as that if the code compiles, it'll probably work)--I
just got fed up with it.

Re: Debugger Rant

[Alexander Kopilovitch]

Marc A. Criley wrote:

>A debugger, like a whiteboard, is a powerful software development
>tool, and I would fiercely oppose giving up either of them, or having
>someone level at me the notion that they were simply a crutch.

Well, you occasionally may need your revolver at your office workplace,
I understand -:) . All right, keep your revolver at hand, if you are sure
that you can control it and that it may be of good use.

>After several years of reading the occasional response to an Ada
>newbie that they'll virtually never need a debugger when programming
>in Ada (as well as that if the code compiles, it'll probably work)--I
>just got fed up with it.

But it is normal to work in offices without revolvers, especially for newbies,
isn't it? Just imagine that all people in your office are carrying loaded
revolvers -:) -- it will be more like a squadron of 19-century cowboys than
a programmer team.

Yes, certainly there are cases where debugger is badly needed. But these cases
aren't for newbies anyway. Also, there are cases where you can locate some
stupid local error much quicker with debugger than without it -- I mean the
situations where you know that there is an error in those several lines, and
you look straight at the error -- and don't see it. But with Ada those situations
are much less likely to occur than with other (existing) languages.

(And yes, every time when I work with debugger I feel myself as I have a revolver
in my hand -:)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Debugger Rant

[Wesley Groleau]

Marc A. Criley wrote:
> After several years of reading the occasional response to an Ada
> newbie that they'll virtually never need a debugger when programming
> in Ada (as well as that if the code compiles, it'll probably work)--I
> just got fed up with it.

OK, how about:

    If the code compiles, it's far more likely to work
    than C code that compiles.

(It may take trillions of monkeys on keyboards
to duplicate a Shakespeare sonnet, but it only
takes a thousand to make something that passes
a C compiler.)

:-)

Re: Debugger Rant

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> (And yes, every time when I work with debugger I feel myself as I have a revolver
> in my hand -:)

ROTFL!  But I tend to feel that using a debugger is more like using a 
bazooka or a hand grenade.  It can do the job but it is hell on the 
spectators.  You can make lots of changes with a debugger that the Ada 
compiler will prevent you from making.  If you know what you are doing, 
and can mentally track the effects of your changes, including through 
compiler optimizations, great.

But I am not that smart, and I tend to suspect that no one else is either.

If you use a debugger as a tool to steer around a program so you can 
figure out what is going on, then make changes and recompile, that is 
better.

But what I/we are advocating is that you write software that is 
demonstratably correct and demonstrates that it meets all the 
requirements.  In other words Marc sees as a 'normal' use of the 
debugger, I see as a requirements definition failure.  You may get me to 
sign off on a design where a debugger is required to demonstrate certain 
requirements.  But only after slogging through several days of 
requirements analysis--and then I will go home and think about it some 
more.  Coverage analysis tools, expecially on secure software are a very 
different story.  But I will still protest coverage that can only be 
demonstrated using a debugger.(It depends on how much code is involved 
in the debugger demonstration, and how much needs to be mangled by the 
debugger.  I still much prefer object code inspection in many cases.)



-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Debugger Rant

[Pascal Obry]

I have started this thread. As I said when working in Ada you have less
often a need for a debugger. I still maintain this claim, and this does
not mean that with Ada you just don't need a debugger as some have promptly
understood.

I have, like most of you probably, build some C/C++ applications and some in
Ada. My experiences are that for an Ada application I do rarely used a
debugger. That's the feedback I can give and I understand that other can have
other experiences. Maybe this is due to the way we build software in Ada. Block
by block we build abstractions and test them as soon as possible, this means
that most of the problems are fixed early on and are not to be debugged during
integration.

Just my 2 cents!
Pascal.

PS: Again, I have not said that a debugger is not useful with Ada!

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595