TINU went public

As of today my pet project is online and public. So I'd like to introduce it (as a FAQ, however no questions were asked yet):

What is TINU?

TINU is a unit test framework. The way it organizes tests should be familiar to anyone who used xUnit or something similar.

Why another unit test framework?

In other test frameworks when a unit test failed, you cannot easily determine the exact problem and the location of the problen without using a debugger or logging a lot.

TINU offers some extra features usefull in solving that problem:

• Full stack trace of the failure
• Internal leak detector
  
• Handling segmentation faults without aborting
• Log test results to different destinations (syslog, file, etc.)
  

Why did you write it?

It started as a secondary idea. I was writing a backup application (which is currently on hold) and I needed to verify that my code works. The idea was to write each unit test right after implementing a feature.

In order to accomplish this I started writing a test framework. The first try was very simple: just a collection of macros. Soon I found that this approach had serious limitations (I couldn't organize my tests well and I had a lot of them).

After realizing this I wrote some bizarre C++ framework that was so complicated even I lost track. Which is counter-intuitive considering that unit tests must be as simple as possible.

The third iteration was the lucky one: the "interface" is almost self-explanatory (albeit a tutorial and some Doxygen-generated documentation is available). It should integrate well and I'm currently testing on syslog-ng's unit tests whether converting existing test code is easy or not.

What is the state of TINU?

The currently published code is mature enough to be used but some features are still missing. Also I'd like to port it to Windows and other UN*X systems (even some non-POSIX ones).

Where is it?

The project page (where the issue database, the Wiki and the on-line repository browser resides) can be found at http://tracker.bteam.hu/

The git repository can be cloned (read-only, all patches should at this time be sent to me directly):

git clone http://git.bteam.hu/~herczy/tinu.git

A small tutorial can be found on the project page, here.

EDIT: This arrangement is probably temporary only. The project will get a proper page soon.

Esoteric languages

There are quite a few so called 'esoteric programing languages': languages that are funny, witty, interesting or plain stupid without having any practical value. These are kind of in-jokes of the CS and IT trade. They are often used as exaggerations of already existing languages.

And this is the keyword we're looking for. They are satires. Satires that - sort of - work. To be fair an esoteric language does not have to have a working implementation. In some cases it is out of the reach of computer science (violating established mathematical concepts), physics (e.g. violating quantum-mechanics) or plain common sense.

So here is a "Best of" selection of my three favorite esoteric languages - the ones that work (sort of):

Brainf**k

Apart from having the rudest name, this language is pretty easy: it has 8 simple, easy to understand instructions. Also, it is proven to be Turing-complete, that is, from a very theoretical point of view it is of the same computational class as C, C++, Java or any other general-purpose language. There are BF interpreters written in BF!

An interesting note that part of the "popularity" of BF is the challenge to write the smallest compiler (you heard right, compilers, not interpreters). The winner is - as far as I know - around 200 bytes, written in assembly for Linux.

Read more about it here.

Malbolge

Named after eighth level of hell this language certainly earned it's reputation. Deliberately being as hard as possible, it is a very, very scary programming language. It runs on a virtual machine employing a base 3 numeral system, to further complicate things. The instruction currently executed does not only depend on the instruction emitted but also the current memory positions value too.

Allegedly that this language is so hard that the first "Hello, world" application written in it was generated with a LISP program (and the solution isn't even producing a case-correct output).

Read more about it here.

Whitespace

This is fun. There are three valid symbols in this language: space, tab and line-feed. The program is composed of these white-space characters. Best summed by the perpetrators words:

Whitespace is a particularly useful language for spies. Imagine you have a top secret program that you don't want anyone to see. What do you do? Simply print it out and delete the file, ready to type in at a later date. Nobody will know that your blank piece of paper is actually vital computer code! - source

Oh, har-har! You see, I said earlier that "witty." No much use other than this. Also, if a CS professor tells you that the code must be submitted on paper and he/she does not specify a language... so, yeah, figure it out!

Read more about it here.

Befunge

While it seems that befunge is based on BF mentioned above, it has a fun twist: the command flow is two-dimensional! So your program - depending on the current direction - could be executed from left to right, up to down, etc. It's like walking on a map, with the added feature that you could - theoretically - fall of the edges.

Read more about it here.

This concludes this brief tour of my favorite esoteric languages. Feel free to read this list from the Esolang wiki. Oh, horror!

All the small things

It still amuses me to no end how small differences in code can make or break a feature.

Take todays assignment for example: SCB wasn't letting a connection through. The proxy failed to verify correctly an RSA key. The difference was that the exponent of the public key was padded with a zero at the start (the most significant byte, to be specific) but when OpenSSH sent the very same key, this zero went to /dev/null (figuratively speaking).

Normally this wouldn't cause any problems since the two keys are equivalent (zeros at the beginning of a number should be insignificant), but the verification process used the hash of the base64-encoded key. So because the two keys have different binary representations the hashes differed too.

The fix is relatively easy. Still, the total inflexibility of code - meaning that everything must be specified in excruciating detail - caused many hours of headaches for coders everywhere.

Still, it's fun to find out these things and the accomplishment when the fix is tested and verified is worth the pain. You know, no pain, no gain.

Some DB rambling

Today we (me and nucc) were trying to find out why a particular PostgreSQL query took forever to complete. The query analyzer showed three levels of nested loops, lot an' lots of string comparisons, etc. After analyzing the results we came up with a solution that will increase speed by a factor of 10... just kidding, we didn't accomplish anything (except for knowing precisely where the bottleneck is) and it seems that we cannot avoid restructuring the database somewhat.

And it dawned on me why I don't like to deal with database applications particularly. There are so many ways to screw up (to be fair C/C++ is much worse at times, but at least I'm used to those kind of problems). You can forget to make an index and suddenly your query is slower. You could decide to be lazy and use a text column instead of an integer one and your query gets slower. Forget some obscure trick you've read on Stackoverflow and it's slower.

With PostgreSQL it's not even particularly bad. Try Oracle. From what I've heard, you'll need a lot of DBA experience and know-how. And as I am constantly reminded when reading related forums, a lot of companies apply highly paid consultants (HPC, we're talkink about $100+/hour, baby) to get some task efficiently done. Of course, they are (mostly) worth it, but that kind of cash looks like a lot. The result is worth it, some of the most successful Fortune 500 companies use Oracle for their critical large-scale applications with success. But still... much money.

Maybe I'm just a stupid C/C++ jock who can't understand databases. But I'm trying to learn, that's why I took the assignment, to learn how to deal with databases. Maybe it'll make me a better programmer.

EDIT: Well, maybe I'm onto something. Bazsi wrote this a year ago:

"Among other small things, you can find a quite important patch against the Oracle driver. Without this patch Oracle 10.2 (the server!) segfaults and dumps core. So beware."

rsync configuration

I finaly had to do a basic rsync setup to sync my files between my netbook and my desktop. While I'd like to tell a tale about how heroic my efforts were to set up the server, I'll just pass the link to a basic setting howto which I used. Have fun.

Eyes on the prize

I haven't been writing much (read: any) lately but I have a reason: the last few weeks have been pretty eventful. We have been making sure that the newest SSB (1.1) will be something we can release with a clear conscience. I think that we just did it. The preview demo went pretty well and we delivered what we aimed for. At least for such a limited time it seems like an accomplishment.

The experience was - to say the least - pretty interesting. Mainly, the coding. After a year working on a C++ GUI application it was a nice change to work on a C project. First it was a bit wierd to work again on C but thanks to my colleagues the transition was relatively smooth. And oh boy, was it fun! I think I got out of it more than I thought I would. I got a good grasp of Glib, a library I wanted to learn to use and at last I got to push some bits (no pun intended), my second favorite thing to do with C.

The atmosphere was a bit tense at first, but I lightened up a bit. The SSB team is fun to work in with a lot of smart and experienced people. I still feel a bit out of place, mostly because the others are mainly working on the PHP part of the project. The important thing is that with such a good start I'll stay motivated enough and probably do my best.

QUnit

Some time ago I had to write a few unit tests for syslog-ng Agent. To be a bit more specific: a new release came with the feature of white-list filters (instead of blacklist ones). This means that only messages matching the filter criterias will pass.

This new feature required some unit tests, so I was asked to find a suitable unit test framework. First, the main objective was to find one that integrated well in Microsoft Visual Studio. Also, if possible it should also be able to work with C#. This was later dropped since
the frameworks supporting this feature required managed C++ code.

So we decided to use QUnit. It's noting impressive, just a simple C++ unit-test framework, relying only on STL. It seems to be what we were looking for: it's simple, it's platform-independent, and only a header file.

Most common unit test frameworks try to imitate xUnit: tests have a setup phase, the test itself and a tear-down/cleanup phase. Tests are collected in suites and then run. When assertions aren't met, the test fails.

QUnit deems these unnecessary: there are only assertions. This means that writing tests that have no need for setup/cleanup can be written trivially. I.e.:

#include "QUnit.hpp"

int
main(int argc, char *argv[])
{
 QUnit::UnitTest qunit(std::cerr, QUnit::normal);

 // ... some tests ...

 QUNIT_IS_EQUAL(42, ask_question());

 // ... even more tests ...

 return qunit.errors();
}

In my opinion this gives some flexibility: you can organize the cases to suit your requirements. Instead of forcing you to follow the above mentioned scheme you can use whatever you deem appropriate.

However there are some downsides: if your project is sufficiently big it might provide tiresome not to have some fixed format for test cases. Also, the way of xUnit is more or less an accepted method of organizing test.

But we found QUnit to be an appropriate tool in our case. The simplicity also makes modifications and customizations easier. All-in-all I'd say that for simple projects with few test cases it is a good choice.

QUnit can be downloaded here .