Traffic report

So there are a couple of newborn lambs tottering around near the car this morning, and when I start turning it around, one of them makes the equation “large pale moving object = mother” and rushes in.  I get out to chivvy it out the way, and it has shoved its nose into the spokes of the passenger-side front wheel and is looking hopefully up into the wheel arch and waiting for milk to come out.

Intelligence: ur doing it wrong.

Fixing TeamCity errors in the Visual Studio experimental instance

The good people at JetBrains obviously think Visual Studio extensibility isn’t painful enough already, and the latest version of their otherwise nice TeamCity continuous integration server makes it positively excruciating.  The Visual Studio add-in for TeamCity 5.1 installs itself into the experimental instance as well as the main instance, and makes a complete pig’s ear of the debugging experience.  Not only does TeamCity fill up the debug window with endless first-chance InvalidOperationExceptions, making it hard to see your own debug output, but whenever you close a document window or Visual Studio itself under the debugger, TeamCity throws a NullReferenceException or InvalidOperationException and breaks into the debugger.  This gets very tedious very quickly.

You can’t remove TeamCity through Extension Manager or Add-In Manager, but there is an obscure dialog that allows you to ‘suspend’ it:

• Go into Tools > Options
• In the list on the left, select TeamCity
• Click the Suspend button
• Click OK

(This dialog is helpfully documented in the Resharper help file, the obvious place to look for TeamCity troubleshooting.)

As a parting gift, TeamCity will throw a few more spurious exceptions (“No application shell running.”  Er, yes it is), but after that you should be able to run the experimental instance under the debugger without getting bogged down in stupid errors.

Well, except the ones in your own code, of course.

Fixing the Server Explorer “The given key was not present in the dictionary” error

One of Visual Studio’s most cryptic error messages is Server Explorer’s infamous “the given key was not present in the dictionary.” This typically means that you’ve installed a custom data provider, created a Server Explorer connection using that provider, and then uninstalled the provider without deleting the Server Explorer entry.  This pretty much kills Server Explorer: from now on, any time you try to add or remove a connection, it barfs up the useless error.  This means you can’t even remove the dud connection.

The top Google hits for this issue recommend such brilliant solutions as creating a new user account and formatting your hard drive and reinstalling Windows.  Fortunately, you don’t have to go to such extreme lengths.

If you can guess what provider you might have installed and uninstalled, then you can reinstall that provider, delete all associated connections, then uninstall the provider once and for all.

If you can’t identify the provider, or can’t reinstall it, then you can go under the hood to remove the invalid connection.  Here’s how.

First, close all instances of Visual Studio.

Now, go into your user AppData directory (e.g. C:\Users\Alice\AppData) – note this may not be shown in Windows Explorer if you have “Show hidden files and folders” turned off – and drill down into Roaming > Microsoft > Visual Studio > 10.0 > ServerExplorer.  You’ll find a file in there called DefaultView.SEView.  This bad boy is where the connections are stored.

This is a plain XML file, so in theory, you can locate the dud connection by its Label and just remove the containing DataViewNode XML element.  In practice, I didn’t have much luck with this – the file stores blobs against connections by index, so deleting individual items can throw those indexes off.  But if you’ve got a lot of connections defined and you don’t want to have to recreate them, it’s probably worth giving this a try in case you get luckier than I did.

Otherwise, just delete the DefaultView.SEView file.

Then restart Visual Studio and party on.

Hat tip to Jason Short at VistaDB.

It has been that kind of a day

This morning I was doing one talk at TechEd New Zealand.

Now it looks like I’m doing four.

I believe the Civil Service vernacular is Transport Muggins.

F# pattern matching for beginners: index

This post provides links for the F# pattern matching for beginners series.

1. Getting started with the F# match keyword and some seemingly trivial but important patterns.

2. Decomposition of tuples and discriminated unions to pick out the interesting bits of data in each case

3. Guards allow you to inject custom logic into match cases

4. Lists and recursion using patterns

5. More useful patterns

6. Active patterns, a way to extend the pattern system with your own encapsulated reusable abstractions

The complete F# patterns documentation is here.

F# pattern matching for beginners, part 6: active patterns

