We have our own test framework that we use in our project which was primarily developed by David Carlton. It works very well for our needs. However, for my personal projects, I wanted to try something that is more widely used in the industry. I started using CppUnit for a while until I found Boost Test Library coming a long way. Now, I use Boost Test Library for all my personal projects. It is very easy to setup tests and I really like it.

I also wanted to write a quick introduction to Boost Test Library. So, I thought that I will put down a screencast that will solve two purposes of demonstrating Boost Test Library and serve as an introduction to TDD. This is not an extensive demo or an introduction. I have chosen a really simple problem that is often asked in preliminary rounds of technical interviews. But, it is a good place to start. I don’t guarantee that the solution is efficient. But, it is correct to my knowledge. Please feel free to suggest issues or improvements.

Please note that a HD version of this video is available when viewed on Vimeo’s site.

Problem:
Implement a function ‘int atoi(const std::string &val)‘ that converts the given string in decimal notation to its integer value. Return 0 if the input is not a valid integer.

Source code:

#include <string>
 
#define BOOST_TEST_MODULE atoi
#define BOOST_TEST_DYN_LINK
 
#include <boost/test/unit_test.hpp>
 
namespace impl {
 
int atoi(const std::string &val) {
    int result = 0;
    int multiplier = 1;
    bool negative = false;
 
    for (std::string::const_reverse_iterator i = val.rbegin();
         i < val.rend();  ++i) {
        if (*i <= '9' && *i>= '0' ) {
            result += (*i - '0') * multiplier;
            multiplier *= 10;
        } else {
            if (*i == '-' && i == val.rend() - 1) {
                negative = true;
            } else {
                return 0;
            }
        }
    }
    return negative ? -result : result;
}
 
} // namespace impl
 
BOOST_AUTO_TEST_CASE(unit_position) {
    BOOST_CHECK_EQUAL(impl::atoi("6"), 6);
}
 
BOOST_AUTO_TEST_CASE(tenth_position) {
    BOOST_CHECK_EQUAL(impl::atoi("45"), 45);
}
 
BOOST_AUTO_TEST_CASE(large_number) {
    BOOST_CHECK_EQUAL(impl::atoi("123456789"), 123456789);
}
 
BOOST_AUTO_TEST_CASE(negative_number) {
    BOOST_CHECK_EQUAL(impl::atoi("-876"), -876);
}
 
BOOST_AUTO_TEST_CASE(sign_in_wrong_position) {
    BOOST_CHECK_EQUAL(impl::atoi("72-56"), 0);
}
 
BOOST_AUTO_TEST_CASE(invalid) {
    BOOST_CHECK_EQUAL(impl::atoi("abcd"), 0);
}

Compilation and execution:

# g++ -g -lboost_unit_test_framework -o atoi atoi.cpp && ./atoi --log_level=test_suite --report_level=short

I will start with a very simple one, macros. Quoting from Emacs documentation, “A keyboard macro is a command defined by an Emacs user to stand for another sequence of keys. For example, if you discover that you are about to type C-n M-d C-d forty times, you can speed your work by defining a keyboard macro to do C-n M-d C-d, and then executing it 39 more times.”

In this demo, I have taken a real world example where you have to add C++ class member variables and accessors. There are other efficient ways to do such tasks in GNU Emacs. I personally use yasnippets to do these things. However, this approach is shown just to demonstrate keyboard macros. To supplement this video, please take a look at the keyboard macro documentation that is available within Emacs.

#define	PRFNSZ		16	/* Maximum size of execed filename */
#define	PRARGSZ		80	/* number of chars of arguments */
 
typedef struct psinfo {
         /* Fields omitted */
         char pr_fname[PRFNSZ];    /* name of exec'ed file */
         char pr_psargs[PRARGSZ];  /* initial characters of arg list */
         /* Fields omitted */
} psinfo_t;

So, due to the 80 characters restriction in psinfo::pr_psargs, the kernel will not be keeping track of arguments beyond the limit. Now, the only way to get the information is from the process’ memory of argv. In order to do this, you should have access to read the processes’ memory. This is the trick employed by both pargs and BSD version of ps with -ww switch.

To get the full length command line arguments passed to a process, you can do one of the following.

$ /usr/ucb/ps eww <pid>

$ pargs -l <pid>

One catch here is that, if the process has modified the argv since it was started, the output reported by both ps and pargs will show the modified data and not the initial arguments that were passed in. However, modifying argv within a program is not a standard practice and hence the chance of encountering such a scenario is remote.

$ pfexec svcadm enable vtdaemon
$ pfexec svcadm enable console-login:vt2
$ pfexec svcadm enable console-login:vt3
$ pfexec svcadm enable console-login:vt4
$ pfexec svcadm enable console-login:vt5
$ pfexec svcadm enable console-login:vt6

To enable hot keys for switching virtual consoles, do the following.

$ pfexec svccfg -s vtdaemon setprop options/hotkeys=true
$ pfexec svcadm refresh vtdaemon
$ pfexec svcadm restart vtdaemon

Console security is enabled by default. What it means is that if you leave a virtual console and move to another one, the previous virtual console will be locked and you will have to provide the password to unlock it. If you don’t like that, turn the security off.

$ pfexec svccfg -s vtdaemon setprop options/secure=false
$ pfexec svcadm refresh vtdaemon
$ pfexec svcadm restart vtdaemon

If you have already logged into an X session while doing this, logout and wait for Xorg to restart. After that, you should be able to switch between the virtual consoles by pressing the hotkey Alt + Ctrl + F#, where # => 1 to 7. Console 1 is the primary console, 2-6 are virtual consoles and 7 is the Xorg.

First, I downloaded Mercurial source and extracted it. This is a standard procedure for installing any package from source.

$ wget http://mercurial.selenic.com/release/mercurial-1.3.tar.gz
$ tar -zxvf mercurial-1.3.tar.gz
$ cd mercurial-1.3

The installation mechanism is directly controlled by the Makefile. Per-user installation can be selected by choosing Makefile target install-home, install-home-bin or install-home-doc. The target install-home is a collection of install-home-bin and install-home-doc targets. The target install-home-bin builds/installs Mercurial binaries and the target install-home-doc builds/installs Mercurial documentation. To build the documentation, we would need ASCIIDOC and XMLTO. So, I decided to skip building the documentation. The target that I chose was install-home-bin. The installation prefix can be controlled by the environment variable HOME.

The build process uses C compiler to compile Mercurial extensions written in C and linker to create the shared libraries. We need to specify the desired compiler and linker through CC and LD environment variables respectively. When using GCC, we need to specify CFLAGS to build relocatable objects. If the Python library is located in a non-standard location, we have to specify LDFLAGS appropriately as well. Here is how my compilation line looked like.

$ make install-home-bin HOME=/home/praveen/chaos.SunOS CC=gcc CFLAGS="-fPIC" \
    LDSHARED="gcc -shared" LDFLAGS="-L/opt/csw/lib -Wl,-R/opt/csw/lib"

Once installed, I had to configure my PATH and PYTHONPATH with the location of installation. To make this persistent, I had to add it to ~/.bashrc file.

$ export PYTHONPATH=${HOME}/chaos.SunOS/lib/python
$ export PATH=${HOME}/chaos.SunOS/bin:$PATH

Now I verified that Mercurial worked fine by running the following.

$ hg debuginstall
Checking encoding (ascii)...
Checking extensions...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
 No username found, using 'praveen@HOSTCENSORED' instead
 (specify a username in your .hgrc file)
No problems detected

Happy distributed version controlling!

[ad#page-footer-adsense-728x90]

Step 1. Backup your current metacity.

$ pfexec cp /usr/bin/metacity /usr/bin/metacity.orig

Step 2. Download the fixed Metacity binary from developer’s site and replace the original binary.

$ wget http://www.gnome.org/~erwannc/bugs/8748/metacity -O /tmp/metacity
$ pfexec cp /tmp/metacity /usr/bin/metacity

Note: Don’t do this in one step using wget -O /usr/bin/metacity. This broke my system.

Step 3. (Optional) By now, your new Metacity should have already started working. If not, replace the current instance by hand.

$ metacity --replace

Happy dual-screening on your OpenSolaris 2009.06!