To All of Brett’s Friends and Followers

Brett Daniel

January 17, 1984 - December 5, 2010

Brett Daniel

Brett David Daniel, 26, of McCordsville, IN, passed away Sunday, December 5, 2010 at his home with his family by his side. Brett was born on January 17, 1984 in Midland Michigan to Diana and David Daniel.

Brett graduated as a National Merit Scholar from Hamilton Southeastern High School in 2002. From there, he attended Purdue University where he graduated with honors with Bachelor's Degrees in Computer Science and Mathematics. Brett continued his educational journey at the University of Illinois at Urbana-Champaign where he was pursuing his PhD in Computer Science. He has published and presented a number of technical papers related to his research.

Brett was very positive and always happy and demonstrated to everyone he knew what it meant to truly live. He had a never ending thirst for knowledge and adventure and loved to share what he learned.

Brett was preceded in death by his birth mother Diana Kedzie Daniel, grandfathers Robert L. Daniel, Henry E. Lescale, Laurent J. Troxclair, and Dr. Robert W. Kedzie. He leaves behind to cherish his memory devoted parents David and Susan Daniel, sister Erica M. D. (Sean) Kepner, grandmothers Dorothy Daniel, Elaine Lescale, and Joanne Kedzie, and his loving girlfriend and best friend Yun Young Lee. He will also be missed by numerous aunts, uncles, relatives, and many, many friends.

Services for Brett were held Friday December 10, 2010 at 2pm with visitation beginning 2 hours prior at 12pm all at Flanner and Buchanan Funeral Centers-Washington Park North 2706 Kessler Blvd. W. Dr. Indpls, IN. Burial took place in Kessler Woods Natural Burial Ground at Washington Park North Cemetery.

Tributes from Brett's friends and family are available at his Memorial & Tributes page.

This website will continue on as one of his legacies. He had a large backlog of posts that we will be putting on the site, as well as commenting on subjects close to his heart.

Brain Tumor and Radiosurgery

It has been a long time since I wrote about my ongoing fight against cancer. A lot has happened in several months—many changes, several surprises, lots of ups and downs—and I have a backlog of half-finished posts that I hope to publish eventually. For now though, I wanted to write about one recent development and some interesting medical technology that I encountered because of it.

Last June I tweeted that one of my pupils was much smaller than the other. That medical mystery prompted several scans and tests. Unfortunately one of the scans revealed a small tumor in the back right of my brain. It is still a mystery whether that actually caused the problems with my eye, but it is obviously a(nother) serious problem.

MRI of the brain tumor. It is visible as the circular area at the top right of the image surrounded by brighter inflamed tissue.

I was strangely unbothered by the news. I already had tumors in my lungs and leg; what was one more when I was already undergoing chemotherapy? The problem is that the brain is protected by the blood-brain barrier that also prevents many chemotherapy drugs from acting on tumors in the brain. Fortunately, radiation therapy provides an alternative treatment for brain tumors, since the brain can withstand a larger dose of radiation than other tissues. My oncologist quickly referred me to a radiation oncologist. Within just two days, I had an appointment scheduled for radiosurgery.

There are several forms of radiosurgery, but all essentially bombard a tumor with a lethal dose of high-energy radiation. It sounds violent, but the treatment is noninvasive, painless, and has few side effects. The radiation oncologist recommended a particular technique/machine/brand called Novalis that is similar to the more widely-known (or at least better-marketed) Gamma Knife.

Novalis radiosurgery machine

To hold the patient's head absolutely still and to calibrate the machine, it is necessary to brace the patient's head with a custom-molded plastic mask. The mask is made out of thermoform plastic mesh that is bolted directly to the table. Forming the mask was the most interesting part of a long day in the hospital.

The mask started at the back of the head. The technician laid a piece of the plastic mesh across a bracket, forming a headrest.


Next, two strips passed across the forehead and below the nose. Biting down on a small tab kept the upper jaw in place.

Mask braces

The strips formed the foundation for the mesh body of the mask.

Molding the mask material

The technicians heated all of the plastic pieces in a steaming vat of water. It started out transparent, malleable, and uncomfortably hot, but quickly cooled, solidified, and turned opaque.

Heating mask material

With the mesh solidly in place, the technicians marked key points for calibration. During the treatment itself, they attached small infrared beacons (which looked like glossy silver marbles) to the calibration points, allowing the machine to precisely determine the location of the tumor.

Marking the mask with registration points

The completed mask looked like a crocheted statue head and fit like a clamshell.

