ada writing guide

ada writing guide

[Riyaz Mansoor]

i was wondering where i can get/find ada code conventions? i know C has a
standard.

like for example what is the "standard" way to write a procedure
declaration.

procedure (D : in out Data; C : in Cata);
procedure
   (D : in out Data;
    C : in     Cata);

or what?

thanx

riyaz

*******************

Re: ada writing guide

[Robert Dewar]

In article <8d1rso$bir$2@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
> i know C has a standard.

I don't know this.

Can you say clearly what you are referring to in the above
statement.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Riyaz Mansoor]

> > i know C has a standard.
>
> I don't know this.
>
> Can you say clearly what you are referring to in the above
> statement.

hehe

ok so it was stupid. but u know what i mean.

riyaz

Re: ada writing guide

[Jean-Marc Bourguet]

In article <8d41ki$c3f$1@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
>
> > > i know C has a standard.
> >
> > I don't know this.
> >
> > Can you say clearly what you are referring to in the above
> > statement.
>
> hehe
>
> ok so it was stupid. but u know what i mean.

I do not know. Emacs comes with something like 10 different
indentation styles for C, and allows quite a lot of customization
from these starting points.

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Robert Dewar]

In article <8d41ki$c3f$1@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
>
> > > i know C has a standard.
> >
> > I don't know this.
> >
> > Can you say clearly what you are referring to in the above
> > statement.
>
> hehe
>
> ok so it was stupid. but u know what i mean.


Not at all, I have no idea what you mean. There is absolutely
NO standard for C layout conventions, so please explain,
"hehe" is not very helpful.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

In article <8d1rso$bir$2@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
> i was wondering where i can get/find ada code conventions? i know C
> has a standard.

Try the Ada Quality and Style Guide, at
http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h
tml/cover.html

It is mean to be tailored to match site-specific guidlines, but it still
should give you a good idea of what is typical usage.

> like for example what is the "standard" way to write a procedure
> declaration.
>
> procedure (D : in out Data; C : in Cata);
> procedure
>    (D : in out Data;
>     C : in     Cata);

You forgot the procedure's name. ;-)  I prefer:
   procedure Foo
      (D : in out Data;
       C : in     Data
      );

but some prefer
   procedure Foo (D : in out Data;
                  C : in     Data);

I prefer the former because the parameters start in a standard place,
and won't get squeezed for space if the procedure name is long. Also,
its easier to see that the parens match. It does use up more vertical
real-estate, though (in this case, twice as much).

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Robert Dewar]

In article <8d1vhj$hdr$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> You forgot the procedure's name. ;-)  I prefer:
>    procedure Foo
>       (D : in out Data;
>        C : in     Data
>       );

I find the use of IN redundant since it is the default, but
this is a matter of taste, as usual the critical thing is to
be consistent. I especially find the use of IN annoying in
functions.

I find the extra ); on its own line offensive and unnatural,
just as clear, and much easier on the eye to write

>    procedure Foo
>       (D : in out Data;
>        C : in     Data);

In GNAT we prefer to put things on a single line:

>    procedure Foo (D : in out Data; C : Data);

If they fit comfortably on one line, and use the form with
one line per parameter only if that is not the case.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

In article <8d2hig$7e6$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8d1vhj$hdr$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > You forgot the procedure's name. ;-)  I prefer:
> >    procedure Foo
> >       (D : in out Data;
> >        C : in     Data
> >       );
>
> I find the use of IN redundant since it is the default, but
> this is a matter of taste, as usual the critical thing is to
> be consistent. I especially find the use of IN annoying in
> functions.

I'm beginning to come to the same conclusion on functions. You *know*
they all have to be "in", so why bother saying it? If anything, that
just give maintainers a false sense that the mode is under their
control.

For procedures, I think if you explicitly specify one mode, you should
explicitly specify them all. But  as you say, consistency is the most
important thing here.

> I find the extra ); on its own line offensive and unnatural,
> just as clear, and much easier on the eye to write
> >        C : in     Data);

...which I find uglier. But I'm probably in the minority there.

> In GNAT we prefer to put things on a single line:
>
> >    procedure Foo (D : in out Data; C : Data);
>
> If they fit comfortably on one line, and use the form with
> one line per parameter only if that is not the case.

In most places I've worked that is preferred too, if it is only one (or
no) parameter. Any more than that, and it ends up being a personal
judgement call which IMHO gives too much leeway to sloppier coders.
Also, a multiple parameter procedure seems to be much more likely to
have an extra parameter or two added later. Its annoying to have to
radicaly reformat 4 lines of code from one because you added one
parameter.

(sigh) I guess any "example" he gave was doomed to start a long thread.
:-)

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Jeffrey D. Cherry]

Robert Dewar wrote:
> 
> I find the extra ); on its own line offensive and unnatural,
> just as clear, and much easier on the eye to write
> 
> >    procedure Foo
> >       (D : in out Data;
> >        C : in     Data);
> 
> In GNAT we prefer to put things on a single line:
> 
> >    procedure Foo (D : in out Data; C : Data);
> 
> If they fit comfortably on one line, and use the form with
> one line per parameter only if that is not the case.

I quite agree that if a complete declaration can appear on one
line, it should not be arbitrarily broken up into two or more
lines.  I also agree with the ");" looking silly when it's 
on a line by itself.  The part about "in" mode for parameters
(not quoted above, but in the original post) I would also 
agree with, especially with function parameters.  Now 
here is where I stray ... just a bit.

I like the following form for a subprogram declaration:

    procedure Foo(
       D : in out Data;
       C : in     Data);

There are two subtle differences.  First, I like to put the
opening parenthesis on the line with the subprogram name.
This allows the parameter names to line up starting in the
same column.  Second, I don't leave a space between the 
subprogram name and the opening parenthesis.  I'm pretty
comfortable with the first point while the second I find is
debatable.

Personally, I eliminate the space between a subprogram name 
and its opening parenthesis because it handles parentheses 
consistently when they are associated with an identifier.  
However, this might _not_ be the more readable practice.  
Consider the following contrived example:

procedure Silly is
   function foobar(a : float) return integer is
   begin -- foobar
      return integer(float'truncation(a));
   end foobar;
   f : float := 3.33;
   i : integer;
   n : array(1..5) of integer := (5, 6, 7, 8, 9);
begin -- Silly    
   i := foobar(f) + n(2);
end Silly;

Notice the consistency in the assignment statement.  But is
it more readable to write:

   i := foobar (f) + n(2);

This may give the reader a subtle indication that foobar is
a function call while n is an array.  I am curious to hear 
what others think of this practice ... is it just silly to 
worry about or does it indeed improve the readability of 
an expression?  

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: ada writing guide

[Samuel T. Harris]

"Jeffrey D. Cherry" wrote:
> 
> Robert Dewar wrote:
> >
> > I find the extra ); on its own line offensive and unnatural,
> > just as clear, and much easier on the eye to write
> >
> > >    procedure Foo
> > >       (D : in out Data;
> > >        C : in     Data);
> >
> > In GNAT we prefer to put things on a single line:
> >
> > >    procedure Foo (D : in out Data; C : Data);
> >
> > If they fit comfortably on one line, and use the form with
> > one line per parameter only if that is not the case.
> 
> I quite agree that if a complete declaration can appear on one
> line, it should not be arbitrarily broken up into two or more
> lines.  I also agree with the ");" looking silly when it's
> on a line by itself.  The part about "in" mode for parameters
> (not quoted above, but in the original post) I would also
> agree with, especially with function parameters.  Now
> here is where I stray ... just a bit.
> 
> I like the following form for a subprogram declaration:
> 
>     procedure Foo(
>        D : in out Data;
>        C : in     Data);
> 

I prefer ...

procedure foo
 (
  d : in out data; -- some meaningful comment about d.
  c : in     data  -- some meaningful comment about c.
 );

procedure foo
 (
  d : in out data;
  c : in     data
 )
is
  [declarations]
begin
  [statements]
end;

I find the extra white space around the parameter group
natural and appealing.

The comments about d and c in the subprogram specification
can naturally be about the contact (a la Eiffle) assumptions.

The comments about d and c in the subprogram body
can be about internal assumptions or design details.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Paul Graham]

"Jeffrey D. Cherry" wrote: 
> Notice the consistency in the assignment statement.  But is
> it more readable to write:
> 
>    i := foobar (f) + n(2);
> 
> This may give the reader a subtle indication that foobar is
> a function call while n is an array.

That would violate the principle of "referential transparency" :-)

I like to keep the lexical components of a name together, so I don't put
a space between a function/array name and the '('.  Use of spaces with
parentheses can lead to names like this:

    f (x).y

where the tokens "(x).y" appear to be a lexical unit by themselves,
unconnected to function (or array) f. 

Paul

Re: ada writing guide

[Ted Dennison]

In article <38F5DF8C.1A01E5A4@utech.net>,
  "Jeffrey D. Cherry" <jdcherry@utech.net> wrote:
> Robert Dewar wrote:
> >
> > I find the extra ); on its own line offensive and unnatural,

> lines.  I also agree with the ");" looking silly when it's

> I like the following form for a subprogram declaration:
>
>     procedure Foo(
>        D : in out Data;
>        C : in     Data);
>

