Doxygen Rocks

June 8th, 2007

Consider the enormity of the problem. I’ve got a pile essentially uncommented C++ code from the Helix Producer code in front of me. I need to understand its structure and purpose. I start by whipping up a Python program to ferret out the class hierarchy. It works pretty well, only getting confused by some of the more complicated class declarations that are hidden in preprocessor directives. The output of the program is rough html - no clever formatting, just page after page outlining three thousand one hundred six classes. Ugh.

I decided that I needed to see some class hierarchy diagrams. Of course, I jump to GraphViz to try to remember how the “dot” language works. On that Web site, I encounter something interesting: Doxygen a documentation tool for several programming languages. I look at it an see lots of references to specially formated comments and then make the faulty assumption that it works only if the code’s comments follow the special format. I decide to drop further investigation.

However, a code sample in Doxygen’s documentation catches my eye. There is an example of a C++ with a class name identical to a class name in my pile of Helix code. Digging a little deeper, I find several other classes that match, too. Is Doxygen actually using this same code that I got as their examples? Well, of course not. I used Google to search for those class names on the internet in general. I find lots of references to Microsoft Web sites. It turns out that Helix producer is pretty tightly coupled to a Microsoft API. I had no idea. Some code is reproduced literally. Is this a copyright problem for this Open Source project? I’m assured by others, that it is not.

Back to Doxygen: I dropped it until our overlords at our funding institution mentioned it. I was told I should revisit Doxygen. After the meeting, I came back to my machine and did:

sudo apt-get install doxygen
sudo apt-get install doxygen-gui

Within ten minutes, I had fantastic documentation for the important part of our project. It turns out that Doxygen does need the specially formatted comments to produce this kind of documentation. It actually parses the source code to analyze the structures. It even then uses GraphViz to create the hierarchy diagram.

Without I doubt, I find Doxygen to be one of the coolest tools available to a programmer.

He’s back…

May 4th, 2007

Ok, it’s been a while since I posted to this blog. That’s because I left the OSL in March of 2006. Well, I’m back just over a year later. This time, instead of as an employee, I am a contractor. I’m assigned to OSU’s contribution to the OLPC project. I will be back to programming in C++ after a several year long excursion into Python.

Lost History?

September 29th, 2005

Several years ago, when helping clean out my father’s house before it was sold, I ran across an old trunk. Inside, I found hundreds of papers: the notes and articles written by my great uncle Larry Rue, a World War II war correspondent in Europe. The papers covered roughly thirty years of his career and included a personal letter from Herbert Hoover. I spent hours reading through those fascinating papers. Aside from some messy handwriting, nothing about these papers had become obsolete or unreadable.

I wish I could say the same for my own “papers.” It was 1984 when I first put a word processor on a computer. I started writing volumes. Every letter, every journal entry and every note ended up with a dot doc extension. As the years passed, I upgraded and moved my documents to new machines. By 1990, when in graduate school, I was using Word for Windows under Windows 386 (a nearly forgotten precursor to Windows 3.0). At that point, I discovered that I was no longer able to read the files that I had written only five years earlier. Another fifteen years has passed and now I can’t read my own graduate thesis document.

As their products evolved, Microsoft made conscious decisions to drop support for older document formats. The decisions were made for business or technical reasons for their own benefit and convenience, not mine. Future files formats will allegedly be patented, insuring that no matter what software reads these documents in the future, Microsoft’s corporate palm must at some time be crossed with silver.

By endorsing OpenDocument v. 1.0, the Commonwealth of Massachusetts has mandated that all government documents must be in an open format. Apparently, a state government has noticed that important documents from the past aren’t readable any more. Apparently, they also noticed that a single company could potentially put a toll booth on the discourse between citizens and their government. This is a great decision. Not only does it open the possibility that historians and archivers in the future will have access to the information, but it levels the playing field for different vendors right now. Anyone could write a document processor to read these documents. For the first time in years, perhaps we can see some real competition in the field of office document programs.

As a citizen, shouldn’t I be entitled to access the information and documents generated by my government? Isn’t this a rather basic right? No corporation should have to be paid in order for me to exercise my rights.

In the realm of my own life, I find it repugnant that a corporate toll booth could sit between me an my own journal and correspondence. I’m certainly glad nothing stood between me and my Uncle Larry. Perhaps it is just vanity, but I’d like to think that my painstakingly transcribed thoughts will someday be a found treasure. But as it stands right now, it just a bunch uselessly cryptic but beautifully organized binary files.

Lars at OSCON 2005 - on Laptops and Projectors

August 18th, 2005

Several years ago, I went to a small conference of antique rose enthusiasts. There were five speakers scheduled including the greenhouse manager of my nursery. He declined my offer of scanning his photographic slides and the use of a laptop computer for the presentation. He’s a professional photographer and sited the inability of LCD projectors to accurately reproduce color as he reason for refusal.

