Older blog entries for zhaoway (starting at number 302)

for a quick and conservative adoption of scons, GenerateConfigH provides excellent example.

in fact, that example could be even simplified a little bit more.

it should be noted that it's still easy to provide the user the usual interface to a source package:

$ ./configure
$ make
$ make install

just dump the m4 and autotools, in favour of python and scons. (i think it should be perfectly ok if one has nothing against make, especially when one's project is small.)

funniest ad of the week:

nobody reading your blog?

rotfl..

i thought AVL was initiatives of three persons. it seems it was two. (i am totally confused about the plural and singular stuff.)

suppose there is a solar system in a galaxy far far away.

suppose there is only one planet in this solar system.

suppose there is a civilization which is like the one on our earth about five hundred years ago.

now think about their Issac Newton.

can you notice something interesting?

now i, too, know that blogging is risky. :D

bonus point:

have you read the paper by nobel prize winner Michael Spence on Job Market Signaling?

a little economics is good for us. ;)

my finger is faster than my brain.

Just happened to know R6RS effort is underway for awhile.

chromatic, please don't be too serious about my last post. ;) you can read it as my halfly joking frustration towards unit testing instead. ;)

on the other hand, when you read about people talking about ideas of construction software, you have to:

1. check out what great projrects they have done before. this alone could save you alot of time from taking serious about many false ideas. in my case, i've only a hand of introductory articles. now you see. ;)

2. this point is rather radical. my take is the only next big news is a proof technique for real. nothing else could be big news any more. no silver bullet. we just tends to forget about it so very often. (unless we can prove for real.)

open source answer to unit test: don't.

let me explain. ;)

in a sense, open source is about lowering the development cost, and unit test is more work to do.

one way to lowering deveopment cost, for open source projects, is to let users help testing. then as developers, we should: 1. help users do testing; 2. make every bit of your program testable by users.

the way to help users do testing for us, is to write attractive docs. e.g. write usage docs in ezines. saving the time to write test cases, use the time to write interesting tutorials. write more tutorials.

the way to export every bit of our program so they're testable by users, is to write libs. structure our programs as a bunch of libs plus a small executable. write more docs about the api. see point 1 above.

so. the open source answer to unit testing is: write more libs, write better docs.

that's the open source way to do it. i'm serious. ;)

unit testing is for corporate lusers. ;)

finally got the idea of how to implement my own avl tree lib. it's different from Ben Pfaff's libavl, and mine will definitely be slower. i'm confident in that aspect. ;) me just got a different way to structure the function-calls' in my lib.

(why reinvent the wheel, and badly?) (i stared at my display for ten minutes trying to get a clever answer but failed. i humbly left this question to the reader.)

another news is that, i'm beginning to adopt Fefe's practice in his dietlibc and libowfat to organize my own program source. namely, one function per file, and write a manual page alongside.

Update: Ankh has a precise description about one public-API function per file and doc alongside.