aunit?

aunit?

[chris.danx]

Hi,

I was wandering about looking for a testing framework as an example for 
one I was building in and found JUnit, then found Aunit and now I'm not 
gonna bother implementing one at all and get on with the real problem. 
Has anyone used it?  If so how did you find it?

I opened up the files to see what license it has, but am confused.  Is 
it GPL or GMGPL?  Doesn't really matter, just wondering.


Danx

Re: aunit?

[Simon Wright]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> I was wandering about looking for a testing framework as an example
> for one I was building in and found JUnit, then found Aunit and now
> I'm not gonna bother implementing one at all and get on with the
> real problem. Has anyone used it?  If so how did you find it?

We have been using it and getting on well. The only problem is that
the source as supplied doesn't obey ACT's coding style, so if you use
-gnaty you get lots of warnings ..

Re: aunit?

[Georg Bauhaus]

Simon Wright <simon@pushface.org> wrote:
: 
: We have been using it and getting on well. The only problem is that
: the source as supplied doesn't obey ACT's coding style, so if you use
: -gnaty you get lots of warnings ..

Always wear your tie fixed with a silver needle, otherwise
the code can't be correct :-) SCNR.
(Some studies seem to show that coding standards
having to do solely with typographical layout do _not_ lead to
increased productivity, or reliability. Example:
http://www.cs.kent.ac.uk/people/staff/lh8/pubs/pubist602s/MISRAC.pdf)

Re: aunit?

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Simon Wright <simon@pushface.org> wrote:
> : 
> : We have been using it and getting on well. The only problem is that
> : the source as supplied doesn't obey ACT's coding style, so if you use
> : -gnaty you get lots of warnings ..

I just fix those in my copy.

> Always wear your tie fixed with a silver needle, otherwise the code
> can't be correct :-) SCNR. (Some studies seem to show that coding
> standards having to do solely with typographical layout do _not_
> lead to increased productivity, or reliability. Example:
> http://www.cs.kent.ac.uk/people/staff/lh8/pubs/pubist602s/MISRAC.pdf)

To each his own. If code is not "properly formatted", I sometimes
spend enough time being bothered by it that it's worth fixing. I
invested time teaching Emacs how to fix the simple problems, so it's
very efficient for me to fix formatting most of the time.

ACT is happy to accept patches that fix such things, even though they
don't promise to fix them on their own.

-- 
-- Stephe

Re: aunit?

[Georg Bauhaus]

Stephen Leake <Stephen.A.Leake@nasa.gov> wrote:
: 
: If code is not "properly formatted", I sometimes
: spend enough time being bothered by it that it's worth fixing.

In my view "worth fixing" needs careful consideration.
The bulk of -gnaty warnings is about issues which can or
cannot be an improvement, depending on settings entirely
outside the control of GNAT. Whether or not a space before
a paren is a good thing depends, among other things, on
the fonts used, and on the medium used to display the Ada
source code. (consider f (x) in most various circumstances.)
Seen this way one might argue that -gnaty is
completely unaware of any typographical tradition in mathematical
typesetting. It seems to be aware of typical font appearance
in typical plain text editors, on typical low res displays, as preset.
That is, fixed width Courier, typically _not_ by IBM, but by
Monotype or Adobe. Or, on character terminals, aware of the screen
font that comes with your VGA, for example.

Consistent indentation is a different, unrelated matter.

I wish one could ask -gnatyX to concentrate on those aspects
of source code which render Ada text ambigous to the human eye,
like using l near 1 (or using l at all. Isn't there a "k instead
of i in GNAT" policy?).

Source code might look familiar because of the same spacing
applied between tokens. But does this make you familiar with
the source code? To each his own, yes. Ophelia doesn't sound
like Hamlet, and that play will change a bit if you make them
sound alike. I don't see the same danger for Ada source code,
but I do see the time spent. My preference is (mostly) to 
learn how to read code that I haven't written, and only suggest
-gnaty like improvements in case of a deeply nested mess.

-- Georg

Re: aunit?

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Stephen Leake <Stephen.A.Leake@nasa.gov> wrote:
> : 
> : If code is not "properly formatted", I sometimes
> : spend enough time being bothered by it that it's worth fixing.
> 
> In my view "worth fixing" needs careful consideration.
> The bulk of -gnaty warnings is about issues which can or
> cannot be an improvement, 

I accept ACT's definition of "good style". Because to do otherwise
takes more time than it is worth.

> depending on settings entirely outside the control of GNAT. Whether
> or not a space before a paren is a good thing depends, among other
> things, on the fonts used, and on the medium used to display the Ada
> source code.

Emacs, any fixed font. Of course :)

In general, I would recommend adapting the display tools to agree with
the "standard" definition of good style (as defined by ACT, in this case).

> (consider f (x) in most various circumstances.) Seen this way one
> might argue that -gnaty is completely unaware of any typographical
> tradition in mathematical typesetting. 

Ada source code is not meant to be typeset; that's what LaTeX is for. 

> It seems to be aware of typical font appearance in typical plain
> text editors, 

Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font
in bitmapped displays".

> on typical low res displays, 

1280 by 1024; I don't think that counts as "low res".

> as preset. That is, fixed width Courier, typically _not_ by IBM, but
> by Monotype or Adobe. Or, on character terminals, aware of the
> screen font that comes with your VGA, for example.

Yes, picking a good fixed with font is critical. But I've done that.

> Consistent indentation is a different, unrelated matter.

Ok.

> I wish one could ask -gnatyX to concentrate on those aspects of
> source code which render Ada text ambigous to the human eye, like
> using l near 1 (or using l at all. Isn't there a "k instead of i in
> GNAT" policy?).

Again a matter of good font choice; no excuse for using a font in
which 1 (one) and l (letter ell) are confused.

> Source code might look familiar because of the same spacing applied
> between tokens. But does this make you familiar with the source
> code? 

No, but it helps.

> To each his own, yes. Ophelia doesn't sound like Hamlet, and that
> play will change a bit if you make them sound alike. I don't see the
> same danger for Ada source code, but I do see the time spent. My
> preference is (mostly) to learn how to read code that I haven't
> written, and only suggest -gnaty like improvements in case of a
> deeply nested mess.
> 
> -- Georg

-- 
-- Stephe

Re: Ada programs depend on fonts (was: aunit?)

[Georg Bauhaus]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:
: I accept ACT's definition of "good style". Because to do otherwise
: takes more time than it is worth.

Hm. (For the same reason one could accept MSs definition of C++...)
Why does it take less time to transform source code into ACT style
than to obey one or more definitions of good style? (After all,
others might have good reasons for using a different good style and
that will likely lead to a bunch of programmers grimly reformatting
their sources :-)
But that is a matter of a source code _view_, see below, as in
to model-view-controller, or structure-and-form, or shape-and-content.

: Emacs, any fixed font. Of course :)
: 
: In general, I would recommend adapting the display tools to agree with
: the "standard" definition of good style (as defined by ACT, in this case).
 
There is some interesting evidence that looking at your program
in different shapes (for example on screen vs. carefully typeset)
will let you see things that you do not see if you look only at the on
screen version.  (The same might be true of more prose like text: you
see orthographical mistakes in one form of the text that you have not
seen in the other.)

I'm always annoyed by collegues relying on font colors, when they put /*
and */ and only these 4 characters around some larger portion of source
code. They say they can easily see that this part of the program is
ineffective, because it appears in a color for comments.  (At least Ada
defeats this problem.) To me, this seems less likely to happen if people
don't make their programming depend so much on font choice etc.

:> (consider f (x) in most various circumstances.) Seen this way one
:> might argue that -gnaty is completely unaware of any typographical
:> tradition in mathematical typesetting. 
: 
: Ada source code is not meant to be typeset; that's what LaTeX is for. 

Depends. It might increase quality. Then, there is also Ada letters.

:> It seems to be aware of typical font appearance in typical plain
:> text editors, 
: 
: Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font
: in bitmapped displays".

Emacs is a sophisticated plain text editor, aware of a number of
syntax rules for plain text. Editing Plain text, including editing program
text, is complicated and Emacs can help a lot knowing the syntax rules
of the plain text. (That implies syntax directed plain text navigation,
and there are a few Emacs major modes that are excellent in this respect.)
Ada source code is just plain text. No fancy formatting,
no fonts, no colors. Ada compilers don't handle fonts and colors
(note the omission of formatting, because of front ends aware
of indentation).
A view of Ada source code might have fonts and colors, but should programs
be written in a way that is largely influenced by one view
of source code? I think not.


:> on typical low res displays, 
: 
: 1280 by 1024; I don't think that counts as "low res".

But it is low resolution, as long as the resolution isn't around
some 400 dpi. What counts is the number of pixels per visible stretch,
the shape of pixels, and, if applicable, the resolution of a font.
That does not necessarily have anything to do with the number of pixels
of a device.
 
:  picking a good fixed with font is critical. But I've done that.

I hope it's not mission critical? :-)
 
:> I wish one could ask -gnatyX to concentrate on those aspects of
:> source code which render Ada text ambigous to the human eye, like
:> using l near 1 (or using l at all. Isn't there a "k instead of i in
:> GNAT" policy?).
: 
: Again a matter of good font choice; no excuse for using a font in
: which 1 (one) and l (letter ell) are confused.

Well, I'd rather say, no excuse for making source code depend on
font choice. You have given hints in 2 paretheses, presumably because
you know that different news reading software might display 1 and l 
differently?
Who is going to maintain the program text in which IDE using what
font? Yours in both respects? Source code maintenance shouldn't be a
matter of choosing good font choice, should it?


-- Georg
(require 'ada-mode)

Re: Ada programs depend on fonts (was: aunit?)

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote:
> : I accept ACT's definition of "good style". Because to do otherwise
> : takes more time than it is worth.
> 
> Hm. (For the same reason one could accept MSs definition of C++...)

Touche :).

> Why does it take less time to transform source code into ACT style
> than to obey one or more definitions of good style? 

The point is for the entire Ada community to have exactly _one_
definition of good style, and _always_ use it. Then it is always
faster to convert everything to that _one_ style, or to simply write
in that style in the first place.

> (After all, others might have good reasons for using a different
> good style and that will likely lead to a bunch of programmers
> grimly reformatting their sources :-) 

Yes, there are often "good reasons" for picking one style over
another. But they are all swamped by the overwhelming advantage of
simply using _one_ style.

> But that is a matter of a source code _view_, see below, as in to
> model-view-controller, or structure-and-form, or shape-and-content.

Yes, you can use tools to present different views.

> : Emacs, any fixed font. Of course :)
> : 
> : In general, I would recommend adapting the display tools to agree with
> : the "standard" definition of good style (as defined by ACT, in this case).
>  
> There is some interesting evidence that looking at your program
> in different shapes (for example on screen vs. carefully typeset)
> will let you see things that you do not see if you look only at the on
> screen version.  (The same might be true of more prose like text: you
> see orthographical mistakes in one form of the text that you have not
> seen in the other.)

Interesting. I don't have much experience with looking at code other
than in Emacs (or equivalent), so I can't really comment.

> I'm always annoyed by collegues relying on font colors, when they put /*
> and */ and only these 4 characters around some larger portion of source
> code. They say they can easily see that this part of the program is
> ineffective, because it appears in a color for comments. 

That feature of Emacs has saved me many times when reading C code. I
agree it's not good; that's one reason I use Ada :).

