I just blogged about this problem I was having with Gallio/MbUnit. I don’t regard the issue as fixed, but I’ve certainly worked around it.

I found that the delay happened when the tool Gallio.Utility.exe was being run during the startup process of Icarus. I noticed that the same thing happened when I tried to run other included tools like the control panel, and it also happened when using TestDriven to run an MbUnit test from VS. I had the impression that the tool was being run multiple times, but that turned out to be a mistake – the tool was simply running for a rather long time, jumping up and down a bit in the task manager list. I finally ran the tool on its own and found that (a) it has something to do with the plugins that Gallio apparently uses (for purposes unclear to me, I have to admit) and (b) even to just run the tool and display the usage info message in a console, it takes 25 seconds or so.

So, simple solutions are sometimes the best: I deleted Gallio.Utility.exe. Next run of Icarus, it was restored. Okay, MSI is more cleverer than I. Or so it thinks – I went and configured the file access permissions on the file and removed all access permissions. Hah, take that, MSI. Next run, Icarus comes up within about 3 seconds, taking another 2-3 to load my test assembly. Hah!

Running a test through TestDriven from VS takes about 3.9 seconds now, so it’s at least 2 times slower compared to running the same test through the CodeRush test runner. Weird, but then who am I to complain.

Now, could somebody please fix that Utility program before I end up needing it for something?

I just started playing with MbUnit, or at least that’s what I had in mind – found out then that it comes in that Gallio package these days, with all sorts of stuff on board that doesn’t all have a clear purpose. Clear to me, that is. Well, I think at this point that I would prefer to have a simple package comparable to NUnit, but maybe when I see what’s in there, I’ll change my mind.

Anyway, so far, so good – I took a small test project with five tests in it, which was working with NUnit so far. Threw out the NUnit references and added MbUnit ones instead. I went for MbUnit as well as MbUnit35, since the project uses .NET 3.5, and I found I also had to add Gallio in order for everything to build. Then I ran my tests using the CodeRush Test Runner, and everything behaved exactly like before. Brilliant! All five tests run through in about 1.6 seconds, for future reference – roughly the same as I got with NUnit.

For some reason I had the idea to look around a bit, and I ran one of my tests through TestDriven.NET, which I’ve also still got installed (I mean in addition to the CodeRush thing, which I really use most of the time these days). And there’s a surprise: it took almost exactly 60 seconds (!) to run the one single test!

The process had two stages, which seemed to take roughly an equal amount of time. Stage one is up to the point where the Test tool window in VS says “Initializing the test runner. … Running the tests", and it took about 33 seconds. The stage after that is when the test actually runs, and it took about 27 seconds. Wow. Now, stage 1 must have had something to do with first-run initialization, because on subsequent runs the time of stage 1 is now down to less than a second. The time for stage 2, however, is still the same as before, comes up with about 27-28 seconds every time I try it.

Obviously I was glad to have the CodeRush runner, but then I thought it might be interesting to see the standard runner that’s included in the package. It’s called Icarus, and here’s surprise number 2: that thing is equally slow! I’ve now started it a few times, so I guess it’s now faster than it was in the beginning. I just did a rough test, and it takes almost 30 seconds for the UI of Icarus to even show up on screen. During that time, I can see in task manager that a process called Gallio.Util.exe (or is it Utility?) pops up many times and goes away again - no idea what the … thing… is going on there. Well, when the UI finally comes up, a progress bar dialog appears, telling me that the program is now exploring my tests. It moves to 49% pretty quickly, then hangs around for >20 seconds before finishing after an overall 25 seconds or so. Phew.

This is the same 5 test assembly I was using before. So, final test: run everything. The progress bar at the bottom of the window comes up to 53% very quickly, then stops. After a good while it continues and makes its way up to the top. Overall outcome: rather close to those 27-28 seconds I got from TestDriven.

Okay, this is the weirdest thing I can imagine… I don’t suppose there’s anything intentional about all this, but I can’t imagine what the problem is either. Why do those delays happen? How does CodeRush manage to run the tests without the delays, something that neither the much more mature TestDriven nor the standard runner can do? Very odd. I might go hunt around for the right place to report a bug on this etc etc. But who knows.

Update: I added a bug report here

