Work: Using F# in anger

During working hours (and sometimes beyond) I’ve been developing a large project using lots of F#, a little bit of C# and a bit too much XAML. It’s quite an interesting mix, with technologies that have a vastly different outlook on life: F# with it’s strong, compile-time type checking and XAML with its, err, not-so-strong type checking. In fact, XAML and WPF play so fast and loose with types, that errors in the binding mechanism only happen at run-time and are almost always eaten silently. As you can imagine, this makes for some fun debugging. All I can say is thank goodness for Snoop.

We have a quite a substantial amount of ViewModel code in F# (tens of thousands of lines), much of it using Async to allow us to create responsive UIs without requiring tons of boilerplate code. Generally it works nicely, but I do have some concerns about the amount of thread hopping going on, and how that will affect performance. Especially as we break things down into pretty small pieces of functionality, sometimes just a few simple operations, and each is run on the thread pool. I don’t have any concrete figures to go on here, and I’m hoping we don’t end up in a situation where we sacrifice user productivity for developer productivity. Time (and perfmon) will tell.

Debugging

I’ve done less hardcore WinDbg stuff this year. In fact, a couple of times I’ve been guilty of jumping in with the debugger where it probably would’ve been more effective to take a high-level look first. A case of having a debugger-shaped hammer, and everything looking like a nail.

Moving to 64bit

A very positive thing that happend this year was the move to 64-bit Windows 7 for development at work, meaning that Visual Studio actually stays up without crashing for more than an hour. Previously I’d been having a terrible time: the combination of a couple of large-ish F# projects and 32-bit XP caused frequent VS out-of-memory errors, which was very frustrating. Luckily the move to Windows 7 has resolved it, and I can even run more than a handful of apps at the same time; what a luxury.

Home: iOS

After a long day at work, I finally get to go home, put the kids to bed and then my feet up, and break-out Xcode for a bit of iOS hacking. This year I’ve been feeling like I’m finally getting my head around some of the things that are fundamental in iOS development; from Objective-C concepts like release/retain semantics to iOS specifics, view controllers, table views etc. Previously I’ve been guilty of some copy-and-paste coding, mostly because it’s pretty slow going getting up to speed with new tech (and the myriad iOS APIs) when you’re only getting to do it for a few hours while knackered after work. Well, that’s my excuse anyway.

I’ve been trying to finish off some of the apps that I’ve started, but not shipped. I tend to procrastinate a bit (massive understatement), and of course things aren’t helped by the development ‘fat tail’, where the last 20% – polishing and getting things ‘just right’ – takes at least 80% of the time. My 2010 post on Core Animation flip clocks continues to get a lot of traffic, and I finally bit the bullet and posted a (free!) app that uses it and it’s getting a lot of downloads, which is nice. I also had a look at iAd, which I’ll reserve judgement on for the time being, at the minute it’s not looking particularly lucrative…

As well as iOS stuff, I also took a look at OpenGL. I tend to do this every now and again, each time dipping in a little further and understanding a bit more. This time round it was looking at shaders (in OpenGL ES 2.0) and integrating with Bullet physics. My learning was certainly helped by this excellent Learning Modern 3D Graphics Programming tutorial.

Kinect and F#

Also while at home I finally got around to setting-up by my Kinect to do a bit of F# hacking. In the end I didn’t produce very much, but it was pretty good fun anyway.

Bring on 2012

So, to sum it up: more of the same really, I guess. Although this year there’s definitely been a bit more of a focus on UI development, in both WPF and iOS, which I’ve been enjoying. It does tend to feel a bit schizophrenic, switching between technologies and platforms at the end of the working day. It can be interesting to identify the common themes and significant differences in the two approaches to GUI development.

This year I’m hoping to make my blogging a bit more regular, but who knows if I’ll be able to stick to it… If there’s anything you’d particularly like me to focus on, feel free to leave a comment.

Just what do you think you're doing, Dave?

The first bit was easy: I’m “lucky” enough to have one of the older Xboxes, which meant I’d had to get a Kinect with separate power, which is the one required by the SDK. Now all I needed was a Windows machine to develop on.