> (At least Ada defeats this problem.) To me, this seems less likely
> to happen if people don't make their programming depend so much on
> font choice etc.

No, the font choice is a reasonable fix for a bad language design
combined with bad programming style. What alternate fix would you
propose? Hmm, I guess you could require /* */ on each line; Emacs does
that when you ask it to comment out a block.

> :> (consider f (x) in most various circumstances.) Seen this way one
> :> might argue that -gnaty is completely unaware of any
> :> typographical tradition in mathematical typesetting.
> : 
> : Ada source code is not meant to be typeset; that's what LaTeX is for. 
> 
> Depends. It might increase quality. Then, there is also Ada letters.
> 
> :> It seems to be aware of typical font appearance in typical plain
> :> text editors, 
> : 
> : Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font
> : in bitmapped displays".
> 
> Emacs is a sophisticated plain text editor, aware of a number of
> syntax rules for plain text. Editing Plain text, including editing program
> text, is complicated and Emacs can help a lot knowing the syntax rules
> of the plain text. (That implies syntax directed plain text navigation,
> and there are a few Emacs major modes that are excellent in this respect.)
> Ada source code is just plain text. No fancy formatting,
> no fonts, no colors. 

I think we are trying to define the term "plain text"; you seem to be
saying "fonts and colors is not plain text". Since Emacs can display
Ada code using fonts and color, it is not a "plain text" editor.

