GMail and IMAP

Finally the people at Google have gotten around to letting people access their GMail accounts via IMAP, and finally my account has been enabled too (it took a few days). I've wanted this almost since the very beginning (for some 2 years ago), and I gather from the reactions around the web that I'm not alone. Google on "gmail imap" and you get some 6 million hits, many (of course) referring to GMail now getting IMAP support, but a sizable amount of hits are from before this and talk about how to get IMAP support for GMail in other ways.

Half-Life 2: Episode Two

I finally finished Episode Two yesterday. This time, I set the difficulty level to "hard" directly. When I've played the other Half-Life games, I've always started on "medium" (or even "easy", I think), but this time I decided to take the difficult route the first time through. And Valve really makes you earn your kills.

A fun thing about Episode Two (and Team Fortress 2) is there is a set of "achievements" (or sub-missions); such as breaking every web cache in the caves, killing all the antlion grubs, etc. There is also a fun achievement involving the gnome you find at the very beginning of the game.

The first really tough part was trying to kill two Antlion Guards. You don't have enough ammo (even if you've fully stocked on the shotgun and the MP5) to take them out, so you'll have to be a little creative with explosive barrels and other things you can shoot at them. To make things more fun you have the antlions to worry about too.

The second fun part was the helicopter battle where you desperately try to find a rocket launcher just to realize that there isn't any. The point is to take it out by taking the mines it drops and throw them back at the helicopter. Ah, the joy of crawling around and being shot at by helicopters!

Then there is the Hunters. The first time you encounter them is when Alyx is injured, but the first time you have to take one out is later on when you and Alyx are attacked by a pack of them in a farm house. Also a fun scene, where you have to be a little creative with the gravity gun.

Then there is the final battle. You've reached the White Forest rocket base, but it's being attacked by Striders. And not one, two, or three, but at least 8 or 9. I didn't keep count. This is where the real fun begins. And to make it even more challenging, each Strider is escorted by 2 or even 3 Hunters.

This game is nothing less than a masterpiece. And you haven't really played it until you've played it with the difficulty set to "hard".

Xcerion

Xcerion is a new Swedish startup which is working on a "internet operating system", something which runs entirely inside your webbrowser. The market-speak on their website gives the impression that it will revolutionize the computer industry and bring down Google and Microsoft and the same time. That is, of course, not true. They will be absorbed by either long before that happens.

I tried to get some hard details about what they're actually doing, but details are scarce, and any information I could get hold of is full of market-speak. Things like the following sounds like something Dilbert's boss would say:

"Given that everything is defined in XML creates enormous synergies and unleashes the innate power of XML,"

I'm not sure why they push XML so hard. XML is an underlying code/data representation, and will not cause any magic to happen by itself. XML may very well be the best choice of a representation, but it is not a silver bullet.

The fact that all applications are written in XML rings a big, fat, warning in my head. We've heard several claims over the last 20 years about new technologies which will render "traditional programming" obsolete, but we're still here writing code in C++, Java, Erlang, Ruby, Python, etc. What's the common denominator of the 20 most popular programming languages today? Their source code is written using text editors. Yes, some text-editors are most advanced than others, but we're still writing code. Practical, general purpose point-and-click programming won't be here for years.

