3070.1

That's the cycle odo at the end of the month, well over my stretch goal for the month of hitting of 3000. The question now is how far over 3100 by the end of the year.

And then to see what I can do by the end of next June : in order of difficulty, 2000 miles in the year, to 4000 recorded, to 1000 miles in the half year.

F# -- where has our Roslyn been?

The big thing about the new Roslyn CTP is that it's a C# compiler built in C#, so accessible simply from C# code via a standardized set of APIs; including ones that permit parse tree rewriting (and hence DIY language extensions) as well as giving a more official mechanism for such things as source-level inspection (e.g. StyleCop). Indeed, the lack of any such managed language service for VB is a reason that there's no StyleCop equivalent for the other major managed language.

F# has had the managed compiler from the start -- but presumably (as I've not noticed anything being done with it by way of meta-programming or suggesting coding conventions in the manner of StyleCop) not the suitable APIs. There is a project or several here for someone to take up.

F# under the covers XIV -- Match expressions : Does my complexity look big in this?

The code generation in F# in debug builds is fond of adding plenty of extra branch points that will confuse any naive computation of code complexity based on counting branch instructions at the IL level. Let us take the innocent method

The instructions that map to the match alist with context include

where the first branch could be replaced with a brfalse.s IL_0044 and the code at offsets 0xb, 0xc replaced by nops with no change in the semantics -- but as given it adds an extra cycle to the flow of control graph, and hence false complexity.

The release build of the code retains the first two instructions, but then rather than jumping to get and return an empty list, it in-lines that fraction of the code. If we look at it in C#, the release build looks like

where the debug version has a goto in that if clause that jumps to a statement that returns the empty list.

As an aside, it's also worth noting that nowhere in the .pdb information is there a map to any of the match expressions : there is never a source context which matches the | h :: tail -> or | [] ->; it's all collapsed into the match ... with fragment.

For more complex match expressions such as

the debug IL organizes into trying each of the branch criteria in turn, then jumping ahead to the matched expression; this ends up with a series of redundant branches like

culminating in a final triple burst

whereas the release build treats it more as an if..elseif..elseif..else construct.

As I noted yesterday, this means that there can be a factor of at least two difference in the naively computed cyclomatic complexity of a method depending whether the release or debug build is chosen.

Computing cyclomatic complexity with PowerShell and FxCop

A measure of the cyclomatic complexity of a .net method can be gauged by counting the number of IL branch instructions that do nor branch to the next instruction, and which have a distinct target from any other branch -- this is essentially the algorithm used in NDepend 1.x to make the computation. The introspection mechanism of FxCop provides enough decompilation of the IL that getting the instruction type and offset, and the target offset of a branch. An actual FxCop rule, though feasible to write, however, would be less useful than one could hope.

For one thing, FxCop itself doesn't provide any convenient way of passing parameters to custom rules (to e.g. set a trigger threshold); and for another, any analysis is likely to be run over a debug build (DEBUG and CODE_ANALYSIS variables defined there to not contaminate the released code with [SuppressMessage] annotations), which is likely to have a different underlying complexity to a release build (this is especially true in F# debug builds where there are a lot of sequences that look like

which can be replaced by

which, as it turns out, is pretty much what the release build does.

A more configurable and flexible way of performing the operation is to drive the FxCop facilities from a script -- these days I'm doing a lot of my .net scripting in PowerShell, but it could equally well be done with IronPython or similar .net scripting language. The result looks like this:

and running it over a set of F# code shows that the reported complexity of the release build of a method halves (or more) what is reported for a debug build. I haven't made a comparison over an significant amount of C# as yet, to see how much complexity the compiler removes between the two configurations.

End of Season Cycling

View Autumn 2011 in a larger map

The autumn having settled to being bright, mild and breezy, a last chance to have a cycle break before winter -- indeed I was apparently the last customer of the season at Suffolk Cyclebreaks; going through the south of Suffolk and the north of Essex, which I haven't done as much as places further north in the region.

An early start on Sunday took me most of the way past Ipswich by shortly after midday; though having been pointed at the restaurant at Wherstead Hall, I'd aimed for that, rather than again to the Butt and Oyster at Pin Mill, taking the bridlepath past Jimmy's Farm to cut the corner, and only have to do a little way along the main road until diving off into Wherstead village. The concrete track past the church brings you to the "hall" -- a large modern building, housing a local produce market, garden centre, and restaurant serving locally sourced food -- for me, a cheeseburger with local beef and cheese, plus a bottle of the local lager.

A14 bridge over the Orwell

