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:
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!
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.
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.
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.
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.