I don't mind this so much. But there is a small problem with it. Emacs
Ada mode (at least my version of it), will try to line up the parameters
with the open paren, so unless you want to fight Emacs your whole life
to put it back, you end up with:

   procedure Foo(
                 D : in out Data;
                 C : in     Data);

Which is really a smidge worse than:
   procedure Foo (D : in out Data;
                  C : in     Data);

...which is what I was trying to get away from, due to the wasted
horizontal space.

> Notice the consistency in the assignment statement.  But is
> it more readable to write:
>
>    i := foobar (f) + n(2);
>
> This may give the reader a subtle indication that foobar is
> a function call while n is an array.  I am curious to hear
> what others think of this practice ... is it just silly to
> worry about or does it indeed improve the readability of
> an expression?

Interesting. I never really thought about my tendancies here before. I'm
one of those who *likes* the syntactic transparency between arrays and
functions (and I'm a working engineer who has to debug a lot of other
people's bad buggy code, not some "ivory tower acedemic", as had been
claimed).

Hmmm. It looks like what I do is the following:
   Most functions have multiple parameters. In this case, named notation
is used in a style similar to the one used for subprogram specs.

   For the rest of the cases, about %90 of the time, there is a single
space between the "(" and the identifier. This is true whether its an
array, type conversion, or function call. So I do preserve
reference transparency.

   So what's different about the other %10? Some are situations where
there is some calculation or complex subranging inside the parenthesis.
One theory for why I did this would be that I have been
semi-subconciously using extra whitespace to draw the eye to the
"important parts" of a line.

  Other occurances happen when the contents of the parenthesis are
another identifier-parenthesis pair. Again, it could be argued that this
keeps from drawing undue attention to the identifier on the outside of
the operation. However, I suppose it could also be argued that this is
just a panicked attempt to save enough space to fit it all on a line,
turned into idiom.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Jeffrey D. Cherry]

Ted Dennison wrote:
> >     procedure Foo(
> >        D : in out Data;
> >        C : in     Data);
> 
> I don't mind this so much. But there is a small problem with it. Emacs
> Ada mode (at least my version of it), will try to line up the parameters
> with the open paren, so unless you want to fight Emacs your whole life
> to put it back, you end up with:
> 
>    procedure Foo(
>                  D : in out Data;
>                  C : in     Data);
> 
> Which is really a smidge worse than:
>    procedure Foo (D : in out Data;
>                   C : in     Data);
> 
> ...which is what I was trying to get away from, due to the wasted
> horizontal space.
 
Oh I definitely agree with you here.  I like neither of the above two 
forms.  Since the indentation is based on the length of an identifier 
name, differing identifiers produce differing indentation.  I think this
practice produces an ugly jumble of code that is much more difficult
to read when compared to a consistent indentation.

Regarding Emacs ... I don't use Emacs so this behavior was a surprise for me.
I would guess that there must be a way to change this behavior within Emacs.
I don't often use the automated layout features of my editor since my fingers
already do their own automated layout. ;)

> Hmmm. It looks like what I do is the following:
>    Most functions have multiple parameters. In this case, named notation
> is used in a style similar to the one used for subprogram specs.
 
Would you agree that always using named notation makes the code longer and
less readable?  Or would you disagree?  Is there some optimal number of 
parameters to a subprogram that makes you use named notation rather than 
positional notation?  Or is there other criteria that makes you choose one
method over the other?

>    For the rest of the cases, about %90 of the time, there is a single
> space between the "(" and the identifier. This is true whether its an
> array, type conversion, or function call. So I do preserve
> reference transparency.

Cool.  How about another question that is related to array references versus
subprogram calls?  I've noticed that some people put space between consecutive 
parameters in a subprogram call, but never put a space between index components
in an array reference.  For example:

   Target(i,j) := foobar (a, b, c);

In this example, Target is a two dimensional array and foobar is a function 
that takes three parameters.  Should there be a space in the index expression
of the array component?  Your thoughts?

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: ada writing guide

[Robert A Duff]

After all of these opinions about what layout style people like, the
answer to the original question -- is there a standard style? -- should
be clear.  ;-)

I'll throw in an opinion: I don't like leaving a space before "(",
because it leads to:

    Mumble (X).Bumble

which implies the wrong grouping.

- Bob

Re: ada writing guide

[Ted Dennison]

In article <38F603FE.B0C3ED83@utech.net>,
  "Jeffrey D. Cherry" <jdcherry@utech.net> wrote:
> Ted Dennison wrote:

> Regarding Emacs ... I don't use Emacs so this behavior was a surprise

I guess there are still a few of you. :-)

I can definitely understand wanting to keep your own council on
formatting. But Emacs' is so close to "right" for me, that its really
easier just to use it. My main complaint is that occasionaly I don't
want the standard capitalization (eg: acronyms).

> Would you agree that always using named notation makes the code longer
> and less readable?  Or would you disagree?  Is there some optimal
> number of parameters to a subprogram that makes you use named notation
> rather than positional notation?  Or is there other criteria that

I draw the line at one. For single parameter subprograms, (or multiple
parameter subprgrams where all but one are left defaulted) there is no
possibility of confusion, so it is indeed clearer to not supply the
parameter names. The only other situation where I'd advocate leaving off
the names is when the parameters are commutative.

It might look a little prettier when you write it to just slam all the
parameters together with no names. But when the code isn't working, the
first thing a person debugging it is going to be forced to do is go back
to the spec to verfy that those unnamed parameters weren't confused.

> subprogram calls?  I've noticed that some people put space between
> consecutive parameters in a subprogram call, but never put a space
> between index components in an array reference.  For example:
>
>    Target(i,j) := foobar (a, b, c);
>
> In this example, Target is a two dimensional array and foobar is a
> function that takes three parameters.  Should there be a space in the
> index expression of the array component?  Your thoughts?


On the theory that speaking from practice is better than just blathering
about theory, I went to look to see what I've done in the past. What I
found is...I don't do that. I do this instead:

   Target(i)(j) := foobar (a, b, c);
In the highly unlikely event that the three parameters of foobar are
commutative. More likely something like:
   Target(i)(j) := foobar (foo      => a,
                           bar      => b,
                           foobrand => c
                          );

I think "foobrand" is the correct technical term for a parameter to a
"foo" function. :-)

The problem with multidimensional arrays is that you can't easily take a
vector out of them and pass that to a standard subprogram, like you can
with arrays of arrays. I almost always end up wanting to do that. Thus I
don't use multidimensional arrays.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Pascal Obry]

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


Ted Dennison <dennison@telepath.com> a �crit dans le message :
8d5dsc$c27$1@nnrp1.deja.com...
> In article <38F603FE.B0C3ED83@utech.net>,
>   "Jeffrey D. Cherry" <jdcherry@utech.net> wrote:
> > Ted Dennison wrote:
>
> > Regarding Emacs ... I don't use Emacs so this behavior was a surprise
>
> I guess there are still a few of you. :-)
>
> I can definitely understand wanting to keep your own council on
> formatting. But Emacs' is so close to "right" for me, that its really
> easier just to use it. My main complaint is that occasionaly I don't
> want the standard capitalization (eg: acronyms).
>

This is addressed in latest GLIDE release where you can build an
exception list. This way you can write tbd and EMACS will
automagically capitalize it to TBD ! You just write it the way you want
once and you put it (with a magic key :) in your exception file that's
all.

So your main complaint is fixed :)

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Re: ada writing guide

[Ted Dennison]

In article <8d6hjn$j9p$1@clnews.edf.fr>,
  "Pascal Obry" <p.obry@der.edf.fr> wrote:
> This is addressed in latest GLIDE release where you can build an
> exception list. This way you can write tbd and EMACS will
> automagically capitalize it to TBD ! You just write it the way you
> want once and you put it (with a magic key :) in your exception file
> that's all.

Perfect! I'd considered writing some elisp to do exactly that myself,
but it didn't really look like a one-day job. Is the code that
accomplishes this elisp that comes with GLIDE, or an actual integral
part of GLIDE? It'd be a shame if folks had to use Gnat's IDE to get
access to it.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Pascal Obry]

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


Ted Dennison a �crit dans le message <8d76vj$9jt$1@nnrp1.deja.com>...
>In article <8d6hjn$j9p$1@clnews.edf.fr>,
>  "Pascal Obry" <p.obry@der.edf.fr> wrote:
>> This is addressed in latest GLIDE release where you can build an
>> exception list. This way you can write tbd and EMACS will
>> automagically capitalize it to TBD ! You just write it the way you
>> want once and you put it (with a magic key :) in your exception file
>> that's all.
>
>Perfect! I'd considered writing some elisp to do exactly that myself,
>but it didn't really look like a one-day job. Is the code that
>accomplishes this elisp that comes with GLIDE, or an actual integral
>part of GLIDE? It'd be a shame if folks had to use Gnat's IDE to get
>access to it.


This is already implemented in the latest Ada mode I think. Have a look
at version 3.4b of the Ada mode available here:

http://www.ada-france.org/ada-mode/

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"

Re: ada writing guide

[Ted Dennison]

In article <8d7uak$1d1$1@wanadoo.fr>,
  "Pascal Obry" <p.obry@wanadoo.fr> wrote:

> This is already implemented in the latest Ada mode I think. Have a
> look at version 3.4b of the Ada mode available here:

Downloaded, installed, and works. Thanks a bunch.

I do have one (minor) problem with the implementation, though. It looks
like the exception file is read once at startup into an internal buffer.
When someone adds an entry, it is their internal copy that is added to,
then written to disk. If another user changed that file in the
meantime, their changes are lost. This, combined with the advice for
projects to keep one master file which everyone uses, could lead to a
big mess.

I warned everyone here to load before they do any adds, but I'm afraid
its going to be easy advice to forget.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> I do have one (minor) problem with the implementation, though. It looks
> like the exception file is read once at startup into an internal buffer.
> When someone adds an entry, it is their internal copy that is added to,
> then written to disk. If another user changed that file in the
> meantime, their changes are lost. This, combined with the advice for
> projects to keep one master file which everyone uses, could lead to a
> big mess.

Put the file under version control.  I'm amazed to see that there are
still projects with multiple developers which do not use it. ;)

Re: ada writing guide

[Ted Dennison]

In article <87em84vavt.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> Ted Dennison <dennison@telepath.com> writes:
>
> > I do have one (minor) problem with the implementation, though. It
> > looks like the exception file is read once at startup into an
> > internal buffer. When someone adds an entry, it is their internal
> > copy that is added  to, then written to disk. If another user
> > changed that file in the meantime, their changes are lost. This,
> > combined with the advice for projects to keep one master file which
> > everyone uses, could lead to a big mess.
>
> Put the file under version control.  I'm amazed to see that there are
> still projects with multiple developers which do not use it. ;)
>