Another update: I just notice that running the Gallio Control Panel app shows the same startup behavior as Icarus – takes forever, with that Gallio.Utility.exe thing popping up probably ten times or so. What sort of a weird application architecture is this? Hm…

Whoa: Sorry for all the updating :-) But this is interesting… I thought I’d see what the Utility thingy even did, so I ran it just like that. Comes up with a console window, and, well…. does absolutely nothing for a really long time, perhaps something like those 30 seconds long. I had enough time to read the helpful output in the console and think about it, before the window suddenly closed because the program was finally done doing nothing. I thought it was waiting for a keystroke by then :-)

In case somebody’s interested – I’m running in a VM with 2GB RAM, 2 cores available to the VM exclusively. Windows 7, VS 2008 and 2010 RC installed, working in 2008.

It seems to turn into a shoot-out: listing directories is suddenly en-vogue! :-)

So, Craig Andera posted this code in written in Clojure, which lists some directories lazily, and Chris Sells thought he could do that in C#, too.

I thought these code examples all look rather verbose – in the case of Clojure because in that way rather typical for Java, the APIs are pretty verbose to use, and in the case of C# because of all the syntactic, well, ahem, necessities, as well as the fact that there’s no language feature for integrating nested sequences seamlessly.

Keeping it nice and simple, in F# that example can look like this:

open System.IO

let rec GetDirectoryDescendants(path) =
    seq {
        yield! Directory.GetFiles(path)
        for subdir in Directory.GetDirectories(path) do
            yield! GetDirectoryDescendants(subdir)
        }

For one thing, this code only contains what’s needed, like the Clojure code does – no namespaces, class declarations, loads of curlies, …. nice. Second, the “yield!” statement. There’s also “yield", without the “!", in F#, and the difference is that while yield returns a single element for inclusion in the sequence, yield! takes an entire sequence and returns it one by one into the “upper level” sequence.

You could argue that’s the same thing the C# code does as well, and you would be right, in a way. But the F# way is much shorter, more concise, and the code doesn’t break down again to the level of the sequence element. Functional languages like these things – by using map instead of a for(each) loop, you have a well-known pattern to apply, and the reader of your code has to read less to see what exactly is going on. In the same way, by using yield! it is obvious what I’m doing without finding the code inside the foreach loop and confirming that all it does is, again, yield.

I thought I was being pretty cool with this code:

IEnumerator<t> System.Collections.Generic.IEnumerable<t>.GetEnumerator( ) {
  Action<unbalancedbinarytree <T>> yielder = null;
  yielder = t => {
    yielder(t.Left);
    if (!t.IsEmpty)
      yield return t.Value;
    yielder(t.Right);
  };
  yielder(this);
}

But as it turns out (and I think I knew before, but had forgotten), C# doesn’t accept this. Not in 3.0 at least, and I think not in 4.0 either. Need to test. Meanwhile – why? Hm…

… or maybe this is not a recent change at all, I don’t really know.

Long ago I blogged before about the ways Google misunderstands me, and nothing has changed on that particular count. Today I noticed that there’s a new way Google intentionally misinterprets my query. Weird.

So, I was searching for Comparer<t> (try it yourself). Right at the top of the page, Google says this:

Showing results for Icomparer<t>. Search instead for Comparer<t>

Brilliant, eh? I’m starting to think it would be good if Google could have a programmer’s mode or something. Actually, just call it a “accept my queries as they are please, I now what I’m doing” mode. I can’t even guess why it’s doing this thing with Comparer<T> – once I click that link in the prompt, there are several results with that precise string in the page title. The URL changes to this, btw:

<a href="http://www.google.com/search?hl=en&amp;q=Comparer%3CT%3E&amp;nfpr=1">http://www.google.com/search?hl=en&amp;q=Comparer%3CT%3E&amp;nfpr=1</a>

That nfpr parameter seems to make all the difference.

So maybe bing doesn’t have that problem? No, it doesn’t. But then it doesn’t try to suggest anything on that search string either, so I guess somebody could call this a missing feature instead. Oh, and bing doesn’t solve that old problem with “special” characters either – they seem to have established a special case for the term “.NET” (surprise surprise), but searching for something like “.text” or even for help on regexes with “.+?” fails just as miserably as ever.