Each of the conference speakers was to bring a CD of their Power Point presentation to be used on the conference supplied computer or their own laptop to be plugged into the projector. Every single Power Point presentation failed. Some presentations started fine and then the image would vanish. They fiddled with the cables, the projector settings and computer settings to no avail. The only successful presentation came from my greenhouse manager with his old fashioned physical slides.

Somehow, I expected with a conference center filled with geeks that OSCON would be entirely different. Yet I’d estimate that twenty-five percent had difficulty getting their presentations going. I witnessed no total failures on major talks, the delays were noteworthy. How many times in the main conference hall did one or two of the projection screens blank out suddenly or show an image seriously shifted to the right or left? I won’t even go into The Lucky Stiff’s presentation debacle during the Ruby love fest.

I would think that the connection between laptop computers and projectors would be a fairly mature, stable technology. Yet, after seeing so many presenters at OSCON struggle to get their presentation slides on the big screen, it’s clear that industry has more work to do. Why is it so difficult for projectors when it seems so easy for desktop monitors?

Lars at OSCON 2005 - on Python’s whitespace

August 8th, 2005

Python uses syntactically significant whitespace to define blocks of code. When casually talking with some Ruby and Java developers at OSCON about Python, I inevitably had to wait for them to stop ranting about mandatory whitespace. When I queried as why they we’re so opposed, I never once really understood their objections. I really love Python’s whitespace rules.

One noteworthy complaint I heard was that code written in one editor by programmer A can get its indentation munged by another editor used by programmer B. Yeah, I can see how that can happen, but only if tabs are expanded or replaced by the second editor. That would break a Python program. In another language, you’d have to make the same corrections anyway or the code could be rendered unreadable or deceptively indented even though it still compiles. In Python, properly indented readable code is a requirement. Maintenance programmers in the future will call this a good thing. The problem can be avoided entirely by not using tabs.

The first code time I encountered indenting code was in Pascal in 1978. It made the code so much more readable. The “begin” was by itself on a line, subsequent lines were indented until, on a line by itself, the “end” statement terminated the block. Later, programming in Fortran 77, indentation was used in a similar manner, though without the “begin” and an “endif”, a “wend” (DEC variant) or a labeled “continue” to terminate the block. C was just like Pascal, only with braces to define the block.

Programmers in C started a unsavory habit of placing the opening brace at the end of the line preceding the block while the close brace lived on a line of its own. This meant that the opening and closing braces rarely, if ever, lined up horizontally. To this day, my eye/brain combination has a terrible time matching braces. To my dismay, that style has become the standard, not only in C, but in all its children: C++, Objective-C, Java and C#. Yet, it is the convention to also use indentation. Why? Because the braces alone are not good enough at making blocks readable. Try eliminating the indentation and the code becomes nearly impossible to read. Braces are good enough for the compiler but not enough for humans (at least this one). It’s like the parenthesis in Lisp: once you get four or more opening or closing parenthesis in a row, I can no longer mentally match them up at a glance. Perhaps my brain is defective.

Have you ever heard the doctrine of “once and only once”? Originating in our own software world, it suggests that it is a bad idea to duplicate effort. Throughout the realm of programming, trying to maintain two parallel solutions to the same problem leads to problems. Remember the relief that Java gave us over maintaining separate header and implementation files in C and C++? Remember how difficult it is to keep documentation synchronized with the source code?

Why do the C derived languages use two separate techniques to indicate a block of code? We use braces for the compiler and whitespace indentation for the programmers. Python demonstrates that the compiler can use the same queues that we use to see blocks of code.

Honestly, the technique used to delineate a block of code in a language is a minor issue. I really like Python’s technique because it synchronizes with how my brain seems to work. I’ve lived with braces in my code for years and years. It hardly seems a reason for such vehemence as I heard at OSCON from some other developers.

Lars at OSCON 2005 - On Ruby

August 7th, 2005

Ruby: the new black, the cream in the coffee, the acid in the Koolaid

If it’s true that the right mix of illicit pharmaceuticals can alter one’s perspectives leading to new insights and ways of thinking, one might suspect a lot of folks at OSCON 2005 were dosed with Ruby. That first understanding of Ruby’s functional programming aspect is just such a mind-opening experience, bringing to mind the now twenty years gone epiphany I had when I suddenly understood recursive pattern matching algorithms in Lisp. I hope folks who have been tripping on Lisp for decades nod and welcome this new generation of Ruby programmers into their expansive way of thinking.

Lisp suffers an unfortunate history. In spite of its considerable power, it never became a dominant programming language. Good technology at the wrong time, perhaps? I first encountered Lisp in graduate school in an artificial intelligence course. I recall the thrill of its power, and the frustration at its difficulty of code maintenance. It’s not a failure of the language, it’s a failure of the tools that enable expression of the language. It think that is a major reason why Lisp never became dominant.

Another progenitor of Ruby’s more advanced features is Smalltalk. It is another very powerful elegant language that failed to capture dominance. It differs from Lisp in that it had, when introduced, a revolutionary built in integrated development environment. There was nothing else out these like it, yet it failed to sweep the planet. Was it too far out of the main stream? I believe that Smalltalk’s tight binding to its operating environment contributed significantly to sabotaging its deserved success. This, again, exemplifies the failure of the tool rather than a failure of the language.

I heard several times during Ruby track sessions at OSCON, “Syntax is important.” In each case, the presenter was showing off some elegant, yet simple way of expressing a construct that would be awkwardly verbose at best in Java or C++. Lisp and Smalltalk both have elegant, yet simple constructs, too. The syntax alone was not enough to propel these languages into ubiquity.

It takes more than clever syntax to insure the success of a language. It takes dedicated enthusiasts, a demonstration of successful projects, as well as compelling tools to draw developers. Ruby has the first in spades. Perhaps Ruby on Rails will prove to be the second. The third, through my limited view from OSCON, is not evident.

I admit, I drank the Koolaid, too. I am excited about the possibilities of Ruby to succeed where its virtual ancestors Lisp and Smalltalk did not. I sincerely hope that the community surrounding this worthy project expands enough to negotiate the path to ubiquity. Meanwhile, I’m going to sit back and enjoy the trip. Yield to the block, man.

How I learned to stop worrying and love OSS

July 21st, 2005

I am a software developer. I’ve had a long and fruitful career both as a corporate employee and an independent consultant. In 1999, I took a left turn with my career and opened a nursery specializing in rose bushes. I took a couple of older computers discarded by my software consulting business and dedicated them to the new business. Using Microsoft Access, Visual Studio C++ and libraries licensed from Rogue Wave Software, I created the software to control the entire business: inventory management, customer management, order fulfillment, web site generation and accounting. Most of my waking hours were dedicated to the evolution of this all encompassing small business software package.

In 2001, as my business was growing rapidly, I got a letter from Microsoft and the Business Software Alliance (BSA). I was told that there was pirated software in use in my business and I was potentially liable for thousands of dollars in damages to Microsoft. Reading on, I was informed that the BSA has the right to audit my business at anytime and if they found illegally copied software the consequences would be dire for my business.

I was dumbfounded. I began an audit of my own operations. I realized I was missing some paperwork. The machine that I used with Microsoft Access was purchased in 1997 by my software consulting business. While I had the original receipt for the machine that showed that I had purchased the Small Business package that included Access, I could not find the Certificate of Authenticity for MS Office.

I went back to the letter from the BSA. According to them, there was some good news: an amnesty program. I could get legitimate licenses for my software at discounted rates directly from Microsoft. It would be so convenient, they provided an 800 number as well as a Web site. They suggested that I take advantage of their offer immediately, because the BSA is auditing thousands of businesses every year.

I considered biting their hook. But some research showed that Access had changed significantly between the 97 and 2000 versions. I would have to re-implement the front end of my software to make it work with Access 2000. The price for the new software coupled with the lost time and expense of re-engineering the front end was too much. In the midst of the nursery’s busy shipping season, I had no time to dedicate anything but order fulfillment, inventory care and keeping the irrigation system running.

I remember sitting at my desk one evening pondering how to resolve this problem. Then I noticed the envelope that the original letter had come in: it was addressed to “Ms. Rose Uncommon”. My business is called “The Uncommon Rose”. There is no one here named Ms. Rose Uncommon. We get junk solicitation mail for this non-existent person all the time. It was suddenly clear that they had purchased a bulk mailing list and carpet bombed everyone on it. Microsoft had adopted a policy of marketing by blackmail: “Buy our products or we’ll sue you!”

My business is my livelihood: it puts food on my table. It was time to swat Microsoft’s hand out of my revenue stream.

I stopped worrying about it until the end of the shipping season that year. I acquired a couple no-name computers and loaded them with Red Hat Linux. I learned about PostgreSQL, the Python language and Open Office. I cobbled together a replacement for all Microsoft products before the beginning of the next shipping season.

It’s now three years later and the business runs entirely on computers running Linux. OSS enables the Uncommon Rose to thrive without the yoke a mega-corporation whose agenda I neither understand nor trust. I’m no longer so intimately involved in the day to day operation of the nursery: I have employees for that. With my position at the OSUOSL, I have a great opportunity to contribute back to the community that helped me so much.