Programming

So what have I been up to lately? Well, lots of different things. I have been taking it easy on the open source and blogging side of things as its been a hectic time of late in my personal life. This seems to be changing now so I’m starting to get all of the ideas spinning around in my head into physical reality, or virtual reality, or what ever you want to call it. Anyway, here’s the first post on the subject of programming in F# using MonoDevelop and Mono natively on Macs.

If I walk into my garage now and open up a toolbox, whats inside?

Here’s a quick selection:

• Ball-peen hammer
• Jointer plane
• 1/2 inch mortise chisel
• Soldering iron
• Set square
• Low angle block plane
• Torx screw drivers
• Hack saw
• Monkey wrench
• Pipe cutter

Notice it doesn’t just contain:

• A sledge hammer.

Different tools have different purposes, you wouldn’t use a hammer and try to cut down a tree, or use a chisel to hammer a nail.

Deep in the darkest depths lurks an ancient horror, when the time is right it will rise forth and leave you screaming for mercy and begging for forgiveness…

OK, I have a penchant for being over dramatic but in this post I am going to reveal some little known caveats in a well known and much revelled area of F#, agents aka the MailboxProcessor. Gasp!

First let me give you a demonstration:

In the last post I discussed an asynchronous version of the ManualResetEvent and as promised this time we will be looking at an asynchronous version of the AutoResetEvent. I’m using Stephen Toubs post as reference and we will be building a version that is functional in style that maps straight into asynchronous work flows without and conversion or adaptors.

What is an AutoResetEvent?

An AutoResetEvent can be described as a turnstile mechanism, it lets a single waiting person through before re-latching waiting for the next signal. This is opposed to a ManualResetEvent which functions like an ordinary gate. Calling Set opens the gate, allowing any number of threads that are waiting to be let through. Calling Reset closes the gate.

In this post we are going back to the primitive. No it’s not about the same named song by Soulfly, (which incidentally does contains F# notes) but a return to thread synchronisation primitives and their asynchronous counterparts.

We are going to be looking at an asynchronous version of the ManualResetEvent. This was recently covered by Stephen Toub on the pfx team blog. We will be taking a slightly different view on this as we will be using asynchronous workflows which will give us nice idiomatic usage within F#.

In this edition we are going to be doing a taste test, C# vs F#. Oh yeah, if you quickly glanced at the title you may have thought this was a recipe for black scones, as interesting and tasty as that may be, unfortunately its going to be finance related.

I recently presented a paper on the benefits of F#, part of this was a comparison of the famous Black-Scholes equation in both C# and F#. I was mainly going to be looking at code succinctness and the inherent suitability of the language for calculation based work, but there ended up being more to it than that.

This will be the last post on rebuilding the MailboxProcessor using TDF, here’s a quick discussion of the missing pieces…

First, lets start with the simple ones, these don’t really require much discussion.

DefaultTimeout

let mutable defaultTimeout = Timeout.Infinite

member x.DefaultTimeout
   with get() = defaultTimeout
   and set(value) = defaultTimeout <- value

This simply provides a mutable property using Timeout.Infinite as a default setting.

CurrentQueueLength

member x.CurrentQueueLength() = incomingMessages.Count 

Another simple one, this methods uses into the underlying BufferBlock to extract its current queue length using its Count property.

Right, no messing about this time, straight to the code.

Construction

This is pretty straight forward and I don’t want to detract from the important bits of this post, the only thing of note is the cancellationToken which is initialized to a default value using the defaultArg function if the optional parameter cancellationToken is not supplied. The TDF construct that we to use to perform most of the hard work is incomingMessages which is a BufferBlock<'Msg>.

This is going to be a new series on using TPL Dataflow with F#. First a little bit of history and background.

TPL Dataflows heritage and background

TPL Dataflow or (TDF) has been around for quite a while, it first surfaced more than a year ago as the successor to the Concurrency and Coordination Runtime (CCR) and with coming release of .Net 4.5 it will be part of the System.Threading.Tasks.Dataflow namespace. Elements of the now halted project Axum are also present within the design of TDF.

Due to popular demand… well, I had a couple of requests anyway :-) Heres a post inspired by my recent encounters profiling some of the code in Fracture-IO.  I have recently been profiling the code in fracture to remove any so called low hanging fruits. During this time I also noticed an increase in memory allocation.  I remembered I had recently been experimenting in a branch using pipelets as a buffer between the send and receive stages in the Http Server, so I set up a simple test to see if pipelets were contributing to the memory allocation issues I was seeing.  Here’s the simple iteration test code I used for the memory profiling:

SOLID and its relevance to F#

There has been an increasing amount of exposure for F# and functional programming lately.  If you come from an object-orientated background a change in mindset is required when working with functional programming, there is a lot of misinformation on functional languages and their relationship with object-orientated design. In this post we run quickly through SOLID to see if these object-orientated principles apply to F#, and if so, how.

I recently wrote an article for Developer Fusion on the changes in mindset required when moving from C# to F#.

The article has proved to be more more popular than I envisaged.  I think a lot of .Net developers are interested in F# but are unsure on the path to take when trying to accomplish this.  For me it was almost a leap of faith, I saw the potential benefits and just jumped right in.