I talked earlier about how you could incorporate custom logic into patterns by using guard clauses.  Guards are fine for picking out special cases from a more general match, but they have a few limitations.

First, as I noted, guards are opaque to F#.  So if you’re matching integers and have one guard for picking out odd numbers and one for even numbers, you still need a fallthrough case.  You know that the odd and even guards are exhaustive, but the F# compiler can’t prove it, so it demands a useless “any other” pattern.

Second, guards aren’t reusable.  If you’ve got some classifying logic that you want to use in more than one place, you’re going to end up with duplicate guards.

Third, guards are simple predicates: they don’t perform any decomposition the way that patterns do.  So if you guard checks for a particular piece of information, and you want to use that piece of information in the result expression, you end up duplicating the logic to extract that piece of information.

To address these issues, F# provides a way for you to define your own extensions to the pattern system.

Active patterns

An active pattern is a reusable function that can classify and/or decompose its input.  Matching against an active pattern runs the classification logic, and makes the results of the decomposition available for further pattern matching.

That sounds a bit abstract, so let’s look at a simple example.  Here’s another take on the hotpo function from part 3:

let hotpo n =
  match n with
  | Even -> n / 2
  | Odd -> 3 * n + 1

This is pretty self-explanatory, but where did those Even and Odd patterns come from?  They look a bit like a discriminated union pattern, but that can’t be right, because n is an integer, and an integer wouldn’t be matching against a discriminated union.  Rather, they are partitions of an active pattern defined as follows:

let (|Even|Odd|) n =
  if n % 2 = 0 then Even else Odd

The syntax of an active pattern is like that of a function, except that instead of a name, the active pattern has a list of partition names, separated by | characters and enclosed in banana brackets (the (| |) construct).  The body of the active pattern is just like a normal F# function, and must return one of the partitions.

Active patterns can be decomposing

In the example above, the even/odd pattern just classifies its input.  One of the nice things about pattern matching, though, is the way that patterns can decompose their input, extracting data that is useful to a result expression.

We can extend the even/odd pattern, for example, to extract the halved value of the even case.  (This is a rather silly example for simplicity; we’ll see a better one in a moment.)  To do this, we just pass the desired extracted value to the partition constructor:

let (|Twice|Odd|) n =
  if n % 2 = 0 then Twice (n / 2) else Odd

Note how the Twice case takes n / 2 as an argument.  This enables a Twice pattern to get at that halved value:

let hotpo n =
  match n with
  | Twice m -> m
  | Odd -> 3 * n + 1

How about a more realistic example?  The following active pattern matches .NET Type objects, and classifies them according to whether they are nullable types (in which it case it extracts the underlying type), generic types (in which case it extracts the generic type definition and the type parameters) or anything else.

let (|Nullable|Generic|Simple|) (t : Type) =
  if (t.IsGenericType) then
    match Nullable.GetUnderlyingType(t) with
    | null -> Generic (t.GetGenericTypeDefinition(), t.GetGenericArguments())
    | ut -> Nullable ut
  else
    Simple

We can use this pattern to crack open type definitions and format them in different ways:

let rec csharpString typ =
  match typ with
  | Nullable t -> t.Name + "?"
  | Generic (g, typeParams) -> 
      sprintf "%s<%s>" 
        g.Name 
        (Array.reduce (fun s1 s2 -> s1 + ", " + s2) (Array.map csharpString typeParams))
  | Simple -> typ.Name

Active patterns don’t have to classify

An interesting use of active patterns is to decompose a composite type without classifying it.  You can use a different active pattern depending on which way of decomposing the data is useful in the case at hand.

Consider the case of complex numbers.  A complex number can be represented in two ways: as real and imaginary parts, or as a modulus and angle.  The first representation is easier to work with when you want to add complex numbers; the second is easier when you want to multiply them.  By using active patterns, we can crack open complex numbers in different ways for different operations.

type Complex = { Re : float; Im : float }


// assume complexFromRect and complexFromPolar utility functions
 
let (|Rect|) c =
  match c with
  | { Complex.Re = re; Complex.Im = im } -> (re, im)
 
let (|Polar|) c =
  match c with
  | { Complex.Re = re; Complex.Im = im } -> (sqrt(re * re + im * im), atan2 im re)
 
