Ok sorry, it is just a book gives no feedback.

Ok sorry, it is just a book gives no feedback.

[Mark Pagdin]

Hi ya,

I am sorry to keep on asking qns, but my text book doesn't give answers,
i.e. it says things like write a procedure to do ......., but it doesn't
actually give the answer at the back, so that if you are a bit stuck then
everything won't work and you get demoralised.

I want to become good at programming and I am prepared to work hard, but I
am not brilliant at maths and I don't think thsi helps my plight.

I am sorry to ask newbie qns here, but I am in a catch 22, or I think I am.

Anyway,
Have a fun New Years,

mark

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <t4ug0qb63j7e4e@corp.supernews.co.uk>,
  "Mark Pagdin" <mark_pagdin@lineone.net> wrote:
> Hi ya,
>
> I am sorry to keep on asking qns, but my text book doesn't
give answers,
> i.e. it says things like write a procedure to do ......., but
it doesn't
> actually give the answer at the back, so that if you are a
bit stuck then
> everything won't work and you get demoralised.


Study the examples rather than the questions, make sure you
really really understand every character of the examples.


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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <t4ug0qb63j7e4e@corp.supernews.co.uk>,
  "Mark Pagdin" <mark_pagdin@lineone.net> wrote:
> Hi ya,
>
> I am sorry to keep on asking qns


Did you try one of the online tutorials (go to
www.adapower.com). Please report back on your
experience in this endeavor!


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

Re: Ok sorry, it is just a book gives no feedback.

[Tarjei T. Jensen]

Mark Pagdin wrote in message ...
>Hi ya,
>
>I am sorry to keep on asking qns, but my text book doesn't give answers,
>i.e. it says things like write a procedure to do ......., but it doesn't
>actually give the answer at the back, so that if you are a bit stuck then
>everything won't work and you get demoralised.

How about the library. Do they have any ada books? Take a look at Michael
Feldmans review page for various Ada books at
http://www.seas.gwu.edu/faculty/mfeldman/ada95books.html

I think the ones to look out for is the ones by prof Michael Feldman. In any
case, have a look at the code which accompanies the books. It should be
interesting to read.  His home page is at
http://www.seas.gwu.edu/faculty/mfeldman/. Look at the links section where
there are links to the publishers pages for his book. There is a pointer to the
source code in the publisher pages.


Web sites

SIGAda - learning Ada : http://www.acm.org/sigada/ada_95/learning.html




Greetings,

Re: Newsgroup cla (was: Ok sorry, it is just a book gives no feedback.)

[Anders Wirzenius]

"Mark Pagdin" <mark_pagdin@lineone.net> wrote in message
news:t4ug0qb63j7e4e@corp.supernews.co.uk...
> Hi ya,
>
...

> I am sorry to ask newbie qns here, but I am in a catch 22, or I think I
am.
>

Someone suggested a while ago to split comp.lang.ada into several subgroups.
As a half-hobby programmer and as a newbie to Ada I want to raise the
question once again.

Why not start subgroups like comp.lang.ada.int_lang to deal with questions
about interfacing to other languages? Or: comp.lang.ada.com to deal with
AdaCom questions? Or: comp.lang.ada.newbie? comp.lang.ada.os?

A newbie like me could then start on a low level group (.newbie) and then
advance to higher knowledge (.lang_adv) later on. Or I could choose a
special group (.access) when I want to look at a special area.

Has comp.lang.ada reached a level with dotsomethings at the end?

Anders Wirzenius

Re: Newsgroup cla (was: Ok sorry, it is just a book gives no feedback.)

[Florian Weimer]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> writes:

> Has comp.lang.ada reached a level with dotsomethings at the end?

No, it hasn't.  IMHO, comp.lang.ada doesn't enjoy that much traffic.

Re: Newsgroup cla (was: Ok sorry, it is just a book gives no feedback.)

[Andrew Hately]

> Or: comp.lang.ada.newbie? 

Experience in other domains indicates that groups with demeaning names
get little traffic.

Andrew

Re: Newsgroup cla (was: Ok sorry, it is just a book gives no feedback.)

[Larry Kilgallen]

In article <87bstqs06g.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> writes:
> 
>> Has comp.lang.ada reached a level with dotsomethings at the end?
> 
> No, it hasn't.  IMHO, comp.lang.ada doesn't enjoy that much traffic.

Whereas I feel that comp.lang.ada doesn't _suffer_from_ that much traffic.

Re: Newsgroup cla (was: Ok sorry, it is just a book gives no feedback.)