We do of course. I thought there was about a %30 chance someone would
bring this up. :-(

That is the first thing I thought of as well. However, further thought
will show you that it won't really solve the problem. It just gives us a
recovery option from particularly bad losses, at the cost of a lot of
overhead around any changes.

To help you see, cosider the following scenario:

  Monday Fred opens up an emacs session.
  Tuesday, Joe opens up an emacs session and adds 3 capitalizations.
  Wednesday, Joe adds 3 more capitalizations
  Thursday, Joe adds  3 more capitalizations
  Friday, Fred adds 5 capitalizations (wiping out all of 6 Joe's)
  Monday, Joe adds 4 more capitalizations (wiping out Fred's 5)
  etc.

With revision control, we have:

  Monday Fred opens up an emacs session.
  Tuesday, Joe opens up an emacs session, checks out the cap file, adds
3 capitalizations, and checks back in the cap file.
  Wednesday, Joe checks out the cap file, adds 3 more capitalizations,
and checks back in the cap file.
  Thursday, Joe checks out the cap file, adds 3 more capitalizations,
and checks back in the cap file.
  Friday, Fred checks out the cap file, adds 5 capitalizations, and
checks back in the cap file. (wiping out all 6 of Joe's)
  Monday, Joe checks out the cap file, adds 4 more capitalizations, and
checks back in the cap file (wiping out Fred's 5)
  etc.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

In article <8dfpj7$crs$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

>   Tuesday, Joe opens up an emacs session and adds 3 capitalizations.
>   Wednesday, Joe adds 3 more capitalizations
>   Thursday, Joe adds  3 more capitalizations
>   Friday, Fred adds 5 capitalizations (wiping out all of 6 Joe's)

Eeeah. That adds up to *9* capitalizations, not 6. Where's that english
sentence compiler when I need it?....

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Robert Dewar]

In article <8dfpj7$crs$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> checks back in the cap file. (wiping out all 6 of Joe's)
>   Monday, Joe checks out the cap file, adds 4 more
capitalizations, and
> checks back in the cap file (wiping out Fred's 5)
>   etc.


This is incomprehensible, with proper revision control no one
ever wipes out anyone else's work.

If individuals need variants, a proper revision control system
accomodates this.

This sounds like a comment from a VERY uncontrolled environment.
Ted, what configuration control software are you using?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

In article <8dgk8i$ak4$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:

> This is incomprehensible, with proper revision control no one
> ever wipes out anyone else's work.
(sigh) You seem to be missing the point too.

Yes, the old versions are still there. But in order for version 1.2 to
be based on version 1.1, the person who created 1.2 had to have been
working from version 1.1 (and not 1.0). Right?

If this were a normal source file, then emacs would at worst warn the
user that the file has changed on disk before it allows them to edit it.
A similar warning would be given before the file can be saved. But the
exception file is *not* a normal source file (unless you load and
hand-edit the file, I guess), and no such warnings occur. Try it
yourself with two emacs sessions if you don't believe me. Throw RCS into
the mix, and verify for yourself that the same thing happens, only with
saved copies.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Robert Dewar]

In article <8dhqi7$jv3$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Yes, the old versions are still there. But in order for
version 1.2 to
> be based on version 1.1, the person who created 1.2 had to
have been
> working from version 1.1 (and not 1.0). Right?

Robert is a bit incredulous here (and again wonders what
kind of configuration management is used in Ted's company).

Of *course* if you update a file, you have to worry about not
blotting out changes done to previous versions.

This is achieved in one of two ways

1. You merge changes yourself, always going from the most
recently checked in version.

2. You use an automatic merge facility such as that provided
in CVS.

I personally prefer the first approach, but many find the second
approach fine.

T.E.D. seems to be describing a system in which people use
neither approach, and merrily destroy one anothers fixes by
updating old versions. I would NOT call this version control
at all.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

In article <8dhuuu$ou5$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8dhqi7$jv3$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:

> T.E.D. seems to be describing a system in which people use
> neither approach, and merrily destroy one anothers fixes by
> updating old versions. I would NOT call this version control
> at all.

I must be a really crappy communicator if a complaint about an emacs
configuration file being difficult to control from long-lived sessions
comes off this horribly off-target. I guess I should quit while I'm
behind, but...

Substitute "emacs" for "people", and "exception file changes" for
"fixes", and that's my exact problem with it.

Perhaps if I rephrase it this way: How easy is it for a "fix" to get
wiped out using emacs? I have used 6 different revision control systems,
but the following process will work with all of them (ClearCase requires
custom emacs lisp files, but they exist).

  First, for a normal source file:
    The file has to be explicitly opened in an emacs buffer.
    The file has to be updated outside of the emacs buffer, while the
emacs session remains running.
    The updated version has to be checked in.
    The emacs user has to check the source file out *outside* of emacs,
while it is already in the emacs buffer. Checking it out inside of emacs
would cause the buffer to get updated with the latest copy.
    If the buffer was read-only when the user loaded it, the user must
manually change it to read/write without realoading the file. This can
be done, but few would routinely do it that way with managed files.
    Next the user would have to edit the buffer (containing the older
version). This will cause emacs to dispaly a prompt asking if they
really want to edit, as this isn't the latest version. The user *must*
type a "y" to proceed.
    Next the user must save the buffer. Again, a warning will be
displayed stating that this isn't the latest version. The user must type
a y at the prompt (which they wouldn't normally have to do) to save the
file. A backup of the old file will be created by emacs.
    Finally, the user must check in the buffer (inside or outside of
emacs).

Reading over all this, it should be clear to anyone that there is *no
way* all this is going to happen on accident.

Now, for an exceptions file:
   The user starts up emacs
   A second user (or possibly the same user with a second emacs session)
checks the file out.
   The second user modifies it somehow.
   The second user checks the file in.
   The first user checks the file out.
   The first user types Ctrl-C Ctrl-Y in their emacs session.
   The first user checks the file in.

No warnings are given, no backups are made. The old version is
over-written. Even for those who know the danger, this would be easy to
accidentally do.

Again, if anyone is still confused, I'm *not* saying this can happen
with normal source files. Its a problem with the emacs Ada-mode
capitalization files, which is cheifly an artifact of the fact that the
tool that uses them never rereads them once it has started. It would be
roughly equivalent to sources only you had to issue some special command
or reboot every time you wanted your compiler to read the latest source
files from disk.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Brian Courtney]

Ted Dennison wrote:

> In article <8dhuuu$ou5$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <8dhqi7$jv3$1@nnrp1.deja.com>,
> >   Ted Dennison <dennison@telepath.com> wrote:
>
> > T.E.D. seems to be describing a system in which people use
> > neither approach, and merrily destroy one anothers fixes by
> > updating old versions. I would NOT call this version control
> > at all.

Perhaps I can clear things up a bit here.  Teds complaint stems
from the fact that the implementation of  Emacs ada-mode
assumes that each user has their own copy of a special
capitalization exception file (used to overide the default
capitalization rules used by the editor).  If each user has
their own copy, then there is no problem.  Think of it like a
.cshrc file were each user defines their own customized
commands, aliases, etc...).  If a single 'common' file is used
(shared among several users) to ensure that all capitalization
is consistent, there is a chance that changes to the capitalization
exception file can be lost, due to the fact that there is no protection
built into Emacs to detect if someone else has modified the file
since it was last read in.  Whether the file is under configuration
control or not is irrelevant in this situation.   This is a special
configuration file used by the Emacs editor that can be updated
on-the-fly by a user.  Since the implementation of ada-mode
modifies to its "potentialy out of date" internal copy of the exception
file before writting it to disk, someone elses updates to the same file
(made after your Emacs session read the file) can be lost.

Ted was simply giving his opinion on a possible pitfall associated
with using  ada-mode and a *single* capitialization exception file.
I do not believe this is a CM issue.  CM comes into play *after*
the updates have been made to a file.  A CM tool can not prevent
you from accidently deleting lines from a file and then saving them.
CM will, however, allow you to restore the file to the last controlled
version, but all the intermediate changes made outside the CM
tool (while you are still editing the file) are not controlled.   This is
the situtation we are dealing with.

Ted,

There are two possible solutions that I see

 1. make the capitalization file read-only and have the users submit
     changes to the file through the owner.  Not the best solution.

  2. change ada-mode.el to re-read the exception file and update
     the internal copy just before it saves the file.  NOTE: There may
     still be small chance that changes will be lost with this approach,
     but very very unlikely.

     ex,  (NOTE: I have not tried this, but it should work).

from ada-create-case-exception

  ;;  Save the list in the file
  (find-file (expand-file-name ada-case-exception-file))
  (erase-buffer)
  ;; force update of ada-case-exception (reread exception file)
  (ada-case-read-exceptions)   ;; this line added from original
  (mapcar '(lambda (x) (insert (car x) "\n")) ada-case-exception)
  (save-buffer)
  (kill-buffer nil)
  )

Re: ada writing guide

[Florian Weimer]

Brian Courtney <bcourtn@hercii.mar.lmco.com> writes:

> I do not believe this is a CM issue.  CM comes into play *after*
> the updates have been made to a file.

Some CM flavors give each user his own set of source files.  I'm
surprised such systems aren't more widespread.  There are numerous
advantages with this approach, and only few drawbacks.

Re: ada writing guide

[Brian Courtney]

Brian Courtney wrote:

>   2. change ada-mode.el to re-read the exception file and update
>      the internal copy just before it saves the file.  NOTE: There may
>      still be small chance that changes will be lost with this approach,
>      but very very unlikely.
>
>      ex,  (NOTE: I have not tried this, but it should work).

Famous last words!

>
>
> from ada-create-case-exception
>
>   ;;  Save the list in the file
>   (find-file (expand-file-name ada-case-exception-file))
>   (erase-buffer)
>   ;; force update of ada-case-exception (reread exception file)
>   (ada-case-read-exceptions)   ;; this line added from original
>   (mapcar '(lambda (x) (insert (car x) "\n")) ada-case-exception)
>   (save-buffer)
>   (kill-buffer nil)
>   )


That's what I get for not testing it myself.

Add the call to ada-case-read-exceptions to the first line
of the ada-create-case-exception function and that
should solve your problem (I tested it this time and it seems
to work).

Re: ada writing guide

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> No warnings are given, no backups are made. The old version is
> over-written. Even for those who know the danger, this would be easy to
> accidentally do.

This can't happen with systems like CVS where each user works on his
private copy of the source files.  The master files are often not
directly accessible.  Problem solved. ;)

Re: ada writing guide

[Robert Dewar]

In article <874s8yeg81.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> Ted Dennison <dennison@telepath.com> writes:
>
> > No warnings are given, no backups are made. The old version
is
> > over-written. Even for those who know the danger, this would
be easy to
> > accidentally do.
>
> This can't happen with systems like CVS where each user works
on his
> private copy of the source files.  The master files are often
not
> directly accessible.  Problem solved. ;)

Exactly! I find it extraordinary that the master files should
ever be directly accessible. I would find a system where Ted's
scenario can occur quite unacceptable!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

Robert Dewar wrote:

> In article <874s8yeg81.fsf@deneb.cygnus.argh.org>,
>   Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> Exactly! I find it extraordinary that the master files should
> ever be directly accessible. I would find a system where Ted's
> scenario can occur quite unacceptable!

I have already explained that this scenario can occur just as easily
when the revision control master files are not directly accessable. So
you have now agreed that you find the current version of emacs Ada mode
"quite unacceptable".

That's a bit more extreme than my position that its just a somewhat bad
problem, but at this point I'll take agreement where I can get it. :-)

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: ada writing guide

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> I have already explained that this scenario can occur just as easily
> when the revision control master files are not directly accessable.

No, you have shown that careless programmers can make a mess even if a
CM system is used.  For example, with CVS, a programmer cannot commit
his changes to a file if they are based on an outdated version (i.e. a
newer one has been committed to the repository since he first checked
out the file).  He has to adapt his changes to match the newest
version of the file first.  Of course, if the programmer doesn't
handle this situation properly, changes to the file might get lost.
But if a programmer can't cope with this situation (the simple format
of the file makes merging the changes particularly easy), you are soon
going to have much severe problems than lost entries in a exception
list controlling identifier casing.

> So you have now agreed that you find the current version of emacs
> Ada mode "quite unacceptable".

I think Robert talked about CM systems. ;)

Re: ada writing guide

[Ted Dennison]

Florian Weimer wrote:

> Ted Dennison <dennison@telepath.com> writes:
>
> > I have already explained that this scenario can occur just as easily
> > when the revision control master files are not directly accessable.
>
> No, you have shown that careless programmers can make a mess even if a
> CM system is used.  For example, with CVS, a programmer cannot commit
> his changes to a file if they are based on an outdated version (i.e. a
> newer one has been committed to the repository since he first checked
> out the file).  He has to adapt his changes to match the newest
> version of the file first.  Of course, if the programmer doesn't

Since I don't see any specifics in my post addressed, I'll try to do it
for you myself. One of us is missing something. It could well have been
me:


  1. User does checkout of cvs repostitory
  2. User starts emacs, which loads the exception file into a local
     buffer.
  3. Exception file changes outside of emacs, and is updated.
  4. User realizes that lots of stuff is out of date (not nessecarily just
     exception file), so he does a "cvs update". Now as far as CVS is
     concerned, user is looking at the most up-to date version. However,
     his emacs is still working from the old exception file.
  5. User sees a new exception, and does a Ctrl-C Ctrl-Y, which saves the
     *old* version of the exception file to disk, with his one update
  6. User wants his new exception saved in cvs, so he does a "cvs commit".
     Cvs has no problem with this, as it thinks the user was working from
     the latest version.

Now the result of this process is that User just wiped out the previous
version revision-controlled changes to the exception file.

So what are your *specific* problems with this scenario? You said:

   * "Careless programmers can make a mess, even if CM is used". So
     perhaps you think that User above was being careless in not routinely
     doing an update of emacs' internal exceptions buffer before doing the
     write? That is perhaps a reasonable position. But in that case, why
     bring up revision control at all? Revision control doesn't even
     materially change the mistake a "careless" programmer has to make. It
     just adds some steps to either side of it. Plus, if the way to *not*
     be careless is to take one extra step (reloading the exceptions
     buffer) every time it is saved, what's wrong with advocating that
     emacs do both instead of just the one? Why leave it open to easy
     carelessnes? Why make the user perform two steps (forgetting one of
     which will sliently hose his file) every single time?
   * "with CVS, a programmer cannot commit his changes to a file if they
     are based on an outdated version". This is true only in the abstract.
     All CVS does is force the programmer to have issued a "cvs update"
     from the most recent version before he does a "commit". CVS does not
     force emacs to reload its local copy of that file. Emacs, won't
     notice the problem on its side, like it would for a normal file. CVS
     has no way of telling that the file used for "commit" really was
     based off that "update" file. If emacs wipes out that most recent
     version with something based off an older version, CVS can't help
     you.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: ada writing guide

[Ted Dennison]

In article <874s8yeg81.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> Ted Dennison <dennison@telepath.com> writes:
>
> > No warnings are given, no backups are made. The old version is
> > over-written. Even for those who know the danger, this would be easy
to
> > accidentally do.
>
> This can't happen with systems like CVS where each user works on his
> private copy of the source files.  The master files are often not
> directly accessible.  Problem solved. ;)

Hmm. I use CVS at home, but I guess that's not multiuser (yet, perhaps
It'll be that way when my kids are older :-)  ).

I'm still not convinced CVS wouldn't have the problem too. But at least
the process give you one hint. I see it working this way.

  User A does a "cvs checkout" of the repository
  User B does a "cvs checkout" of the repository
  User A starts up emacs (which reads the exception file into memory).
  User B starts up emacs (which reads the exception file into memory).
  User A hits Ctrl-C Ctrl-Y
  User A does a "cvs commit" on the exception file
  User B finds out there were changes, and does a "cvs update"
  User B hits Ctrl-C Ctrl-Y (unknowingly wiping out user A's changes)
  User B does a "cvs commit"

At least this way, there is a manual updating step in there, where the
wise user could say, "I'd better bring my emacs up to date, just to be
safe." But it'd still be awfully easy to forget, or overlook a running
session somewhere.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Samuel T. Harris]

Ted Dennison wrote:
> 
> In article <874s8yeg81.fsf@deneb.cygnus.argh.org>,
>   Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> > Ted Dennison <dennison@telepath.com> writes:
> >
> > > No warnings are given, no backups are made. The old version is
> > > over-written. Even for those who know the danger, this would be easy
> to
> > > accidentally do.
> >
> > This can't happen with systems like CVS where each user works on his
> > private copy of the source files.  The master files are often not
> > directly accessible.  Problem solved. ;)
> 
> Hmm. I use CVS at home, but I guess that's not multiuser (yet, perhaps
> It'll be that way when my kids are older :-)  ).
> 
> I'm still not convinced CVS wouldn't have the problem too. But at least
> the process give you one hint. I see it working this way.
> 
>   User A does a "cvs checkout" of the repository
>   User B does a "cvs checkout" of the repository

