The importance of API design

Reflecting on the exercise leading up to yesterday's post, one of the things that struck me in the comparison of the .net Framework used from F# and the Java APIs available to Scala/JVM was how much the former got little details right to facilitate working in the web-page embedded context. Take the simple task of getting at the URL query parameters for the page in which the applet is embedded

In Silverlight, in the main UserControl class:

In an applet, where peer is the Applet instance:

Perhaps this just shows how the old-style Java applet has withered on the vine, while Silverlight as a competitor to Flash has taken on a more aggressive stance for developer acceptance -- but with the decade-plus that Java has under its belt compared with Silverlight's barely more than a year (1.0 not really counting), the comparison is rather disappointing.

I shall have to investigate whether the continued work on scala-msil has led to any material improvements in its robustness since I looked at it last, six months ago.

A few minutes later

Well, my six month old port of the Scala actors package to pure Scala calling the .Net APIs still blows the compiler up in a Scala 2.8 nightly that's just a few days old. The explosion is in pure Scala code taken directly from the 2.7.5 actors package, and not the Scala-calling-.net replacements I coded of the Java parts of that package:

object Eval$2
  symbol = final case  object Eval$2
  owner  = final  object Futures
with methods = List(scala.actors.Futures.Eval$2., scala.actors.Futures.Eva
l$2.readResolve, scala.actors.Futures.Eval$2.canEqual, scala.actors.Futures.Eval
$2.productElement, scala.actors.Futures.Eval$2.productArity, scala.actors.Future
s.Eval$2.productPrefix, scala.actors.Futures.Eval$2.toString, scala.actors.Futur
es.Eval$2.productElements, scala.actors.Futures.Eval$2.productIterator)
Exception in thread "main" java.lang.RuntimeException: ILGenerator.emit(): Stack
 underflow in method: public static System.Void scala.actors.Futures$+scala.acto
rs.Futures.Eval$2$::.cctor()
        at ch.epfl.lamp.compiler.msil.emit.ILGenerator.emit(ILGenerator.scala:48
7)

So, still not ready for prime-time.

Anime — Aoi Hana (Sweet Blue Flowers)

A quiet little story of school-girl romance, very sweetly done; and with a delicate and restrained art style, presumably heavily post-processed photographs in the main. The story follows childhood friends Fumi and Akira though Fumi's first romance with an older and generally very popular pupil from her school, and the messy break-up that follows. But even through that, all the characters involved are just all-around nice -- no real catty or bitchy episodes (unlike the superficially similar schoolgirl story in Marimite, with the insufferable Touko-chan).

Based on an on-going manga, it ends like a chapter ending rather than the tale being all told, but for all that it comes to a satisfying conclusion. Alas, poor DVD sales means a second series is unlikely -- which is disappointing as it's one of the better shows in what has been a dreadfully thin year for new anime.

Presumably there aren't enough trainspotters to buy it on the strength of the many railway scenes during Fumi and A-chan's commute to their adjoining schools (if Aria can be considered scenery porn, this verges of the train porn at times).

---

Sample frames and a YouTube link removed following DMCA complaint. If the buggers can't understand fair use quotation for purposes of review, then my recommendation would be to not reward them with any of your hard earned.

A quick Scala gotcha

Wouldn't it be nice, I thought, to be able to put UI decoration as a mixin to any sort of component, like

In Scala 2.8 recent nightlies, this compiles happily -- but when you run it, the self.paintComponent(g) call just stack overflows, flipping between TiledContainer.paintComponent and Tiled.paintComponent as it goes.

At 2.7.x, it doesn't compile -- which at least prevents you getting the run-time error