For all my Visual Studio stuff at home I use a virtual machine, and unfortunately I missed the point in the readme about “Kinect for Windows applications cannot run in a virtual machine”. Doh. That would explain why, try as I might I couldn’t get VirtualBox to detect the device when I plugged it into the host. Whatever I did I ended up with a ‘resource is busy’ error.

I even tried another VM, this time from VMWare. It got further, with the guest seeing the devices, but whenever I tried to run the sample apps the API initialisation call failed. Unfortunately the samples make a bit of a rookie mistake and don’t display the error code associated with the failure; the only way to get the underlying HRESULT is to debug the app. As it turned out the error was the catch-all 80080014, which is attributed to various USB issues.

So, I finally relented and decided to once again set-up Bootcamp, which I’d stopped using a while back: why bother when VMs had done everything I needed? Again I was snookered, this time by the incompatibility of the EFI firmware in my ageing MacBook with the Win7 x64 install disc (which I’d had to actually burn onto optical media – can’t remember the last time I burnt a real physical disk)!

Eventually, I got Win7 x86, Visual Studio and the Kinect SDK installed on the metal, plugged in the sensor and – whoa – the devices were recognised and the drivers installed and… the samples ran!

From this point doing some hacking was pretty straightforward. I set about creating a project that used the skeletal tracking ability from the SDK. The project needs to reference the Microsoft.Research.Kinect assembly, then we can open some namespaces and initialise the API:

open System
open Microsoft.Research.Kinect
 
let nui = Nui.Runtime()
nui.Initialize(Nui.RuntimeOptions.UseSkeletalTracking)

The API uses .NET events to communicate back to the application that some form of data is available. Depending on the options that you specify at init time, any of the skeletal, depth frame or colour data will be returned in the event arguments. This seems like a good place to use F# Async’s event integration: Async.AwaitEvent. We can quite easily write some code that will create an Async task that will repeatedly listen for events:

    let skeleton (nui : Nui.Runtime) =
        let rec loop () =
            async { 
                let! args = Async.AwaitEvent nui.SkeletonFrameReady
                // Do something with the args
                return! loop () 
            }
        loop ()
    // Start the process of listening for events...
    skeleton nui |> Async.Start

This seems to work nicely, although I’m not sure of the overhead involved, perhaps a solution involving Rx would be more appropriate. Anyway, let’s do something with the data we get in the event, like getting all the skeletons that are being tracked, and passing them to a draw function:

                args.SkeletonFrame.Skeletons 
                |> Seq.filter (fun s -> s.TrackingState = Nui.SkeletonTrackingState.Tracked)
                |> Seq.iter draw

All that’s left is doing something cool in draw! Oh, and setting up all the GUI stuff necessary to actually get some pixels on the screen. I went for the WPF approach (as the managed samples do), which involves creating a simple object tree to display a rectangle in a canvas in a grid in a window, and doing a bit of marshalling back from the thread pool (where our Async code runs) to the main GUI thread.

Here’s all the code for possibly the most tedious thing you could do with a Kinect! But hey, it’s a starting point, right? I’m sure at some point I’ll get around to doing something cooler than a couple of small red rectangles with it…

open System
open System.Windows
open Microsoft.Research.Kinect
 