Here is your problem. Any tool which does not provide some
check on multiple check-outs and a way to prevent then
is seriously broken IMO. Access controls become more and more
important as project size grows, or the separation between
developers increases. Multiple changes to the same source
simply cannot be allowed. Merging is just not a viable
mitigator to this chaotic sequence of events.

>   User A starts up emacs (which reads the exception file into memory).
>   User B starts up emacs (which reads the exception file into memory).
>   User A hits Ctrl-C Ctrl-Y
>   User A does a "cvs commit" on the exception file
>   User B finds out there were changes, and does a "cvs update"
>   User B hits Ctrl-C Ctrl-Y (unknowingly wiping out user A's changes)

With access controls, this would not happen because the B's
check-out would have failed. This mentality of letting anyone
do anything and merge it all together later is simply frought
with too many pitfalls.

>   User B does a "cvs commit"
> 
> At least this way, there is a manual updating step in there, where the
> wise user could say, "I'd better bring my emacs up to date, just to be
> safe." But it'd still be awfully easy to forget, or overlook a running
> session somewhere.

There in lies the rub. Merging later depends upon that later
actually coming. Better to prevent multiple changes up front.
User A and B have a file based upon some common version.
User A checks it out, makes changes, and then checks it in.
User B checks it out and fails because he does not have the
latest version. User B can not attempt the check out again
and force the system to ignore User A's changes (B had better
know what he is doing here) or User B can accept the changes
from User A and then check out the file.

> 
> --
> T.E.D.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Samuel T. Harris]

Florian Weimer wrote:
> 
> Ted Dennison <dennison@telepath.com> writes:
> 
> > No warnings are given, no backups are made. The old version is
> > over-written. Even for those who know the danger, this would be easy to
> > accidentally do.
> 
> This can't happen with systems like CVS where each user works on his
> private copy of the source files.  The master files are often not
> directly accessible.  Problem solved. ;)

When programming in the large or huge, every developer simply
can't have his own copy of the entire project. There just isn't
enough disk space available. Therefore, a divide and conquer
mentality is in order where various groups of developers
depend upon shared "releases" of the other groups. This is where
good configuration management tools diverge from the simple
domain of version and access control.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Robert A Duff]

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:

> 
> Florian Weimer wrote:
> > 
> > Ted Dennison <dennison@telepath.com> writes:
> > 
> > > No warnings are given, no backups are made. The old version is
> > > over-written. Even for those who know the danger, this would be easy to
> > > accidentally do.
> > 
> > This can't happen with systems like CVS where each user works on his
> > private copy of the source files.  The master files are often not
> > directly accessible.  Problem solved. ;)
> 
> When programming in the large or huge, every developer simply
> can't have his own copy of the entire project. There just isn't
> enough disk space available. Therefore, a divide and conquer
> mentality is in order where various groups of developers
> depend upon shared "releases" of the other groups. This is where
> good configuration management tools diverge from the simple
> domain of version and access control.

CVS supports that model, too.

(But this is a separate issue -- neither CVS nor any other CM system
solves the editor-related bug we were talking about.)

- Bob

Re: ada writing guide

[Robert Dewar]

In article <390483D0.3AE3A577@Raytheon.com>,
  "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:
> When programming in the large or huge, every developer simply
> can't have his own copy of the entire project.

I agree with that for many reasons.

> There just  isn't enough disk space available.

But that's a week argument these days, when you can get 90
gigs of Raid 5 storage accessible from any NT or Unix machine
for under $3000. Any organization that let's itself be
limited by disk space is wasting the time of its programmers!

The arguments for avoiding unnecssary documentation are
organizational rather than resource based in my view.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Samuel T. Harris]

Robert Dewar wrote:
> 
> In article <390483D0.3AE3A577@Raytheon.com>,
>   "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:
> > When programming in the large or huge, every developer simply
> > can't have his own copy of the entire project.
> 
> I agree with that for many reasons.
> 
> > There just  isn't enough disk space available.
> 
> But that's a week argument these days, when you can get 90
> gigs of Raid 5 storage accessible from any NT or Unix machine
> for under $3000. Any organization that let's itself be
> limited by disk space is wasting the time of its programmers!
> 
> The arguments for avoiding unnecssary documentation are
> organizational rather than resource based in my view.
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Please be careful for careless use of the word "any".

We have 300 developers, 7000 program units, 150 separate
compilation areas which all have to be pieced together.
Even with a terabyte RAID array we are still running out!
At it cost several more zeros than $3000.

Huge project, numerous parallel development, maintenance
and operational paths, 300 developers, and the need
for reasonable back-up performance. You do the math!
Disk space is a limiting factor!

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Emmanuel Briot]

Ted Dennison <dennison@telepath.com> writes:
> I do have one (minor) problem with the implementation, though. It
> looks like the exception file is read once at startup into an
> internal buffer. When someone adds an entry, it is their internal
> copy that is added  to, then written to disk. If another user
> changed that file in the meantime, their changes are lost. This,
> combined with the advice for projects to keep one master file which
> everyone uses, could lead to a big mess.


Note that this was indeed a limitation in ada-mode 3.4b, that has been
fixed about 3 or 4 months ago in the developpment version.
This version is currently only available to ACT's customers (this is
part of our integrated environment Glide), but will soon be included in
a public version (that's a long time since I released the last version,
I should do something about that :-)

The fix was indeed to reread the project file before addind a new
casing exception in there, which should mostly solve your problem,
except maybe in the rare case where two users are trying to add an
exception at exactly the same time. And even then, Emacs's internal
mechanism will check and warn you that the file is already opened by
another user.

Emmanuel
ada-mode maintainer.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

Emmanuel Briot wrote:

> Ted Dennison <dennison@telepath.com> writes:
> > looks like the exception file is read once at startup into an
> > internal buffer. When someone adds an entry, it is their internal
> > copy that is added  to, then written to disk. If another user
> > changed that file in the meantime, their changes are lost. This,
> > combined with the advice for projects to keep one master file which
> > everyone uses, could lead to a big mess.
>
> Note that this was indeed a limitation in ada-mode 3.4b, that has been
> fixed about 3 or 4 months ago in the developpment version.

Cool. I thought this looked like a rather obvious problem, which would
probably get fixed eventually. This is the kind of thing I was hoping to
hear.

Thanks for the good work Emmanuel (not to mention the voice of reason).

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: ada writing guide

[Samuel T. Harris]

Ted Dennison wrote:
> 
> With revision control, we have:
> 
>   Monday Fred opens up an emacs session.
>   Tuesday, Joe opens up an emacs session, checks out the cap file, adds
> 3 capitalizations, and checks back in the cap file.
>   Wednesday, Joe checks out the cap file, adds 3 more capitalizations,
> and checks back in the cap file.
>   Thursday, Joe checks out the cap file, adds 3 more capitalizations,
> and checks back in the cap file.

Any version control system which allows Fred to simply check-out
the file without warning him that his content is no longer
based on the latest version is seriously broken! This is a
basic access control feature. If you want this protection,
then support of this feature becames a primary tool selection
requirement!

>   Friday, Fred checks out the cap file, adds 5 capitalizations, and
> checks back in the cap file. (wiping out all 6 of Joe's)
>   Monday, Joe checks out the cap file, adds 4 more capitalizations, and
> checks back in the cap file (wiping out Fred's 5)
>   etc.
> 

Our configuration management tool fails on Freds Friday check-out
because the version upon which he is basing his check-out is no
longer the latest version available. At that point, Fred can
try again and either accept the latest version before the
check-out (thus preserving Joe's changes) or forcing his
version to become the latest (because he KNOWS Joe's changes
are bogus).

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Ted Dennison]

"Samuel T. Harris" wrote:

> Any version control system which allows Fred to simply check-out
> the file without warning him that his content is no longer
> based on the latest version is seriously broken! This is a
> basic access control feature. If you want this protection,
> then support of this feature becames a primary tool selection
> requirement!

(Sigh). You are talking about a different revision control setup than I was
in the quoted post (one in which the latest source is always visible, unless
a local copy is checked out for editing). I addressed the (CVS) style you are
referring to in another post. Suffice to say, the problem still exists in the
setup you are talking about too (unless you have some kind of revision
control system that notices that emacs has an obsolete copy loaded in its
internal buffer).

It seems like a lot of heat is getting generated on this issue due to
misunderstandings about how different revision control systems work. The
tragic part of this is that it doesn't matter at all what style of RCS you
are using. We are *not* talking about external files here, but a buffer
internal to emacs that never again gets checked against the file it was
loaded from. No gyration done with external files can *possibly* solve this
problem.

Clearly the right solution to this problem (emacs checking the file for
changes before writing it back out), has already been arrived at and
implemented. So I don't see much point in continuing to sit here and argue
over whether the problem exists. If the maintainer of the emacs ada mode saw
that it exsits, and thought it was enough of a problem that it warranted
fixing by the next revision, that's good enough for me.

If anyone still feels compelled to continue this discussion, please at least
do me the service of writing down your own scenario that shows how this won't
be a problem. I feel like I'm swinging at the wind here.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: ada writing guide

[Robert Dewar]

In article <38FF4D28.8F946BDA@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> "Samuel T. Harris" wrote:
>

Ted, I think you missed my point :-) I will say again, that
this kind of mistake is COMPLETELY IMPOSSIBLE for my working
environment. Why, because every time I check something in, I
carefully verify that the changes I am making are exactly as
I expect them to be. I find any system which does not involve
such careful double checks to be seriously flawed. I also
carefully watch version numbers and double check BEFORE the
checkin that the version number is what I expect.

I quite understand that in the (to me) sloppy kind of
environment you are envisioning there could be a problem,
and I am glad that the emacs change helps bullet proof
you from this mistake, but I will say again, that I think
that any configuration control system that lets you accidentally
undo changes is broken.

It really all depends on what you are looking for. It sounds
like you are looking for a very light weight system, where
following the rule of always using emacs mostly bails you out
of this kind of error, but I certainly would not rely on that
in my environment.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

Robert Dewar wrote:

> Ted, I think you missed my point :-) I will say again, that
> this kind of mistake is COMPLETELY IMPOSSIBLE for my working
> environment. Why, because every time I check something in, I
> carefully verify that the changes I am making are exactly as
> I expect them to be. I find any system which does not involve

