I have been meaning to write this post for quite a while now. Since the first announcement of the iOS7 beta I immediately saw the list of new API’s and SpriteKit caught my eye straight away. I only managed to get time to briefly look over the API and saw that is wasn’t the usual trashy API with a million method overloads, internal mutation sucker punch type thing. It seems to be very declarative and intuitive, which makes for a nice change.

It also allows you to use C# in a Read Evaluate Print Loop - REPL. This is nothing new to F# and indeed lots of other languages have REPL’s too. One of the other benefits of ScriptCs is that it also integrates nicely with Nuget allowing you to use your favourite libraries quite easily. Finally there are Script Sacks which can be used to further reduce the amount of code you need to write when working with common frameworks.

What am I talking about here? Maybe it’s Monster Zero or King Ghidorah as it’s sometimes known. No it’s TPL Dataflow!

Yeah, yeah, I have a penchant for being over dramatic and writing quirky intros. This post is about TPL Dataflow otherwise known as TDF. I have blogged about this before in my TDF agent series but I thought it might be worth while returning to it while on the subject of monsters.

Lately on one of my projects I have been doing a lot of stream manipulation, and although I solved the problem quite easily using F# async workflows, there were other solutions available to help solve the problem. I could of used things like async await, TPL Dataflow(TDF), and Reactive Extensions (Rx). This is going to be a short post on using Rx with F#.

What is Edge.js?

Unless you live in a hole you have probably heard of node.js so I’ll not bother to explain what it is or what it does. An interesting project has come to light lately, namely Edge.js. The Edge.js project allows you to connect node.js with .Net.

The creator of Edge.js Tomasz Janczuk sums this up nicely:

An edge connects two nodes
This edge connects node.js with .NET

Currently Edge.js is only available on Windows but there is work underway to bring this to Mono, thus opening up the possibilities even further.

In this post weare going to look as async again, but from the perspective of F#.

Xamarin Evolve 2013

I was going to title this post as ‘Now for something completely different’ but felt that a little bit too Pythonesque, and when I thought about it a bit it isn’t really completely just slightly different, namely C# rather than my usual F# posts.

Right, enough of the waffling, this post is a little tour into the relatively unknown area of async on iOS. Xamarin announced the alpha preview of async await on March 11th this year (2013). There are a couple of blog post floating around on the net if you look around, Rodrigo Kumpera posted a small example here.

In the last post we left at the point where everything was running fine and dandy on the Simulator. So what happens if we compile for the real hardware?

Lets change the active configuration to Debug|iPhone and hit build, what do we get?

Boom!

Error MT2002: Could not resolve: FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (MT2002) (singleview)

So I guess we need to tell it where the FSharp.Core.dll is, lets add a reference to it:

MonoTouch and F# that would be a cool duo right?

Well let me explain what needs to be done and why to get this pair working together.

I heard rumours a while ago that F# and MonoTouch would not play together nicely because of limitations in the ahead of time compilation (AOT). So I thought I would either prove or disprove this with some concentrated hacking. How hard can it be?

As my good friend and colleague Dr. Kewin would quote:

I’ve been on a bit of a break from my normal jovial self due to a shit storm of bad stuff happening that I wont go into here, but hopefully this years going to be awesome. Anyway, here’s the next exciting installment in my series on MonoGame. (Well I find it exciting anyway :-) )

If you remember back to the last post I mentioned the platonic solids, and we created and rendered the tetrahedron, lets recap on what the five solids are:

This time we are going to get into a little bit of code and produce the simplest of all 3d solids, the tetrahedron. I know its not the most exciting of things but we have to start somewhere. The scope of 3D graphics in computers is so vast that its very easy to get lost in the vast piles of research papers.

First lets do some basic setup, if you followed my last post then you will will have a project template to use, this makes this a little easier.

What we are going to do in this post is take a whistle stop tour of getting MonoGame up and running along with a simple demo in F#. Over the last few days I have been building an F# project template for MonoDevelop, this post will also how to get that installed too.

First of all I’m going to assume that you have the following installed:

• Mono 3.0 beta
• MonoDevelop
• MonoDevelop F# language binding

If you don’t have a look at my previous post that explains all that, if you don’t want to build the F# binding from source then you can use the Add-in Manager. If you look in Gallery the language binding section contains the F# language binding. I prefer using the source at the moment as I like to tweak a few things here and there and nosy around in the code.