[Florian Weimer]

Andrew Hately <hat@cfmu.eurocontrol.be> writes:

> > Or: comp.lang.ada.newbie? 
> 
> Experience in other domains indicates that groups with demeaning names
> get little traffic.

de.comp.os.unix.linux.newusers was a high-traffic group (until it was
removed).

Re: Ok sorry, it is just a book gives no feedback.

[John English]

Mark Pagdin wrote:
> I am sorry to keep on asking qns, but my text book doesn't give answers...

I seem to have missed the start of thios thread: which textbook are you
using?

> Anyway,
> Have a fun New Years,

I think that must be why I missed the start of this thread... :-)

  raise Happy_New_Millenium; -- to all those who read this newsgroup!

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

Re: Ok sorry, it is just a book gives no feedback.

[Nick Roberts]

My own opinion is that, generally, functions should have no side effects
(whereas procedures generally do).

Ada does not enforce this principle (rightly, since it would be difficult
and sometimes wrong to do so), but it does disallow parameters of mode 'out'
and 'in out' for functions.

What is a 'side effect'? If a subprogram (a function or procedure), when
called, changes something outside itself, that is a side effect. The 'thing'
outside could be anything: a variable; a display or printer; a hard disk
floppy disk; etc. The 'change' is any kind of change whatever: modification
of a value; output of a character or string; writing or modifying a file;
etc. To be crystal clear, when I say a function 'should have no side
effects', I mean it should be written so that it never causes a side effect.

Some people do not respect (or even recognise) this principle, although
there are good arguments for it. I would suggest you follow the principle
unless you have a very good reason not to.

Briefly, the main argument for functions not having side effects is that an
expression such as A+B, where A and B are both function calls, may be
compiled to execute A first and then B, or B first and then A (depending on
complex optimisation rules within the compiler). If both A and B could both
cause a side effect which interferes with the other, it might then become
unpredictable what this expression does or returns: often a particularly
pernicious type of bug! Keeping functions free of side effects avoids the
possibility of this type of bug.

It follows from the above that the kind of side effect in a function which
you can get away with most easily is the kind which is carefully designed
never to interfere with any other function.

Do keep up your hard work with Ada. How did you get on with 'hangman'?

My advice with regard to books is: try to have a go with as many as you can,
before purchasing if possible. Does your place have a good library? Might
your friends lend you theirs for a while? Often you can get nowhere with
many books, and then find one which just seems to 'click'. (Clearly, that's
the one to buy!) Sometimes one book will explain one thing well, and another
book something else. (In which case, a photocopier might be handy.)

Happy New Year!

--
Nick Roberts
http://www.AdaOS.org


"Mark Pagdin" <mark_pagdin@lineone.net> wrote in message
news:t4ug0qb63j7e4e@corp.supernews.co.uk...
> Hi ya,
>
> I am sorry to keep on asking qns, but my text book doesn't give answers,
> i.e. it says things like write a procedure to do ......., but it doesn't
> actually give the answer at the back, so that if you are a bit stuck then
> everything won't work and you get demoralised.
>
> I want to become good at programming and I am prepared to work hard, but I
> am not brilliant at maths and I don't think thsi helps my plight.
>
> I am sorry to ask newbie qns here, but I am in a catch 22, or I think I
am.
>
> Anyway,
> Have a fun New Years,

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <931r2l$4ai5t$2@ID-25716.news.dfncis.de>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:

> My own opinion is that, generally, functions should have no
> side effects

This principle is in general a reasonable one, but it is not
easy to define what this means. Nick goes on to give an
explanation, but his explanation is wrong, it would forbid
many functions, e.g. anything that allocates and returns a
pointer, which is far too severe.

Getting the explanation right is very hard (which is why the
language does not attempt to enforce this). For example,
memo functions clearly violate Nick's rules, but should be
allowed.

Also Nick's definition would not allow any instrumentation of
functions, and that's wrong too.

In any case, the answer is far afield from the question, at the
level the question is asked, the answer is

use a function if a value is returned
use a procedure if no value is returned

(yes that's not quite right either, but the question is not
about subtle semantics and language design, it is more in the
realm of "I don't understand any of this stuff, help!!!" :-)




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

Re: Ok sorry, it is just a book gives no feedback.

[n_brunot]

In article <931t08$5u5$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <931r2l$4ai5t$2@ID-25716.news.dfncis.de>,
>   "Nick Roberts" <nickroberts@callnetuk.com> wrote:
>
> > My own opinion is that, generally, functions should have no
> > side effects
>
> This principle is in general a reasonable one, but it is not
> easy to define what this means. Nick goes on to give an
> explanation, but his explanation is wrong, it would forbid
> many functions, e.g. anything that allocates and returns a
> pointer, which is far too severe.
>