[<STAThread>]
do
    let nui = Nui.Runtime()
    nui.Initialize(Nui.RuntimeOptions.UseSkeletalTracking)
 
    // lifted straight from the sample code
    let getDisplayPosition w h (joint : Nui.Joint) =
            let mutable depthX = 0.0f
            let mutable depthY = 0.0f
            nui.SkeletonEngine.SkeletonToDepthImage(joint.Position, &depthX, &depthY)
            let depthX = depthX * 320.0f; //convert to 320, 240 space
            let depthY = depthY * 240.0f; //convert to 320, 240 space
            let mutable colorX = 0
            let mutable colorY = 0
            let iv = new Nui.ImageViewArea()
            // only ImageResolution.Resolution640x480 is supported at this point
            nui.NuiCamera.GetColorPixelCoordinatesFromDepthPixel(Nui.ImageResolution.Resolution640x480, iv, 
                (int)depthX, (int)depthY, 0s, &colorX, &colorY)
 
            // map back to visible area
            new Point((w * (float)colorX / 640.), (h * (float)colorY / 480.))
 
    // Set-up the WPF window and its contents
    let width = 1024.
    let height = 768.
    let w = Window(Width=width, Height=height)
    let g = Controls.Grid()
    let c = Controls.Canvas()
    let hd = Shapes.Rectangle(Fill=Media.Brushes.Red, Width=10., Height=10.)
    ignore <| c.Children.Add hd
    ignore <| g.Children.Add c
    w.Content <- g
 
    // We simple move the rectangle to where the head is
    let draw (s : Nui.SkeletonData) =
        let point = getDisplayPosition width height s.Joints.[Nui.JointID.Head]
        ignore <| w.Dispatcher.BeginInvoke(Threading.DispatcherPriority.Normal, Action(fun () ->    
            hd.SetValue(Controls.Canvas.TopProperty, point.Y)
            hd.SetValue(Controls.Canvas.LeftProperty, point.X)))
 
    let skeleton (nui : Nui.Runtime) =
        let rec loop () =
            async { 
                let! args = Async.AwaitEvent nui.SkeletonFrameReady
                args.SkeletonFrame.Skeletons 
                |> Seq.filter (fun s -> s.TrackingState = Nui.SkeletonTrackingState.Tracked)
                |> Seq.iter draw
                return! loop () 
            }
        loop ()
 
    skeleton nui |> Async.Start
 
    let a = System.Windows.Application()
    ignore <| a.Run(w)
 
    nui.Uninitialize()

The moral of the story? Don’t be like me, and make sure you actually read the FAQing readme, then maybe you’ll spend more time doing a decent demo and less time plugging and unplugging your Kinect!

module Test = 
    let work i = 
        async { 
            System.Threading.Thread.Sleep(500) 
            return i+1 
        }
    let run _ = 
        [1..1000] |> List.map work 
        |> Async.Parallel 
        |> Async.RunSynchronously

(Waits for people to start FSI and paste in the code…)

My guess would’ve been something just over 500ms; each of the 1000 async tasks would surely sleep in parallel, and then the operation itself is trivial. The additional elapsed time would be dominated by the overhead of thread management, and depend on the number of threads that can physically run in parallel (I’m using an 8-core machine). But still, something close to 500ms…

The actual result? 28000ms. Yes, you read that right: 28 seconds. What on earth did we do wrong?

Surely it can’t be that Sleep, right? I mean, each task is going to run on the thread pool anyway, so what difference would that make? Well, that *is* exactly the problem. It turns out that you can’t mix “vanilla” threading calls with Async API ones, because Async works in a completely different and incompatible way. If we use raw threading functions like Sleep, the async framework has no way of knowing if we’re doing anything useful. It eventually ends up causing .NET thread pool starvation, as we’re essentially grabbing and holding each thread in a way that doesn’t cooperate with anything else. New threads will spin-up to compensate and we’ll end up getting additional memory usage as well as worse performance.

Nasty

Instead Async uses what’s called continuation passing style, a technique favoured by the functional programming community, that also happens to map quite nicely to features in the CLR, including the thread pool, tail calls and garbage collection. It has the rather nice feature that it never blocks an OS thread (unless it’s busy actually executing). Instead it queues a function (a continuation) to be called at some later point.

Nice

For all the gory details and full Async semantics, I suggest you read the paper from Microsoft Research. Tucked away in there you’ll see that they do mention this restriction:

The key facet of an asynchronous I/O primitive is that it does not block an OS thread while executing, but instead schedules the continuation of the asynchronous computation as a callback in response to an event.

So how do we “fix” our example? Simple: we replace the non-CPS-friendly explicit Sleep, with an Async-native Sleep.

module Test = 
    let work i = 
        async { 
            do! Async.Sleep(500) 
            return i+1 
        }
    let run _ = 
        [1..1000] |> List.map work 
        |> Async.Parallel 
        |> Async.RunSynchronously

The result now: 558ms. Much more like it!

What happens is that the Async.Sleep call is converted into an event that is fired after 500ms to continue the execution, i.e. actually perform the addition. In the meantime, each of the other instances of the workflow get a chance to run, and we get real parallelism.

In this case it might look screamingly obvious, but be aware if you’re doing something such as calling into a third-party, legacy, or otherwise non-Async-aware code, it could cause your otherwise highly parallel code to choke. You’ll have to wrap it up in order to make it play nicely with Async and make sure you get the full benefit of this powerful F# feature.

