The Daily Cow

I'm doing some research work that involves heavy work with the Java string classes (I have IBM Java), and I was trying to determine concretely (besides synchronization and such) the differences between StringBuffer and StringBuilder. I replaced "StringBuffer" with "StringBuilder" in StringBuffer.java and then diffed them. The subsequent confusion led to an interesting discovery.

Before I go there, here's a brief summary for those of you with modest Java experience: StringBuilder is similar to StringBuffer in that it can be used to dynamically build strings of indeterminate length. The main difference is that StringBuilder, which came later (Java 1.5), is not synchronized (meaning that multiple threads could cause objects to act unexpectedly--a risk that pays for some level of performance), unlike StringBuffer. But since I was dealing with them at the code level, I needed to know more deeply where they differ.

Back to the topic: Check out the following excerpts from StringBuilder.java:

The constructor:

/**
 * Constructs a new StringBuffer using the default capacity.
 */
public StringBuilder() {
	this(INITIAL_SIZE);
}

A normal method copied from StringBuffer:

/**
 * Optionally modify the underlying char array to only
 * be large enough to hold the characters in this StringBuffer.
 */
public void trimToSize() {
	if (!shared && value.length != count) {
		char[] newValue = new char[count];
		System.arraycopy(value, 0, newValue, 0, count);
		value = newValue;
	}
}

Another method copied directly from StringBuffer:

/**
 * Adds the specified code point to the end of this StringBuffer.
 *
 * @param		codePoint	the code point
 * @return		this StringBuffer
 */
public StringBuilder appendCodePoint(int codePoint) {
	if (codePoint >= 0) {
		if (codePoint < 0x10000) {
			return append((char)codePoint);
		} else if (codePoint < 0x110000) {
			if (count + 2 > value.length) {
				ensureCapacityImpl(count + 2);
			}
			codePoint -= 0x10000;
			value[count] = (char)(0xd800 + (codePoint >> 10));
			value[count+1] = (char)(0xdc00 + (codePoint & 0x3ff));
			count += 2;
			return this;
		}
	}
	throw new IllegalArgumentException();
}

If it's not apparent yet, what's clear is that the authors of IBM Java 5 copied-and-pasted StringBuffer into StringBuilder--word for word, including comments--and changed some variable names until the red underlines (from syntax errors) disappeared, and forgot about the comments.

Interesting discovery. I'm not sure what the lesson here is. I suppose enterprise developers are also lazy and forgetful.

I can't claim to be familiar with Makefiles, but after these mishaps I can confidently assert that I've learned a thing or two about them.

The first error was easy to catch and fix: Tabs and spaces are completely different! For each label, the dependencies list must come after a space, not a tab; but the instructions must be tab-prefixed.