Well "generally" seems reasonable and never said that this behavior is
forbidden.
Of course some functions must have side effects, but I agree it's better
to avoid it each time side effects are not necessary.

Just look the following code (simplified from old buggy code).
Depending if the compiler evaluate right or left term first for "&",
you get quite different behavior ....
This is a pathologic case, but good example to show why it's not so bad
to avoid side effect each time you can, and keep constantly testing your
code on different Ada compilers ...

with Text_Io;
procedure Test is
   N : Natural := 10;
   function Decrement return String is
   begin
      N := N - 1;
      return "A";
   end;
   function Recursive return String is
   begin
      if N /= 0 then
         return Decrement & Recursive;
      else
         return "A";
      end if;
   end;
begin
   Text_Io.Put_Line (Recursive);
end;


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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <932632$e0e$1@nnrp1.deja.com>,
  n_brunot@my-deja.com wrote:
> Just look the following code (simplified from old buggy
code).
> Depending if the compiler evaluate right or left term first
for "&",
> you get quite different behavior ....
> This is a pathologic case, but good example to show why it's
not so bad
> to avoid side effect each time you can, and keep constantly
testing your
> code on different Ada compilers ...
>
> with Text_Io;
> procedure Test is
>    N : Natural := 10;
>    function Decrement return String is
>    begin
>       N := N - 1;
>       return "A";
>    end;
>    function Recursive return String is
>    begin
>       if N /= 0 then
>          return Decrement & Recursive;
>       else
>          return "A";
>       end if;
>    end;
> begin
>    Text_Io.Put_Line (Recursive);
> end;

This would be horrible code even if procedures were used.
Global variables in general are harmful if not very carefully
used.

You argue that functions should not have side effects, and then
use as an example a very poorly written junk function. The
point is that there are plenty of legitimate functions that
have side effects in the sense in which they were defined
here.

E.g. A function that takes two pointers to strings and returns
a pointer to their concatenation is quite reasonable, but has
side effects according to this definition.

Note that ANY allocation has a side effect, so these rules
about
functions would say that no functions can ever do allocations.
That's an unreasonable restriction!


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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

Just to be clear on my position here.

When someone says "feature X should not be used"
(in this case X = functions with side effects), the
burden is to prove the *universal* quantifier over
all, or at least most all, uses.

It is NOT an argument to show one case in which X
should not be used.

On the other hand, the burden of proof in the other
direction is much easier, because there it IS
sufficient to show specific examples.

(I already gave some, memo functions, instrumented
functions, functions that do allocations ... there
are many other examples).



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

Re: Ok sorry, it is just a book gives no feedback.

[n_brunot]

In article <932an8$ijs$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <932632$e0e$1@nnrp1.deja.com>,
>   n_brunot@my-deja.com wrote:
> > Just look the following code (simplified from old buggy code).

> This would be horrible code even if procedures were used.
> Global variables in general are harmful if not very carefully
> used.

Exactly, that's right. :-)
I found this kind of code in several years old code which worked
perfectly well until compiled on a compiler differently evaluating "&".
When you have a big project with more than 1 million lines code, it's
unrealistic to assume that this kind of thing is impossible.
Assuming that one single person, however genius he is, can check every
single line code, and cannot make mistakes is totally unrealistic and
dangerous.

Therefore simple rules like
- yes, avoid side effects when you can
- no, don't avoid them if you cannot :-)
(Is it necessary to say such an evidence ...)
- test your code on different compilers
(you'll have more chances to detect bugs which could remain unnoticed
because of specific behavior of one compiler)

are wise and don't bring any restriction

> You argue that functions should not have side effects.

Yes, when you can avoid it, avoid it :-)
No, nobody said that side effects are forbidden,
look at previous posts ...

> point is that there are plenty of legitimate functions that
> have side effects in the sense in which they were defined
> here.

Yes, nobody denied that, and nobody said it's bad :-)

> E.g. A function that takes two pointers to strings and returns
> a pointer to their concatenation is quite reasonable, but has
> side effects according to this definition.
> Note that ANY allocation has a side effect, so these rules
> about
> functions would say that no functions can ever do allocations.
> That's an unreasonable restriction!

And may be that's we never read anything asking for that !! :-)



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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <93421h$2ju$1@nnrp1.deja.com>,
  n_brunot@my-deja.com wrote:
> > Note that ANY allocation has a side effect, so these rules
> > about
> > functions would say that no functions can ever do
allocations.
> > That's an unreasonable restriction!
>
> And may be that's we never read anything asking for that !!
:-)


Oh but we did! The set of rules that was proposed here (not by
you, you did not give any definitions of what you mean by
side effects), precisely ruled out this case.

That's the point, it is easy to make vague statements about
"side effects considered harmful", but it is quite another to
rigorously define what you mean by side effects.

You do NOT want to tell people that instrumenting functions is
for some peculiar reason undesirable, or that memo functions
are undesirable (though of course in the multi-tasking case,
you have to worry about reentrancy in both these cases).


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

Re: Ok sorry, it is just a book gives no feedback.

[Randy Brukardt]

Robert Dewar wrote in message <934j5c$eu9$1@nnrp1.deja.com>...
>In article <93421h$2ju$1@nnrp1.deja.com>,
>That's the point, it is easy to make vague statements about
>"side effects considered harmful", but it is quite another to
>rigorously define what you mean by side effects.
>
>You do NOT want to tell people that instrumenting functions is
>for some peculiar reason undesirable, or that memo functions
>are undesirable (though of course in the multi-tasking case,
>you have to worry about reentrancy in both these cases).

Indeed, that is why pragma Pure is so hard to use in practice: because
you can't instrument or otherwise debug code controlled by it. About all
you can do is remove the pragma, but that often makes the clients of the
package illegal. Thus debugging these things can be horrible.

            Randy.

Re: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <ZZq56.1574$xo3.422321@homer.alpha.net>, "Randy Brukardt" <randy@rrsoftware.com> writes:
> Robert Dewar wrote in message <934j5c$eu9$1@nnrp1.deja.com>...
>>In article <93421h$2ju$1@nnrp1.deja.com>,
>>That's the point, it is easy to make vague statements about
>>"side effects considered harmful", but it is quite another to
>>rigorously define what you mean by side effects.
>>
>>You do NOT want to tell people that instrumenting functions is
>>for some peculiar reason undesirable, or that memo functions
>>are undesirable (though of course in the multi-tasking case,
>>you have to worry about reentrancy in both these cases).
> 
> Indeed, that is why pragma Pure is so hard to use in practice: because
> you can't instrument or otherwise debug code controlled by it. About all
> you can do is remove the pragma, but that often makes the clients of the
> package illegal. Thus debugging these things can be horrible.

Is it the case that implementations are forbidden to allow debugger
breakpoints in code controlled by pragma Pure ?

I would think that would be well beyond what the Standard should
control.

Re: Ok sorry, it is just a book gives no feedback.

[Simon Wright]

n_brunot@my-deja.com writes:

> Assuming that one single person, however genius he is, can check
> every single line code, and cannot make mistakes is totally
> unrealistic and dangerous.

Which is one reason for doing code inspection .. four heads, focussed
on the job, for no more than two hours at a time, can find a lot of
problems, and the process tends to enforce standards.

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <dxC7xviP+UiB@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> Is it the case that implementations are forbidden to allow
> debugger breakpoints in code controlled by pragma Pure ?

Of course not, but that is entirely irrelevant to the (very
important) point that Randy was making!

For example, you cannot add a Put_Line in a pure function,
and that is often very annoying. In GNAT, it is convenient
that GNAT.IO is at least preelaborable, because you cannot
even do a normal Text_IO.Put_Line in a preelaborable package.


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

Re: Ok sorry, it is just a book gives no feedback.

[Laurent Guerby]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Indeed, that is why pragma Pure is so hard to use in practice: because
> you can't instrument or otherwise debug code controlled by it. About all
> you can do is remove the pragma, but that often makes the clients of the
> package illegal. Thus debugging these things can be horrible.

The trick is to use pragma Import in Pure units to import "unpure"
debugging stuff without withing it.

package body Of_Pure_Unit
   procedure Dbg (Msg : in String);
   pragma Import (Ada, Dbg); 
   -- May need compiler tweaking with link names, plus of course
   -- a matching Export somewhere in the code.

   function Not_That_Pure return Integer is
   begin
      Dbg ("hello!");
      return 0;
   end Not_That_Pure;

end Of_Pure_Unit;

-- 
Laurent Guerby <guerby@acm.org>