From there, I carried on along the coast, deciding as the hour was advancing (past 1:30, but in the low sun, feeling later) not to detour to the Butt and Oyster for more beer; but carried on, until suddenly happening upon the Baker's Arms at Harkstead, which advertised food still being served, let alone beer, so had a pint of Wherry, before carrying on. The official route as I took it last weaves a long way to fit through crossings of the Stour and the A12. This time I decided that being a quiet Sunday afternoon, the main road through Manningtree would be a simpler route, arriving at Dedham by 4pm -- and the Sun Inn was open, and serving amongst others, Arizona Bitter (Phoenix Brewery) and Wolf Bitter (Wolf Brewery). Thus fortified, I reached Milsoms (which in the last three years has realised that it makes no more sense to charge separately for wifi than it does for hot water).

Dinner was bresaola, king prawn and green mango curry, and lemon cheesecake, with lots of mineral water; and then with the windows closed in the cool night, not even the steady drone of traffic on the A12 disturbed me.

Morning, fortified with a full English, etc, I decided to avoid the rather unpleasant country between Dedham and Stoke-by-Nayland, and head rather directly to Hadleigh (where I got tricked by the cyclepath again), pushed up the long grind after crossing the A1071, then with most of the pubs mentioned in the guide being closed Mondays, struck straight cross country to Sudbury (cadging a coffee from my surprised parents), before taking a loop west on the way to the night's rest at Lavenham.

Partly guided by the OS map's PH markers, I struck through Glemsford, to find the first two pubs closed at lunchtime, and as it was close upon 2pm, I was despairing of finding a place to pause, when suddenly, the Cherry Tree Inn "Open all day for quaff and scoff". There was one other customer there when I went in, but more regulars drifted in as I committed a couple of pints of shandy, and I ended up joining in the attack on the Times' crossword.

Then when I could justify hanging around indoors on a glorious sunny afternoon no longer, made the last leg to Lavenham, parking up at the Angel. I took a bit of a wander around, including a pint at the Greyhound (where a greyhound wandered out from behind the bar and looked for attention), before dining at the hotel -- potted duck with Agen prunes, shepherds' pie with peas and spinach, then the cheeseboard; which I was ready for, having not actually felt the need for lunch.

The rain, which long range forecasts had suggested might wash the whole holiday out, went over in the night, leaving it somewhat raw but otherwise fair cycling weather in the morning. Approaching Gedding, there were some diversion signs, and I saw that the route I was planning to take was marked as road closed. But then I saw that the other end of the closure was a few yards away, and between, just a fenced off hole with more than ample room to cycle past; so I went on as I intended, until just after midday, when the Brewer's Arms called.

A burger of local red poll beef, and a pint later, and the sheet of cloud that had been hanging overhead all morning gone, I decided to amble north of the A14, then loop through the lanes back to Alder Carr farm. This time I ran into a rather more serious road closure on the approved route, but fortunately I could back off and take a separate cycle path through the new development.

And then, shortly after crossing the A1120, a sudden rattle rattle pop! as a bulge near the valve on the back wheel finally wore through and the inner-tube burst spectacularly. At least it was warm and sunny, and the road quiet, as I replaced the inner tube, moved the tyre around, and pumped up to do the last couple of miles. I suspect the tyre may be a little narrow for the wheel, as the new tube is also bulging in the same way. Still, now it'll soon be past the end of BST, and cycling to work, I can put it in for a service and get everything replaced that needs it.

With all this under the wheels, my odo is now well over the 3000 mile mark, getting me well past my stretch goal for the month.

2908.4

Back at the end of June, I was hoping to have managed another 1000 miles on my bike by the end of the year.

Tonight getting home, on a clear if breezy day, the odo was showing 2908.4, or 1001.6 miles since then. The question now becomes whether I can roll it over the 3000 mile mark before the end of the month, let alone the end of the year!

Harnessing the PowerShell command line parser in .net

One of the annoying niggles about the .net framework is the lack of an intrinsic command line parser -- yes, there's Mono.Options or the F# power-pack, but they're not always just there to hand. PowerShell is there on Win7 and up, and is likely to be there on machines with older OS versions in a suitably technical environment, So if you just want to whip up a simple command line tool, and you're not writing it in PowerShell, why not at least borrow its features?

First, we want to get the argument list as provided -- for this we have to get the semi-raw line via Win32 (semi-raw as the shell will already have processed escapes -- in PowerShell that means that backticks, semi-colons and double-dashes are significant):

This uses the PowerShell tokenizer to strip out the executable name. We also want to be able to describe what the command line parameters are like, and other usage text

Then we can build a PowerShell function that takes the parameters we've defined, and just places them in a hash : this is the meat of the exercise

For producing a usage description, we can ask PowerShell for one, flatten it to a sequence of strings, and then strip out the unwanted PowerShell-isms

Finally, we can parse a supplied command-line, writing a failure reason and usage info if things fail