Ahh, you're right, I didn't catch that part before. So you are saying
you always do a diff and visually inspect the report prior to doing a
checkin? That would indeed catch the problem. It wouldn't *prevent* the
problem, but it would catch it before you hose the baseline. The removal
of an item would stick out like a sore thumb on a diff. Personally, I'd
prefer to see the problem prevented than caught though. Remember that my
complaint was that it can happen in the first place, not that its
impossible to catch.

> such careful double checks to be seriously flawed. I also
> carefully watch version numbers and double check BEFORE the
> checkin that the version number is what I expect.

Again, version number cheking wouldn't help in this situation (assuming
cvs). CVS would think your version number is as it should be. Or are you
talking about embedding version a CVS version code in the exception
file? I guess you could do that, if it isn't the first thing on a line.


--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: ada writing guide

[Larry Kilgallen]

Reply-To: Kilgallen@eisner.decus.org.nospam
Organization: LJK Software
Lines: 21

In article <38FFD43E.70F1BB7D@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
> Robert Dewar wrote:
> 
>> Ted, I think you missed my point :-) I will say again, that
>> this kind of mistake is COMPLETELY IMPOSSIBLE for my working
>> environment. Why, because every time I check something in, I
>> carefully verify that the changes I am making are exactly as
>> I expect them to be. I find any system which does not involve
> 
> Ahh, you're right, I didn't catch that part before. So you are saying
> you always do a diff and visually inspect the report prior to doing a
> checkin? That would indeed catch the problem. It wouldn't *prevent* the
> problem, but it would catch it before you hose the baseline. The removal
> of an item would stick out like a sore thumb on a diff. Personally, I'd
> prefer to see the problem prevented than caught though. Remember that my
> complaint was that it can happen in the first place, not that its
> impossible to catch.

But there is nothing to prevent me, in using an editor, from making
a change that exactly removes a previous change.  Therefore, human
inspection of what gets checked in will always be required.

Re: ada writing guide

[Robert Dewar]

In article <38FF4D28.8F946BDA@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> "Samuel T. Harris" wrote:
>

Ted, you are also not listening here. I will say again, that
this kind of mistake is COMPLETELY IMPOSSIBLE for my working
environment. Why, because every time I check something in, I
carefully verify that the changes I am making are exactly as
I expect them to be. I find any system which does not involve
such careful double checks to be seriously flawed.

I quite understand that in the (to me) sloppy kind of
environment you are envisioning there could be a problem,
and I am glad that the emacs change helps bullet proof
you from this mistake, but I will say again, that I think
that any configuration control system that lets you accidentally
undo changes is broken.

It really all depends on what you are looking for. It sounds
like you are looking for a very light weight system, where
following the rule of always using emacs mostly bails you out
of this kind of error, but I certainly would not rely on that
in my environment.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Samuel T. Harris]

Ted Dennison wrote:
> 
> "Samuel T. Harris" wrote:
> 
> > Any version control system which allows Fred to simply check-out
> > the file without warning him that his content is no longer
> > based on the latest version is seriously broken! This is a
> > basic access control feature. If you want this protection,
> > then support of this feature becames a primary tool selection
> > requirement!
> 
> (Sigh). You are talking about a different revision control setup than I was
> in the quoted post (one in which the latest source is always visible, unless
> a local copy is checked out for editing). I addressed the (CVS) style you are
> referring to in another post. Suffice to say, the problem still exists in the
> setup you are talking about too (unless you have some kind of revision
> control system that notices that emacs has an obsolete copy loaded in its
> internal buffer).
> 
> It seems like a lot of heat is getting generated on this issue due to
> misunderstandings about how different revision control systems work. The
> tragic part of this is that it doesn't matter at all what style of RCS you
> are using. We are *not* talking about external files here, but a buffer
> internal to emacs that never again gets checked against the file it was
> loaded from. No gyration done with external files can *possibly* solve this
> problem.
> 
> Clearly the right solution to this problem (emacs checking the file for
> changes before writing it back out), has already been arrived at and
> implemented. So I don't see much point in continuing to sit here and argue
> over whether the problem exists. If the maintainer of the emacs ada mode saw
> that it exsits, and thought it was enough of a problem that it warranted
> fixing by the next revision, that's good enough for me.
> 
> If anyone still feels compelled to continue this discussion, please at least
> do me the service of writing down your own scenario that shows how this won't
> be a problem. I feel like I'm swinging at the wind here.
> 

I only like to add that I now understand the actual nature
of your problem. I can't say why I didn't get it before but
it was Emmanuel Briot's post which finally clued me into
to the real problem you were talking about.

Integration of CM tools with other tools is a black art.
You have an integration problem which no CM tool can
fully prevent. Part of our tool selection criteria is how
candidate tools can be fit into our CM system. Some tools
are great at what they do, but their file structures or
change flows simply make them incompatible with our systems.

I have felt your pain!

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Robert A Duff]

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:

> I only like to add that I now understand the actual nature
> of your problem.

I'm glad you posted this.  After seeing your previous posting, along
with many others incorrectly blaming sloppy CM, I was about to start
ranting and raving about "why doesn't anybody get it?!"  ;-)

The point is that this was a bug in Emacs, and no CM system could
possibly prevent the problem.  Actually, not a bug in Emacs per se, but
a bug in an Emacs extension.

In particular, Emacs was overwriting a (properly CM'ed) file with bogus
information it (Emacs) had evilly saved in its own in-memory buffers.
No CM system could prevent that -- it doesn't matter whether you like
the strict-locking style, or the "hack now, merge later" style.  Neither
one could prevent Emacs from overwriting the (properly checked out!)
file with bogus obsolete data.

>... I can't say why I didn't get it before but
> it was Emmanuel Briot's post which finally clued me into
> to the real problem you were talking about.
> 
> Integration of CM tools with other tools is a black art.
> You have an integration problem which no CM tool can
> fully prevent.

No, I don't agree.  The blame clearly lies on the Emacs side, not on the
CM side.  And (apparently) the bug has been fixed, which indicates that
the author of the Emacs extension in question agrees.  Let's not be
wishy-washy, and blame the bug on some amorphous interface between the
two.

>... Part of our tool selection criteria is how
> candidate tools can be fit into our CM system. Some tools
> are great at what they do, but their file structures or
> change flows simply make them incompatible with our systems.

True, but this case is a plain-and-simple bug in Emacs (or actually an
extension thereof).

- Bob

Re: ada writing guide

[Samuel T. Harris]

Robert A Duff wrote:
> 
> "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:
> 
> > Integration of CM tools with other tools is a black art.
> > You have an integration problem which no CM tool can
> > fully prevent.
> 
> No, I don't agree.  The blame clearly lies on the Emacs side, not on the
> CM side.  And (apparently) the bug has been fixed, which indicates that
> the author of the Emacs extension in question agrees.  Let's not be
> wishy-washy, and blame the bug on some amorphous interface between the
> two.

Let me clarify. By saying you have an integration problem, I
did not mean to direct blame, but only to classify the kind of
problem you were having. The tool IS clearly to be blamed
for not taking care in the writing and rewriting of such
a clearly important file. I believe we are in total
agreement!

> 
> >... Part of our tool selection criteria is how
> > candidate tools can be fit into our CM system. Some tools
> > are great at what they do, but their file structures or
> > change flows simply make them incompatible with our systems.
> 
> True, but this case is a plain-and-simple bug in Emacs (or actually an
> extension thereof).

My point here is that if any tool under consideration behaved
like Emacs does/did, then that tool would find itself on
the fast-track out the door! In such sitations, I don't care
if its a bug or intended behavior. If I can't control the
parts that need controlling, then I have no use for the tool!

Now, if the tool changes behavior, then I'm glad to reconsider it.
This is the happy result which you now enjoy and your enjoyment
makes me happy. The world is a better place now :)

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: ada writing guide