Another way to look at it; in the beginning, Emacs only worked with
character cells; that's a good definition of "plain text". But with
version 21, Emacs can deal with arbitrary bitmapped displays, so it
really is no longer a "plain text" editor.

> Ada compilers don't handle fonts and colors (note the omission of
> formatting, because of front ends aware of indentation). 

That's true; Ada compilers do require "plain text" input.

> A view of Ada source code might have fonts and colors, but should
> programs be written in a way that is largely influenced by one view
> of source code? I think not.

I agree that the semantics of a program should not be determined by
the view (one reason I don't like Python; indentation determines
semantics!). But the user process of writing that code can benefit
from a good view (fonts and colors).

> :> on typical low res displays,
> : 
> : 1280 by 1024; I don't think that counts as "low res".
> 
> But it is low resolution, as long as the resolution isn't around
> some 400 dpi.

Ok; that's a meaningful definition.

> What counts is the number of pixels per visible stretch, the shape
> of pixels, and, if applicable, the resolution of a font. That does
> not necessarily have anything to do with the number of pixels of a
> device.

Ok.

> :  picking a good fixed with font is critical. But I've done that.
> 
> I hope it's not mission critical? :-)
>  
> :> I wish one could ask -gnatyX to concentrate on those aspects of
> :> source code which render Ada text ambigous to the human eye, like
> :> using l near 1 (or using l at all. Isn't there a "k instead of i in
> :> GNAT" policy?).
> : 
> : Again a matter of good font choice; no excuse for using a font in
> : which 1 (one) and l (letter ell) are confused.
> 
> Well, I'd rather say, no excuse for making source code depend on
> font choice. You have given hints in 2 paretheses, presumably because
> you know that different news reading software might display 1 and l 
> differently?

Exactly; I have zero control over your newsreader. But I have total
control over the software development process used on my projects, and
I can easily require a proper font.

> Who is going to maintain the program text in which IDE using what
> font? Yours in both respects? 

Yes.

> Source code maintenance shouldn't be a matter of choosing good font
> choice, should it?

That's part of it, yes. Just as I have to specify what config
managment tool to use, and what backup tool to use, I can specify what
font makes the code readable. The font choice is less important, but
in the same category of "things I have control over, and therefore
should specify".

-- 
-- Stephe