Cooked linux console

Recently while I was playing around with code, there was a log line

printf("foo: skipped '%c'\n", c);

When c was a carriage return; the log line obtained was

'oo: skipped '

This was because carriage return takes the current position to the beginning of the line. Now, as the linux console is cooked by default [Most *nix programs get their tty input via the kernel tty driver in `cooked' mode.], it formatted the whole line and printed the line at once producing the effect.

A simple way to detect parts where the "cooked" console interferes is to run the command from within emacs. Emacs does its own input handling and is not cooked. The same log line in emacs is shown as:

foo: skipped '^M'

These petty issues must be kept in mind while considering portability of software.

Stages in software development

During development of software, debugging becomes easy when we have working code after each commit. O'Rielly's "must read" articles for programmers also recommend planning each commit well. This actually is a better way than unit testing, though is much the same in some cases. The advantage here is the developers are not only sure of the working of the newly added unit but also of its integration with the rest of the code.

To exemplify, I share the following screenshots. The screenshots are of an rtf file renderer. The folowing is the screenshot after foreground color implementation. Here the font size is rendedred double the required size. Also note the unnecesary space in between the letters 'm' and 'p' of the word "example". There are other similar cases too.

In the next commit, the font size problem is fixed, yet the problem of unnecessary space remains unsolved, though it doesn't seem to make much difference.

Then the unnecessary space problem was solved.

In the subsequent commit, double underline support was added.

The above were the screenshots of successful additions to the software. However, in between these, there must be numerous trials that reveal error in implementation. The point is while attempting to get a particular task done and properly integrated reduces debugging load.

The process described above is typical in scripting languages like Python, Lisp, etc. Following these lines in languages like C isn't difficult either. Its just one task at a time. So you build the base first - an unpolished prototype of a prototype - add features to it and improve the base to integrate better with the added features, i.e. bottom up.

Rtf file size comparision

Recently, I was experimenting with rtf files. I found something really interesting. An rtf file containing 14 unformatted character created in Microsoft Word turned out to be around 30 kb in size, while an rtf file containing 54 formatted chars created in OpenOffice was only 2kb in size.

I was doubting Microsoft when I read the following line in the rtf specification v1.0:
"All styles in the document's style sheet can be included, even if not all the styles are used." However, when I actually tested them, I found their software to be producing even larger files than I expected.