4 little babies of this animal were found in the attic of my home in Palakkad, Kerala.  Cool eh?  I am not sure what its called in English.  The Malayalam name for this is merugu.

I don't particularly mind dealing with bugs as long as they are interesting to fix and you learn something along the way.  I was not always so well disposed towards them though.  It is only after reading Debugging Applications by John Robbins that I realized how much fun fixing bugs can be 8-)!  There are bugs that you feel good about when you fix 'em because it required you to use your "amazing ingenuity" and "extensive knowledge" of how stuff works under the hood and then there are bugs that make you feel rotten because the darn thing won't get reproduced on your box!

Those are the nastiest kind of bugs to get stuck with because you know it is there somewhere and there isn't a single thing that you can do about it!  I had to deal with a bug like that the other day the root cause for which in the end turned out to be a fairly silly little programming error.  "If you can shoot yourself in the foot with 'C', you can blow your whole leg off with C++" reminisced the wise old man while helping himself up the handicap ramp seated on his wheelchair.  I know he said this because I was right there behind him when he said it with a big smoking hole in my right foot.  Here's what happened.

Ours is an ambitious little web application that seeks to do a whole lot of things all by itself using pretty much every single technology that mankind has managed to come up with till about 5 minutes back.  One of the things that it jauntily goes about doing every now and then is to call a little Internet Server API (ISAPI) extension on the web server whenever somebody logs off.  When a user happens to crash out of a web session however (as can happen for instance when lightning strikes the user's computer and does not give her a chance to cleanly exit the browser and shut the computer down) that little notification does not ever reach the ISAPI extension and the web server remains tragically unaware of the user's untimely end.  After twiddling thumbs for some time though the ISAPI extension runs out of patience and just ends that user's session.  Now, here's the important part - as part of the processing where it terminates that non-responsive user's session, it turns on a little boolean member in a little C++ class to register the fact that that session has been aborted (as opposed to cleanly logging off).

All the session information is stored in a Standard Template Library list<> object and this is what the session object looks like:

class CSession
{
public:
    bool    m_bAbnormalLogOff; // this tells me whether
                               // this session ended abnormally
    int     haplessInt;
    float   haplessFloat;

public:
    CSession()
    {
        //
        // initialize everything
        //
        m_bAbnormalLogOff = false;
        haplessInt = 0;
        haplessFloat = 0.0f;
    }

    CSession( const CSession& s1 )
    {
        haplessInt = s1.haplessInt;
        haplessFloat = s1.haplessFloat;
    }
};

Now, can you spot the error in this code?  The error is of course that m_bAbnormalLogOff is not initialized in the copy constructor.  Why is that a bad thing?  Please look at the following code and try predicting what the output will be:

list<CSession> listOfSessions;

//
// create an abnormal session and push
// it onto the list
//
CSession badSession;
badSession.m_bAbnormalLogOff = true;
listOfSessions.push_back( badSession );

//
// now pop it off the list and push
// a normal session object
//
listOfSessions.pop_front();
CSession goodSession;    // now m_bAbnormalLogOff would be "false"
listOfSession.push_back( goodSession );

cout<<goodSession.m_bAbnormalLogOff<<endl;

If you said that it would print 0 (zero), then wouldn't you be surprised if I told you that the actual output on Microsoft's C++ compiler (the one they give free with Visual C++ Express Edition 2005) is 1?  Well, fact is, it prints 1 and this is the nasty little bug that troubled us no end!  Here's my take on what is most likely happening in this case:

• When the first CSession object gets pushed on to the list<> it allocates some space for it and keeps it there.  The point to note here is that list<> classes maintain their own copies of the objects that they are tracking and routines like list<>::push_back invoke the object's copy constructor for creating the copy.  This is the reason why it is important that classes that you plan to store in STL containers implement the copy constructor and the assignment operator.
• When this object gets popped off the list<> and is replaced by another CSession object, the new instance, instead of occupying fresh memory space just sits nice and snug in the space that the previous CSession object had occupied.  As before list<>::push_back dutifully invokes CSession::CSession( const CSession& s1 ) for creating the object copy.
• Since we forgot to copy the value for m_bAbnormalLogOff from s1 in the copy constructor it automatically assumes whatever value is currently stored in that location.
• Given that we initialized m_bAbnormalLogOff with the value true for badSession,goodSession continues to use the same value!

The fallout of this little beauty is that every once in a while the system would report sessions where the user had logged off legitimately as having been aborted.  Invariably this would always happen for 2 or 3 sessions that immediately followed a session that got aborted!

The following is a link to an open source pre-processor program for Java:

http://jappo.opensourcefinland.org/

I think it is shockingly short-sighted on the part of Sun developers that they are so obstinately refusing to include a pre-processor with the Java compiler. While MACROs are admittedly the source of many bugs in the C and C++ world, a more reasonable approach should have been taken instead of completely cutting it out as the benefits derived out of using them is real and indispensable. C# and .NET for instance include a pre-processor that has relatively fewer capabilities as compared to the C/C++ pre-processor but still allow for the writing of conditionally compiled code.  Microsoft has got it perfectly right on this count IMO.

If you’re wondering where all this angst is coming from, we recently discovered that the changes that we had made to a certain applet for incorporating a set of changes was not implemented in the source branch for Microsoft's VM (yep, we have customers who still use that VM!). If we’d had conditional compilation then it would have been a simple matter of #ifdef ing out the relevant portions instead of having an entire branch!

The fact that an open source effort for developing a pre-processor for Java exists at all is evidence enough IMO of the need for it. Grrrr.

The nerd is pleased to anounce the general availability of Really Simple Syndication (RSS) on Nerdworks Blogorama! Muaha! ha! ha! ha! Please use the link pointed at by the orange button on the right hand side of your screen in your favourite RSS feed reader.

A screen shot of what this looks like using Google's Feed Reader is available here.

The February edition of the Chip India magazine (the dead trees version that is) reports that the United States Department of Defense now has a tool that let's them remotely detect whether somebody is lying!  The Remote Personnel Assistance (RPA) will apparently be used as a "remote or concealed lie detector during prisoner interrogation".  It works by reading information from beams reflected off a suspect's body.  Where's the planet heading I ask, if a man cannot lie in peace!

In other news (again from the same magazine), scientists at the Massachussetts Institute of Technology have found found that algae can help clean the planet up by laundering it off all the CO₂ spewed out by factories and vehicles.  That's good news because now you can present a straight face while telling your spouse/parent that they are acting in an extremely un-eco-friendly manner by asking you to clean your room up and that such interference while you are busy saving Mother Earth is not appreciated!

I am currently working on an online e-learning/collaboration tool that features all the bells and whistles that one would normally expect of such a tool.  The basic functioning of the application is fairly straightforward in that it let's a presenter collaborate with a set of participants by passing messages around through a web server.  There was this recent requirement where the application had to automatically detect the network bandwidth available to a user and provide appropriate warnings on finding that it is less than the minimum required.  The idea is to measure the net time it takes for a message to travel from the presenter to the web server and then from the web server to the participant (and vice versa).

The first thing that you would probably try is:

• have the presenter put a timestamp on the message that she sends (let's call this PrTS - for presenter timestamp)
• have the server put another timestamp before forwarding it to the participant (this would be SvrTS - for server timestamp)
• and finally, let the participant mark the time of receipt of message and do a little arithmetic to figure out the net latency (let's call this PaTs - for participant timestamp); basically the net latency from presenter to participant is a simple matter of subtracting PrTS from PaTS

Perfect.  Except that the whole thing comes crashing down when you realize that,

1. the presenter, the server and the participant could be in different time-zones (but this can of course be handled), and
2. the presenter and the participant might have set their clocks to the previous (or maybe the next) century!

Basically, this system requires that the clocks on all three computers be absolutely accurate.  So we went back to the drawing board and came up with this, IMO nifty little approach:

• the presenter sends out a message of a fixed size with a timestamp - i.e. with presenter's local time (let's call this PrTS1)
• the server plonks its timestamp on to the message before forwarding it to the participant (let's call this one SvrTS1)
• the participant receives the message, marks the time of receipt and just sits pretty (let's call this PaTS1)
• the presenter, after sending the first message, waits for a random interval (say 5 seconds) and sends out a second message, again with a timestamp (let's call this PrTS2)
• the server, as before puts its time of receipt on the message and forwards it to the participant (SvrTS2)
• the participant, upon receiving this second message, records the time of receipt (PaTS2) and does the following arithmetic to figure out the latency

Presenter to Server latency (PrSvrL)	=	( SvrTS2 - SvrTS1 ) - ( PrTS2 - PrTS1 )
Server to Participant latency (SvrPaL)	=	( PaTS2 - PaTS1 ) - ( SvrTS2 - SvrTS1 )
And finally, Presenter to Participant latency (PrPaL)	=	PrSvrL + SvrPaL

Now I know this sounds complicated, but really, it isn't.  Work it out; it seems to work! :)

[Updated - 27 May, 2006]

Well, some further analysis reveals that this algorithm does not in fact measure latency.  What it does measure however is jitter, i.e., variations in latency.  We are only measuring the difference between the latencies of the first message and the second message and not the latency itself.  Sigh!