It took several hours for the radiation oncologist and technicians to plan the treatment itself. They combined two earlier scans with the new calibration points to calculate the precise path of the machine. When they finished, the treatment took just 20 minutes. I simply laid on the table, the technicians reattached the mask, and the machine made ominous buzzing noises. A followup appointment in a month should show whether the treatment was effective.

(Thanks, Dad, for taking pictures.)

Slide Rule (Updated)

Last April I bought a slide rule.

The front of a Frederick Post Company model 1447 slide rule. Manufactured in Japan by Sun Hemmi.
The back of a Frederick Post Company model 1447 slide rule. Manufactured in Japan by Sun Hemmi.

It is a Post model 1447 made by Sun Hemmi in Japan. I found it in an antique store buried under a pile of other slide rules and slide rule instruction booklets. Its beautiful bamboo-and-brass construction caught my eye, and I had to get it. As a computer scientist and programmer, so much of what I build is nonphysicial, so I love the idea of holding a physical computing device.

That is why I was especially excited when last week I came across the following book in the library:

Asimov slide rule introduction

It is called An Easy Introduction to the Slide Rule. I found it completely by accident. Only after taking it off the shelf did I notice the most surprising feature of the book: it was written by Isaac Asimov, he of science fiction super-fame.

The book explains the slide rule starting from first principles. It is informative and very enjoyable to read, even though some of the motivating stories show their age. Here is an excerpt from the first chapter:

We have all heard, these days, of electronic computers. These marvelous instruments, which came into use during World War II, are capable of performing in a few seconds work that might take years if all we could use were pen and paper.

There are times when arithmetical problems come our way and we might wish that we ourselves owned such a computer to do the work for us. Such a situation would have its disadvantages, however. Electronic computers are bulky, expensive, complicated, and can be handled only by people with special training.

Besides, electronic computers aren't at their best when used for everyday problems. That would be like trying to shoot a fly with naval artillery.

For a fly, an ordinary swatter is much better, and for ordinary mathematical problems, we could best use a really simple computer.

There happens to be a simple computer, just suitable for everyday computations, that was invented about 350 years ago. It isn't electronic; there are no electric currents involved. In fact, it is no more than a piece of wood with some marks on it. It looks like a ruler except that it has a middle piece that can slide back and forth, so that it is called a slide rule.

If a 45 year old book on slide rules sounds interesting to you (and how couldn't it!?), then you might also like How Round Is Your Circle, which explains how one would actually make a slide rule using nothing but a pencil, a piece of string, and three pieces of wood.

Update Tuesday, August 17, 2010

While antique shopping, I came across this handmade (!), four-foot-long slide rule.

Giant slide rule. The tag says: 'For the slide rule collector who has everything, this is a home made demonstration classroom slide rule. I've had others that were company produced, but this is the first [that was made by hand].'

The tag says, "For the slide rule collector who has everything, this is a home made demonstration classroom slide rule. I've had others that were company produced, but this is the first [that was made by hand]."

I would love to meet whoever made it. I would ask how he or she machined the hardware and determined the positions of the markings.

Summer Activities

Champaign-Urbana empties every summer as students leave for home or jobs. Those of us who remain have to be creative when thinking of ways to entertain ourselves. My friends and I have come up with some unique ideas. We made up a game involving chopsticks and M&Ms, cooked hairy hotdogs, and tried (and failed at) stargazing.

M&M Chopstick Challenge

One night, several friends and I were debating different ways of holding chopsticks. That discussion led inevitably to a contest to determine who was the best at handling chopsticks. We set up a round-robin tournament in which pairs of participants had to move 15 M&Ms from a plate to a bowl. Whoever cleared their plate fastest won.

The M&M Challenge: move 15 M&Ms from a plate to a bowl using only chopsticks. (Kevin's picture)

We used smooth chopsticks and ceramic plates, which made it infuriatingly hard. I was eliminated in the first round. Kevin won in a photo finish against Yun Young with a time of just under a minute.

Chopsticks game final

Hairy Hotdogs

I don't know who first had the idea to skewer hot dogs with uncooked spaghetti, but it likely came from somewhere in Russia. The idea spread across the internet and inspired Alejandro, Yun Young, and me to make it ourselves.

Yunyoung skewering
Skewered dog
Hairy hotdogs
Me bowl

Failed Stargazing

A while back my father gave Yun Young his old six-inch reflector telescope that he was hoping to sell. Two nights ago Yun Young and I took the telescope to a dark cornfield to see what we could see.


Unfortunately, storm clouds rolled in as soon as we set up the telescope, but we did see some impressive lightning in the distance.

Lightning in the sky over Philo, Illinois

Texas Vacation

I recently visited central Texas. Between Tuesday, May 18 and Monday, May 24, I visited Elise in Dallas, Eric and Shannon in Austin, and Marc and Shantelle in San Antonio. Along the way, I also admired the Dallas Botanical Gardens, spoke at the University of Texas at Austin, remembered the Alamo, and explored the Texas hill country.

Like the New Zealand trip, I made an annotated map showing my route and the places I visited.

Texas trip map

I also posted many pictures in the gallery. Here are a few of my favorites:

Koi pond in the Dallas Arboretum Texas State Capitol building Me and Eric at the State Capitol in Austin Mission San Jose wall and sky Hill country panorama

Testing a Testing Tool Part Three: ReAsserting ReAssert

This is the third in a series of posts in which I discuss the challenges I encountered when testing ReAssert. I already showed how I used tests as their own input and automatically deployed ReAssert for my own use. Here, I combine both aspects by demonstrating how ReAssert can repair its own unit tests.

ReAsserting ReAssert

Tests break when the system under test evolves in ways that invalidate the assumptions encoded in the tests. ReAssert addresses this problem by making it easier to update tests to reflect the changed behavior. Like any other complex piece of software, ReAssert itself has evolved, making it susceptible to the same problem that it attempts to solve. There have been several times in which a change to ReAssert broke its unit tests. It is natural to ask whether ReAssert could repair them.

Recall from the first post in this series that ReAssert's unit tests have two parts: a failing test method marked with the @Test annotation and its expected repair marked with the @Fix annotation. When such a test breaks, it means that the @Fix method must change to reflect ReAssert's actual output.

Here is a real example of one time that ReAssert's evolution caused tests to break. An early version of ReAssert lacked the ability to trace an expected value back to its declaration. Instead, ReAssert would simply overwrite the expected side of a failing assertion. The following code (similar to the example used in the first post) shows the @Test and @Fix methods that verified this early behavior.

public void testString() {
  String expected = "expected";
  String actual = "actual";
  assertEquals(expected, actual);
public void fixString() {
  String expected = "expected";
  String actual = "actual";
  assertEquals("actual", actual);

This is probably not what the developer would expect. Overwriting the expected side removes the use of the expected variable. This makes the test harder to understand and might cause a compiler warning since the variable is not used anywhere else. Such a repair could also cause other tests to fail if the assertion was located in a utility method called from multiple places. Indeed, this behavior confused several participants in the user study that Vilas and I performed to evaluate ReAssert.

I changed ReAssert such that it would instead replace the initial value of a variable used on the expected side of a failing assertion. Even though I wrote tests to verify this behavior prior to making the change, it still caused many tests to break. The example above broke, and it was necessary to update the @Fix method in the following way:

public void fixString() {
  String expected = "actual";
  String actual = "actual";
  assertEquals(expected, actual);

Since I had the ReAssert plugin installed as per the second post in this series, I wanted it to automate repairs like the one above. Doing so proved challenging because the process was so self-referential: ReAssert used ReAssert's result to repair a test that (as per part one) triggered ReAssert. Don't worry if that sounds confusing because it is. The following diagram illustrates the process more clearly:

ReAsserting ReAssert

To avoid confusion, I will refer to the "upper" and "lower" instances of ReAssert. The upper instance is triggered when I tell the plugin to repair a failing @Test-and-@Fix method pair. The upper instance executes the test under JUnit, which—via FixChecker, my custom test runner—invokes the lower instance of ReAssert. The lower instance "repairs" the body of the @Test method and saves the result in memory. Finally the upper instance copies this result into the body of the @Fix method and outputs the repaired source code.

But what prevents the lower instance from introducing an infinite recursive loop? After all, the lower instance of ReAssert invokes JUnit, which runs the test with FixChecker, which repairs the test with ReAssert, which invokes JUnit, and so on. FixChecker breaks this loop by ensuring that only one instance of itself is active. This allows the lowermost instance of JUnit to execute @Test normally.

This experience with ReAssert reinforced my belief that meta-execution is an ideal way to test and improve software development tools. Not only does the developer discover bugs that would otherwise impact users, but executing a program on itself can indicate how easily one can extend the tool's behavior. In ReAssert's case, meta-execution not only uncovered many bugs but also led to several improvements in the internal design of the tool.

I think ReAssert's meta-repair capability is one of the most interesting aspects of the tool. Unfortunately, I didn't have room to describe it in the paper, which is why I wanted to write this series of weblog posts.

How a Prosthetic Leg Works

Today I got a new artificial leg.

Prosthetic right

It is hard to believe that it has been two years since I got my first permanent prosthesis. In that time, my leg has shrunk considerably, and I have gone through two other temporary legs. The size difference is remarkable.

Prosthetic comparison Opening comparison

I have written before about how these legs were made; in the following video, I show how this newest leg works.


Testing a Testing Tool Part Two: Build and Deploy Local Eclipse Plugin

In my previous post, I discussed the first of several challenges I encountered when testing ReAssert. In this, the second of three articles in the series, I will describe how I automatically deployed the tool for my own use.

Build and Deploy Local Eclipse Plugin

When developing software tools, it is good practice to eat one's own dog food by using the tool oneself. It is one of the easiest ways to uncover bugs and improve usability. I ate ReAssert's dog food by using it to repair tests in other research projects and (as I'll describe in the next post) ReAssert itself.

ReAssert is implemented as an Eclipse plugin. The easiest way to deploy such a plugin is to include it in Eclipse's plugins directory1. When Eclipse starts, it automatically loads all plugins in the directory. If there is more than one version of a particular plugin, Eclipse loads the most recent.

To keep from having to install ReAssert's plugin manually, I made it such that the normal build process automatically updates version numbers and copies the plugin to the appropriate place. A single Ant build script handles the entire process.

The main challenge lies in accessing Eclipse's build metadata in the script. Each Eclipse plugin holds the metadata in a file called MANIFEST.MF. It contains things like the plugin's name, it's version number, and the other plugins it depends on. For example, here is part of ReAssert's:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: edu.illinois.reassert.plugin
Bundle-SymbolicName: edu.illinois.reassert.plugin;singleton:=true
Bundle-Activator: edu.illinois.reassert.plugin.ReAssertPlugin
Require-Bundle: org.eclipse.ui,
Bundle-Vendor: University of Illinois at Urbana-Champaign

ReAssert's build script first updates this file with the build number (based on the current date and time). Then, it reads the version and build number by converting MANIFEST.MF into a Ant property file. Finally, it bundles the plugin using the values.

Here are the relevant pieces of the script that implements this process:

  1. Set the date and time with tstamp, then replace the build number in the manifest with the date and time.
  2. Convert MANIFEST.MF into manifest.properties that Ant can read.2
  3. Set plugin name using the properties and bundle the plugin's JAR file.
  4. Copy the JAR to Eclipse's plugins directory. The eclipse.home variable is set when the script is run within Eclipse.
    Restart Eclipse to enable plugin

It is a pretty straightforward process but useful to keep my installed version of ReAssert up to date.

I have also seen a similar process scaled up to an entire enterprise. The company had an automated nightly build process that would post the plugin to an Eclipse Update Site on the local intranet. Every morning developers would update to the latest plugin. Any bugs they found while using the tool went straight into the bug tracking system.


  1. One can also install plugins through Eclipse's Update Manager with a plugin update site, but I felt this was overkill for ReAssert since it was such a simple plugin.
  2. Adapted from this article describing how to build a simple plugin.

Testing a Testing Tool Part One: Tests as Test Inputs

I wrote ReAssert to make it easier to maintain unit tests. Ironically, I encountered several challenges when testing ReAssert itself. First, ReAssert acts on source code, so I created a test framework that made it easy to build input programs and check ReAssert's output. Second, I ate my own dogfood by deploying the tool on my local machine. Finally, I combined both aspects by ReAsserting ReAssert itself.

This is the first of what I expect to be three posts in which I discuss these challenges.

Tests as Test Inputs

ReAssert transforms source code. Given the source code of a failing unit test, it outputs a transformed test that passes. Testing program transformation tools is difficult because writing input programs, passing them to the tool, and checking the output requires a lot of effort. Developers often automate the process by saving inputs and expected outputs to the filesystem or including them as string literals in their unit tests. Tests pass the input file contents or string literal to the tool and then verify that the tool's output exactly matches the expected output.

Both approaches are exceptionally common but have several disadvantages. First, files make it difficult to debug failures, since it can be difficult to figure out which file(s) corresponds to which test(s). Second, strings can make test code very verbose, and one has to worry about linebreaks, escape characters, and character encoding. Strings are also opaque to the IDE, so they lack helpful features like syntax highlighting and automatic formatting. Finally, both approaches require that the tool's output exactly matches the expected output byte-for-byte, whitespace and all. Such strict matching is rarely necessary when checking source code and can make tests very fragile. As soon as one changes the tool's pretty-printer, it can break every test even if program contents remain the same (which is actually one of the problems that ReAssert aims to solve).

I wanted ReAssert's unit tests to make testing as simple as possible while avoiding the problems caused by input files or string literals. The solution I built relies on the fact that ReAssert acts on unit tests. The test itself serves as the input to ReAssert, and another method in the same test class represents the expected output. To implement this idea, I extended JUnit's default behavior with a custom test runner called FixChecker and a new @Fix method annotation.

Here is an example: say I want to test that ReAssert replaces the initial value of a string used in a failing assertion. The failing test would look something like the following:

public void testString() {
  String expected = "expected";
  String actual = "actual";
  assertEquals(expected, actual);

ReAssert should repair the test by replacing the "expected" string with "actual". To verify this behavior, I create a second method annotated with @Fix whose body contains the expected repair.

public void fixString() {
  String expected = "actual";
  String actual = "actual";
  assertEquals(expected, actual);

Then, I tell JUnit to use FixChecker by annotating the test class with JUnit's @RunWith annotation. FixChecker intercepts JUnit's normal result when a test fails. It then "repairs" the test and checks that the repair matches the body of the @Fix method. If not, or if no @Fix method exists, then the runner reports that the test fails. Otherwise, it reports that the test passes. In a sense, the @Test-and-@Fix method pair act like assertEquals with the repaired test on the actual side and the @Fix method on the expected side.

FixChecker's repairs do not change the source code directly. Instead, it holds the modified source code in memory and compares it against the parsed source code of the @Fix method. In this way, the comparison ignores differences in source code formatting, and one can use either qualified or unqualified class names. Also, since both the test and the @Fix are normal methods, they can reuse aspects of the surrounding test class, and both receive the full support of the IDE.

FixChecker also provides two other useful features. First, it is smart enough to ignore tests that pass and lack an @Fix method. Instead, it forwards them along to JUnit unchanged. This allows me to mix ReAssert tests with standard unit tests. Second, I can test when ReAssert is expected to fail by marking unrepairable tests with @Unfixable, another new annotation that FixChecker knows to look for.

public void testIgnoreAssertFail() {

Several aspects of this framework are applicable to other program transformation tools. It is often useful to use real application code when testing even when a tool does not act solely on unit tests. Also, custom test runners can be exceptionally powerful and allow one to tailor tests to many contexts.

In later posts, I'll describe how I automatically deployed ReAssert for my own use, and how I used the tool to repair its own unit tests.

Siebel Center Igloo (Update 2)

Nine friends1 and I built an enormous igloo in the courtyard between Siebel Center and the NCSA building.

Igloo with Siebel Center in the background (Yun Young's picture) Siebel center sculpture and igloo

How enormous? It is nearly eight feet tall and eight and a half feet in diameter. The doorway is four feet high and two wide. All 10 of us could easily fit inside. We estimate that it took over 80 man-hours to complete: we worked from 5 to 8 PM on Friday, then from 4 PM Saturday to 5 AM (!!!) Sunday. In that time, the temperature never got above 15° F.

It was a team effort. Yun Young and Alejandro deserve credit for initiating the construction and for their inspiring enthusiasm. Ellick documented the construction process with over 600 pictures (some of which I have used with his permission here). Nathan, being the tallest, was instrumental in completing the roof. Jeff O., Kevin, and Alejandro formed an efficient snow-brick-making machine. Lucas, Jeff D., and Jeremy provided much-needed reinforcement when they arrived near the end of construction. Finally, I helped for a few hours on the first night, then observed, supported (read: bought pizza), and provided unsolicited engineering advice on the second night.

The construction team admiring the progress (Ellick's picture)

None of us expected it would turn out so big or take so long to complete. Construction was completely unplanned and proceeded organically by trial and error. We eventually converged on the following process: pack snow into bricks, lay the bricks, pack the gaps with snow, smooth the edges, and spray water on the surface to strengthen the walls.

Laying the first bricks to form the wall Nathan and Yun Young mortaring the partially constructed wall with Alejandro and Kevin making bricks

We created bricks by packing snow into two small trash cans. It was difficult to form the dry, powdery snow into solid bricks. Our first attempts did not turn out very well.

The first unsuccessful brick The first unsuccessful brick

However, Alejandro realized he could use one trash can to compress the snow inside the other. After that, he became the brickmaking expert. He could produce solid bricks that slid out of the molds like muffins out of a muffin tin. Later, he found we could alternate the wide and narrow ends of the bricks to make the joints flush.

Using one trash can to compress a snow brick in the other trash can

At the end of the first night, we had three uneven layers of bricks. But there was a problem: they rose straight up, not inward as is needed to form the roof of a proper igloo. We seriously considered simply making an open snow fort. However, after adjusting the pattern of bricks on the second night, the walls started curving inward.

The unfinished spiraling wall near the end of the first day Starting the curve of the roof (Ellick's picture)

The next challenge was the doorway. Compressed snow has zero tensile strength (as we learned through bitter experience), but somehow we were able to make a lintel by forming a rough stairstepped arch.

Kevin and Yun Young inside the unfinished igloo (Ellick's picture)

The walls sloped more and more precariously.

Alejandro inside the unfinished igloo (Ellick's picture) Kevin mortaring the bricks (Ellick's picture) Yun Young smoothing the outside wall (Ellick's picture)

A small opening remained at the peak of the igloo. This was the most difficult part because it was too large for a single brick and the surface was too steep to hold more bricks. Yun Young and Kevin furiously packed handfulls of snow around the edge, spraying many bottlesful of water to make sure the snow stuck. Eventually, the hole shrunk enough that Nathan and Alejandro could jam three bricks together to form a peak at the top of the igloo. They filled the remaining space with rubble.

Plugging the hole in the roof (Ellick's picture) Plugging the hole in the roof (Ellick's picture) Plugging the hole in the roof (Ellick's picture) Plugging the hole in the roof (Ellick's picture)

The igloo was enclosed! The final step was smoothing the inside and outside surfaces and reinforcing joints with snow and water.

Lucas and Jeremy smoothing the roof (Ellick's picture)

Frozen to the bone and exhausted, we collapsed on the couches inside Siebel Center.


Here is an overhead view of how the igloo came together.

Work crew (4:38 PM Saturday, January 9, 2010) Progress from above (Ellick's picture. 6:08 PM Saturday, January 9, 2010) Progress from above (Ellick's picture. 8:22 PM Saturday, January 9, 2010) Progress from above (Ellick's picture. 11:18 PM Saturday, January 9, 2010) Progress from above (Ellick's picture. 12:29 AM Sunday, January 10, 2010) Progress from above (Ellick's picture. 1:23 AM Sunday, January 10, 2010) Progress from above (Ellick's picture. 4:03 AM Sunday, January 10, 2010) Progress from above (Ellick's picture. 5:18 AM Sunday, January 10, 2010)

The next morning, Yun Young, Kevin, Ellick, and I visited the igloo in daylight. We met a group of students who complimented us on the project. Throughout the day we observed many other people stopping to look and take pictures.

The igloo is very popular with students walking through the courtyard

We are all incredibly proud with what built and hope that others who pass by Siebel Center will enjoy it for however long it lasts.

Tree and igloo The igloo's room number: 19100 Siebel Center with signatures of the construction crew.

You can see more pictures in the gallery, Yun Young's Facebook album, or Kevin's Picasa album.

Update (January 12, 2010)

The igloo has been extremely popular. We saw a steady stream of visitors all day yesterday, and our guestbook already has several pages of signatures. It even caught the attention of the local news. WILL radio and WCIA both briefly mentioned the igloo, and WICD, the local ABC affiliate, interviewed Alejandro and Yun Young.

Thanks to Jeff O. for posting the video.

Update 2: Aftermath (January 15, 2010)

A full day of above-freezing temperatures and light rain proved too much for the igloo. It had noticeably shrunk, and the sides had been bulging outward all day. It finally collapsed yesterday evening around 6:30 PM.

Aftermath (6:30 PM January 14, 2010)

Judging from the orientation of the debris, it looks like the walls exploded outward and roof fell straight down onto the floor. Only the right side of the door frame remained standing.

Aftermath (6:30 PM January 14, 2010)

Yun Young, Alejandro, and I paid our last respects and rescued the guestbook, which had been buried under the pile of snow.

Aftermath (6:30 PM January 14, 2010)

Here are some of the best quotes from the guestbook.

You've brought joy to many.

Amazing – I'm tempted to skip work today and just chill in your igloo

This is what the Blue Waters building should be. I love it.

Sweet! will you come to my house & build one for my kids?

Get back to work!
—Your Advisor

You have a marvelous island of quiet in the busy world & it was great fun watching you build it

I've been trapped outside for the weekend.
Thank you for a shelter from the wild beasts.
The end was near the light shines through.
Godspeed to all who may encounter this oasis of warmth.

Great igloo. How about an ice pane window? We love it.
—Erin and Spencer

So proud to be an alum of UI!
—Dr. Pam

Is this igloo internet accessible too?! [It was! —ed.]
—Jill & Tom

This is a real gift to our community . Many people have stopped to enjoy your creation. Thank you!
—Mark & Teddy

Wow this is one of "the seven wonders of UIUC"

Too cool for school

Victoria needs to sleep


I think the best epitaph comes from Rajhans via Facebook:

This igloo is not just a shelter; no sir for that purpose has been thwarted by modern architecture. It is actually an icon of something very very special - the perseverance which grad students show in making something completely useless yet incredibly beautiful. Its a symbol of all the free time grad life provides and the crazy ideas it fills us with; ideas of finding ways of killing that free time. Who invented Ping Pong - I am sure it was a student of Confucius. Who created Olympics - the grad student mentioned somewhere in Illiad. Gustave Eiffel was a grad student too! And so, dear Yum Yum [Yun Young's nickname. —ed.], this Igloo is not anyone's baby - its bigger than a baby or for that matter, any of us. It is indeed one of the foremost exemplar of the primary grad student trait I have so painstakingly just described.

Goodbye, Siebel Center igloo. You were a testament to friendship, teamwork, and determination despite cold and discomfort. While you may have at first appeared completely useless, you brought joy to everyone who passed by.


  1. Alejandro, Yun Young, Kevin, Nathan, Ellick, Jeff O., Lucas, Jeff D. and Jeremy

Then and Now

Then and now: me proudly holding a Lego model in 1991 and 2009.

Then: Me proudly holding a Lego model in 1991 Now: Me proudly holding a Lego model in 2009



New Zealand

When I told people I was going to New Zealand to present my ReAssert paper, nearly everyone asked if I was planning to travel around the country. Absolutely. One does not visit New Zealand for a three-day conference, then immediately turn around and go home. I stayed for 10 days. During that time, I attended the conference, toured Auckland, drove all over the south island with Yun Young and Danny, and saw more interesting things than I could possibly fit into one weblog post.

I considered writing a travel report like my Yellowstone or California posts, but the length of this trip made me feel that a different approach was necessary. The map below shows the path I/we took through New Zealand. Clicking it will take you to an annotated, interactive map with descriptions and pictures of the interesting places.

Annotated map of where we traveled. See the interactive version for details.

I posted more pictures in the gallery (see also Yun Young's Facebook albums). Here are a few of my favorites:

Auckland skyline
Panorama of Auckland from One Tree Hill. The Sky Tower is to the left and Rangitoto Island is far in the background on the right.
River and snow-covered mountain
Harrison River with Mt. Pembroke in the background
Panorama from the vista point overlooking Lake County and Arrowtown
Danny and Yun Young taking pictures on the vista point overlooking Lake County
View toward mountains from Gillespie's Beach
Punakaiki panorama

explain: Short Documentation for Unix Commands

Here is a scenario that may sound familiar to Linux users: say you want to do something in a terminal but don't know the appropriate command. A quick web search yields a number of possible solutions, but every one is a long, impenetrable command with several unexplained flags. One should avoid running unknown commands that may do something malicious (e.g. "rm -rf ~"), but it is difficult to search through each command's documentation to find the meaning of all of the flags.

I wrote a small utility program that addresses this problem. The utility, called explain, prints short documentation for a given command string, including the documentation for all flags passed to the command.

For example, say you want to copy a file only when it is newer than the destination file. This superuser.com thread suggests the following commands:

cp --update src dest
rsync -avz /from/where/ /to/dest/

explain shows what both of these commands actually mean:

$ explain cp --update src dest
cp - copy files and directories
    -u, --update
        copy only when the SOURCE file is  newer  than  the  destination
        file or when the destination file is missing
$ explain rsync -avz /from/where/ /to/dest/
rsync - copying tool
    -a, --archive
        This  is equivalent to -rlptgoD. It is a quick way of saying you
        want recursion and want to preserve almost everything  (with  -H
        being  a  notable  omission).   The  only exception to the above
        equivalence is when --files-from is specified, in which case  -r
        is not implied.
    -v, --verbose
        This  option increases the amount of information the daemon logs
        during its startup phase.  After the client connects,  the  dae‐
        mon’s verbosity level will be controlled by the options that the
        client used and the "max verbosity" setting in the module’s con‐
        fig section.
    -z, --compress
        With  this  option, rsync compresses the file data as it is sent
        to the destination machine, which reduces  the  amount  of  data
        being transmitted — something that is useful over a slow connec‐

This documentation is simpler than a command's full man page, provides a more focused view of only the flags that one cares about (including their synonyms), and makes it easier to compare different commands. Thus, explain is complementary to existing Unix utilities like man, whatis and apropos.

To get explain, you can download its source code or clone its Mercurial repository. The bundled INSTALL file contains installation instructions.

Update from the comments: internally explain parses the command's man(1) page and searches for sections that look like flag documentation. This is somewhat challenging because the file contains no semantic markup and there is no "standard" format, just ad-hoc suggestions on what it should contain. These two factors are probably part of the reason why a utility like explain doesn’t already exist.

explain currently handles just one command at a time. I hope to improve the utility by explaining more complex commands with sub-commands, pipes, and redirects. I would also like it to explain non-flag arguments such as the source and destination arguments in the examples above. Finally, certain common commands use nonstandard flags that explain could probably handle as special cases. For example, it would be good if explain could show documentation for commands like "java -Xmx1024M" or "chmod +x". If you have any other feature requests or if you find any bugs, please post them on the issues page.

Over the past week, I have used explain at least once per day. I hope others find it useful, too.

Weekend Road Trips

Even though most of my time is taken up by graduate school and medical appointments, I recently managed to find time to travel. I spent each of the past four weekends visiting friends all over the Midwest. First I helped Charlie celebrate his birthday in Louisville, Kentucky. Then, Michael had a bachelor campout—like a bachelor party with less debauchery and more trees—at Stuart's family's farm in Ohio. The following weekend, several UIUC friends and I visited Josh at his new graduate school home in Nashville, Tennessee. Finally, last weekend Michael and Alice got married in northwestern Indiana.

Fall  road trips

Each trip could fill its own post, but for now I will just describe one particularly noteworthy event from each.

Charlie and the Belly Dancers

Last year I helped Charlie celebrate his birthday in Montana. This year he came to Louisville, Kentucky, where he had spent several years at the University of Louisville. He visited several UofL and high school friends who were in the area. I drove south from Indianapolis to meet them there.

Charlie had his birthday dinner at a restaurant in the blocks-long entertainment district of downtown Louisville. The restaurant was decorated with faux-Greek wall hangings and pottery. The entertainment as well as the food also had a Mediterranean flavor. About halfway through the meal, three belly dancers in sequined dresses began dancing through the aisles, playing castanets and hand drums. It wasn't salacious dancing—it was a family restaurant, after all—just surprising and pleasant entertainment.

Charlie, knowing, it seems, everyone in town, recognized one of the dancers. I mentioned this and the fact that it was Charlie's birthday to the server. She in turn told the dancers, who came to the table and danced around Charlie. Afterward, the head dancer got all the other restaurant patrons to wish Charlie a happy birthday. It is difficult to embarrass Charlie, but I think that experience came close.

Michael's Bachelor Camping Trip

Two weeks prior to his wedding (which I write about below), Michael had his bachelor party. Unlike most bachelor parties, we went camping. Stuart offered his family's farm as the destination. It had a beautiful man-made lake surrounded by woods and cornfields.

Michael by lake Todd stuart michael and lake

We did normal campout activities like sit around the campfire roasting hot dogs, but I also got to do something I had never done before: shoot a gun. Before leaving for the farm, Michael's father gave us a small 22-caliber target rifle and an old mailbox. He urged us to destroy the mailbox. We placed it by an earthen berm next to one bank of the lake and did just that.

Me shooting an old mailbox Holy mailbox

It was deeply satisfying to hear the loud "ping!" when one hit the mailbox. We noticed that some of the bullets left trails along the edge of the mailbox or failed to make it all the way through both walls.

There are more pictures in the gallery.

Visit Josh in Nashville

This picture illustrates the best part about visiting Josh in Nashville: getting to spend time with good friends.

The group: Lucas, Nathan, Jeff, Me, Josh, and Karin

It is a good thing we visited because Josh has been so busy that he has not gotten a chance to enjoy Nashville's famous music district. It was a new experience for all of us. We found several venues with live music, but the best came when we found a jam band playing mid-90s alternative rock. One member of the band soloed on electric violin, which gave them an especially interesting and unique sound. The lead guitarist would also trade his guitar with friends in the audience. That informality and the style of music reminded me strongly of the shows I saw my friends play in high school.

There are more pictures in the gallery and Karin's Facebook album.

Michael's Wedding

Michael finally married Alice, the fellow Purdue alum that he has been dating since right around the time he and I graduated.

Like the trip to Louisville, the wedding gave me a chance to catch up with longtime friends. Of course that includes Michael and Alice, but Stuart, Todd, Matt, Joe, Josh H., Brittany, and Megan also attended. Even though I have been keeping this weblog for over eight years, it is amazing (and discouraging) how much I have forgotten about my time at Purdue. Similarly, despite electronic social networks, I knew less than I would have liked about the lives and activities of the other attendees that I knew from that point in my life. The wedding underscored the importance personal contact with friends.

I am sure this pales in comparison to Michael's experience at his own wedding, so I won't try to overstate anything. Instead, I can simply say that I am deeply honored to have helped him celebrate his marriage, and I wish him and his wife the absolute best in their new life together.

What is this Building?

A small house on top of a pole.  Seen while driving through Knox, Indiana.

Seen north of Knox, Indiana next to an old railroad bed and train station. The building is bigger than it looks in the picture; about 10 feet off the ground and big enough to hold maybe two people. Any guesses on what it was used for?

Older Posts