Re: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <937jk6$s6l$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <dxC7xviP+UiB@eisner.decus.org>,
>   Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
>> Is it the case that implementations are forbidden to allow
>> debugger breakpoints in code controlled by pragma Pure ?
> 
> Of course not, but that is entirely irrelevant to the (very
> important) point that Randy was making!
> 
> For example, you cannot add a Put_Line in a pure function,
> and that is often very annoying.

I supposed it might be annoying to some people, but I detest
that style of debugging.  I much prefer to place a breakpoint
(even a conditional breakpoint) that will examine the data in
question rather than change the source.  Sometimes setting up
that breakpoint may take an elaborate command procedure in order
to get it on precisely the 125th iteration that has a non-negative
parameter, but to me it is better than altering the source.

And now I have learned that it is more compatible with "Pure" :-)

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <86hf3c5ure.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:

> The trick is to use pragma Import in Pure units to import
> "unpure" debugging stuff without withing it.

Sshhhh! This is a secret trick that should not be revealed to
the uninitiated :-) :-)

Few Ada programmers realize what a huge hole this is in the
language (introduced in Ada 95 with the formal recognition of
Ada as a convention).

You can do all *sorts* of things by using pragma Import and
Export with convention Ada. You can completely disconnect type
checking at the subprogram call interface. You can compeltely
disconnect elaboration order checking in elaboration code etc.
You can also bypass any "silly" rules that you don't like about
what you can and cannot WITH.

I wonder whether we realized what a big hole we were creating
there. I very seldom favor absolute rules in coding standards,
so I hesitate to say *never* use convention Ada in this manner,
but for sure you have to be super careful, it is as bad or
worse than any of the unchecked interfaces in the language, and
does not clearly announce itself, since the Import can be
buried deep in the implementation code.


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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <aYmc6X7X+C3D@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> I supposed it might be annoying to some people, but I detest
> that style of debugging.

Well I think a programmer should be able to use whatever tools
are available.

Sounds like you would be totally stuck if you had no
debugger available, and that would be unfortunate:-)

Sure, if the
debugger can solve your problem fine, but there are definitely
occasions on which the "put line" style of debugging is useful.

That's particularly true if the added debugging code is
complex, and you have a debugger that does not allow for
complex conditionals in breakpoints.


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

Re: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <9386t0$av0$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <aYmc6X7X+C3D@eisner.decus.org>,
>   Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
>> I supposed it might be annoying to some people, but I detest
>> that style of debugging.
> 
> Well I think a programmer should be able to use whatever tools
> are available.
> 
> Sounds like you would be totally stuck if you had no
> debugger available, and that would be unfortunate:-)

Yes, relying a debugger that does not exist is a bad idea.
Lacking a debugger would be something I would detest. For
non-embedded work, I would hope the portability of Ada
would let me debug on a machine with a good debugger (for
some meaning of "good") for most of the work.

> Sure, if the
> debugger can solve your problem fine, but there are definitely
> occasions on which the "put line" style of debugging is useful.
> 
> That's particularly true if the added debugging code is
> complex, and you have a debugger that does not allow for
> complex conditionals in breakpoints.

Are there many such debuggers still in use for major operating
systems ?  I remember something called ODT (Octal Debugging
Tool) for the PDP-8, but I think a lot of people do not even
remember the PDP-8.

To some extent I look at how far kernel mode debuggers have
progressed and figure that is indicative of the world at
large.  Sure, Alpha VMS has a kernel mode debugger giving
full symbolic support using a second machine.  But then I
have read about (but not used) the same thing for MacOS.
Unix fans are often touting the sophistication of their
tools.  So where are the weak debuggers ?

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <z4W1k714y7z3@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> Are there many such debuggers still in use for major
> operating systems ?  I remember something called ODT (Octal
> Debugging Tool) for the PDP-8, but I think a lot of people do
> not even remember the PDP-8.

You miss my point, I am not talking about symbolic debugging,
but cases where elaborate logic is required for detecting and
logging an error situation. I know of no debuggers where it is
easy to program complex functions that operate comfortably
within the target environment.

For example, suppose you have logic which expects that a
certain number should always satisfy certain constraints,
due to logic in the program. You suspect that at some point,
you have a value that does not meet these constraints.
Basically what you want to add is a check to see if these
conditions are met (arbitrarily complex code), and if they
are not met, dump out various complex information at a high
level of abstraction. This is not a task that is within reach
of typical debuggers!

I find that people who "detest" certain styles of working and
working environments sometimes lack the flexibility to deal
with difficult situations. It sounds for instance like you
would be really stuck if you were in a hiesenbug situation
where the bug does not appear if you operate in the presence
of the debugger. This can most certainly happen with some kinds
of erroneous programs, or where timing problems are an issue.