let sum c1 c2 =
  match (c1, c2) with
  | (Rect (re1, im1), Rect (re2, im2)) –> complexFromRect (re1 + re2, im1 + im2)
 
let product c1 c2 =
  match (c1, c2) with
  | (Polar (r1, theta1), Polar (r2, theta2)) –> complexFromPolar (r1 * r2, theta1 + theta2)

The Rect and Polar active patterns don’t classify complex numbers into different partitions, but they do decompose complex numbers into values that are useful for different scenarios.  A similar example might be decomposing colours into RGB or HSB values depending on what you want to do with them.

Notice that an active pattern that doesn’t classify doesn’t need to return a discriminated type.  Rect and Polar both return tuples: we don’t have to prefix the return values with the case names the way we did in the Twice|Odd and Nullable|Generic|Simple examples.

Partial active patterns

Sometimes an active pattern doesn’t want to match every possible input.  A pattern which recognises and parses numbers from strings might match strings of the form “123” but not “xyzzy.”  You can create such a partial active pattern by specifying a wildcard (_) as part of the pattern name.

A partial active pattern can have only one non-wildcard partition, so it can only classify into “matches” or “doesn’t match.”  It represents the result as a F# option type, i.e. Some or None, rather than using the partition name.  Here’s an example:

let (|Integer|_|) s =
  match Int32.TryParse(s) with
  | (true, n) -> Some n
  | _ -> None

If you need multiple tests, you just have to create multiple partial patterns:

let (|Float|_|) s =
  match Double.TryParse(s) with
  | (true, d) -> Some d
  | _ -> None

And use them in the right order if they overlap:

let describeNumber s =
  match s with
  | Integer n -> sprintf "%d : int" n
  | Float d -> sprintf "%f : float" d
  | _ -> "call that a number? cos I don't"

> describeNumber "123";; 
val it : string = "123 : int" 
> describeNumber "456.78";; 
val it : string = "456.780000 : float" 
> describeNumber "bob";; 
val it : string = "call that a number? cos I don't" 

Parameterised active patterns

I described an active pattern as a function that classifies and optionally decomposes its input.  But what if your classification function needs inputs other than the value to be classified?  Our even/odd active pattern works fine for detecting multiples of two, but sometimes one needs to detect multiples of other numbers.  Of course, we could write similar active patterns for those other numbers, but these will be identical to the even/odd pattern except for a “multiple of what” parameter.  What we’d prefer is a way to parameterise the active pattern with that “multiple of what” value, so that we can write the active pattern once and just reuse it with different parameters.

We can do this by simply supplying additional parameters to the active pattern before the matchable input:

let (|MultipleOf|_|) (multiplicand : int) (n : int) =
  Some (n / multiplicand, n % multiplicand)

To use the parameterised active pattern, place the parameter before the pattern that is going to receive the match result – i.e. parameters go in the same order as in the pattern definition:

let toqpo n =
  match n with
  | MultipleOf 3 (m, 0) -> m
  | MultipleOf 3 (_, r) -> 4 * n + (3 - r)
  | _ -> 0

> toqpo 3;; 
val it : int = 1 
> toqpo 4;; 
val it : int = 18 
> toqpo 5;; 
val it : int = 21

Parameterised active patterns must always be partial (and consequently do not classify).  This is because an evil match expression could change parameters between cases, so that none of the supposedly exhaustive classifications ended up matching:

let (|ExactMultiple|RemainderedMultiple|) (multiplicand : int) (n : int) =
  if (n % multiplicand = 0) then
    ExactMultiple (n / multiplicand)
  else
    RemainderedMultiple ((n / multiplicand), (n % multiplicand))
 
// what happens when n = 6?
let ohNoes n =
  match n with
  | ExactMultiple 4 m -> m
  | RemainderedMultiple 3 (m, r) -> 4 * m + r

Rather annoyingly, the compiler will not complain when you define a non-partial parameterised active pattern; instead, it will emit a rather cryptic error when you use it.

Summary

Active patterns come in four related varieties:

• Multi-case, like our Even|Odd and Nullable|Generic|Simple patterns.  A multi-case pattern partitions the entire input space, and optionally decomposes it.  Different partitions can be decomposed in different ways.
• Single-case, like our Rect and Polar patterns.  A single-case pattern doesn’t classify the input, but typically decomposes it in a useful way.
• Partial, like our Integer and Float patterns.  A partial pattern matches a chunk of the input space, and optionally decomposes inputs in that chunk.  It doesn’t classify any further within that chunk.
• Parameterised, like our MultipleOf pattern.  A parameterised pattern does the same job as a partial pattern, but is, well, parameterised so you can reuse the pattern logic with different settings.

I’ve tried to keep things simple in this overview, but I’d recommend Chris Smith’s articles on active patterns if you want to see more in-depth examples of where active patterns really start to pull their weight.

Report on planet three

Perigo Minas: “The dominant life form is a sedentary plant group called ‘Grass’. The group comprises a number of individual species, who largely live separately in their own ethnic groups… While the presence of colonies across the planet indicate that in the past the Civilised Grasses have been willing to wage war on each other, most aggression has been directed at the Uncivilised Grass. In this, the Civilised species use their Human slaves to further manage beasts of war. Our Observers have recorded the use of large quadrupeds of a number of species, but mostly of the kind known as ‘Cattle’, to attack Grass in a most barbaric way.”

Yeah, I get this way too after reading The Extended Phenotype.

F# pattern matching for beginners, part 5: more useful patterns

In this part, I want to briefly mention some useful patterns that I haven’t covered in the previous instalments.  I’m not going to cover everything, but if you want to know more, the F# documentation contains a full list of patterns with examples.

Record patterns

In addition to tuples, F# supports record types, which have named members like C# or Visual Basic classes.  A record pattern is like a tuple pattern, but identifies members by name instead of by position.  It uses curly brace syntax, with semicolon separators if multiple fields are involved in the pattern.

type Person = {
  Name : string;
  Age : int
  }
 
let isBob person =
  match person with
  | { Person.Name = "bob" } -> true
  | _ -> false

> isBob { Name = "bob"; Age = 40 };; 
val it : bool = true 
> isBob { Name = "alice"; Age = 50 };; 
val it : bool = false

Obviously, you’re not restricted to a constant expression: you can use a variable expression to capture the decomposed values:

let getAgeIfBob person =
  match person with
  | { Person.Name = "bob"; Person.Age = age } -> Some age
  | _ -> None

Type testing

A type test pattern is like the C# is operator: it matches if the matched item is an instance of the specified type.  Its syntax is :? followed by the type name.  The result of a successful match is strongly-typed to the specified type, and you can use an as pattern to capture this strongly-typed value into a variable so you can access type-specific members.

let sizeof (obj : Object) =
  match obj with
  | :? int -> Some 4
  | :? string as s -> Some s.Length
  | _ -> None

> sizeof 123;; 
val it : int option = Some 4 
> sizeof "hibble bibble";; 
val it : int option = Some 13 
> sizeof DateTime.Now;; 
val it : int option = None

Note we could not have called Length on obj directly, because the F# compiler would complain that Object doesn’t have a Length property.  Hence the need to capture the result of the :? string pattern: the F# compiler knows that this is of type string, so it is safe to access the Length property.

Other patterns

For other patterns defined by F#, see the Patterns topic in the documentation.

But what if you have classification and decomposition logic that can’t be readily expressed using the compiler-defined patterns?  In the final part of this series, we’ll look at how you can extend the F# pattern system with your own active patterns.

Many worlds

John Gravois: “Google maintains thirty-two different region-specific versions of its Maps tool for different countries around the world that each abide by the respective local laws. Thus on India’s version of Google Maps, for example, all of Kashmir appears as an integral and undisputed part of the country—because Indian law sees it that way. Similarly, ‘Arunachal Pradesh’ is nowhere to be found on ditu.google.cn. What you find instead are all the same Chinese place-names that caused the uproar of Google Maps in August.”

Pass the crop circle palmistride, please

Crispian Jago: The Periodic Table of Irrational Nonsense.  Major groups include Dipshits, Fucktards and New Age Bollocks.  (Via Ian Randall.)