A simple example driver would be

There are some quirks -- Mandatory positional parameters and arbitrary nameless options don't mix : the current example program if given a command line "-Val hello -N 23 -S a b c" will yield

"$args" -> [|"a"; "b"; "c"|]
"ValueArg" -> "hello"
"SwitchArg" -> True
"NextArg" -> 23

Make NextArg mandatory, and instead it goes

A positional parameter cannot be found that accepts argument 'a'.

NAME
    ConsoleApplication1.exe

SYNOPSIS
    This is the synopsis

SYNTAX
    ConsoleApplication1.exe [[-ValueArg] <string>] [-NextArg] <int32> [-SwitchArg]...

So, perhaps not industrial strength; but suited to gentle use when there's nothing else to hand.

Links for 9-Oct

The world has moved on, have you? Xml APIs you should avoid using. (Microsoft XML Team's WebLog) -- tl;dr = XmlText* classes should be retired in favour of objects minted by Xml*.Create() factories.

5 Awesome Free jQuery Plugins -- toast, sliders, tickers...

What you see vs what you get : matching source and IL with Mono.Cecil and PowerShell

Following on from yesterday, looking at how Mono.Cecil pairs up debug information in the .pdb file with just the sequence points the IL -- which follows the approach taken by coverage tools such as dot-net-coverage. The code is much the same as before:

with the addition of the line/column data in SequencePoint ("null" if the values are not given, "0xfeefee" for the well-known compiler generated fake line number).

Launching PowerShell 2.0 into .net4 via F# Interactive or IronPython 2.7

With .net4 being 18 months old, and the Win8/PowerShell 3.0 being both in CTP and only for Win7+, it's a drag having to do things with .net 4 code when you really could do them faster and better in PowerShell. So, why not bootstrap ourselves from out of the box PowerShell 2.0 into the .net 4 world with a little help from another scripting language which is .net 4 aware? This saves messing about with environment activation variables, centralized registry settings or application config files, and takes advantage of the fact that PowerShell, like other scripting languages, can be hosted by another .net process.

The recipe is based around Bart de Smet's Option 2 – Hosting Windows PowerShell yourself.

Via F# interactive:

Via IronPython 2.7 (augmented to take command line arguments via the -Options parameter):

Since we can't pipe into Start-Process, the inner script is written to a temporary file; and then the initial PowerShell process waits so that it can safely delete it. If you would rather, it's reasonable to save the script to a constant .fsx or .py, replace $source with the path to that file, then the -Wait and Remove-Item -Force $source can be removed.

Replacing the fixed command line arguments for the F# interactive launched PowerShell with ones input to the script as per IronPython follows the same pattern. In either case, care has to be taken with getting your quotation marks right, and the IPy example is rather rough-and-ready. Besides, doing appropriate quotation parsing and escaping would obscure the real point of the exercise.

Note: Launching PowerShell directly from the .net4 command line launches PowerShell in the plain old .net 2 configuration; it is, alas, not sticky.

Note: These scripts are intended to give you a .net4 based interactive session; an alternative approach aimed at running individual commands can be found on Jason Stangroome's GitHub.

What you see vs what you get : matching source and IL with FxCop and PowerShell

The mapping between the code you write and the object code that gets generated is not always a simple one; F# code in particular is heavily restructured in the compilation phase. So when trying to perform code analysis to detect source level artefacts in the compiled code, some guide is useful to navigate between the two representations.

So, here is a PowerShell script to do just that, looking at the IL instructions or logical statements for a method and the corresponding source code as given via the .pdb debugging information -- PowerShell rather than F# interactive because the former has a much nicer user interaction model, especially when asking the user to resolve which overloaded method name was really intended.

As the script writes rich objects in the successful output to pipeline, it can be used as a starting point for further analysis; or the output can be piped into e.g. Out-GridView for inspection.

Summer at last

So, we get the hottest days of the year at the start of October : it's like summer was put on back to front, going from warm, to April showers, to autumn, to high summer.

After clocking up to ~2705 miles in Q3 -- 800 miles in the quarter -- I took a ~40 mile spin on the bike yesterday, with lunch at the Carpenter's Arms in Gt. Wilbraham, then carrying on out past Six Mile Bottom, West Wratting, Balsham and back. With the lack of wind, and low humidity, it was a beguilingly easy ride (apart from the long grinds up out of Six Mile Bottom towards Brinkley; and from West Wratting to Balsham). So easy, that it wasn't obvious quite how much I was sweating, and thus how much I needed to rehydrate, until I finished a 75cl bottle of Lucozade Sport in pretty much one gulp.

In the evening, it was still so warm that we sat out in the garden until well after sunset, something that we never had weather for over the nominal summer.