Older blog entries for zhaoway (starting at number 298)

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.

new card: nvidia geforce 4.

reason: nvidia's driver doesn't work with my geforce 2.

reason justified: same software. GF2, x can't start. GF4, x works.

shame: i rewarded this irresponsible company another 200 dollars.

stupid: i bought a Cg book a few weeks ago.

i hope this company goto hell.

--

终于有时间按照来医的指点，把中文字体又设置了一遍。How to make Debian support Chinese. clear instructions. easy to follow. thanks. ;)

i was thinking to implement a (rather confusing) rwlock mechanism in my program, then i read in Ben Pfaff's libavl about the concept of generation. hoho. i love this diligent documenter. ;) it's not exactly a match of rwlock. but it's nevertheless very interesting. and almost did the job. ok, now you know i'm really an amateur to joy about such trivial things. ;)

on the other hand, yesterday's delight about my new understanding of the centipede game turns out to have rather serious problems itself. heheheh.

the centipede game has troubled me for more than one year, and this afternoon i finally saw a light through the tunnel. it's pretty amazing. but i'm still far away from the blue sky. ;)

i'd like to find a good reference on the web about the centipede game of game theory, but it seems to have great difficulty to differentiate itself from a certain computer arcade game. :D

i'm reading through Daniel S. Christiansen's microeconomics with calculus. his pdf is simply beautiful. (i'm not knowledge enough to judge the contents of the text.)

i'm also reading through a game theory book (in pdf). there're really many free stuff on econ on the net. (last time i found many free stuff by googleing parent directory and pdf heeheehee) but whenever i came to a bookstore, i simply find there're far far more books. and the covers and thickness always impress me and implies to me far better qualities within.

recently i set a rule for my self. only reading books. do not read papers. it's more efficient reading. only reading books. before that i was eager to reading numerous papers on the internet simple because they're free. but i know now that i can't even finish reading a small portion of the best books. then why bother with papers. even if the author write really brilliant papers, chances are she will later on write better books to explain things more clearly and in better ways.

just don't read papers. the saved time could be spent on book.