Indeed in real time programs, the paradigm of breakpoint and
examine often breaks down badly. Yes, there are some
asyncrhonous debugging tools around (like OCS Aprobe) which
can be very valuable in such situations, but sometimes, a
judiciously placed put_line can be the most efficient and
effective debugging approach. If you are sure you "detest"
such an approach, you may end up proceeding in less than
an optimal manner. Flexibility is always a plus.

Note that when using GDB, there is a very useful hybrid
approach that is often very attractive, which is to write
debugging routines that output information in a suitable
high level abstract form (see for example the pn routine
in GNAT for printing an AST node). Then the routine is
called from the debugger. For example, when we are debugging
the GNAT compiler itself, we write as a gdb command:

  pn (125)

and this prints the contents of node 125 in a high level
symbolic form.

But this capability requires that the debugging routines be
able to do output, so you run into the same Pure/Preelaborable
situations.

Larry, I take it you are still stuck in an Ada 83 environment,
where this particular issue does not arise? (I say that because
it is quite a familiar problem to Ada 95 programmers :-)

Robert


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

Re: Ok sorry, it is just a book gives no feedback.

[Laurent Guerby]

Robert Dewar <robert_dewar@my-deja.com> writes:
>   Laurent Guerby <guerby@acm.org> wrote:
> > The trick is to use pragma Import in Pure units to import
> > "unpure" debugging stuff without withing it.
> 
> Sshhhh! This is a secret trick that should not be revealed to
> the uninitiated :-) :-)

;-)

> Few Ada programmers realize what a huge hole this is in the
> language (introduced in Ada 95 with the formal recognition of
> Ada as a convention).
> 
> You can do all *sorts* of things by using pragma Import and
> Export with convention Ada. You can completely disconnect type
> checking at the subprogram call interface. You can compeltely
> disconnect elaboration order checking in elaboration code etc.
> You can also bypass any "silly" rules that you don't like about
> what you can and cannot WITH.
> 
> I wonder whether we realized what a big hole we were creating
> there. I very seldom favor absolute rules in coding standards,
> so I hesitate to say *never* use convention Ada in this manner,
> but for sure you have to be super careful, it is as bad or
> worse than any of the unchecked interfaces in the language, and
> does not clearly announce itself, since the Import can be
> buried deep in the implementation code.

I think the language designers did not realize this, at least that's
what I infer from reactions when I posted this trick circa 1995 (IIRC)
in comp.lang.ada.

In the "break everything" area you also have stream based code which
does all sorts of "unchecked" stuff without having "unchecked" in its
name (well it's obvious, but it breaks the "grep Unchecked" rule ;-).

Another marginal use of pragma "Import Ada" is to portably disable (I
guess in most implementations ;-) global optimizations. If you want
for example to benchmark a piece of code with inlining on, but don't
want some stuff to be inlined, or to have a smart compiler computing
everything at compile time via global analysis, just "Import Ada" the
given stuff.

-- 
Laurent Guerby <guerby@acm.org>

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <86snmvv79k.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:
> I think the language designers did not realize this, at least
> that's what I infer from reactions when I posted this trick
> circa 1995 (IIRC) in comp.lang.ada.

Actually you can find uses of this in the GNAT run-time going
way back, and indeed it is much older than that, since DEC
Ada 83 always supported this capability, and the DEC test suite
contains a number of tests that use this capability to bypass
compiler checking that would defeat the test purpose (related
to the optimization point that LG made).

>
> In the "break everything" area you also have stream based
> code which does all sorts of "unchecked" stuff without having
> "unchecked" in its
> name (well it's obvious, but it breaks the "grep Unchecked"
> rule ;-).

But that's really no different from Sequential_IO ...


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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <86snmvv79k.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:
>
> In the "break everything" area you also have stream based
> code which ...

Actually we find that it is address clauses (now
semi-legitimized for overlay purposes in Ada 95, though
they were widely used that way in Ada 83, even though
erroneous) that are the most frequently abused unsafe feature.

We even find examples like

   X : Integer;
   Y : Integer;
   for Y'Address use X'Address;

where a renaming would be just as good, but people get so in
the habit of using this low level tool that they overuse it :-)


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

Re: Ok sorry, it is just a book gives no feedback.

[Robert Dewar]

In article <x7v66jt40h3.fsf@smaug.pushface.org>,
  Simon Wright <simon@pushface.org> wrote:
> Which is one reason for doing code inspection .. four heads,
> focussed on the job, for no more than two hours at a time,
> can find a lot of problems, and the process tends to enforce
> standards.


At Ada Core Technologies, we work by having another person
review all checked in changes, for both content and style
issues, and this definitely helps keep style consistent,
as well as finding other problems.


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

Re: Ok sorry, it is just a book gives no feedback.

[Laurent Guerby]

Robert Dewar <robert_dewar@my-deja.com> writes:
> Actually you can find uses of this in the GNAT run-time going
> way back, and indeed it is much older than that, since DEC
> Ada 83 always supported this capability, and the DEC test suite
> contains a number of tests that use this capability to bypass
> compiler checking that would defeat the test purpose (related
> to the optimization point that LG made).

I doubt the DEC Ada 83 compiler used this trick to bypass "pragma
Pure" since it is an Ada 95 extension. I cannot comment on the use in
the GNAT runtime (was this to bypass Pure?). The general trick of
using export/import of symbols to bypass compiler sanity checking
surely predates all that stuff, that's a part of K&R C ;-).

> Laurent Guerby wrote:
> > In the "break everything" area you also have stream based code which
> > does all sorts of "unchecked" stuff without having "unchecked" in
> > its name (well it's obvious, but it breaks the "grep Unchecked" rule
> > ;-).
> But that's really no different from Sequential_IO ...