Simples?

Of course the idiomatic way to avoid problems at the boundary between your F# code and the outside world is to ensure that you only expose a small set of compatible types. This works pretty well if your clients are also .NET languages. For instance you can do things like exposing your collections as seq, rather than say, a native F# list, and this will mean your collections can be consumed as IEnumerable. The only problem is it means you’ve got the added burden of maintaining this mapping layer, because you’ll no doubt want to use the F# “native” types internally.

So, what options do we have if some of our F# types happen to leak into our public API? Luckily, lots. Let’s take a look at how some of the common F# constructs can be called from C#.

Unions

I talked about the power of discriminated unions a while back, so how do they map to C#? Interestingly the F# compiler generates a very simple OO type hierarchy, with an abstract base class that each of the cases derive from. This will mean that your calling code will need to use some casting, but don’t worry, you’re not back in the hell of runtime typing; there are a set of methods on the type that you can use to identify the case before you do the cast, so at least you get some compile time sanity checking.

Here’s a simple discriminated union that we’ll be using as an example:

    type TestDU =
        | One of int * int
        | Two of string
        | Three

If we wanted to use this type in F#, we’d do so like this:

    // A function 'f' that takes an instance 't' of our union type
    let f t = match t with One (a,b) -> printf "Got One" | _ -> ()
 
    // Apply our function with a particular TestDU union case
    let _ = f <| Two "foo"

That’s pretty natural, as you’d expect. If we exposed the function f to C#, it looks like this:

void Module1.f(Module1.TestDU t)

This means we have to create an instance of the TestDU type, but we’ll quickly discover it’s abstract. As I mentioned before, the F# compiler has generated a very simple class hierarchy, with the union cases being subtypes of TestDU, implemented as nested types (which are used quite extensively by the F# compiler). But if we try and instantiate one of these subtypes…?

The union case types have no constructors.

    var one = Module1.TestDU.NewOne(1, 2);
    var two = Module1.TestDU.NewTwo("foo");

And slightly oddly, the parameterless cases (Three in our example) use a property on the base class instead:

    var three = Module1.TestDU.Three;

So now we can create instances of the union type to pass to the F# function.

But what if we’re returned one instead? It will be of type TestDU, so how do we know what case it actually is? And how do we get to the parameters? Well, as we know it’s going to be one of the subtypes, we could use the C# ‘is’ operator to determine its identity, but the base class also provides helper methods to do it for us, prefixed with Is, e.g.:

    if (two.IsTwo)
    {
        var x = (two as Module1.TestDU.Two).Item;
        // Do something with x
    }

As you can see, Item contains the case value. For tupled types this becomes Item1, Item2 etc.

Records

Records are immutable types that contain fields, they tend to be used quite a lot in F# code, and luckily using them from C# is very straightforward. The only thing to remember is that they’re only constructor is the one taking all of the field values (because they’re immutable), e.g.:

    type TestRecord =
        {
        field1 : int
        field2 : string
        }

Can be instantiated like this in C#:

    var r = new Module1.TestRecord(1, "foo");

Functions

It’s usual in F# to use curried functions. That is, functions that can be applied one argument at a time, returning a partially applied function. It turns out that the compiler maps this type of function (when directly exposed, as a public function on a module, say) into its tupled equivalent, which makes them easily callable directly from C#. For instance:

let public adder a b = a + b

Has a native F# signature of int -> int -> int, but results in a generated CIL function taking a tuple of two ints, with signature more like int * int -> int.

But there are more complicated cases; F# functions can take functions and return them. When we’re dealing with functions in a first-class way like this, we can use the generic Microsoft.FSharp.Core.FSharpFunc type. For example:

    let public adder a b = a + b
    let public addOne = adder 1

Where addOne is a function that returns a partially applied function. Calling it from F# is a breeze:

    let x = addOne 100

But from C# it’s a bit trickier. The function returns an FSharpFunc, that we then need to apply with Invoke:

    Microsoft.FSharp.Core.FSharpFunc<int,int> f = Module1.addOne;
    var x = f.Invoke(100);

