Subject: CVS: fixed tests; minor manual editing

From: Bernhard Reiter <[email-masked]>
Date: Thu, 11 Aug 2005 16:51:34 +0200

Hi Jakson,

yesterday I was in the train for a few hours and had a recent cvs
checkout with me, but not the proposed new announcement nor the webpage.

Here is the changelog of what I have checked into the CVS just now:

+       * Fixed the unit tests.
+         + tests/test_4_1.sh: fixed test: expecting new comment in the output.
+         + tests/check_memory_handling.c: fixed test for "check" v>=0.9.0.
+
+       * Minor editing of the English manual.
+         + Minor clean of doc/Makefile:
+           - Ignoring errors of rm.
+           - Declared phony targets .PHONY. Also rewrote "all" target.
+         + Called the operating system GNU/Linux as Linux is only a kernel.
+         + Made the message recommending Free Software friendlier and
+           more correct about the security implications.
+         + added the gnuplot method to create output files.
+         + updated the build and install instructions. "su -" in general
+           is prefered over "su".

Did you run the automatic tests during development?
Just say "make check" in src/ to run them.

Automatic tests are nice for development cycle to do 
test a little -- code a little
which is a method also used by extreme programming.

When compiling I also found a few interesting warning by the compiler:
        Comparision ist always true due to limited range of data type.
        in 
		data.c:1057
		recode.c:378
		recode.c:466

        This makes sense, as 'ÿ' == (char)255.
        So you could leave out the right part of the check.
        This would be different if char would be unicode character,
        which has more than 8 bits. I have no experience with unicode
        in modern C development, but I expect that the comparisons
        will be completely different anyway.

Best,
	Bernhard

---

From: Jakson Aquino <[email-masked]>
Date: Fri, 12 Aug 2005 08:45:22 -0300

Hi Bernhard,

I reproduced your changes to the manual into the
Portuguese version. in both versions, I also added one
line acknowledging your contribution. Thanks!

I didn't updated the cvs version of the pdf files, 
since they will be deleted after the next release of 
statist.

> which is a method also used by extreme programming.

In fact, I didn't run the automatic tests. I'll
download the check.h file and run them.

>         So you could leave out the right part of the
> check. This would be different if char would be
> unicode character, which has more than 8 bits. I
> have no experience with unicode in modern C
> development, but I expect that the comparisons will
> be completely different anyway.

Yes, your compiler is right, but It curious that I
didn't received this warning here. You pointed to an
important problem. The test might not
work with utf-8. I'll investigate it. I prefer to be
allowed to use letters with accents in the column
labels.

Best,

Jakson

		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

---

From: Bernhard Reiter <[email-masked]>
Date: Fri, 12 Aug 2005 15:10:28 +0200

Hi Jakson,

> line acknowledging your contribution. Thanks!

you are welcome.

> since they will be deleted after the next release of 

Why not delete it right away then?

> download the check.h file and run them.

Cool, you could even write some tests for your new code.

> didn't received this warning here. 

I am using: gcc-Version 3.3.5 (Debian 1:3.3.5-13)

> You pointed to an
> allowed to use letters with accents in the column labels.

I think that solving the unicode and utf-8 problem will be a major task
that could be deferred.

	Bernhard

---

From: Jakson Aquino <[email-masked]>
Date: Sun, 14 Aug 2005 09:48:51 -0300

Hi Bernhard,

I removed the pdf files from the cvs.

> Cool, you could even write some tests for your new

I ran the tests, and I found very nice that check unit 
allow us to test specific funtions. I can try to use 
it latter.

I'm using valgrind to hunt memory leaks, uninitialized 
variables, buffer overflows, etc... I'll write a test 
for --xcols, including the recodification with awk, 
and merging files with join. (I'll use your 
"test_4_1.sh" as a guide.) I'll only finish the 
removal of "rlen" option when this test is prepared.

> I think that solving the unicode and utf-8 problem
> will be a major task that could be deferred.

I confirmed that the test can't deal with utf-8 
encoding, and I eliminated the accentuated letters 
from the "if" condition.

Best,

Jakson

---

From: Bernhard Reiter <[email-masked]>
Date: Mon, 15 Aug 2005 13:13:42 +0200

Hi Jakson,

> allow us to test specific funtions. I can try to use 

The idea is, to write the test for a funcationality or procedure first 
and then implement it. This way it helps designing good interfaces,
because you start thinking about this first.

> "test_4_1.sh" as a guide.) 

Do you call "join" or "awk" directly from statist?
Usually this would be done by the user.

I am unshure if we should add tests for this as statist
does not do it. But it would be interesting to have example
scripts for people to use.

	Bernhard

---

From: Jakson Aquino <[email-masked]>
Date: Mon, 15 Aug 2005 20:40:28 -0300

Hi Bernhard,

> Usually this would be done by the user.

No, I don't call "join" and "awk" directly from statist.

> scripts for people to use.

The test included "awk" and "join" because I wanted to check whether the
instructions that I wrote on the manual really work as I described. I was
testing the user manual, not only statist. The fixed width data file that I
created had some empty spaces where they normally are not found in real fixed 
width data files. This wasn't tested with the PNAD database that I used 
before to test --xcols. I can create a directory doc/example with some 
scripts and sample data files (but after the release of 1.3.0).

I liked the use of tests. They increase our trust in the code that we are
writting. Next time I add a feature to statist I will first write the result
as it have to be, and, then, write the code.

Best,

Jakson

---

From: Bernhard Reiter <[email-masked]>
Date: Tue, 16 Aug 2005 16:52:06 +0200

Hi Jakson,

> No, I don't call "join" and "awk" directly from statist.

ah, good.

> testing the user manual, not only statist. 

Okay, this is good, though I am considering to move those tests
into the doc directory under tests/ or so.

> The fixed width data file that I

This is also fine.

> as it have to be, and, then, write the code.

Yes, I also really like it, this is the reason why I started it
when redoing some of the memory stuff.

	Bernhard