[Simon Wright]

"Jeffrey D. Cherry" <jdcherry@utech.net> writes:

> Regarding Emacs ... I don't use Emacs so this behavior was a
> surprise for me.  I would guess that there must be a way to change
> this behavior within Emacs.  I don't often use the automated layout
> features of my editor since my fingers already do their own
> automated layout. ;)

But your fingers aren't the same as mine.

Mine hit the TAB key and it's all done for me.

It is MUCH better to have a tool do the indentation for you and all
your colleagues so you can recognise one another's work .. you
probably wouldn't like APEX, you have NO control over layout! or
casing, as far as I can tell!

If you have a tool which will do

  procedure x
     (p1 : integer;
      p2 : integer);

you have just what you wanted (all the parameters neatly lined up),
why get antsy about that extra little paren?!

(I realise we will never agree about this, BTW)

Re: ada writing guide

[Robert Dewar]

In article <x7vhfd2t3ye.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:

> It is MUCH better to have a tool do the indentation for you
> and all your colleagues so you can recognise one another's
> work .. you
> probably wouldn't like APEX, you have NO control over layout!
> or casing, as far as I can tell!

I agree tools that check for consistency can be helpful, but
personally I find it intolerable for the editor to do ANYTHING
for me that I don't type myself, it just inteferes with my
thinking, and I type fast enough that typing speed is never
a bottleneck. I realize that others have different tastes, but
it is important for toolsets to accomodate both viewpoints.

What we do in the GNAT project is to put syntax and format
checks at the checkin interface. People use their own approaches
to generating the sources. Some people do indeed like to use
GLIDE and have everything automated, but we don't insist on
this approach.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ray Blaak]

Ted Dennison <dennison@telepath.com> writes:
> >     procedure Foo(
> >        D : in out Data;
> >        C : in     Data);
> 
> I don't mind this so much. But there is a small problem with it. Emacs
> Ada mode (at least my version of it), will try to line up the parameters
> with the open paren, so unless you want to fight Emacs your whole life
> to put it back, you end up with:
> 
>    procedure Foo(
>                  D : in out Data;
>                  C : in     Data);

Well, if you do this:

    procedure Foo
      (D : in out Data;
       C : in     Data);

then things look better IMHO, and you don't have to fight Emacs at all.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: ada writing guide

[Robert Dewar]

In article <8d4t07$o15$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> I don't mind this so much. But there is a small problem with
> it. Emacs Ada mode (at least my version of it)

I think you can safely assume that if I say something is
standard GNAT mode, then EMACS Ada mode handles it fine
(remember that the maintainer of EMACS Ada mode works for
ACT/Europe :-)

SO you are using an old version of EMACS.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <8d4t07$o15$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> 
> > I don't mind this so much. But there is a small problem with
> > it. Emacs Ada mode (at least my version of it)
> 
> I think you can safely assume that if I say something is
> standard GNAT mode, then EMACS Ada mode handles it fine
> (remember that the maintainer of EMACS Ada mode works for
> ACT/Europe :-)
> 
> SO you are using an old version of EMACS.

Well, is it really the case that this

  procedure Foo(
		D : in out Data;
		C : in     Data);

is the behaviour of old Emacses? It's the way adamode-3.4b behaves on
emacs 20.3 .. not all that old really. And perfectly reasonable
behaviour too! if it can stop just one person using those horrible
dangling open parens it will be worth it .. I tried it with a dangling
close paren too,

  procedure Foo(
		D : in out Data;
		C : in     Data
	       );

which is way too clever, can't we come up with some scheme to make
this really revolting?!

Re: ada writing guide

[Riyaz Mansoor]

link does not seem to be working ted.

"Ted Dennison" <dennison@telepath.com> wrote in message
news:8d1vhj$hdr$1@nnrp1.deja.com...
> In article <8d1rso$bir$2@bunyip.cc.uq.edu.au>,
>   "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
> >
> > i was wondering where i can get/find ada code conventions? i know C
> > has a standard.
>
> Try the Ada Quality and Style Guide, at
> http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h
> tml/cover.html
>
> It is mean to be tailored to match site-specific guidlines, but it still
> should give you a good idea of what is typical usage.
>
> > like for example what is the "standard" way to write a procedure
> > declaration.
> >
> > procedure (D : in out Data; C : in Cata);
> > procedure
> >    (D : in out Data;
> >     C : in     Cata);
>
> You forgot the procedure's name. ;-)  I prefer:
>    procedure Foo
>       (D : in out Data;
>        C : in     Data
>       );
>
> but some prefer
>    procedure Foo (D : in out Data;
>                   C : in     Data);
>
> I prefer the former because the parameters start in a standard place,
> and won't get squeezed for space if the procedure name is long. Also,
> its easier to see that the parens match. It does use up more vertical
> real-estate, though (in this case, twice as much).
>
> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: ada writing guide

[David C. Hoos, Sr.]

Riyaz Mansoor <s800032@student.uq.edu.au> wrote in message
news:8d41os$3jn$1@bunyip.cc.uq.edu.au...
>
> link does not seem to be working ted.
>
Here is a link that is working:
http://www.adaic.org/docs/style-guide/95style/

The above directory has the document in several formats.
<snip>

Re: ada writing guide

[Ted Dennison]

In article <8d41os$3jn$1@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
> link does not seem to be working ted.
>
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:8d1vhj$hdr$1@nnrp1.deja.com...
> > Try the Ada Quality and Style Guide, at
> >
http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h
> > tml/cover.html
> >

That's funny. I pasted the above into my browser and realoaded it. It
loaded right away. Sometimes wuarchive can be a bit slow though.
You did use the *entire* URL, right? I notice that your browser
split it into two lines when you replied. You need both parts.

Also, I'm a lot closer to Washington University (St. Louis) here in
Oklahoma than you are over in Austrailia. :-)

Can you get to the main page at http://wuarchive.wustl.edu/ ? wuarchive
is one of the main (perhaps even *the* main) software repositories on
the web. I'd definitely want access if I were you.


--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Riyaz Mansoor]

after reading a whole lot of replies (thanx) i have come to the
understanding that ADA does not have strict code writing standard such as
the ANSI C standard. nobody has mentioned any standard for ADA code writing.
just different formats that different people use.

of course i may be wrong. so is there a standard?

riyaz

ps: somebody replied something about this, but i had to ask.

Re: ada writing guide

[Ted Dennison]

In article <8d6jfu$f6b$1@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
> after reading a whole lot of replies (thanx) i have come to the
> understanding that ADA does not have strict code writing standard such
> as the ANSI C standard. nobody has mentioned any standard for ADA code
> writing. just different formats that different people use.

I'm curious exactly what this "strict code writing standard" for C you
keep referring to is. There's "Hungarian notation", but that's not
universally adhered to, and usually not rigidly when it is. And that
just addresses identifier naming, not indentation.

For instance, my vxWorks system uses at least 3 different naming styles
for the C OS calls. Contrast that to the Ada world, where the issue of
naming is really all-but decided (see the AQ&SG for an explanation). In
fact, vxWorks even has some code that doesn't adhere to the convention
of using ".h" for included files!

If anything, I think you'll find that Ada code from different
professionals looks much more similar that C code. There are some nitty
disagreements, as this thread shows. But the small scope of those just
shows how broad the agreement in the Ada community really is. The style
guide I pointed to will clue you in on the basics of this style.

--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Marin D. Condic]

Ted Dennison wrote:
> If anything, I think you'll find that Ada code from different
> professionals looks much more similar that C code. There are some nitty
> disagreements, as this thread shows. But the small scope of those just
> shows how broad the agreement in the Ada community really is. The style
> guide I pointed to will clue you in on the basics of this style.
> 
The ARM itself kind of implies some style. Most people code similar to
what you see there. I've seen the Ada Quality and Style guide several
years back and adopted a lot from that. Again, most Ada code I've seen
follows that to some extent - at least in the more professional
examples. (Then you see stuff that was clearly written by C programmers
who were trying to make Ada look like C. :-) Naming conventions and such
quite often change with problem domains, so its more important to stay
consistent within the project rather than impose something across the
board.

If there is a C/C++ "Style" anywhere, I can say that I've seen lots of
code that had no signs of consistent style at all - so it must not be
very well adhered to.

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/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: ada writing guide

[tmoran]

>understanding that ADA does not have strict code writing standard such as
>the ANSI C standard. nobody has mentioned any standard for ADA code writing.
  Do you mean preferred style, or language definition?  The answers
people have posted to your question have assumed you meant style, but
of course there is no strict style standard for C (if you know of one,
please tell us), so perhaps you meant language definition.  If so,
what you want is the Ada Language Reference Manual (LRM).  Look for a
link to it at www.adapower.com

Re: ada writing guide

[David C. Hoos, Sr.]

<tmoran@bix.com> wrote in message
news:%wJJ4.740$%Y3.249597@news.pacbell.net...
> >understanding that ADA does not have strict code writing standard such as
> >the ANSI C standard. nobody has mentioned any standard for ADA code
writing.
>   Do you mean preferred style, or language definition?  The answers
> people have posted to your question have assumed you meant style, but
> of course there is no strict style standard for C (if you know of one,
> please tell us), so perhaps you meant language definition.  If so,
> what you want is the Ada Language Reference Manual (LRM).  Look for a
> link to it at www.adapower.com