Although obviously you can combine this into a single line, and remove some of the type signatures (which I tend to do as much as possible using var when writing C# code):

    var x = Module1.addOne.Invoke(100);

Things get even nastier if you happen to expose an F# function that takes a function. For example, a function that takes another function and applies it to two arguments:

    let apply op a b = op a b

In F# interactive we can see that this has the following, nicely generalised type signature:

    val apply : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c

i.e. it’s a function that takes as its first argument a function that takes an ‘a and a ‘b and returns a ‘c, it also accepts the ‘a and ‘b to pass to this function, and returns the ‘c result. Clear as. We may well want to create a version of this that uses the integer operator +, which is trivial from F#:

    let add a b = apply (+) a b

So how does it look if we try and do that from C#? In a word: messy. We have to use the Microsoft.FSharp.Core.FuncConvert.ToFSharpFunc helper functions, along with the .NET framework Converter as a way of specifying a generic, value-returning function.

    using Microsoft.FSharp.Core;
...
    var op = FuncConvert.ToFSharpFunc(new Converter<int, FSharpFunc<int, int>>((aa) =>
        {
            return FuncConvert.ToFSharpFunc(new Converter<int, int>((bb) =>
            {
                // The 'meat' of the function. Hmmm...
                return aa + bb;
            }));
        }));
    var zz = Module1.apply(op, 1, 2);

Whoa. That’s enough for now. As you can see, the various different ways of interoperating between F# and C# range from the neat to the nasty. The trick is definitely to pick your battles. Think carefully about what you need to expose and remember it’s probably best not to cross the beams if you can avoid it.

Hopefully soon I’ll manage to post some new stuff, possibly more ‘transitioning to F#’ posts and bit more iOS development malarkey. In the meantime, keep on keeping on.

Discriminated unions are one of those things in the lexicon of functional programming that can often sound baffling to “outsiders”; it’s almost up there with monads and currying. But in practice they’re simple and incredibly useful. I thought I’d try and show a concrete example of where they can be used in a way which is more powerful and robust than the equivalent OO approach.

The usual suspects

When people first start looking at functional programming, they often come across examples that implement a compiler, and this is their first exposure to discriminated unions. Unfortunately these examples tend to use complex recursive discriminated unions to represent the language syntax tree, which can be a bit of turn-off for anyone who’s not a language geek.

A problem

The way I like to think of DUs is a means of easily and precisely specifying a set of types that we’re expecting to work with.

What do I mean by this? Well, imagine you’re writing some code that can work on various different types, and you need to identify some common aspect to identify them. For example, you’re valuing different financial product types: swaps, swaptions, caps and floors. Although each of these trade types would be represented differently, you may want to perform the same operation across all of them.

The OO approach

The normal OO approach would be to use an interface; implemented by all of the types and consumed by our method. For instance:

class Swap : public IValuable { ... }
class Swaption : public IValuable { ... }
...
public double ValueTrades(IValuable[] trades) { ... }

But this isn’t particularly elegant or easy. For a start it requires that the type implement the interface – what if you’re working with externally provided types that can’t be changed? The other thing is that interfaces tend to give you a false sense of security about type safety. Given that we know there’s an object implementing the interface, I’ve all too often seen OO code taking an interface parameter then immediately type-casting it to another interface that the underlying object is expected to support. Run-time typing failures FTL.

The union

So how could we implement this using discriminated unions instead?

type Trade = 
    | SwapTrade of Swap
    | SwaptionTrade of Swaption

What we’ve done is create a new type that consists of exactly one of its possible cases. We identify each case with a tag (in fact, these types are often called tagged unions) called SwapTrade and SwaptionTrade and separate them with the bar ‘|’.

Easy, isn’t it? But, err, how do we get to the actual thing we want? Well that’s where another functional programming staple steps in: pattern matching. We can add some code that will match against the possible union cases and allow us to get at the type itself:

let valueTrades (trades : Trade list) = ...
    trades |> List.iter (fun t ->
        match t with 
        | SwapTrade s -> (* do something with s *) () 
        | SwaptionTrade st -> (* do something with st, which is of type Swaption *) ()
        )

Pattern matching warning

Hope you found this useful. As a long-term OO developer moving to functional programming it certainly helps me to see how aspects of FP can be applied to common OO problems.

I’m a big fan of the Mono.Cecil library for doing reflection (and more!) with .NET. I’ve had issues in the past where the built-in .NET reflection (using Assembly.ReflectionOnlyLoad) attempts to load dependent libraries as you iterate over exposed types, even though it’s not supposed to (unfortunately I don’t have a repro to hand). This makes it very difficult to work on an assembly without having all of its dependencies available. Cecil doesn’t have this problem because it accesses the assembly in a lower-level way.

I downloaded and installed Mono (the latest version is 2.8) and referenced it from the installed Mono GAC location. Then it was just a matter of a handful of lines of F# (after a bit of spelunking through the Cecil API to find the methods relating to assembly references).

#r @"C:\Program Files (x86)\Mono-2.8\lib\mono\gac\Mono.Cecil\0.6.9.0__0738eb9f132ed756\Mono.Cecil.dll"
#r @"gachelper.dll"
 
open System
open System.IO
open Mono.Cecil
 
let getReferencedAssemblies (asm : string) : string list =
    let ad = AssemblyFactory.GetAssembly asm
    let refs = ad.MainModule.AssemblyReferences
    refs 
    |> Seq.cast 
    |> Seq.fold (fun found (r : AssemblyNameReference) -> 
        let fullPath = ref ""
        match gachelper.GAC.TryGetFullPath (r.Name, fullPath) with
        | false -> found @ [ Path.Combine [|(System.IO.Path.GetDirectoryName asm); r.Name + ".dll"|] ]
        | true -> found @ [!fullPath]        
        ) []

As you can see I’ve also used a little C++/CLI wrapper around the GAC to get access to full paths of installed assemblies (which only works with the Microsoft CLR), but I’ll talk about that in a separate post, or you can grab the code here.

Now, we can call our function to get the set of dependencies, e.g. by using F# interactive, we also happen to be getting the dependencies *of* FSI:

> getReferencedAssemblies @"C:\Program Files (x86)\FSharp-2.0.0.0\bin\fsi.exe";;
val it : string list =
  ["C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll";
   "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\FSharp.Core\v4.0_4.0.0.0__b03f5f7f11d50a3a\FSharp.Core.dll";
   "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\FSharp.Compiler\v4.0_4.0.0.0__b03f5f7f11d50a3a\FSharp.Compiler.dll";
   "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll";
   "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\FSharp.Compiler.Interactive.Settings\v4.0_4.0.0.0__b03f5f7f11d50a3a\FSharp.Compiler.Interactive.Settings.dll";
   "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\FSharp.Compiler.Server.Shared\v4.0_4.0.0.0__b03f5f7f11d50a3a\FSharp.Compiler.Server.Shared.dll";
   "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll"]

This is, of course, the tip of the iceberg in terms of Cecil functionality; there are lots of far more interesting things you can do – like IL extraction and re-writing – things which are impossible to do with the Microsoft reflection API.

I ended up using this code to generate DGML graphs that can be opened and explored using VS2010. This functionality comes “in the box” with VS2010 Architecture Explorer in the Ultimate Edition – but who can afford that…? We can do much the same ourselves by just using the information we get from Cecil and spitting out DGML directly. The files can be opened read-only in the Premium edition for perusal.

For the curious, here’s the (somewhat fugly and imperative) F# code to generate the DGML file. It creates a minimal file that only contains Link elements; Visual Studio will “fill in the blanks” by adding the nodes themselves when you open the file.

let genDgml asm (out : string) =
    let doc = XmlDocument()
    let nsURI = "http://schemas.microsoft.com/vs/2009/dgml"
    let nsmgr = XmlNamespaceManager(doc.NameTable)
    nsmgr.AddNamespace("", nsURI)
    let root = doc.CreateElement("DirectedGraph", nsURI)
    let links = doc.CreateElement("Links", nsURI)
    let rec genRefs added asm =
        getReferencedAssemblies asm
        |> List.fold (fun added dep -> 
            let link = doc.CreateElement("Link", nsURI)
            link.SetAttribute("Source", Path.GetFileNameWithoutExtension asm)
            link.SetAttribute("Target", Path.GetFileNameWithoutExtension dep)
            ignore <| links.AppendChild link
            if not <| (added |> Map.containsKey dep)
            then genRefs (added.Add (dep, false)) dep
            else added
        ) added
    ignore <| genRefs Map.empty asm
    ignore <| root.AppendChild links
    ignore <| doc.AppendChild root
    doc.Save out

The DGML in cluster view

It can be quite enlightening, as well as useful, to see your app dependencies laid-bare before you…

The change

The change itself is simple: static fields can no longer be public. Static fields can still be created, but they must be private.

In pre-2.0 versions of F# it was possible to declare a static field on a type like this:

type MyType() =
    [<DefaultValue>]
    static val mutable public MyProperty : int

Resulting in a type containing a static field, as you’d expect:

    .field public static int32 MyProperty

The code now generates the compiler error:

error FS0881: Static 'val' fields in types must be mutable, private and marked with the '[<DefaultValue>]' attribute. They are initialized to the 'null' or 'zero' value for their type. Consider also using a 'static let mutable' binding in a class type.

Notice that there are already some gnarly aspects to the definition of the property; notably the use of the [<DefaultValue>] attribute, which indicates that the field is un-initialized. This gives us a hint that there might be some inherent problems.

Why do we even need them?

In a word or three: WPF dependency properties.

The recommended way of implementing dependency properties in other .NET languages is to use public static fields, e.g. in C#:

    public static readonly DependencyProperty MyPropertyProperty =
        DependencyProperty.Register( 
          "MyProperty", typeof(int), typeof(MyType));

This is one of the few places where C# is terser than F#. Here we can declare and define the value in one line (ish), whereas F# requires a separate declaration of the field (as above) then initialisation in the static constructor (static do).

Why was it removed?

I got the answer from the horse’s mouth. Don Syme said that:

We deliberately removed the ability to create public static fields in Beta2/RC, because of issues associated with initialization of the fields (i.e. ensuring the “static do” bindings are run correctly, and if they are run, then they are run for the whole file, in the right order, with no deadlocks or uninitialized access when initialization occurs from multiple threads).

You can imagine how this would be a problem; there would need to be a way of ensuring that whichever static field was accessed it caused the static constructor to run, which may itself access static fields. All pretty nasty. In fact, Don mentioned that C# suffers from much the same synchronisation issues, but just tends to be used in a way that means it’s less likely to be noticed!

The alternative

At least in theory it’s possible to create a type that uses static properties rather than static fields to store its registered DependencyProperty information.

type Foo () =
    inherit FrameworkElement()
    static mutable private _myPropertyInternal : DependencyProperty 
    static member this.MyProperty with get () = _myPropertyInternal

Whether or not this works depends very much on how calling code accesses DependencyProperty information. If it uses reflection to access the field directly it will obviously fail. But if it uses a more robust/flexible method then it should be OK. Empirically it seems that the WPF framework code itself does the latter, for instance, when it’s instantiating objects from XAML, and it works properly independently of how it’s implemented.

The conclusion

So the conclusion is “wontfix”: the behaviour is by design. Unfortunately it has the effect that it’s no longer possible to create a type with an identical IL “signature” in both F# and C#. It seems a bit of a shame, but I guess the trade-off is that we’re protected against insiduous initialisation issues, so it will probably turn out to be the right thing in the long term.

Cornell Box in the evening

What is a “global illumination renderer”?

In short; a global illumination renderer attempts to simulate the way that light behaves in the real world. It bounces rays of light around the scene, noting which surfaces are hit, and how each of them affects the ray. Of course real light travels fast – at about the speed of light, in fact – and our simulated rays can’t match that, so although the resulting effect looks natural, it’s not a very efficient way of getting there. Graphics systems that need to be near real-time (i.e. games), use a variety of short-cuts to try and get the same effect without requiring the same amount of number crunching.

Even this implementation is forced to use a couple of techniques to improve performance, I won’t go into them here, as they’re explained pretty thoroughly on the Minilight site.

Interestingly the algorithm uses a Monte Carlo technique to simulate the random path of the ray through the scene and the same technique is used in finance to model how the price of an asset will change through time.

Translating to F#

Room with sun and light, 800 paths per pixel

Some of the ML constructs caused warnings from the F# compiler as I didn’t use the explicit ML compatibility mode. For instance, the use of the ^ operator to concatenate strings:

warning FS0062: This construct is for ML compatibility. Consider using the '+' operator instead. This may require a type annotation to indicate it acts on strings.

Some other changes included:

• Using dot rather than # notation to access class members
• Using square bracket for array element access (array.[n] rather than array.(n))
• Removing let...and for non-recursive bindings

There was also the opportunity to make use of some of the .NET framework classes, things like System.Drawing.Bitmap to write pixels directly into a bitmap and then save it into a .PNG file. Much easier than trying to find something to read the .PPM file that the original version emits.

Potential improvements

One of the most obvious improvements that could be made is to make use of the parallelism support in F# and .NET. The algorithm itself is easily (if not embarrassingly) parallelisable, given that it iterates over the pixels in the output image, and performs independent operations on each of them. Unfortunately I haven’t had a chance to look at this yet – and the Windows VM I’m using only has a single processor anyway, so on a purely selfish note, I wouldn’t see any immediate performance improvements. It should be as simple as changing the pixel loop to use Parallel.For, or creating an async computation expression.

Something else to note: I err’d on the side of caution when it comes to saving intermediate images, so every iteration it creates and writes the file. This will be doing lots of allocation and strictly unnecessary work, especially for simple scenes.

Given this approach is so completely compute bound it would be interesting to see how moving some of the calculations to a GPU would affect it. It might even be possible to use quotations for some of the inner loops and then generate Nvidia intermediate language (PTX) from them – that’s something I’ve been wanting to do for a while.

I did run the code through the Visual Studio 2010 profiler to get a rough idea of where the time was being spent; it looked like the majority was in the leaf of the calculations where numerical operations where being performed on the vectors, which is consistent with what we’d expect.

Use the source

So, here’s the source. No warranties implied, use at your own risk, your mileage may vary, all errors are mine etc, etc.
minilight_fsharp

#I @"C:\winnt\Microsoft.NET\Framework\v2.0.50727\"
#r @"Microsoft.Build.Tasks.dll"
#r @"Microsoft.Build.Utilities.dll"
#r @"Microsoft.Build.Framework.dll"
#r @"Microsoft.Build.Engine.dll"
 
open System
open Microsoft.Build.Framework
open Microsoft.Build.Utilities
open Microsoft.Build.Tasks
 
do
    let t = 
        ResolveAssemblyReference(Silent = true,
            Assemblies = [| upcast TaskItem( ItemSpec="class1" ) |],
            AllowedAssemblyExtensions = [|".dll"|],
            AppConfigFile = "c:\\dev\\myapp\\myapp.exe.config",
            SearchPaths = [|"{GAC}"|]
            )
    match t.Execute() with
    | true  -> printf "%A\n" t.ResolvedFiles
    | false -> printf "Task failed"

The output is:

[|C:\WINNT\assembly\GAC_MSIL\class1\1.1.8.0__120bce90f68b861a\class1.dll|]

The code makes good use of F#’s named constructor arguments, which map to property setters on the object we’ve just created. We can also create the arrays of TaskItems and strings fairly easily, although an explicit upcast is required in order to obtain the ITaskItem (F# doesn’t upcast implicitly like many object oriented languages).

I’ve just discovered that Jomo Fisher wrote about exactly the same thing back in May 2008! He mentions using an object expression in order to provide an implementation of IBuildEngine, which I’m getting away with by setting the Silent property on the ResolveAssemblyReference task, meaning that it never attempts to obtain the logging context from the build engine.

Another gotcha here is the fact that versions of various interfaces including IBuildEngine and ITaskItem exist in both the 2.0.0.0 and 3.5.0.0 versions of the Microsoft.Build.Framework assembly. Be careful that you reference the correct version for the task that you’re calling. Normally it will be the 2.0 versions, in which case you’ll need to use explicit file references in your script, adding the directory to the library include path:

#I @"C:\winnt\Microsoft.NET\Framework\v2.0.50727\"
#r @"Microsoft.Build.Framework.dll"

Rather than partially qualified assembly references:

#r @"Microsoft.Build.Framework"

As the latter will resolve to the latest installed version of the assembly, 3.5, which is not what you want. Look out for errors like:

System.InvalidCastException: Unable to cast object of type ‘Microsoft.Build.Utilities.TaskItem’ to type ‘Microsoft.Build.Framework.ITaskItem’.

Alternatives

The Tools|Options MSBuild verbosity setting