Today I saw on the web the homepage of Jeff Relf. Of course that's just my personal opinion, but that guy has a really weird visual setup in his Windows! The first thing I saw was this shot of a Visual Studio window (click the image for the full-size version):

(I downloaded this image to my server to avoid creating too much traffic for Jeff. The original source is here.)

If you like what you see, on the web page you can find a user stylesheet for Firefox that'll make web pages look just the same!

Peter Golde has published a note on his blog about the new MSDN TV video on Power Collections.

In the interview, Peter talks about the genesis of the project and various design decisions and he gives an overview of the library structure and the differences between the various collection classes. The whole project is kind of a collaboration between Peter, people at Microsoft who've helped launch the whole thing and a community built around Peter's blog and the PowerCollections forum.

One thing that Peter specifically talks about is the BigList class (see also this post). This is a class with a similar interface to the standard List class, but it's optimised to work efficiently with large lists, especially for operations like insertions, deletions, copies and concatenations. Peter explains the inner workings of the BigList in detail in the video.

Personally, I've been using PowerCollections for a while and I think it's certainly to be recommended as a well thought through collection library. I've also had my problems with parts of the design, but nothing insoluble... plus, PowerCollections is not yet final so some problems have to be expected.

I thought I'd pass on a collection of links to articles on debugging I've read today. Much of this is not new, but I guess I'm not the only one who doesn't feel the need to use additional debugging tools every day... meaning apart from those that are integrated in the IDE. I used to do much more of that when I did more development for Linux, but right now the VS integrated debugger is the only one I've been using for a while. I guess that may change, though, because I'm really positively surprised how much I've been missing! I advise everyone to have a look!

Here we go:

• Debugging tools for Windows download
• Fabrice's article Advanced debugging with SOS.dll, which made me have a closer look at this.
• Several articles on Mike Taulty's blog: A word for WinDbg, A word for WinDbg (2) and More on debugging with SOS.DLL - enter Visual Studio.
• An MSDN article by John Robbins: SOS: It's Not Just an ABBA Song Anymore
• Traversing the gc heap (and introducing PSSCOR.DLL) is an article about an extension to the SOS.DLL that has since been integrated in the default distribution.
• A Code Project article by Saikat Sen: Windows Debuggers: Part 1: A WinDbg Tutorial
• Another Code Project article by Toby Opferman: Debug Tutorial Part 4: Writing WINDBG Extensions
• Rico Mariani on Tracking down managed memory leaks (how to find a GC leak)
• An article by Dana Epp: Driver Debugging with WinDbg and VMWare

Update: The March 2005 edition of MSDN magazine has another article by John Robbins (see above): Mini Dump Snapshots and the New SOS

Yesterday, I moved my blog over to the new release 1.5 of WordPress. I had been using version 1.2.2 of WordPress previously, as packaged in Debian unstable. Now I wanted to use the downloadable version, to be more flexible in the future to do experiments.

The first problem I faced was that I didn't want to have any downtime while I was playing around with the new version, porting my theme and everything. So started off by cloning my complete WordPress database in MySql by dumping it to an SQL file (I do that every night for backup purposes anyway) and using that file to create an exact copy of the database. I also had to grant the database user I'm using for WordPress the same rights on that new database that he has on the old one.

I untared the new distribution into its own folder and created a wp-config that used the new database with the old user account. I created a new alias in my Apache config to access the new installation in its path, leaving the old alias untouched. I accessed the new URL and I could immediately see my old blog content in the new theme! The main problem was that all the links were still wrong because I hadn't yet changed the WordPress and blog address configuration settings, plus my old permalink structure wasn't there anymore. After a little bit of fiddling, I managed to access the management frontend of the new installation to change the settings and recreate the permalink structure (or rather the correct .htaccess file).

Now I created a new theme by copying the Classic theme folder to a new name. I copied my own style sheet to the new theme folder (calling it style.css) and added a header to it:

/*
Theme Name: Oliver
Theme URI: http://sturmnet.org/blog
Description:
Version: 1.0
Author: Oliver Sturm

*/

In my old 1.2.2 setup, I had made considerable changes to the index.php and also some small ones to the comments. With the old blog in another browser window, I went and recreated these changes in the new theme system. That wasn't very complicated, as the new files have mainly been split into parts. It's easily possible to recognize the old content in them.

In the old installation, I had also used several plugins, most of which I could easily copy to the new plugin folder. These are the ones that I could use without problems:

• Kitten's Spaminator
• The Polite-ifier
• Dunstan's Time Since
• WP SpamAssassin

The one plugin that had some problems was Syntax Highlighter Enscript, which relied on a specific formatting that the old WordPress version apparently applied to <pre> formatted text. This seems to have changed and I fixed the plugin for that (you can find the fix in this comment).

Two other problems I found were in WordPress itself. Firstly, something that hadn't originally worked in WordPress 1.2.2: private posts didn't appear in the blog, even when the user was logged on. I had at some time applied a fix for that problem to my old WordPress, but now I couldn't even find that fix any longer. I read a lot of articles in the WordPress support forums before I found the fix for this problem: adding a line saying get_currentuserinfo(); in line 501 of wp-includes/classes.php (right after the comment line saying // Get private posts) did the trick this time.

The second issue I found seems to be a bug in WordPress. As you can see, my category list is shown as a hierarchical structure, with the child categories indented a bit. This specific layout suddenly wouldn't work at all in 1.5, and the categories appeared to be unsorted. After looking around quite a while for the source of the problem, I found it: the file template-functions-category.php has a problem around line 275, resulting in the fact that the hide_empty parameter must effectively be 0 (zero) for any of the sorting and hierarchical view code to work. I'm quite sure that this is a programming mistake and I'll go report it when I find the time. (Why do I have to register to post in the support forum? If it was easier to just drop someone a line, I'd probably already have done so.) At the moment, though, I worked around the problem by adding these parameters to the call to the wp_list_cats function in sidebar.php: children=1&hierarchical=1&sort_column=name&hide_empty=0. Problem is, now my test category is visible although it shouldn't be... That'll go away when there's a real fix in the future.

So, that's all. Oh, of course, I forgot: Finally, I switched the new WordPress installation over to be the active one. I simply changed the WordPress and Blog addresses once again and recreated the permalink structure. Then I switched the aliases in Apache around so the new blog would be the active one and voilá: one restart, no downtime at all, new blog software!

In this post, Dave Templin explains the purpose of the .vshost.exe that gets created automatically by Visual Studio Whidbey. What it also mentions is the fact that the application domain my code runs in is of course different when I run in the debugger. I found a problem with this where the FriendlyName is concerned.

I've been using the FriendlyName to construct names based on my application's exe name, the same way the normal app.config files work. The problem is, as soon as I run the app in the debugger, the FriendlyName is no longer the same and the config file that's already there isn't found. To solve this, I was looking for a way to find out the "real" base name of my application's exe file, without the vshost. part. Apparently, there's no special property or anything that would let me access this information directly... maybe that would be a useful extension to the System.Diagnostics.Debugger class.

The solution was simple for the moment: I used a regular expression to do a simple replacement on the string:

  string myName = Regex.Replace(AppDomain.CurrentDomain.FriendlyName, 
    @"(?<basename>.*).vshost(?<extension>\..*)", "${basename}${extension}");

Of course that's not a perfect solution, but as it's only relevant for a developer who may run the program in the debugger, it should be alright for now. Maybe they'll expose some more information about this to the running app in the future so it can behave a bit more intelligently... or I'm missing something :-)