Have you ever looked at
http://www.delorie.com/gnu/docs/GNU/standards_toc.html

This provides a coding stabndard for C, which could be considered "strict."

Re: ada writing guide

[tmoran]

> http://www.delorie.com/gnu/docs/GNU/standards_toc.html
>
> This provides a coding stabndard for C, which could be considered "strict."

It's hard to know what to say.  A document dated 1999 that gives a
standard for C and cautions against using any other language, including
C++.  A document whose "C style" part is all of 550 lines, or ten pages,
in length, whereas "Ada Quality and Style" manages somehow to take 270
pages.  A "strict" standard for the "C" language with statements like:

"Please use formfeed characters (control-L) to divide the program
into pages"

"Insert extra parentheses so that Emacs will indent the code properly."

"We find it easier to read a program when it has spaces before the
operator, not after one. Here is the right way:"

"Please put two spaces after the end of a sentence in your comments,
so that the Emacs sentence commands will work."

"Please write the comments in a GNU program in English,
because English is the one language that nearly all
programmers in all countries can read."

I guess the adjective "strict" does apply in cases like:

"It is important to put the open-brace that starts the
body of a C function in column zero, and avoid putting
any other open-brace or open-parenthesis or open-bracket
in column zero. Several tools look for open-braces in
column zero to find the beginnings of C functions. These
tools will not work on code not formatted that way.

It is also important for function definitions to start the name of the
function in column zero. This helps people to search for function
definitions, and may also help certain tools recognize them."

I prefer Ada, and even if I was coding in GNU C, I'd read Ada Quality
and Style for ideas.

Re: ada writing guide

[Marc A. Criley]

tmoran@bix.com wrote:
  <snip>
> 
> I prefer Ada, and even if I was coding in GNU C, I'd read Ada Quality
> and Style for ideas.

I saw to it that some of the AQ&S Guidelines on exception use were
worked into the C++ coding standards for the project to which I'm
assigned.

Marc A. Criley
Software Architect
Lockheed Martin M&DS

Re: ada writing guide

[Robert Dewar]

In article <8d82lq$4fp$1@hobbes2.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:

> http://www.delorie.com/gnu/docs/GNU/standards_toc.html
>
> This provides a coding stabndard for C, which could be
considered "strict."


The most important word here is "a" as in "a" coding standard.

That's the point, there are of course lots of local standards
for writing code in any language (any big COBOL shop for
example will have a detailed document specifying coding
standards, and many Ada shops certainly have such documents
[ACT certainly has a fairly comprehensive document of this
type].

Yes, and of course such documents exist in C shops, the GNU
project does indeed attempt (fairly successfully) to enforce
a single consistent style.

But this is a very different from having "the" standard coding
style.

Languages of course differ in their approach. Some languages
try to leave little lattitude (e.g. in COBOL, the margins for
entering text are fixed, and identifier casing is fixed etc).
Most recent languages have completely free form syntax.

Freedom is good and bad in this context, good because it does
not mandate choices that are really not a necessary part of
the standard, bad because it leads to inconsistencies.

The Ada standard tried to steer a compromise course, of leaving
freedom, but implying preferred choices.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ted Dennison]

In article <8d82lq$4fp$1@hobbes2.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> <tmoran@bix.com> wrote in message
> news:%wJJ4.740$%Y3.249597@news.pacbell.net...
> > >understanding that ADA does not have strict code writing standard
such as
> > >the ANSI C standard. nobody has mentioned any standard for ADA code
> writing.
> >   Do you mean preferred style, or language definition?  The answers
> > people have posted to your question have assumed you meant style,
but
> > of course there is no strict style standard for C (if you know of
one,
> > please tell us), so perhaps you meant language definition.  If so,
> > what you want is the Ada Language Reference Manual (LRM).  Look for
a
> > link to it at www.adapower.com
>
> Have you ever looked at
> http://www.delorie.com/gnu/docs/GNU/standards_toc.html
>
> This provides a coding stabndard for C, which could be considered
"strict."
>
>

Perhaps. But I'm hard-pressed to come up with any C program I've ever
looked at that conforms to the following statement:

Please use underscores to separate words in a name, so that the Emacs
word commands can be useful within them. Stick to
lower case; reserve upper case for macros and enum constants, and for
name-prefixes that follow a uniform convention.

This is completely antithetical to the "hungarian" notation that I find
most commonly. The style used for old K&R C source ususally avoids
underscores as well.
--
T.E.D.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Geoff Bull]

Ted Dennison wrote:

> Perhaps. But I'm hard-pressed to come up with any C program I've ever
> looked at that conforms to the following statement:
> 
> Please use underscores to separate words in a name, so that the Emacs
> word commands can be useful within them. Stick to
> lower case; reserve upper case for macros and enum constants, and for
> name-prefixes that follow a uniform convention.

This is a common convention, and a good one, I think.
Here's an example for you (easy to find, it's from gnat!):
  if (size + MSIZE_ACCURACY >= available_memory)
     check_available_memory (size + MSIZE_ACCURACY);

> This is completely antithetical to the "hungarian" notation that I find
> most commonly.

Yes it is, and hungarian notation is horrible!

Re: ada writing guide

[Robert A Duff]

"Riyaz Mansoor" <s800032@student.uq.edu.au> writes:

> after reading a whole lot of replies (thanx) i have come to the
> understanding that ADA does not have strict code writing standard such as
> the ANSI C standard. nobody has mentioned any standard for ADA code writing.
> just different formats that different people use.

There is a huge variety of styles used in C code.  At least as much as
in Ada.

> of course i may be wrong. so is there a standard?

The Ada RM defines a recommended indentation style, which most folks
follow.  Also a recommended capitalization style for identifiers and
keywords.  But it leaves open certain issues, such as what if things
don't fit on a line, where should the line breaks go.

- Bob

Re: ada writing guide

[Robert Dewar]

In article <8d6jfu$f6b$1@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
> after reading a whole lot of replies (thanx) i have come to
the
> understanding that ADA does not have strict code writing
standard such as
> the ANSI C standard. nobody has mentioned any standard for ADA
code writing.
> just different formats that different people use.


Actually, there IS a big difference in the standards here.
Unlike the C standard, the Ada standard may not mandate a
layout standard, but it does strongly suggest one. How?
By laying out the syntax rules in the recommended style.
Consequently, the basic layout in Ada is typically far
more consistent than in C, since people generally follow
the RM for Ada layout.

There is also a fairly official document called
Ada Quality and Style. Fairly official means that it
was generated with a general consensus process, and
published as one of the Ada project documents. OK,
it is not an official standard, but many people follow
the recommendations in this document. As far as I know
there is no comparable document for C.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Marin D. Condic]

Robert Dewar wrote:
> There is also a fairly official document called
> Ada Quality and Style. Fairly official means that it

I seem to recall this document being on-line somewhere. I know I read
the paper copy at one time because it was available to us as part of the
Software Productivity Consortium. But is there an on-line source?

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/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: ada writing guide

[Ken Garlington]

Ada Quality and Style is available at
http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/html/
cover.html

Allow me also to plug the just-released

ISO/IEC TR 15942:2000(E), Information Technology - Programming languages -
Guide for the use of the Ada programming language in high integrity systems.

It's not on-line, unfortunately, but you can order it from http://www.iec.ch

Re: ada writing guide

[gbull]

Everything under the http://wuarchive.wustl.edu/languages/ada/ajpo
directory seems to have disappeared as of 2000-04-18.
ftp://ftp.freesoftware.com/pub/languages/ada/ajpo/ is empty too!
I found it at:
ftp://ftp.freesoftware.com/pub/ase/ase01_06/docs/95style/html/cover.html


In article <8d0K4.25407$hh2.693734@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> Ada Quality and Style is available at
>
http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/95style/h
tml/
> cover.html
>
> Allow me also to plug the just-released
>
> ISO/IEC TR 15942:2000(E), Information Technology - Programming
languages -
> Guide for the use of the Ada programming language in high integrity
systems.
>
> It's not on-line, unfortunately, but you can order it from
http://www.iec.ch
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: ada writing guide

[Ehud Lamm]

Hi

My SE Links page (down from my home page, see sig) points to the Ada Style
Guide, and other places that may interest you.
(The direct link is:
http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/
          95style/html/cover.html)


Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: ada writing guide

[Robert Dewar]

In article <8d6jfu$f6b$1@bunyip.cc.uq.edu.au>,
  "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:
>
> after reading a whole lot of replies (thanx) i have come to
the
> understanding that ADA does not have strict code writing
standard such as
> the ANSI C standard. nobody has mentioned any standard for ADA
code writing.
> just different formats that different people use.


Clearly you have never read either standard. The claim that
ANSI C has a strict code writing standard is one of the more
amusing fantasy's to appear on this newsgroup in some time :-)

My guess is that you have mistaken some local coding convention
for C with the ANSI standard, which is quite a confusion!


Sent via Deja.com http://www.deja.com/
Before you buy.