error: overriding method paintComponent in class Component of type
(g: scala.swing.package.Graphics2D)Unit; method paintComponent in trait Tiled of type
(g: java.awt.Graphics2D)Unit cannot override a concrete member without a third member 
that's overridden by both (this rule is designed to prevent ``accidental overrides'')
class TiledContainer(tiledBackgroundImage : Image, constraints :Seq[String]) extends 
Form(constraints) with Tiled with HasImage {

Winter Wonderland

Thursday evening last, it started to snow -- blizzarding enough that Karen's evening call carers got lost on the way back, took the wrong turn and ended up stuck in the snow on a farm road, and had to be towed out by tractor.

Friday, the snow was drifted deep against the front door, and going out to the village shop, it was calf-deep in places where it had drifted. A definite work from home day.

Saturday, pulled my boots on, and yomped the footpaths across the fields into town to do some shopping, on an exhilarating crisp winter's morning, where the long grass was sticking through the snow like through blown sand on a beach. Traffic was horrid in town, and for the return journey, when I went part of the way along the main road, the snow had clearly turned to slush and been refrozen, horrible going. So on the last, off-road, leg, when I was getting tired and footsore, when confronted by a pitbull thing, I just kept on going. This unsetled it, and when I got within about six feet, in pronked off and started circling, despite being yelled at by its human. I eventually had just to grab the thing by the harness and wait for the lead to be clipped back on.

Deep and crisp and even

Sunday, I thought it would be a good idea to clear the drive -- but under what looked like nigh virgin snow there was a thick layer of ice. Monday, worked from home again, did some clearing -- though the main bus-route through the village was still thick with ice (no gritting done whatsoever). Tuesday, discover that the other road through the village was clear, so very gingerly make the short drive onto the clear road and the long main-road detour to work. Head home after lunch, expecting the other end of the village to be as clear as the way I went in the morning -- to find a horrible scary drive.

Worked from home the rest of the week, probably getting more done than had I gone in. Yesterday afternoon wheeled the bike out to the main road, then cycled to the nearest supermarket for some last minute food shopping. The main roads were clear, but some of the side roads near the supermarket were sheet ice (one gentle slide to my knees while wheeling over that on the way back).

Today, the thaw was setting in, but there was still snow lying morning and evening -- the first white Christmas I can remember, certainly in the 20+ years living here. the main road was clear, and in the close, the ice was soft and breaking into slush where cars were driving -- but some of the pavements (especially uncleared driveways) were solid slippery sheet ice. One old gent visiting the family for the day managed to get stuck for lack of traction, until I helped him.

Links for 18-Dec

MSFT SCVMM updater for VM images version 2.1 released.

Mixed-language assembly builds in Visual Studio.

.net 4 highlights.

Joe Armstrong approves of WebSockets.

Immutable wrapper pattern.

F#:

• Making F# type inference friendly to C#.
  
• Generic monads.
• FoldR on lazy infinite sequences.
• Continuation monad (also C#).

IronPython:

• WCF service in pure IronPython.
• v2.6 release.

Mono:

• C#4 parity.
• Mono 2.6 and Mono Develop 2.2 plus Moonlight 2.0 release.
• Linux debugging support for Moonlight/Silverlight.

Using a different mscorlib for F# in Visual Studio (Silverlight and probably XNA too)

It turns out that I was lucky last year when building an F# Silverlight 2 application by hand in Visual Studio -- I didn't make an explicit reference to mscorlib.

If you explicitly browse to the Silverlight mscorlib assembly to make an explicit reference, the .fsproj file still only gets the basic

    <Reference Include="mscorlib"/>

which falls back to the full framework version of the assembly when you compile. This behaviour has caused some people to abandon the exercise of getting F# to build against something non-default in Visual Studio.

However, the way forward is very simple indeed -- simply edit the .fsproj to give an explicit hint path pointing at the mscorlib you really mean:

    <Reference Include="mscorlib">
      <HintPath>C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll</HintPath>
    </Reference>

and get the confirmation that this sticks in the command line that echoes to the Output window

C:\Program Files\FSharp-1.9.7.8\\bin\fsc.exe -o:obj\Debug\Library3.dll -g --debug:full --noframework --define:DEBUG --define:TRACE --optimize- --tailcalls- -r:"C:\Program Files\FSharp-1.9.7.8\Silverlight\2.0\bin\FSharp.Core.dll" -r:"C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll" --target:library --warn:3 --warnaserror:76 --vserrors --utf8output --fullpaths --flaterrors Module1.fs

Problem sorted.

(Generalise as required to any other assemblies which refuse to stay pointed at the platform you want.)

Save the version number in the output, this advice is unchanged by the February 2010 CTP.

Packaging Scala applets into one jar in NetBeans with JarJar [Updated]

Pretty much a note to self; using NetBeans that started off as 6.7.1, but has the bleeding-edge depot, and using a Scala 2.8 nightly, FWIW.

Get the jarjar tool; put it and a copy of scala-library.jar and scala-swing.jar in a lib directory under the project. Create a build.xml post-jar target to read

    <target name="-post-jar">
      <taskdef name="jarjar" classname="com.tonicsystems.jarjar.JarJarTask"
               classpath="lib/jarjar-1.0.jar"/>
      <jarjar jarfile="${dist.jar}">
        <fileset dir="${build.classes.dir}"/>
        <zipgroupfileset dir="lib" includes="scala-*.jar" />
        <keep pattern="[your.root.package].*"/>
      </jarjar>
    </target>

Clean and build, get a lot of Scala classes in your output jar file. For which there is then pack200 support to crunch further.

There is an Ant task for that, which we can add to the post-jar target in build.xml thus

    <target name="-post-jar">
      <taskdef name="jarjar" classname="com.tonicsystems.jarjar.JarJarTask"
               classpath="lib/jarjar-1.0.jar"/>
      <taskdef name="pack200"
               classname="com.sun.tools.apache.ant.pack200.Pack200Task"
               classpath="lib/Pack200Task.jar"/>
      <jarjar jarfile="${dist.jar}">
        <fileset dir="${build.classes.dir}"/>
        <zipgroupfileset dir="lib" includes="scala-*.jar" />
        <keep pattern="[your.root.package].*"/>
      </jarjar>
      <pack200 src="${dist.jar}"
               destfile="${dist.jar}.pack.gz"
               GZIPOutput="yes"
               verbose="0"
               />
    </target>

which brings in my first test case, a 2.5Mb jar down to just under 900kb.

F# and Silverlight 3 addendum

You can make a permanent fix for the hint path needed to find FSharp.Core.dll by editing the template in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplatesCache\FSharp\Silverlight\SilverlightLibrary3.zip\SilverlightLibrary.fsproj (and probably the version of the file in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\FSharp\Silverlight\SilverlightLibrary3.zip just to be certain).

Proof of concept -- my orrery-clock upgraded to Silverlight 3.0 (with all the source bundled into the .xap file) here.

F# October CTP and Silverlight 3.0

With the February 2010 CTP, obviously change the version number to 1.9.9.9 instead!

Following on from last year's compendium for Silverlight 2 --

There's an official Silverlight 3.0 project template for Visual Studio 2008; while targetted at the May CTP, these can be used with the October CTP by opening up the .fsproj file and amending the file path for the FSharp.Core assembly -- unload project, edit, and change the version in the hint path for the reference to be 1.9.7.8 like

    <Reference Include="FSharp.Core.dll">
      <HintPath>$(ProgramFiles)\fsharp-1.9.7.8\Silverlight\2.0\bin\FSharp.Core.dll</HintPath>
    </Reference>

and then reload.

The template is still useful as it automatically picks up all the other Silverlight platform assemblies from their location in the Silverlight reference assemblies folder, saving you having to do that manually from C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Reference Assemblies and seems to provide some other integration in conjunction with the Silverlight tools.

Unfortunately, none of the samples provided are pure F# -- they all use a C# bootstrap for XAML and the AppManifest packaging. However we can still use last year's recipe with only minimal changes -- just update the RuntimeVersion in AppManifest.xaml to "3.0.40818.0", and the FSharp.Core.dll which you wrap in the .xap file is, of course, the one from the October CTP at C:\Program Files\FSharp-1.9.7.8\Silverlight\2.0\bin\FSharp.Core.dll (not the one from last year!)

The Moon in Winter

This morning at 07:13, about 35 minutes before sunrise, the sky was pale in the east with the approaching dawn -- and when I went downstairs, the just-past-full moon was casting shadows in the dining room.

The cats all agreed that this was good for their crepuscular activites.

Working on F# with NDepend

Following up from the earlier post here, looking more in depth at some of the results out of NDepend for my own little code quality project, and in addition to the results noted there

First out of the gate, for sanity's sake, when working with F#, it would make sense to add !HasAttribute OPTIONAL:System.Runtime.CompilerServices.CompilerGeneratedAttribute onto every rule. That way, you are not left to contemplate how and why the generated CompareTo methods on a simple record type

can have an IL Cyclomatic complexity of 43.

A similar blanket exclusion should be applied to types whose names contain the sigil @ marking them as generated function objects. Unfortunately, compiler inserted write-once local variables do not have any such distinctive sigils by which they can be filtered, just unexciting normal names like str, str2.

It would be nice if the HasAttribute condition also allowed you to filter on properties of the attributes like !HasAttribute OPTIONAL:Microsoft.FSharp.Core.CompilationMappingAttribute WITH (SourceConstructFlags & 31 == 1) OR (SourceConstructFlags & 31 == 2) -- to filter record or sum types, which are rich in generated structure, where appropriate. For example, though the sum type

may be implemented into the CLR by making Either<'a, 'b> an abstract type with concrete inner types Either<'a, 'b>+Left and Either<'a, 'b>+Right, the headline Either<'a, 'b> type is not an abstract base class in the usual sense, that user written code will be expected to extend the type.

Similarly, while it is arguably an oversight of the F# code generation that none of the inner types within a sum type are marked as sealed -- there is no good case for extending them -- it would also be nice to be able to exclude all (implicitly, generated) types that derived from (or are an inner type of) a sum or record type from analysis; as well as all the content of types attributed with [CompilationMapping(SourceConstructFlags.NonpublicRepresentation | ...)].

Allowing names of the form |ActivePattern|_| is a trivial extension of the "names should be upper case" rule.

There is what looks like a bug in NDepend's analysis as it manages to make all the types I have derived from Microsoft.FxCop.Sdk.BaseIntrospectionRule pass the filter

DepthOfInheritance == 1 // Must derive directly from System.Object

The containing rule for that test Classes that are candidate to be turned into Structures could probably also benefit from having AND !IsStatic added, so as to exempt functional modules.

F# under the covers XI -- Literal expressions that aren't; attributes that don't

The problem with being unable to attribute just the getter or setter of a property is resolved at the 1.9.9.9 release (February 2010 CTP).

Consider the following simple C# property

This compiles in debug mode to

which assigns the literal result -- 6 -- of the expression to the temporary that is then returned. The analogous F# method

compiles to IL which preserves the expression to execute only at run time:

which makes static analysis of the code in the more usually analysed state a rather more complicated business.

Another complicating factor is that while this syntax

builds, it attaches the attribute (with Method and Constructor usage only) to the property as a whole; and not the generated get_Options method, as in

What I'd like to express, and what I've not found a way to express, is

and MSDN remains opaque on the subject as well.

This is something I could code around, but I can't yet see a clean way of doing to allow separate attributes on the getters and the setters.

Later: The intended syntax for this option is, much as you might expect, this:

with the necessary insets as shown (to avoid error FS0010: Incomplete structured construct at or before this point in pattern), however on filing a bug report I got confirmation that it is a known issue with the Beta 2 release (aka October 2009 CTP), that this still decorates the property and not just the getter.

Links for 24-Nov

Simon Willison is excited by Node.js

PPK remarks that Apple is not evil -- and may be surprisingly cunning.

Luke Hoban’s F# for Parallel and Asynchronous Programming (PDC video)

Bart Czernicki’s Silverlight 3 and F# Support in Visual Studio 2010

Pense-moi's Immutable queue library for F#

F# under the covers X -- the curious case of record types

This is unchanged in the February 2010 CTP (1.9.9.9) release.

They're coming thick and fast now...

Define a record type such as

The class that results looks like

where the source context for each method is the same -- the range containing just the type name.

Now, you wouldn't expect anything to be seriously unusual about this class in terms of its implementation, but there is.

FxCop reminds you about the IComparable should-haves that can't be enforced through interface constraints:

[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '!=' since it implements IComparable.
[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '<' since it implements IComparable.
[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '==' since it implements IComparable.
[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '>' since it implements IComparable.

but which aren't there; and Reflector's decompilation to C# is stymied by the highlighted CompareTo overloads -- the simple one is implemented as

which fortunately doesn't give much scope for things to go wrong.

In this and the previous case, the offending instruction that Reflector balks at is a simple branch such as indicated in this example

It's quite clear at every turn that F# is coming at the problem of code generation from a very different direction to the well explored parts of the phase space of valid IL that C# and VB.net dabble in. And clear, too, that this will present a significant challenge to all writers of tools to work with the language -- it takes us well out of our old comfort zone.

F# under the covers IX -- the case of the missing coverage

As I'm driving my little set of FxCop rules and associated helpers to a usable state, I'm looking in more detail at how the code coverage in the automated system/integration test is going, trying to drive that towards 100%. And as usual, the F# code generation is throwing up some interesting results.

Take this method (lightly refactored from last time) which starts at line 167 in the actual source:

Although my tests give a match for every case in the pattern -- and nCover shows a visit for every line from 168 to 176 (2 to 9), and the expression body of each branch of the if/else, it also claims that a code point that spans from from line 168 col 5 to line 177 col 24 (everything from if to then inclusive) is not visited.

Unfortunately, the IL generated for this method is not back-compilable to C# in Reflector (yes, another problem report submitted), so I can't use that to analyse what is going on in this particular case : I shall have to inject some diagnostic code into the rule itself to see what FxCop thinks is going on as a statement which spans those lines.

But this isn't the only mysterious bit of uncoverage I've found in F# code -- in the previous state of the method (as showcased here), it was the identifier result in let result = match… that got the uncoverage, despite the named value being used as the final expression in the method.

In most cases, it is possible to refactor away such temporaries, and clear the spurious uncoverages that they give rise to; but, as this example shows, it is not always possible.

Later

By recursively dumping Statements in FxCop for this method (which inserted 2 lines in a routine above this one, thus displacing the line numbers), I get a lot of multiple hits on statements (same type, same source context range), but the only ones with the appropriate source context are

Block -> from 170 : 5 to 179 : 24
Nop -> from 170 : 5 to 179 : 24
Nop -> from 170 : 5 to 179 : 24
AssignmentStatement -> from 170 : 9 to 170 : 22
AssignmentStatement -> from 170 : 9 to 170 : 22
Branch -> from 170 : 9 to 170 : 22
Block -> from 170 : 9 to 170 : 22
Branch -> from 170 : 9 to 170 : 22
Block -> from 170 : 9 to 170 : 22
Branch -> from 170 : 9 to 170 : 22
Block -> from 171 : 27 to 171 : 35
ExpressionStatement -> from 171 : 27 to 171 : 35
Nop -> from 171 : 27 to 171 : 35
…

So it seems that first Nop pair, with no other statement occupying the the same range, may be what it being detected as uncovered (unlike the second Nop, which overlaps the immediately preceding ExpressionStatement exactly).

The equivalent IL looks like

which does indeed have a pair of Nop opcodes at the start (lines 21 and 22).

So, that looks like another heuristic to add - removing unvisited code point records that correspond to nothing but a Nop.

The February 2010 CTP generates identical code here.

NDepend -- a belated "kicking the tyres" review

While there may be subtle details changed by the February 2010 CTP, the broad thrust of how F# looks to a C# directed tool remains. The mass of compiler inserted locals which skews the analysis certainly containues to hold.

First off, a little confession -- while I'm a C# coder by day, by night I use a whole variety of other languages instead; so I don't have a large corpus of my own code to use it against; and having installed my gift copy of NDepend v2.12.1.3123 (Pro Edition) on my personal development machine at home, there are certain ethical issues involved in getting it to run over code from the day job as-is.

I do have an on-going project in F#, which at least the tool will consume after a fashion (as the tool doesn't know .fsproj files from Greek, analysis has to proceed by selecting a number of assemblies to work with), so my experiences are based on that.

First impressions

At one extreme, tools such as FxCop or StyleCop provide a report that indicates a number of point changes to make to code with pretty much zero configuration to the tools; at the other extreme, nUnit and nCover are things that require you to configure (code) pretty much everything, and responding to the output is a matter of judgement. NDepend is somewhere in the middle -- you can run it with default settings and get some analysis of your code, but the settings are completely malleable; and the response can in places be a judgement call too.

There are some rules in the default set which overlap, and in places contradict, guidance from FxCop or StyleCop -- especially in matters like naming conventions. This latter is the stuff of which religious arguments are made (my own choice being to leave policing of names to the MSFT tools). Similarly, it invents a method-level NDepend.CQL.GeneratedAttribute to mark generated code when we already have System.Runtime.CompilerServices.CompilerGeneratedAttribute and the class-applicable System.CodeDom.Compiler.GeneratedCodeAttribute

Some of the conditions tested (setting aside the false positives out of F#) are useful complements to FxCop, such as flagging places where code visibility could beneficially be adjusted to better encapsulate code, and are essentially resolved by point fixes in many cases.

The real value comes in the rules that examine the structure of the code (even if, again, the precise thresholds used are potentially subjects for debate).

Live test

I ran NDepend against the latest drop of my FxCop rules project; this is possibly a small sample of code, and in some respects an edge case (with strong coupling to framework or FxCop classes, and very low abstraction).

Being F#, I have to just supply the assemblies, and cannot get source level analysis (such as cyclomatic complexity or comment density metrics).

Aside from the language difficulty the one place I have had trouble is making sense of the coverage file integration -- the nCover output I supply seems to get ignored; and the linked-to tutorial refers to such an earlier version that the UI doesn't match at all.

Interpretation (and F# peculiarities)

With no interfaces defined in the project, I seem to trigger a fencepost error in the report for class statistics

Stat	# Occurrences	Avg	StdDev	Max
Properties on Interfaces	0 Interfaces	0	0	-1 properties on
Methods on Interfaces	0 Interfaces	0	0	-1 methods on
Arguments on Methods on Interfaces	0 Methods	0	0	-1 arguments on

and there are some places where the names of F# methods may be problematic -- for a number of rules I get a "WARNING: The following CQL constraint is not satisfied. 1 methods on 358 tested match the condition.", but the name of the offending method I have to find for myself:

methods	# lines of code (LOC)	Full Name
Sum:	2
Average:	2
Minimum:	2
Maximum:	2
Standard deviation:	0
Variance:	0

As I've been posting in my "F# under the covers" series of posts, the IL that gets generated is, shall we say, interesting; and that is one of the things that gets shown up by rules tuned to C#. Indeed, the very first run I made was what provoked a one-shot into an on-going series. For example, this method

has 11 variables and a cyclomatic complexity (in IL) of 12

That method -- which is used in

where >?> and >+?? are combinators, gets detected as unused ("No Afferent Coupling -> The method is not used in the context of this application.")

A number of rules -- such as "A stateless type might be turned into a static type" -- show up quite how many compiler generated classes there are; both the ones with @-line-number names (e.g. Patterns+MapToTypes@41) for F# funs, and simple nested classes for algebraic types. In production use of NDepend on F#, these rules would have to be extended so such types could be filtered automatically.

For other false positives, such as the spurious numbers of locals, it would be beneficial to filter on a suppression attribute (along the lines of System.Diagnostics.CodeAnalysis.SuppressMessage) with a string property that the rule could match on.

Overall

Another useful and interesting tool in the general .net developer's armoury. Even out of the box, I could see that it would provide useful automation to supplement a manual code review process, though it would require a degree of customization to fit into an established build and coding standards regime.

Links for 19-Nov

New from the PDC:

• Windows Identity Framework RTM.
• Silverlight 4 beta.
• Reactive Extensions release (Introduction parts 3,4, another introduction).
• IronScheme 1.0 RC1.

WPF - from C# to F#.

Automating signing of PoSh scripts.

Prefer structured lifetimes – local, nested, bounded, deterministic.

Embedding IronPython in Silverlight.

Mono tools for Visual Studio.

Moonlight futures.

Google's 'go' -- is it the new VB?

Nature notes

Mild wet and very windy up from the south, so mild that, when I went downstairs to get a bedtime drink last night, I found that the cats had brought a frog in, and were just sitting around looking at it.

And while a few clear cool nights have just about ended the tomatoes for the year, it was only a couple of days ago I picked the last couple of properly ripe fruit off the Alicante in the greenhouse. The chilis are still going wild, and we're just getting the first capsicums ripening.

And of course even the tender plants like the fuchsia are going strong.

Alpha-encoding file versions

When building installers the UpgradeVersion must have a unique property value that is an installer public property (upper-case alpha). So, what better way of adding uniqueness than making it have the form "product name + product version" with the version suitably encoded...

So, a script for turning a file version (4 x 16bit ints) encoded as a System.Version into a short alpha string, assuming that Major and Minor will be small, and that common approaches are to step Build, to use a stepped Build plus date-stamped Revision, or a timestamp Build and Revision --

where the first two facets are encoded as telescoped base-13 (with a bit to say "more to come"), and the second two are encoded as pairs of bytes -- Z for a zero byte or as a 2-character base-25 representation if non-zero, with a zero Revision being dropped. This gives 10 characters in a plausible worst case, or as low as 5 in some conventions (stepped build numbers only); as opposed to the naive 64-bit as all-base-26 which would give 11 characters always.

“Hello GTK#” from the latest IronPython and F#

A little post to record a short bit of spiking with GTK# as UI toolkit, porting the simple C# examples from here to my preferred .net languages. Neither of these explorations are totally novel -- there are examples in either language to Google, but not all of them recorded all the details of the slight rough spots that needed a little working (and they were often not at all recent, either).

For IronPython 2.6 latest with GTK# 2.12.9-2, running the programs as ipy Program.py, the code looks like

where the dynamic nature of the language means we can lose a lot of the declaration clutter. We just have to explicitly reference the main GTK# assembly (which is GAC'd by the GTK# installer), and away we go.

F# was almost, but not quite, as smooth. You have to add references to additional assemblies atk-sharp and glib-sharp, and the types are a little more explicit:

With the project built as a Windows Application, the Console output doesn't show (even to the Output window in Visual Studio), so the code has been changed to update the button caption after clicking. Apart from that, GTK# follows the WinForms eventing model, so wiring up the events is just a matter of adding the appropriate handler functions in the same way as you would normally -- including the effect that the function value OnDelete needs to be coerced to a delegate type of the same signature such as via a wrapper fun as shown, and can't just be added directly.

This program is also not FxCop clean, but there's nothing GTK# specific about the tidying operations required.

As expected, these work unchanged with the 1.9.9.9 CTP

Links for 9-Nov

Windows Identity Framework ("Geneva") hits RC.

Trampoline recursion in C#.

Cross-browser XUL and SVG library.

CComPtr<T> type safety issue.

F#:

• Updated language spec.
• Equality and comparison constraints (Motivation).
• Reactive  framework (part 2).
• Multiple outputs from T4 made easy.

F# under the covers VIII

I'm in the tidying up stages for the little project I've been working on lately, a set of FxCop rules, mainly aimed at providing some complementary features for nCover-style code coverage, including static analysis for trivial methods -- or compiler generated ones. I've done the red -- add a set of methods that should give expected static analysis results -- and green -- write the simplest implementation that works when given the code base to analyse as a post-build activity. And now I'm on the refactor leg, abstracting out the common activities, taming sprawling methods into tighter ones, and reducing the level of imperative features (perhaps also making the code more idiomatic), even at times managing to delete whole methods.

And while I'm doing so, I'm running various tools over the code; FxCop and nCover over a small nUnit run every build, of course, but in turns Reflector and NDepend -- the results of which have been the inspiration for this series of posts.

And as we have seen, the code emitted by the F# compiler in its various iterations is unlike that coming from the more traditional .net langauges, in a way that doesn't always play nice with tools developed against C# or VB.net (and perhaps C++/CLI).

NDepend will deserve an essay of its own in due course -- part of the quid pro quo for the copy that Patrick Smacchia has generously donated -- but today's point of interest is that some IL code generated from F# cannot (at least with current Reflector builds) be easily folded back into C# source.

Take this active pattern used to match a property getter method that just returns a backing field with a name related to the property name, which is at a current intermediate stage of refactoring

where MapToTypes turns an FxCop StatementCollection into a list of their corresponding NodeTypes, and @ wraps String.StartsWith with ordinal comparison.

Confronted with a request to decompile into C#, Reflector 5.1.6.0 asks me to file a bug report (which I have done) for an exception "Invalid branching statement for condition expression with target offset 002A."

Now, as far as I can tell from the IL, this is part of line 2 where it is balking

Presumably -- I would have to build some equivalent C# code to validate -- the brfalse.s is not one that C# (or any of the other languages Reflector knows of) would actually emit. Certainly it seems that the new F# CTP compiler is fond of emitting it, and it breaks Reflector every time it does.

Another good reason for avoiding too many imperative constructs in your F# code, it would seem.

---

Later: this C# code that approximates the above F#

compiles to

which indeed, as I suspected, uses a brtrue.s for the final branch out of the if statement (though there is a brfalse.s to perform the short-circuiting.

Code generation here is unchanged in 1.9.9.9 from the previous CTP.

F# under the covers VII

Working with nCover to examine the number of code-points represented by any given method, the October CTP made a large number of changes -- some up, some down -- to the code generated by the compiler.

Most interesting is the change to attribute setters, which used to be NOP;assign;return and are now just assign;return. Also the name of the implicit backing field has changed to be the property name with an appended '@', rather than being a case-mangled version of the property name.

(As always, talking about Debug builds).

Later ... This one is a bit too cryptic for me to decipher what I was writing about. Code like this:

Has internal fields like Line@ still at 1.9.9.9; and property setters as in

compile to the NOP-bearing

with the Feb 2010 CTP.

Links for 3-Nov

Vista presentation mode tips and enabling applications.

Attaching a debugger on process start.

Simplicity is complicated.

F# immutable queue and range.

Validating JavaScript syntax with a .net wrapper.

Underscore -- a functional programming utility library for JavaScript

Nature notes

Driving home, after dining with colleagues, in the hard bright moonlight of a Hunter's Moon, I actually saw a live badger ambling along the verge at one point, a rare spotting of some of the larger wildlife around here.

Quite how starkly bright a winter full moon can be always comes as a surprise.

Also, still harvesting a last few tomatoes from both outdoor and greenhouse plants.

Links for 26-Oct

PoSh --  Official cmdlet and help designer

Erlang used at Yahoo!

T4 template WCF client.

Hiding concurrency in synchronous methods.

F#:

• Tutorial slides and code.
  
• October CTP release notes.
  
• Composing First-class Events.
• Reactive Framework (introduction), with F#.
  
• Dynamic look-up (duck typing) operator.
• Extension methods for use in C#.
• Overview of type inference.

GTK# for windows part 2.

Shutting up a C++ compiler warning.

The last days before winter

View Autumn Holiday - Thursday 22 Oct in a larger map
View Autumn Holiday 23 Oct 09 in a larger map

A quick cycle break in Constable country.

After torrential rain on Wednesday, everything was dripping on Thursday morning; and my first fording was immediately after turning out of the hotel drive. The route to Nayland was on single track roads, deep cut, so not terribly pleasant, but the leg to the west was open, and by this time the sun had burned off the early haze. I avoided the bridlepath return, diverting through Wormingford, and then took the main road to Stoke-by. The next leg started off again narrow and steep -- not pleasant cycling; and the land south of the main road towards the A12 is drear and desolate, so it was pleasant to come to Dedham, a pretty little village, for lunchtime.

The footpath to Flatford Mill was surprisingly free of any sign of the previous downpour, and the walk was nice, in the warm sunshine -- T-shirt conditions. Ate packed lunch on the riverbank, then returned to find my bike swarning with ladybirds.

Long loop to the north into more open country away from the river valleys, crossing the ford at Kersey dry-shod -- then just after Boxford getting one foot wet when suddenly encountering another. And so back, in the rapidly cooling evening sun -- at the hotel just after 5pm.

Friday, a shorter tour of the same sort of area -- sometimes avoiding narrow lanes where the vans and landrover+trailer traffic meant I had to squeeze to the sides, especially on the Stokt to Higham stretch. Despite the delivery van stuck behind me, the Green Lane north from Higham was the most pleasant such -- mainly because it was not cut 4+ feet into the terrain, and there were no high hedges blotting out the light.

Hot roast lamb with mint sauce baguette at the Cock Inn in Polstead, then the final stretch, reversing some of the previous day's, and, forewarned, getting dry across the ford this time. Again, a glorious day, again with none of the threatened showers -- just gorgeous late late Indian Summer weather; a third time lucky for this year's cycling holidays.

F# under the covers VI

First results from the October CTP, as ever, using Debug build

turns up FxCop warnings

warning : CA2208 : Microsoft.Usage : Method '...' passes 'source' as the 'paramName' argument to a 'ArgumentException' constructor. Replace this argument with one of the method's parameter names. Note that the provided parameter name should have the exact casing as declared on the method.

because the operation is in-lined, with code that maps back to C# as

and then immediately follows this with a similar in-lined ArgumentException.

With the new CTP we now get, on a method that used to check clean

On method 'Patterns.As<Target>(object)', prefix generic type parameter name 'Target' with 'T'.

but that's just a minor and easily fixed issue; and also

now gives

warning : CA1810 : Microsoft.Performance : Initialize all static fields in '...' when those fields are declared and remove the explicit static constructor.

A simple test with 1.9.9.9 reproduces the first two, but not the last. The object is now a static member of the synthetic <StartupCode$[assembly name]>.[FileName] static class, and exposed as a property of the module.

F# October CTP first impressions

It's nice to be able to get rid of all those OverloadID attributes; and to see that attributes now do need to have the AttributeTargets.Constructor usage to be applied to constructors.

Not so good -- output from a post-build step no longer appears in the Visual Studio output tab (at least it didn't for me); and when running unit tests from such a post-build step, an F# method being called from a C# test with an final expression of unit caused nUnit 2.5.2.9222 to fail with no diagnostic message (would have needed a post-mortem debug). Workround was to replace () by ignore aValue where ignore _ = (); but I'm still not sure what was going on there.

The code generation (debug builds at least) has changed significantly, as I'm now getting a number of FxCop warnings from code that ran clean with the May CTP. More on that, later.

This funny behaviour -- from code that maps to C#

remains in the February 2010 CTP, but is resolved by code that looks like

Go figure!

Review catch-up — Anime and Manga

Manga : Bokurano

There was a long pause in the scanlation of the manga, broken around the airing of the anime, leading to a somewhat fractured impression when following it as it became available.

It's Mohiro Kitoh, so of course, bad things happen to children. In Narutaru, he took on Pokémon; here, he subverts the super-robot genre in a way to make Neon Genesis Evangelion seem like a happy WAFFy tale. Every time you think he's done everything, he finds a way of twisting the knife again.

The real weakness is the ending -- the epilog chapter really didn't add anything that could not be inferred (and partly relies on your ability to remember the subtle distinctions between one and another of his character designs).

Anime : Sengoku BASARA

16^th century Japan as it was in the movies, or at least ought to have been — on about the level of Henry VIII vs Oliver Cromwell with Maxim guns. Superpowered ninja, high-level fighters with awesome feats, forsoothly Japanese mixed with heavy-duty Engrish. Plus Norio Wakamoto as the arch-villain Oda Nobunaga.

Switch your brain off, put ya guns on, and enjoy!

Asura Cryin' first season

A series that bundles together so many standard elements — supernatural, high-school drama, miko, ghost-girl, yakuza, demons, childhood friend potential love interest, super-robots, school councils (three of them!), apocalyptic threats — that there is no room left for anything like a coherent plot.

Alas, the only other real mindless action series this year after Sengoku BASARA.

Saki

It's about school-girl mah-jongg tournaments, with the same character designer as last year's Strike Witches.

Akagi this is not : there is little of the psychological elements, the winning hands so casually made are even more improbable, and the metaphorical struggles get elevated to full-on mahou shoujo at times. But being about an all-girls competition, it redresses the gender balance.

Indeed, rather than taking many episodes over one hand, the actual games get rattled through rather briskly, with the focus being on the girls, and their individual back-stories and improbable playing styles, like "Stealth" Momo, who is so socially invisible, that nobody notices what tiles she discards or when she declares Riichi -- except for Nodoka, who has to pretend she's playing on-line (and thus ignore any of the people at the table in any case) or the real hax players who just have too many levels of talent to be slowed down by such things.

The real shame is, that, having developed so many interesting characters, most of them will fall by the wayside as and when a second season gets made, since they have been eliminated from the current tournament level. And there has at least to be the potential for a second series, as the driving motivation for the title character is to play against her estranged sister, and that can only happen in the next rounds of the tournament.

Chi's New Address

Continues last year's Chi's Sweet Home; as the family move from their old apartment to a new pet friendly one and settle in.

Old characters return, and new ones are met -- but, alas, it stops being quite the acute observation of what a kitten is about, and becomes rather more tales of anthropomorphised animals; still cute, but not quite the same.

Review catch-up — Films seen recently

Gilliam's The Imaginarium of Doctor Parnassus

The state of the art of SFX is such now that he can do in CGI/live action what he was doing with paper back in the Python days; and it managed to carry off the multiple actors filling in the gaps in Heath Ledger's role in a smooth and unobtrusive fashion (were it not for the fact that Ledger's Australian accent stood out from the understudies).

But (and you were waiting for the 'but') I found the supporting characters grating and unsympathetic, and the inclusion of "socially relevant" elements made the story lurch back and forth too much. Inclusion of the sordid nature of contemporary London for contrast with the pure world of the imagination, yes; but the mood swings were a bit too violent and "am I relevant yet?" in nature.

His Munchhausen was better, IMHO.

Once upon a time in the West

Reissued, remastered, very much of its time, a fairly archetypal "Man with No Name" western, where, with Charles Bronson as the revenge driven guy in the white hat, there are really only shades of grey.

District 9

This savage black comedy is the best new movie I've seen in a long while, with hints of Python and early Peter Jackson in a mix that savages so many stereotypes.

Links for 9-Oct

Exploding Software-Engineering Myths.

Dark Corners of IronPython

Gtk# for .Net developers

Tell don't ask.

Smart Stubs with Rhino Mocks.

Functional

• Matthew Podwysocki’s Generically Constraining F# Parts One, Two and Three
• M<’a> Lib (F# and C# LINQ) Monads Library
• Functional Programming for Everyday .NET Development.

Web

• Free CSS Toolbox - Free CSS Validator, CSS Formatter, CSS Compressor
• Starting with @font-face.

Unsorted links since last time

http://www.ademiller.com/blogs/tech/2009/09/gotchas-adding-attributes-to-interface-properties-in-f/

http://stevehorsfield.wordpress.com/2009/09/17/f-generic-fold/

http://www.lostechies.com/blogs/derickbailey/archive/2009/09/17/how-a-net-developer-hacked-out-a-rake-task.aspx

http://www.lostechies.com/blogs/derickbailey/archive/2009/09/17/an-alternate-way-to-handle-task-dependencies-in-custom-rake-tasks.aspx

http://www.improve.dk/blog/2009/09/12/the-cost-of-latent-logging-code

http://dmitrysotnikov.wordpress.com/2009/09/18/microsofts-ad-cmdlets-available-for-win-2003-and-later/

http://www.downloadsquad.com/2009/09/23/microsoft-silverlight-comes-to-linux-first-stop-moblin/

http://weblogs.asp.net/podwysocki/archive/2009/09/25/pondering-axum-f.aspx

http://code.msdn.microsoft.com/LAgent

http://www.javascriptbeautifier.com/

http://codebetter.com/blogs/matthew.podwysocki/archive/2009/09/27/generically-constraining-f-part-ii.aspx

http://blogs.msdn.com/powershell/archive/2009/09/20/what-s-up-with-command-prefixes.aspx

SyntaxHighlighter 2.0 Brushes for F# and Erlang

Updating the Erlang brush

This also required the following in the CSS theme

And for F#

which is as incomplete as it always was; but doesn't use any extra CSS.

---

Later -- another brush for F# that was published at about the same time can be found at Pense-Moi.

Migration to SyntaxHighlighter 2.0

This will be coming soon. For the moment a little note to myself, expanding from my first how-to for version 1.5:

becomes

To get the legacy mode to work, I had to put the initialization into the onload function.

I'm not rolling this out until I can get the rewritten F# and Erlang brushes to work and not throw _a2.regex is undefined messages.

Later: There are a lot of initial-letter capitalization changes (in both directions) required in this port : the "_a2.regex is undefined" messages came from more of them than at first met the eye. I still can't find the equivalent mechanism to injecting CSS styles, though.

Later yet: There doesn't seem to be a programmatic injection of CSS values any more, so I hacked the values from the 1.5 brushed into the default CSS file.

Even later: To allow legacy and non-legacy highlight styles, the legacy part of the operation must be in the onload, the 2.0 initialization must not.

Yet more: A possible bug in the CSS as supplied -- I needed to add the following

to shCore.css to get the copy-to-clipboard icon to show in the toolbar.