mod_mono Control Panel

The latest release of Mono adds a little control panel to mod_mono, which I cooked up a while back. (Btw, thanks to Gonzalo for fixing it up and getting it in svn.) The control panel only lets you do one thing right now, which is restarting any mod-mono-server processes that it started. I use this whenever I update the code for GovTrack and need to have Mono reload the DLLs.

To activate the control panel at a URL, add something along these lines to your httpd.conf:

  SetHandler mono-ctrl  Order deny,allow  Deny from all  Allow from 127.0.0.1  [or your IP address]

The Order/Deny/Allow directives make sure that you’re the only one that can restart the server. You can also put these directives in a .htaccess file in the directory where you want the control panel to show up, but omit the tags. (Restart Apache after you put this in httpd.conf.)

Now you can visit http://yourservername/mono and you’ll see the control panel, with a link to restart the mod-mono-servers. Clicking the link immediately restarts the servers. (Not Apache, just the mod-mono-servers.)

For those running virtual hosts: If you’ve placed your Mono* directives for mod_mono all in VirtualHost sections, then you’ve already got separate mod-mono-server instances for each virtual host. The control panel will only see the mod-mono-server(s) for the virtual host that’s serving the page, so you could put different access controls on the control panel for different vhosts to allow different people to restart only the mod-mono-severs that they should be allowed to restart.

Programming Language Syntax

If you know a little bit about how compilers work, you know that the syntax of programming languages is context free. That is to say that each syntactic element of the language can be described as a list of sub-elements, regardless of what context it appears in. For example, a while-loop in C# is (roughly) the keyword ‘while’, followed by an expression, followed by a statement (or block of statements), and it doesn’t matter where the loop appears, that syntactic definition is always the same. This is basically the idea of a context free grammar (CFG).

Natural languages (i.e. human languages) are not context free. It’s impossible to come up with a (concise) list of CFG rules, such as “a sentence is a noun phrase, followed by a verb, followed by a noun phrase; and a noun phrase is an article (a ‘determiner’ in the biz) followed by a noun” to describe English, for instance. That will work for simple sentences like “a man walked a dog”, but not for sentences like “which dog do you think a man walked?”

Now, this raises the question of why we don’t program in languages that closely resemble natural languages, in terms of syntactic structure? Wouldn’t that make it easier to program? There’s a good reason why we don’t do that, actually: No one knows what the syntax of natural languages looks like. Try as we might, natural languages are still beyond our understanding.

The reason I’m writing this is that I just came back from a symposium in honor of one of my professors (I study the syntax of natural language, by the way) who invented Tree Adjoining Grammar. TAG is a type of syntactic formalism that can actually be used to describe English fairly well — in the way that CFGs don’t even come close. At a very high level, TAG adds to CFG the ability to splice together two units of structure. I was wondering whether a TAG-based programming language syntax would let us program with new types of syntactic sugar, although I think the answer is that nothing interesting would come out of it.

A Programming Project

A Programming Task for Someone Looking to Hack

The biggest thing that has helped me to program better is little programming projects. My first was a simple math tutoring program in GW-BASIC, written with the help of my dad back around third grade. I’ve almost always had a little project to keep me busy since then.Today, it’s creating an RDF library in C#.

I know that often people are looking for ideas for programs to write, so I thought I’d post a routine that someone might want to spend some time hacking. This is a mildly advanced routine, but anyway:

The goal is to parse an RDF/XML document using only XmlReader. That is, extract the RDF statements without loading the entire document into memory as an XmlDocument. As far as I know, this has never been programmed in C#, and it is really critical if semantic web applications are going to be built in .NET.

Getting the basics going isn’t too difficult a task. Getting the entire spec implemented is more of a challenge. But what’s life without challenges, eh? If you’re interested in taking a stab at this, drop me an email (tauberer@for.net).

A Design Suggestion

When I was riding the train back from D.C. to Philly last week, the speaker in the car I was in wasn’t working, so no one could hear the conductor’s announcements. Probably no Amtrak person noticed the problem.

It made me think that we often build things that don’t notice when they’re not working. Speakers should be built with microphones that realize when the speaker isn’t emitting the sound it should be, and when that happens it sends back a signal to… somewhere. Software should do the same thing. Applications should realize when things aren’t working right and, more importantly, send back a useful message that a problem occured.

Here’s a for instance. I plugged in a printer to my Linux desktop this week, but I couldn’t print a test page. The only message I got back was that I should increase the debugging level and inspect the output. Well, this is not a useful signal. Even with debugging on, the message I got was that the driver couldn’t be loaded. Pretty vague. It turned out the driver wasn’t even present on my system because I didn’t have the RPM installed. This is a condition that the printing system should have been able to detect and inform me of.

The failure here is there was no mechanism built into the system for passing back useful error messages to the user. If there was a useful message at some point, it was discarded before it reached me. Don’t write software like this.

GovTrack’s Insides

I wrote an article about how GovTrack’s website works on the inside. The summary is:

Websites have some of the same design issues as programs. One common issue is how to avoid duplication, but while software developers have solved this issue with functions, website developers are still struggling for a solution. GovTrack.us, my new website, solves this problem using XSL transformations and the Mono framework.

In the interests of full disclosure, I wrote the article just so it would be blogged on Monologue, which it was, so I’m happy. Thanks, Miguel!