The second error took hours (and the help of my CS professor) to figure out: Makefiles should NOT contain the \r (linefeeds) that are inserted by Windows text editors but are invisible in almost all text editors in their default settings. I could not make anything of the inscrutable error I got each time: 'ake: Fatal error: Don't know how to make target `main.o Why? Because the Makefile itself looked just fine! I've made Makefiles before, and that's what they all looked like. It wasn't until my professor opened up my Makefile in vi did he see that it had those Windows characters that *nix systems dislike. Whoops. There goes three hours.

The third problem I did not even detect until I heard that I failed every automated test on my program. I was appalled by that! I was absolutely certain my code was functional and worked correctly. It turns out, I must insert a @ in front of my instructions in order to suppress Make's output to stdout. When my output was compared to the correct output, it was off by the output from Make. Whoops.

So if you ever need to deal with Makefiles, just make sure you keep these things in mind. Otherwise, Makefiles are intuitively pretty simple.

I get asked about programming mishaps--bugs I've encountered, obstacles I had to cross, etc--in my interviews, and I can never come up with anything, leading them to think of me as a snotty little kid who thinks he's too good to make mistakes. Well, I just don't remember them specifically, so I thought it might be helpful if I kept a repository of programming mishaps I encounter on the Daily Cow. Writing will make me remember them, right?

I have one right now, which I'll write up soon. For an example of what I mean, check out my previous post about a CS project in which not realizing that I needed a terminating newline led my program to produce inscrutable errors.

The one major problem with Chrome is that, unlike Mozilla Firefox, it is backed by a gigantic corporation whose goal is to maximize return to shareholders. Despite its performance and design advantages, it misses many of the advantages of being a community-developed software, including extensibility.

Obviously we cannot rely on Google to include in its own browser the feature that directly opposes its whole business model based on advertising. But recently Google added some features to support extensibility and developers are taking full advantage of that. The first such is Adblock.

Because Chrome does not yet have a fully-functional extension system, everything must be done manually. To simplify the task, I've created a simple executable file that saves a Javascript file and a configuration file in a Program Files directory and instructs you on how to enable the addon. Finally there is a solution without installing a private proxy (Privoxy), as suggested by all other solutions, which incurs extra system overhead. Many thanks to Mark8t for the original code.

Bonus feature: Configure your exceptions list by following the instructions at the end of the installation.

CliffsNotes Edition: Just download the installation file (click here), run it, and follow the brief instructions at the end to enjoy ad-free browsing. Have fun! (Obviously this works only on Windows) Note: You MUST update and close Google Chrome before installing this.

If you like this, please Digg it and share it with your friends.

In a BusinessWeek article, various technology company CEOs contend that patent reform is necessary to preserve American innovation, and that due to the large backlog of applications, all the applications will take at least two years to process with the current staff. Because of that, the article claims that "700,000 [applications] are just sitting in a stack."

Wait a minute, are you serious? So the last person who submits his application gets his stuff reviewed first? I think I'm going to apply for a patent then!

MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MoO MoO MoO MoO MoO MoO MoO Moo Moo MoO MoO MoO Moo OOO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo MOo Moo MOo MOo MOo MOo MOo MOo MOo MOo Moo MoO MoO MoO Moo MOo MOo MOo MOo MOo MOo Moo MOo MOo MOo MOo MOo MOo MOo MOo Moo OOO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO MoO Moo

That says "Hello World" in a language called COW. Welcome!

Three things, one directly my fault and the other two not, caused me to waste eight otherwise-productive hours on the second project. You'll see how ridiculous those three things are.

I thought I had a completely functional submission yesterday morning. All I needed to do was to use the test script once to verify that. But when I uploaded it, the test script wouldn't even run. After some time of research (my professor was out of town and nobody else had the same problems), I discovered that it was because I was running Bash as my default shell. I changed that to csh (C-shell) and now the script finally ran.

I failed every test. It gave me absolutely useless explanations for why I failed them, but I found one lethal error that could have caused me to fail them all: instead of using sb $0, 0($a0) to save a null character, I used lb $0, 0($a0) (which obviously doesn't work). After I fixed that (using notepad), I uploaded the file again, and it still failed all the tests. I read through the code again, but I found no bugs!

I opened Mars (our MIPS assembler) and tried running the code, and surprisingly it worked, so I saved it (even though I made no changes) and uploaded it. And now the tests don't complain that they failed--instead they complain about some command not being found. After Googling a bit, I realized that that command isn't in csh, but it's in tcsh. So I changed my shell to that, and program passed all tests--yay!

Now that I was confident my code worked, I put off the last part--commenting the code (yup, the whole assembly file was nearly uncommented when I wrote it) until 10:40. But after commenting, the code stopped working--it failed all the tests again! I was so confused! So I replaced code bit by bit to see what made it work, and only at 11:55 did I figure out that this whole time, the only reason the test script failed me completely was that I didn't have a newline at the very end of my program.

And this is also why opening and saving in Mars, even with no changes, fixed my program up above (paragraph 2). Isn't that stupid? How should I have known that I shouldn't use Notepad to edit my program? (it doesn't automatically add a newline) How should I have known that the script works only on tcsh? I suppose it was unwise of me to change my settings away from the default, but isn't that what settings are for?

Part of it was lack of documentation on Clancy (my professor)'s part--a simple "The script only works on tcsh and on newline-terminated code" would have sufficed to save me 4 hours! The other part was a bona fide mistake of a programmer. (I made one typo!) But together they were disaster because nobody else had the same problems. Lesson: There are dangers to doing things unconventionally.

Bookmarklets are small Javascript applications stored in the URL of the link that, if dragged to your bookmark toolbar, can be used to do cool things when you click them. Here are a couple:

1. Add an image to your Gmail message
2. Add HTML into your Gmail message (a more general form of the above)
3. Make all frames (and subframes) editable (click again to make them all uneditable)

Try them out! And if you like these, please Digg this post.