XML is not designed to be human-editable. This forces you to have top-notch graphical editors on top of everthing, and that is not an easy task. Many have tried and failed (the Eclipse plugin.xml editor is a good example; it is not a bad editor, but it doesn't scale very well for non-trivial XML).

But then again, if Xcerion can deliver on their promises and replace the traditional desktop OS with a system which is light-weight, fast, runs everywhere, and fun to program (sort of like on the old Amiga days), I'm all for it. But I can't help but feeling sceptical about the whole thing.

Xcerion, please prove me wrong.

San Andreas

What do you play when you're waiting for Half-Life 2: Episode Two to be released, when Team Fortress 2 takes forever to load, and when you've completed Half-Life 2 with difficulty level set to "hard"? Well, you can always dig up Grand Theft Auto: San Andreas, and try to get a little closer to those 100%. After cruising around in San Fierro for a while and destroying a motorcycle I found my way to the Blood Bowl race, and decided to give it a try. It's quite hard, and after 20 attempts or so I managed to hold on long enough for the other cars to destroy themselves, making it a little easier to get to the checkpoints.

The lesson here is: there is always something to do in San Andreas.

Writing a toolchain plugin for CDT (or: things not to use XML for)

I'm currently in the process of implementing support for a compiler toolchain for Eclipse/CDT. This means writing a large chunk of XML code describing how the toolchain works (what tools there are, what kind of inputs they take, what options they take, what build configurations are available, and so on). A typical standard thing to do when you want to use CDT with a compiler other than GCC.

Eclipse/CDT is very flexible when it comes to supporting other kind of toolchains; anything which can be broken down to a series of external programs which which interact to produce output from a given set of inputs. You can implement a toolchain for creating PDF files from LaTeX input, although this has little to do with C/C++ development. This great flexibility is actually the first warning flag. Yes, flexibility is a good thing, but the user's have to be able to wield it as well.

Most of the toolchain is defined in the plugin.xml. This is where all tools, configuration, projects type, options, etc. are defined. This is actually the second warning flag. My plugin.xml is at 2000 lines and counting, and I haven't really done anything complicated. A bunch of options, two different project types, two build configurations, and 4 tools (c-compiler, c++-compiler, linker, assembler). Yes, I could probably break out much of this in separate plugins, but that seems a little overkill.

CDT has a system for inheritance among elements in the toolchain definition file. I can define a common base class for my C and C++ compilers, and define C++-specific options in a subclass. What CDT does is basically to paste a primitive inheritance system on top of XML. It works like this:

<option
  id="com.foo.bar.option.parentOption"
  isAbstract="true"/>
<option
  id="com.foo.bar.option.subOption"
  superClass="com.foo.bar.option.parentOption"
  ... />

This may sound great at a first look, but it quickly turns out to be hopelessly inadequate. It's ok to do small things this way, but when you have three different tools with similar set of options you need a way to be able to share these in a more flexible manner.

One of my favorite programming principles is DRY: Don't Repeat Yourself. While writing CDT toolchain definitions you have to break this rule so many times, it's almost physically painful. For example: each XML element has to have a globally unique identifier, and it has to be specified in full in the element itself. In the plugin.xml file which contains my toolchain definition, 25% of the lines includes the reverse-DNS name ("com.foo.bar.plugin", for example) used to make sure that the identifier are globally unique.

There is an option for my compiler which takes 20-30 enumerable values (the target cpu type). To specify this, I have to write an XML element for each of these values:

<enumeratedOptionValue
  command="--cpu FOOBAR1"
  id="com.foo.bar.plugin.toolchain.compiler.generic.option.cpu.FOOBAR1"
  name="FOOBAR1"/>

Instead of allowing me to have a simple list of all cpu types and generate each option, I have to manually (cut-n-paste) expand the enumeration value definitions.

I think it would be better to write the toolchain definition in Java instead. The idea of defining things in the plugin's plugin.xml file is to let Eclipse know things about plugins without having to load the plugin itself, but does this include details about which options my compiler takes? If plugin.xml just defined the entry point classes for my toolchain in the plugin.xml file, I could define the toolchain by creating the appropriate Java objects. This would allow me to use the full power of Java's inheritance system and I can store option metadata (such as the number of available cpu types) in a way most suitable for my needs.

Heroes

I've been catching up on the first season of Heroes (the first seasons
airs here in Sweden on TV4 twice a week), and I must say that it is
the most intriguing TV-series I've watched since the first season of
24. The combination of a compelling story arc and superheroes (without
tights!) makes for very enjoyable TV, especially when most other
programs are some form of reality-tv (home makeover shows, American
Idol (or the swedish equivalent), etc.) which I really can't stand.

And I like the more or less subtle references to Star Trek (there are
more than just Hiro doing the Vulcan salute).