True (except for the grep "IO" thing ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <938qom$ptd$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:

> I find that people who "detest" certain styles of working and
> working environments sometimes lack the flexibility to deal
> with difficult situations. It sounds for instance like you
> would be really stuck if you were in a hiesenbug situation
> where the bug does not appear if you operate in the presence
> of the debugger. This can most certainly happen with some kinds
> of erroneous programs, or where timing problems are an issue.

Been there, done that, got the T-shirt.  I detested it.
I think one of the great debugger advances has been to
use a small engine in the process being debugged and
put the great bulk of the debugger (GUI, etc.) into
another process where it will not impact addresses,
etc.  (Of course that does not eliminate the heisenbug
possibility, but it reduces it in my experience). The
advent of this approach, however, was probably motivated
as much by kernel mode symbolic debugging as by taking
pity on those of us who were bitten by problems that go
away in the presence of the debugger.

> Indeed in real time programs, the paradigm of breakpoint and
> examine often breaks down badly. Yes, there are some
> asyncrhonous debugging tools around (like OCS Aprobe) which
> can be very valuable in such situations, but sometimes, a
> judiciously placed put_line can be the most efficient and
> effective debugging approach. If you are sure you "detest"
> such an approach, you may end up proceeding in less than
> an optimal manner. Flexibility is always a plus.

Detesting something is different from being unable to do it--
but I would expect code labeled PURE to be thoroughly debugged
outside that realtime environment through unit test and test
coverage analysis.

> Larry, I take it you are still stuck in an Ada 83 environment,
> where this particular issue does not arise? (I say that because
> it is quite a familiar problem to Ada 95 programmers :-)

I am quite happy programming in Ada 83, even for compilers that
support Ada 95, in order to preserve portability.  In our past
discussions in this newsgroup when I point out operating systems
without Ada 95 support you have said they are not popular operating
systems with ACT customers.

Re: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <x7v66jt40h3.fsf@smaug.pushface.org>, Simon Wright <simon@pushface.org> writes:
> n_brunot@my-deja.com writes:
> 
>> Assuming that one single person, however genius he is, can check
>> every single line code, and cannot make mistakes is totally
>> unrealistic and dangerous.
> 
> Which is one reason for doing code inspection .. four heads, focussed
> on the job, for no more than two hours at a time, can find a lot of
> problems, and the process tends to enforce standards.

Some of the most useful comments I got out of many weeks of formal
inspection had to do with uniformity of comments and uniformity of
error reporting completeness.  Those same individuals, reviewing
code one-by-one, do not provide such useful feedback to me outside
the "gang" environment.

Re: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <86snmvv79k.fsf@acm.org>, Laurent Guerby <guerby@acm.org> writes:

> In the "break everything" area you also have stream based code which
> does all sorts of "unchecked" stuff without having "unchecked" in its
> name (well it's obvious, but it breaks the "grep Unchecked" rule ;-).

Local standards can specify naming or renaming subprograms to use the
string UNCHECKED_ under certain conditions.

Re: Ok sorry, it is just a book gives no feedback.

[Marin David Condic]

Larry Kilgallen wrote:

> Been there, done that, got the T-shirt.  I detested it.
> I think one of the great debugger advances has been to
> use a small engine in the process being debugged and
> put the great bulk of the debugger (GUI, etc.) into
> another process where it will not impact addresses,
> etc.  (Of course that does not eliminate the heisenbug

I am presuming that you are talking about having a relatively small chunk of code in an
embedded app that will grab the contents of memory and send it down the wire upon request,
etc.? The concept of an on-board monitor that will load & read memory, maintain lists of
addresses to watch & report on periodically, etc. has been around for a while. They work very
nicely - especially since they remain in the production code/box so that you can actually use
them in the field if necessary. You don't need any special equipment besides the presence of
a communication link.

Granted, they do consume some of the available CPU time and may impact timing issues, but
they work very well for debugging in environments where you don't have specialized hardware
or Text_IO.

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: Ok sorry, it is just a book gives no feedback.

[Larry Kilgallen]

In article <3A59B1E1.A46DBE47@acm.org>, Marin David Condic <mcondic.nospam@acm.org> writes:
> Larry Kilgallen wrote:
> 
>> Been there, done that, got the T-shirt.  I detested it.
>> I think one of the great debugger advances has been to
>> use a small engine in the process being debugged and
>> put the great bulk of the debugger (GUI, etc.) into
>> another process where it will not impact addresses,
>> etc.  (Of course that does not eliminate the heisenbug
> 
> I am presuming that you are talking about having a relatively small chunk of code in an
> embedded app that will grab the contents of memory and send it down the wire upon request,
> etc.? The concept of an on-board monitor that will load & read memory, maintain lists of
> addresses to watch & report on periodically, etc. has been around for a while. They work very
> nicely - especially since they remain in the production code/box so that you can actually use
> them in the field if necessary. You don't need any special equipment besides the presence of
> a communication link.

Actually, my own concerns are more within a single general-purpose operating
system where one wants a full GUI debugger interface run by one process and
debugging another process.

My other application, closer to yours, is for debugging kernel code on a
general-purpose operating system with a separate system handling the GUI
for the debugger.

While the same approaches work for me as for you embedded folks, I post
this reply to emphasize the diversity of interests in the newsgroup.

==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================

Re: Ok sorry, it is just a book gives no feedback.

[Stephen Leake]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> In article <937jk6$s6l$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> ><snip> 
> > For example, you cannot add a Put_Line in a pure function,
> > and that is often very annoying.
> 
> I supposed it might be annoying to some people, but I detest
> that style of debugging.  I much prefer to place a breakpoint
> (even a conditional breakpoint) that will examine the data in
> question rather than change the source.  

Until I started writing programs for Win95, I agreed with Ted. But
even the GNAT debugger can't properly handle breakpoints in a window
procedure under Win95 (WinNT is only a little better). So now I'm used
to Text_IO.Put_Line for debugging. 

I do require my unit tests to not rely on modified units; I add child
packages instead.

Yet another reason to switch to Linux, but there are just so many fun
games that don't run there :).

-- 
-- Stephe

Re: Ok sorry, it is just a book gives no feedback.

[Ted Dennison]

In article <ubstiozon.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:
>
> > I supposed it might be annoying to some people, but I detest
> > that style of debugging.  I much prefer to place a breakpoint
> > (even a conditional breakpoint) that will examine the data in
> > question rather than change the source.
>
> Until I started writing programs for Win95, I agreed with Ted. But
> even the GNAT debugger can't properly handle breakpoints in a window
> procedure under Win95 (WinNT is only a little better). So now I'm used
> to Text_IO.Put_Line for debugging.

I think you meant "Larry". Generally, I'd agree with him. But I
currently find myself in a situation where I don't have access to
source-level debugging on our target machines. Plus, I'm doing a lot of
real-time work, which means I get a lot of "timing bugs". Timing bugs
can't really be debugged using intrusive methods like a debugger. So I'm
actually getting pretty good at debugging via other such means. But one
can always become attached to one's faithful tools. I'll sure miss
Windview on my next project!

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


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

Re: Ok sorry, it is just a book gives no feedback.

[Jean-Pierre Rosen]

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


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> a �crit dans le message news: ubstiozon.fsf@gsfc.nasa.gov...
> Until I started writing programs for Win95, I agreed with Ted. But
> even the GNAT debugger can't properly handle breakpoints in a window
> procedure under Win95 (WinNT is only a little better). So now I'm used
> to Text_IO.Put_Line for debugging.
>
Of course you'd better use package Debug from http://pro.wanadoo.fr/adalog/compo2.htm
(shameless plug :-)

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog