Running OpenSolaris wdiff.pl on FreeBSD

The wdiff.pl script is a very cool Perl script, which is part of the OpenSolaris source. It runs diff(1) on two files, parses its output, and generates an HTML page which highlights the source code changes/differences between two files.

The “wdiff” utility it called by webrev (another OpenSolaris utility), to generate html pages for every file affected by a commit/changeset.

As part of an effort to port “webrev” to work with Mercurial on on FreeBSD, I had to make a small change to “wdiff.pl” earlier today. Here’s the output of wdiff running on itself:

http://people.freebsd.org/~keramida/wdiff/wdiff.pl.html

As part of a test to see how the modified “wdiff” would run on FreeBSD sources, I used a changeset from a Mercurial clone of the FreeBSD src tree too. The changeset I used as an example was:

changeset:   130135:d6862f5b2c5e
tag:         tip
user:        wkoszek
date:        Sat Mar 31 15:43:06 2007 +0000
files:       sys/netgraph/ng_base.c
description:
We don't need spinning locks here. Change them to the adaptive mutexes.
This change should bring no performance decrease, as it did not in my
tests.

Reviewed by:    julian, glebius
Approved by:    cognet (mentor)

and the resulting wdiff HTML page is oneline at:

http://people.freebsd.org/~keramida/wdiff/ng_base.c.html

The new “wdiff” seems to work fine so far. Now off to port the rest of “webrev” to FreeBSD. Who knows, maybe if things aren’t very difficult, I may even port “webrev.sh” to work with GNU bash(1), instead of ksh(1) ;-)

Mercurial running on a multicore CPU

Two Mercurial checkouts, running simultaneously on a dual-core CPU:

last pid: 77599;  load averages:  0.70,  0.54,  0.52   up 0+02:54:39  05:07:06
73 processes:  1 running, 71 sleeping, 1 zombie
CPU states: 17.3% user,  0.0% nice, 11.5% system,  1.9% interrupt, 69.2% idle
Mem: 178M Active, 83M Inact, 152M Wired, 2604K Cache, 59M Buf, 69M Free
Swap: 2300M Total, 52K Used, 2300M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME    CPU COMMAND
77087 keramida      1  -8    0 24324K 19756K piperd 0   0:07 13.09% python
77316 keramida      1  -8    0 16148K 11944K biord  1   0:04 13.09% python

This is a snapshot of the top(1) utility, running on a single CPU, dual-core FreeBSD system with SMP support. Note how each Python process has been scheduled to a different CPU core, and ‘idle’ reports the aggregate idle time of both CPU cores.

1. One of these Mercurial processes is running the bisect extension of Mercurial, on a converted (from CVS to Hg) repository of GNU Emacs, checking out the next batch of changes which I’m about to build-test.

The GNU Emacs repository contains now more than 80,000 changesets for around 2,500 files.

2. The other one is pulling changesets over SSH from the OpenSolaris “onnv-gate” repository, which Sun kindly makes available for everyone’s free use at:

ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate

The onnv-gate repository contains now a little over 6,200 changesets for more than 39,000 files.

Kudos to the Mercurial “Crew”

I’ve started using Mercurial several months ago. During the development of a previous release at work, I even managed to keep a local Mercurial “branch” synchronized with Perforce commits happening several timezones away.

A little shell script hackery, and I had an off-line, clonable repository with all the history I needed, plus all the cool features of Mercurial: cheap branching, accountability of changes, the ability to roll back quickly from any commit to any other commit, merging capabilities between arbitrary “remote” changesets and any number of local patches, and the amazing “Mercurial Queues” patch-manager for stacking personal patchsets on top of an existing repo clone.

Months later, I used Mercurial again as an off-line mirror of a Subversion tree. A little more shell hackery, and I had yet again a fully distributed copy of things happening in a centralized Subversion branch. Workspace cloning (what centralized SCM systems call “branching”) and MQ patch queues helped me work both at work and home, entirely disregarding the fact that it’s quite impossible to work in “offline mode” with Subversion (or any other centralized SCM, for that matter).

Now, after using Mercurial for a much longer time than when I was first dabbling with a distributed SCM and the concepts behind repository cloning, and after seeing several of my own changesets pushed by Mercurial Crew people to the official “Crew Repository”, I feel that it’s about time to say to everyone involved in making Mercurial the fantastic SCM tool that it is:

Thank you, everyone! Keep the good work :-)

Mercurial version check

At work, I’ve installed Mercurial on a range of UNIX systems, including Linux, FreeBSD and Solaris hosts. Some times it is necessary to make sure which version of Mercurial is installed on one or more of these systems.

For example, after an important bugfix in the Mercurial Crew Repository, and running tests on my laptop, I update the Mercurial installation on several UNIX systems in a row. Since the update may take a while, and I may be interrupted for some other task in the process, I wanted an easy way to check the version of Mercurial on many hosts at once.

Here’s a small SSH-based script I use to do this:

#!/bin/sh

if test "${CHECKHOSTS}" ; then
    CHECKHOSTS='localhost fingon finrod eomer rohan moria'
fi

for name in ${CHECKHOSTS} ; do
     echo "${name}" \\
       $(ssh "${name}" \\
         'hg version | grep version | \\
          sed -e "s/.*version //" -e "s/)//"')
done 2>&1 | awk '{printf "%-20s %s\\n",$1,$2}'

A typical batch of output from the script looks like this:

localhost            14e67cd9a465
fingon               14e67cd9a465
finrod               14e67cd9a465
eomer                14e67cd9a465
rohan                14e67cd9a465
moria                14e67cd9a465

So, with a glance, I can see that all my test machines run exactly the
same version of Mercurial :-)

Null pointers

Favorite FAQ entry from the “comp.lang.c FAQ” for today:

Why is there so much confusion surrounding null pointers? Why do these questions come up so often?

C programmers traditionally like to know a lot (perhaps more than they need to) about the underlying machine implementation. The fact that null pointers are represented both in source code, and internally to most machines, as zero invites unwarranted assumptions. The use of a preprocessor macro (NULL) may seem to suggest that the value could change some day, or on some weird machine. The construct “if(p == 0)” is easily misread as calling for conversion of p to an integral type, rather than 0 to a pointer type, before the comparison. Finally, the distinction between the several uses of the term “null” (listed in question 5.13) is often overlooked.

One good way to wade out of the confusion is to imagine that C used a keyword (perhaps nil, like Pascal) as a null pointer constant. The compiler could either turn nil into the appropriate type of null pointer when it could unambiguously determine that type from the source code, or complain when it could not. Now in fact, in C the keyword for a null pointer constant is not nil but 0, which works almost as well, except that an uncast 0 in a non-pointer context generates an integer zero instead of an error message, and if that uncast 0 was supposed to be a null pointer constant, the resulting program may not work.

I just fixed another bug which was caused by dereferencing a null pointer :-/