Planet F#

type AuctionMessage = | Offer of int * AsyncAgent // Make a bid | Inquire of AsyncAgent // Check the status
and AuctionReply = | StartBidding | Status of int * DateTime // Asked sum and expiration | BestOffer // Ours is the best offer | BeatenOffer of int // Yours is beaten by another offer | AuctionConcluded of // Auction concluded AsyncAgent * AsyncAgent | AuctionFailed // Failed without any bids | AuctionOver // Bidding is closed let timeToShutdown = 3000
let bidIncrement = 10

This is the format of the messages that the clients can send and the action agent can reply to. F# is really good at this sort of thing. First, we need an auction agent:

let auctionAgent seller minBid closing = let agent = spawnAgent (fun msg (isConcluded, maxBid, maxBidder) -> match msg with | Offer (_, client) when isConcluded -> client <-- AuctionOver (isConcluded, maxBid, maxBidder) | Offer(bid, client) when not(isConcluded) -> if bid >= maxBid + bidIncrement then if maxBid >= minBid then maxBidder <-- BeatenOffer bid client <-- BestOffer (isConcluded, bid, client) else client <-- BeatenOffer maxBid (isConcluded, maxBid, maxBidder) | Inquire client -> client <-- Status(maxBid, closing) (isConcluded, maxBid, maxBidder)) (false, (minBid - bidIncrement), spawnWorker (fun _ -> ()))

Notice that, if the action is concluded, the agent replies to offers by sending an AuctionOver message. If the auction is still open, then, in case the bid is higher than the max, it sets a new max and notify the two parties involved; otherwise it notifies the bidder that the offer wasn’t successful. Also you can ask for the status of the auction.

This is what the code above says. Maybe the code is simpler than words. Anyhow, we need to treat the case where no message is received for some amount of time.

agent <-- SetTimeoutHandler (closing - DateTime.Now).Milliseconds (fun (isConcluded: bool, maxBid, maxBidder) -> if maxBid >= minBid then let reply = AuctionConcluded(seller, maxBidder) maxBidder <-- reply seller <-- reply else seller <-- AuctionFailed agent <-- SetTimeoutHandler timeToShutdown (fun (_:bool, _:int,_:AsyncAgent) -> StopProcessing) ContinueProcessing (true, maxBid, maxBidder)) agent

We start by waiting for the amount of time to the closing of the auction. If we get no messages, then two things might happen: we have an offer that is more than the minimum or we don’t. If we do, we tell everyone that it’s finished. Otherwise, we tell the seller that its item wasn’t successful. In any case, we prepare the agent to shutdown by setting its next timeout to be timeoutToShutdown.

It is interesting that we set the timeout handler inside the timeout handler. This is not a problem because of the nature of message processing (aka it processes one message at the time).

We then need a bunch of of symbols …

module Auction = let random = new Random() let minBid = 100 let closing = DateTime.Now.AddMilliseconds 10000. let seller = spawnWorker (fun (msg:AuctionReply) -> ()) let auction = auctionAgent seller minBid closing

Not a very smart seller we have here … Next up is our definition of a client.

let rec c = spawnAgent ( fun msg (max, current) -> let processBid (aMax, aCurrent) = if aMax >= top then log "too high for me" (aMax, aCurrent) elif aCurrent < aMax then let aCurrent = aMax + increment Thread.Sleep (1 + random.Next 1000) auction <-- Offer(aCurrent, c) (aMax, aCurrent) else (aMax, aCurrent) match msg with | StartBidding -> auction <-- Inquire c (max, current) | Status(maxBid,_) -> log <| sprintf "status(%d)" maxBid let s = processBid (maxBid, current) c <-- SetTimeoutHandler timeToShutdown (fun _ -> StopProcessing) s | BestOffer -> log <| sprintf "bestOffer(%d)" current processBid(max, current) | BeatenOffer maxBid -> log <| sprintf "beatenOffer(%d)" maxBid processBid(maxBid, current) | AuctionConcluded(seller, maxBidder) -> log "auctionConcluded" c <-- Stop (max, current) | AuctionOver -> log "auctionOver" c <-- Stop (max, current)) (0,0)
c

Something that I like about agents is the fact that you need to understand just small snippets of code at the time. For example, you can read the processing for BestOffer and figure out if it makes sense. I have an easy time personalizing them as in : “Ok, the guy just got a notification that there has been a better offer, what is he going to do next?”.

The code should be self explanatory for the most part. In essence, if you can offer more, do it otherwise wait for the auction to end. I’m not even sure the processing is completely right. I confess I’m just trying to do the same as Matthews code from the link above.

We can then start up the whole thing and enjoy the cool output.

open Auction (client 1 20 200) <-- StartBidding
(client 2 10 300) <-- StartBidding
(client 3 30 150) <-- StartBidding
Console.ReadLine() |> ignore

Now for the nasty part. Implementing the framework.

Modeling DSLs with F# and Units of Measure

Thu, 09 Jul 2009 17:00:00 GMT

Very recently on Lambda the Ultimate, they had a really good post describing Soccer-Fun, a way to teach functional programming (pdf). The premise is very simple and is described as the following:

...a domain specific language for simulating football. ... We have used Soccer-Fun in teaching during the past four years. We have also experience in using Soccer-Fun for pupils in secondary education. ... It engages students to problem solving with functional programming because it allows them to compete at several disciplines: the best performing football team can become champion of a tournament; the best written code can be awarded with a prize; students can be judged on the algorithms used. This enables every student to participate and perform at her favourite skill. ... It can be implemented in any functional programming language that supports some kind of windowing toolkit.

This serves as an introductory course in functional programming called “Abstraction and Composition in Programming”. This course covers what you might consider classic functional programming materal including basic types, algebraic data types, high order functions, overloading, recursion and so on. But what’s interesting as well is that it has been applied to secondary school aged students as well. A course such as this which engages through the use of a well known subject such as soccer or football, depending on your nationality of course.

Although the paper discussed here is implemented using the Clean programming language, which has striking similarities to Haskell, another purely functional programming language. As I read the document, I wondered how F# as a language would fare to implement such a DSL, especially with the use of Units of Measure.

Introducing Units of Measure

One feature of F# that was introduced in the September 2008 CTP release of F# was static checking and inference of Units of Measure. The idea is that we have defined in the F# libraries the International System of Units (SI) such as meters, seconds, and kilograms and apply them in ways that they are statically checked and inferred without much ceremony, but as well to create and apply our own such as feet, gallons or whatever we so choose.

For example, I could specify my weight in pounds in F# Interactive as the following:

> [<Measure>] type lb;; [<Measure>]
type lb > let weight = 180.0<lb>;; val weight : float<lb> = 180.0

As you can tell from above, it inferred that my weight is in fact a floating point in pounds, and that I weight approximately 180. What’s powerful about this concept is that I cannot then compare it with just another float, it must be of the same type as we note below:

> weight = 180.0;; weight = 180.;; ---------^^^^ stdin(79,10): error FS0001: This expression has type float
but is here used with type float<lb>

Andrew Kennedy, one of the forces behind this effort and researcher at Microsoft Research Cambridge, blogged about this in a multi-part series covering:

Now that you’re back, you might ask how this applies in this situation. Can we use this to our advantage when modeling such things as basic elements of soccer using units of measure?

Applying to Soccer Fun

Indeed many of the calculations required for Soccer Fun do require a bit of hard type units. For example, let’s look at how to model such things as specifying the size of the football field. As not all fields are the same size, we can model it in meters such as the following. We’ll note that F# already defines the International System of Units (SI) in the SI module in F# in the FSharp PowerPack assembly. Using F# Interactive, we can get up and running to use these standard measurements by doing the following:

> #r "FSharp.PowerPack.dll"
- open Microsoft.FSharp.Math.SI;;

Now getting back to our solution, we can now specify our field dimensions as the following:

type Meter = float<m>
type FieldWidth = Meter
type FieldLength = Meter
type FootballField = { Width : FieldWidth; Length : FieldLength }

I followed the intent closely of the paper to create type aliases for both the Meter as well as the field’s length and width. We can then create a record type to hold both our width and length of our field in floating point meters.

Another example is that both players and the ball both travel at a certain speed and in a certain direction. We need the ability to not only calculate the speed along the surface, but also the speed above the surface in a full three dimensions as well as the direction. We might implement this as the following:

type Radian = float
type Angle = Radian type Velocity = float<m/s>
type Speed = { Direction : Angle; Velocity : Velocity }
type Speed3D = { Speed2D : Speed; Speed3D : Velocity }

Above, I described that our angles will be calculated in radians, and our velocity will be calculated in meters per second. With those two data types in hand, we can then store the speed of the players using the Speed type and the ball using the Speed3D type as it has a tendency to travel in three dimensions whereas the players tend to travel on only two.

Conclusion

This of course is only a start to look at such a concept for how to implement this in F#, but it gives us another tool in our belt to model our data much more accurately in the domain in which we are in. The conciseness of the language makes it an ideal candidate for scientific DSLs where such units of measure are important, but as we can see from this example, it could even apply to the general physics of game play.

Active Patterns (F#)

Thu, 09 Jul 2009 16:59:00 GMT

In this video, programming writer, Gordon Hogenson, continues the discussion of patterns by talking about active patterns, which you can use to customize and extend F#’s pattern matching capabilities. Active patterns are an amazingly flexible language feature, and in this video we just scratch the surface of what can be done with them. You can learn more in the topic: Active Patterns.

Gordon would also like to thank Chris Smith and Brian McNamara, of the F# team, for giving him some ideas for how to use active patterns. Some similar examples to those in the video are discussed in F# team blog postings, such as in Chris Smith’s blog posting on active patterns. For those interested in exploring further, you can read a paper on active patterns by Don Syme, James Margetson, and Gregory Nemerov.

Kathleen McGrath
Visual Studio User Education
http://blogs.msdn.com/kathleen/

Rapid prototyping of DSLs in F# - Part III

Thu, 09 Jul 2009 14:31:40 GMT

The third part of "Rapid prototyping of DSLs in F#" presents the semantic checker for Simply, a small programming language with functions and expressions.

not an f# post

Thu, 09 Jul 2009 05:46:15 GMT

Yes, ladies and gentlemen, i have a day job, and sometimes i must put down the f# koolade and do real work. well... maybe not "real" work per se, but... Anyway, to that end... I've spent some time scratching my head about the best way to integrate a validation mechanism into bistro. Now... there's not an [...]

Interfaces made convenient by type constraints

noreply@blogger.com (Joh.) — Wed, 08 Jul 2009 05:49:00 GMT

If my previous entry convinced you to make extensive use of interfaces, you may have encountered a problem, namely that calling methods implementing interfaces requires casting:

let link = new Link("link", config, ...)
// We want to write:
link.Send(data)
// But that does not compile. Instead, we must write:
(link :> ILinkOutput).Send(data)

The bad news are that there is no work around. The good news is that this situation does not happen to often in practice, as the creator of a link is in general not the user. New instances are often forwarded to other objects or functions, which will see them as ILinkOutput, thus not requiring a cast:

let register (p : ISender) (l : ILinkOutput) =
p.AddOutputLink(l) // OK: p is an ISender, no need for explicit cast
l.ConnectInputTo(p) // OK: l is an ILinkOutput, no need for explici cast

let link = new Link(...)
let process = new Process(...)
register process link // OK: process and link automatically upcasted

Now, what happens if we have a function taking a process and which needs to use two of its interfaces? There are two obvious solutions, which are not so pretty.

Ugly-ish:

let register (p1 : ISender) (l : Link) (p2 : IReceiver) =
p1.AddOutputLink(l) // Nice
p2.AddInputLink(l) // Nice
(l :> ILinkOutput).ConnectInputTo(p1) // Not so nice
(l :> ILinkInput).ConnectOutputTo(p2) // Not so nice

Uglier:

let register (p1 : ISender) (l1 : ILinkOutput) (l2 : ILinkOutput) (p2 : IReceiver) =
p1.AddOutputLink(l) // Nice
p2.AddInputLink(l) // Nice
l1.ConnectInputTo(p1) // Nice (is it?)
l2.ConnectOutputTo(p2) // Nice (is it?)

// Set up two processes communicating with each other.
// As links are uni-directional, use two links.
let p1 = new Process(...)
let p2 = new Process(...)
let link_p1_p2 = new Link(...)
let link_p2_p1 = new Link(...)

// p1 -> p2
register p1 link_p1_p2 link_p2_p1 p2 // Oops!!!
// p2 -> p1
register p2 link_p2_p1 link_p1_p2 p1 // Oops!!!

So many 1s and 2s... We really meant to write:

// p1 -> p2
register p1 link_p1_p2 link_p1_p2 p2
// p2 -> p1
register p2 link_p2_p1 link_p2_p1 p1

The correct solution uses generics and type constraints:

let register
(p1 : ISender)
(l : 'L
when 'L :> ILinkInput
and 'L :> ILinkOutput)
(p2 : IReceiver) =

p1.AddOutputLink(l)
p2.AddInputLink(l)
l.ConnectInputTo(p1)
l.ConnectOutputTo(p2)

// Set up two processes communicating with each other.
// As links are uni-directional, use two links.
let p1 = new Process(...)
let p2 = new Process(...)
let link_p1_p2 = new Link(...)
let link_p2_p1 = new Link(...)

// p1 -> p2
register p1 link_p1_p2 p2
// p2 -> p1
register p2 link_p2_p1 p1

Another use of type constraints is for cases when you want to pass lists of ISenders to a function.

Problem:

let sendAll (ps : ISender list) data =
ps
|> List.iter (fun p -> p.Send(data))

let p1 = new Process(...)
let p2 = new Process(...)

sendAll [ (p1 :> ISender) ; (p2 :> ISender) ] data // Blah!

Solution:

let sendAll (ps : 'S list when 'S :> ISender) data =
ps
|> List.iter (fun p -> p.Send(data))

let p1 = new Process(...)
let p2 = new Process(...)

sendAll [ p1; p2 ] data

Which can also be written:

let sendAll (ps : #ISender list) data =
ps
|> List.iter (fun p -> p.Send(data))

let p1 = new Process(...)
let p2 = new Process(...)

sendAll [ p1; p2 ] data

Breaking up classes using interfaces

noreply@blogger.com (Joh.) — Wed, 08 Jul 2009 04:23:00 GMT

When I started writing F# programs whose code span over multiple files, I was surprised to see that the order of compilation of these files matters. If the code in file B.fs refers to types or functions in A.fs, then A.fs must be compiled before B.fs.

Now, what happens if A.fs and B.fs depend on each other? In this case, you have a problem. The easy fix is to merge the two files, but this solution does not scale well. Another solution is to break code into smaller pieces, building small "islands" of circular dependencies, which can each be moved into their own file. Easily said, but not so easily said.

Consider an application involving processes and links. Processes can be executed, and can communicate with each other using unidirectional links.

The code might look like this:

type Process(name, config, ...) =
// Construction
...

// Methods
// Connection to links
member x.AddInputLink(link : Link) = ...
member x.AddOutputLink(link : Link) = ...

// Control execution
member x.ExecuteInSomeWay(args) = ...
member x.ExecuteInSomeOtherWay(args) = ...
member x.CheckIsReady() = ...
member x.MarkAsReady() = ...

// Debugging, and other stuff...
member x.ToggleDebugging(b) = ...
member x.SetDebugOutput(o) = ...
...

and type Link(name, config, ...) =
// Construction
...

// Methods
// Connection to processes
member x.ConnectOutputTo(p : Process) = ...
member x.ConnectInputTo(p : Process) = ...

// Read/Write data
member x.Send(data) = ...
member x.Receive() = ...

// Debugging ...
member x.ToggleDebugging(b) = ...
member x.SetDebugOutput(o) = ...
...

As Process and Link are mutually dependent, their code must be all in one file. That may seem OK at first, but things will become harder to manage as more code is added over time.

A first solution is to introduce interfaces for Process and Link, simply duplicating all their method signatures, and replace all occurrences of classes Process and Link by their interfaces. The interfaces can be moved to a separate file, which should be shorter, as it contains no code. Classes Process and Link can now each live in separate files.

Interfaces.fs:

type IProcess =
// Connection to links
abstract AddInputLink : ILink -> ...
abstract AddOutputLink : ILink -> ...

// Control execution
abstract ExecuteInSomeWay : Args -> ...
...

// Debugging, and other stuff...
member x.ToggleDebugging : bool -> unit
...

and type ILink =
// Connection to processes
abstract ConnectOutputTo Process -> unit
...

Process.fs:

open Interfaces

type Process(name, config, ...) =
// Construction
...

// Interface implementations
interface IProcess with
member x.ExecuteInSomeWay(args) = ...
...

Link.fs:

open Interfaces

type Link(name, config, ...) =
// Construction
...

// Interface implementation
interface ILink with
member x.ConnectOutputTo(p : IProcess) = ...
...

Still, Interfaces.fs may be excessively long, and we may end up in a situation where all interfaces are defined in one large file. Not very pleasant.

The next step consists of breaking up the interfaces. The debugging-related methods obviously belong to a IDebugable interface, which need not be concerned with the details of processes and links.

A process which is connected to the input side of a link has no need to have access to the methods taking care and transferring data from the link to the process, which indicates that ILink could be split in e.g. IInputLink and IOutputLink.

There is another case of excessive method exposure. Links do not control the execution of processes, that's the task of the scheduler. The final decomposition may look as shown below.

IActivable.fs:

type IActivable =
abstract CheckIsReady : unit -> bool
abstract MarkAsReady : bool -> unit

IExecutable.fs:

type IExecutable =
abstract ExecuteInSomeWay : Args -> ...
abstract ExecuteInSomeOtherWay : Args -> ...

InputInterfaces.fs:

type IReceiver =
abstract AddInputLink : ILinkInput -> unit

and type ILinkInput =
abstract Receive : unit -> Data
abstract ConnectOutputTo : IReceiver -> unit

OutputInterfaces.fs:

type ISender =
abstract AddOutputLink : ILinkOutput

and type ILinkOutput =
abstract Send : Data -> unit
abstract ConnectInputTo : ISender -> unit

The techniques shown here are by no means specific to F#, and are part of the "proper programming" techniques every object-oriented programmer should know and use. Before using F#, I almost exclusively used interfaces for polymorphism, on "as-needed" basis. The fact is, interfaces are also useful for modular programming.

Decomposing programs into interfaces and implementation helps writing reusable, readable code. It does have a cost, though, as it requires more typing. As long as keyboards remain cheaper than brains, the benefits should outweigh the costs.

Concurrency on a single thread

noreply@blogger.com (Joh.) — Wed, 08 Jul 2009 03:21:00 GMT

When I wrote my article about concurrency, I did a bit of searching to find out how to use multi-threading in F#. One of the hits was a blog entry on HubFS by gneverov titled "Hell Is Other Languages : Concurrency on a single thread". At that time, I was a bit confused by the article. Why would one want single-threaded concurrency when we already had multi-threaded concurrency? Part of the answer lies in reactive programming.

Recently, I read an article by Shawn Hargreaves, "Pumping the Guide", where he describes some design issues with using the Guide on the Xbox. The Guide is the part of the Xbox GUI which is used for performing common operations, such as entering text, selecting a device where game data is saved, seeing which of your friends are online and what they are doing... The problem is to have the game still running in the background while the Guide is opened.

The solution chosen by the XNA team was to make calls to the Guide non-blocking. This however makes it harder for game developers to use it, as it forces them to keep track of the application state explicitly, including both the state of the game and the state of the Guide.

Kevin Gadd's shows a elegant solution to this problem in C# using custom enumerators in an article aptly named "Asynchronous programming for xna games with Squared.Task".

Kevin's implementation in C# is as pretty as it can get, but it would probably look even better in F# using asynchronous computations. Although the async { ... } notations is exactly what we want, the Async functions do not seem to support the kind of single-threaded concurrency that Kevin's Square.Task does.

The code by gneverov however should be easy to modify to execute one single step in one of the active tasks, if it does not already support that.

Problems with fslex and fsyacc

Flying Frog Consultancy Ltd. — Mon, 06 Jul 2009 18:26:00 GMT

Back in 2004, we wrote a mini Mathematica implementation in OCaml in only four days. For fun, we decided to port this OCaml program to F#. Incredibly, porting just the lexer and parser from OCaml to F# has taken longer than it took us to write the entire original OCaml code! The reason is simply that OCaml has an incredibly powerful and mature suite of compiler tools for generating lexers and parsers whereas F# does not.

Given that our original OCaml lexer and parser for Mathematica source code were written using ocamllex and ocamlyacc, it seemed obvious to translate the code into fslex and fsyacc. However, there are some serious problems with the F# versions of these tools:

Incomplete: the regular expression implementation in fslex is incomplete, not allowing portions of a match to be named and used in the corresponding action.
Unintegrated: there are no Visual Studio modes for these tools and, consequently, development is cumbersome compared to OCaml development with Emacs.
Unreliable: the fslex and fsyacc tools are not officially part of the F# distribution and, although they are used in the F# compiler itself, they are buggy: reporting bogus errors where there are none.
Slow: where OCaml takes 0.05s to generate and compile the lexer and parser, F# takes over 10s. That is 200× slower! Suffice to say, that seriously bogs down development.

One potential advantage of fslex is that simply adding --unicode on the command line generates a lexer for unicode rather than ASCII text. However, we have no use for unicode and, consequently, have not tested this. In contrast, the conventional OCaml solution is to drop the byte-only ocamllex tool in favour of a different lexer generator such as the ulex unicode lexer-generating syntax extension.

There is another choice for lexing and parsing in F#: the FParsec monadic parser combinator library by Stephan Tolksdorf. The current release of this library does not compile with the F# May 2009 CTP but the latest version in the development repository does. The project is split into C# and F# code in order to write some performance-critical sections in C# but this means that it is distributed as two separate DLLs. We shall investigate this option in the future...

Patterns and Match Expressions in F#

Mon, 06 Jul 2009 15:58:00 GMT

In this video, programming writer, Gordon Hogenson explains and gives examples of patterns in F# and explains the use of the match expression to control branching based on patterns in data. But first, a disclaimer Gordon wanted to make: “Regrettably, I have not been able to retrain myself yet to use the word value instead of variable. In F#, all values are immutable by default, so it’s not really correct to use the term variable, as I do in the video.” See Part 2 of this video: http://channel9.msdn.com/posts/kmcgrath/Active-Patterns-F/

You can also learn more in the topics Patterns and Match Expressions.

Kathleen McGrath
Visual Studio User Education
http://blogs.msdn.com/kathleen/

Discoveries This Week 07/05/2009

Sun, 05 Jul 2009 14:11:00 GMT

If you find yourself in the Boston area tomorrow, Monday July 6th, come see Amanda Laucher’s New England F# User’s Group talk. She is currently working on a new book for O’Reilly: F# in a Nutshell.

Luca Bolognese’s Series on LAgent: Parts One, Two, Three, Four, Five and Six

I built myself a little agent framework based on F# MailboxProcessors. I could have used MailboxProcessors directly, but they are too flexible for my goal. Even to write a simple one of these guys, you need to use async and recursion in a specific pattern […]

Each article is a worthwhile read, containing at least one tasty morsel of F# information. For example, I'm sure to use the dynamic function loading from part six sometime in the near future.

Slides for Robert Pickering’s Tech Days Paris Talk: Introduction to F# and Collective Intelligence

Hello. I’m F#. Friendly, Approachable. Built in .NET.

I enjoyed the quotes from Don Syme, Eric Meijer, and Julien Laugel. The collective intelligence example was also very well demonstrated. Most of all, I enjoyed having a chance to see how Robert Pickering puts together a F# presentation. I particularly like his style of annotating functions.

Oliver' Strum’s Channel 9 Talk on F# – Taking Efficiency One Step Further

Microsoft Research describes F# as "a scripted / functional / imperative / object-oriented programming language". Combining all those aspects in one language is certainly not an easy task, but they've done a good job of it.

In this talk, Oliver covers the basics well. He also does a very good job at conveying why the functional programming constructs in F# are so important.

Matthew Podwysocki’s F# - Async Running with Continuation Scissors

[…] let’s walk through a simple example of using the Twitter HTTP API to get a user timeline using F# asynchronous workflows.

A fast ride through the basics of using the twitter HTTP API in F#. I hadn’t previously seen an example of Async.RunWithContinuations. This error handling style is quite elegant.

The twits - Yet another Twitter app

Sat, 04 Jul 2009 01:26:35 GMT

Taking its name from twitter, with a large nod towards Roald Dahl's cautionary tale, the twits is a twitter app that lets you visualize you network of friends on twitter. It’s available to try here. Before we go any further you should know that this software is in alpha status, i.e. not for the fait hearted. Here’s an image of the results below.

As you can see it does a reasonable job of separating other developers I follow from people at the guardian I follow (the coloured lines & text are added afterwards).

The app is designed to run local and uses .NET 3.5, F#, and WPF, if you’re running vista or win7 it’ll probably work okay out of the box, any other else and you’ll need install .NET 3.5 etc. Caveat: if you have more than about 50 friends (people you follow) it’s unlike to be able to map them all at once, first there’s the twitter API limits, then there’s the fact the algorithm is exponentially expensive in processing time and also you just won’t be able to find them on the screen. I may consider doing a Silverlight port, if it becomes popular, to make it more accessible. The main idea of the app is to show off some of Collective Intelligence work, this app is another example of hierarchical clustering and also uses optimization. There’s also some interesting use of async workflows. If you want to try the source it’s available on git hub. I've lots of ideas for future version - but not much time to develop them. Licence is GPL 2.0, if you'd like that to change, lobby me. If you like it let me know!

UPDATE: The download was broken because of a missing dll, this is fixed now. Thanks to @samjiman for noticing.

LAgent: an agent framework in F# – Part VI – Hot swapping of code (and something silly)

Fri, 03 Jul 2009 11:23:00 GMT

Hot swapping of code

Let’s get back a couple of steps and consider what happens when you get an error. Sure, your agent will continue processing messages, but it might be doing the wrong thing. Your message handling code might be buggy.

Ideally you’d want to patch things on the fly. You’d want to replace the message processing code for an agent without stopping it.

Here is how you do it:

let counter2 = spawnAgent (fun msg state -> printfn "From %i to %i" state (state + msg);
 state + msg) 0
counter2 <-- 2 counter2 <-- SetAgentHandler(fun msg state –>
 printfn "From %i to %i via multiplication" state (state * msg); msg * state)
counter2 <-- 3

Which generates:

From 0 to 2
From 2 to 6 via multiplication

After the agent receives a SetAgentHandler message, it switch from a ‘+’ agent to a ‘*’ agent on the fly!! All the messages that come after that one gets multiplied to the state. Also, the state is preserved between changes in behavior.

It might not be immediately apparent how to load a function at runtime, but it is really simple. Imagine that I get the data on the function to load from somewhere (i.e. a management console UI).

let assemblyNameFromSomewhere, typeNameFromSomewhere, methodNameFromSomewhere = 
 "mscorlib.dll", "System.Console", "WriteLine"

I can then use it to dynamically load a message handler (in this case Console.Writeline).

let a = Assembly.Load(assemblyNameFromSomewhere)
let c = a.GetType(typeNameFromSomewhere)
let m = c.GetMethod(methodNameFromSomewhere, [|"".GetType()|])
let newF = fun (msg:string) (state:obj) -> m.Invoke(null, [| (msg:>obj) |])

And then it is as simple as posting a SetAgentHandler.

counter2 <-- SetAgentHandler(newF)
counter2 <-- "blah"

Now our counter2 agent has become an echo agent on the fly, having loaded Console.WriteLine dynamically. Note how the agent moved from being a ‘+’ agent taking integers to being a ‘*’ agent taking integers to being an ‘echo’ agent taking strings. And it didn’t stop processing messages for the whole time.

Obviously, you can do the same thing with workers:

echo <-- SetWorkerHandler(fun msg -> printfn "I'm an echo and I say: %s" msg)
echo <-- "Hello"

And parallelWorkers:

parallelEcho <-- SetWorkerHandler(fun msg -> tprint ("I'm new and " + msg))
messages |> Seq.iter (fun msg -> parallelEcho <-- msg)

A silly interlude

As a way to show some agents talking to each other, here is a simple program that simulates marital interactions (of the worst kind):

let rec husband = spawnWorker (fun (To, msg) -> printfn "Husband says: %s" msg; To <-- msg)
let rec wife = spawnWorker (fun msg -> printfn "Wife says: screw you and your '%s'" msg)
husband <-- (wife, "Hello")
husband <-- (wife, "But darling ...")
husband <-- (wife, "ok")

Which produces:

Husband says: Hello
Husband says: But darling ...
Wife says: screw you and your 'Hello'
Wife says: screw you and your 'But darling ...'
Husband says: ok
Wife says: screw you and your 'ok'

And yes, you cannot expect messages to be in the right sequence … Next up is an auction application.

WiX again.

noreply@blogger.com (Joh.) — Thu, 02 Jul 2009 06:24:00 GMT

In my previous post I expressed my disappointment with WiX. However, after an additional day of struggling with it, I may change my mind. I managed to find a pretty straightforward solution to (almost) all my problems. Getting there wasn't straightforward at all, though.

Here are the lessons I learned in the process:

Do not overwrite existing files using <File> elements.
When your software gets uninstalled, it will remove your file, but the old file won't be restored. The solution that first popped up in my mind, namely to backup old files, isn't as easy as it seems. The problem is that the backup copy will be left behind after the software gets uninstalled.

<CopyFile> is not your friend.
...at least as far as backing up existing files goes. I tried to back up the old file by copying it into my application's folder using CopyFile, and failed miserably. Maybe I missed something, but it seems CopyFile is designed to make copies of the files you install, not of existing files.

<CustomAction> is way too complex for its own good (and yours).
CustomAction can be used in many different ways, using slightly different syntaxes. I attempted to use it to backup files, and finally succeeded. It wasn't easy. I tried to use it to run a command (COPY), but it failed. Same problem with other commands such as REN and DEL. No success running batch files either. I tried running a jscript, and that failed too. Since the creator pf WiX advises against using scripts in custom actions, I did not insist. I ended up using "xcopy.exe", which worked (with a catch: the target must be an existing directory, otherwise xcopy demands to interact with the user, and we don't want that).

I found ONE use of CustomAction, and I am not planning on trying out other uses. At least not for a while.

<RemoveFile> is your friend.
Unlike CopyFile, it's easy to use to clear up stuff in your application's folder. I used it to remove the backup after restoring it during uninstallation.

In case you wonder how to handle back-ups in WiX, that's the way I did it:

<Property Id='XCOPY'>xcopy.exe</Property>
...
<CustomAction Id='Backup'
Property='XCOPY'
ExeCommand='"[ExistingFolder]PlugIn.dll" "[OldFiles]" /Y'
Result='check'
Execute='deferred' />

<CustomAction Id='Install'
Property='XCOPY'
ExeCommand='"[NewFiles]PlugIn.dll" "[ExistingFolder]" /Y'
Result='check'
Execute='deferred' />

<CustomAction Id='Restore'
Property='XCOPY'
ExeCommand='"[OldFiles]PlugIn.dll" "[ExistingFolder]" /Y'
Result='ignore'
Execute='deferred' />

<InstallExecuteSequence>
<Custom Action='BackupPlugIn' Before='InstallPlugIn'>Not Installed</Custom>
<Custom Action='InstallPlugIn' After='InstallFiles'>Not Installed</Custom>
<Custom Action='RestorePlugIn' Before='RemoveFiles'>Installed</Custom>
</InstallExecuteSequence>

...
<Directory Id='NewFiles' Name='New Files'>
<Component Id='NewFiles' Guid='...'>
<File Id='NewFile' Name='Plugin.dll' Source='build/PlugIn.dll' />
</Component>
</Directory>

<Directory Id='OldFiles' Name='Old Files'>
<Component Id='OldFiles' Guid='...'>
<CreateFolder />
<RemoveFile Id='CleanUpBackup' Name='PlugIn.dll' On='uninstall' />
</Component>
</Directory>

Note how I avoided overwriting files in the "Component" elements. I do that using CustomAction instead, both when installing my plug-in and when restoring the old one.

Something that's missing are rollback actions. There should be one for each deferred action, namely an action removing the xcopy-ed file. I don't know of any standard program to remove files on Windows, and I'd rather not write one myself. Where is "rm"?

UPDATE:

WiX experts are probably shaking their heads when they read this code:

<Custom Action='RestorePlugIn' Before='RemoveFiles'>Installed</Custom>
</InstallExecuteSequence>

While it does do what I intended when the user removes the software, it is also executed when users perform other actions than install or uninstall, such as repair an installation. As a result, an attempt to repair an installation will restore the old plug-in, which of course is more likely to destroy the installed software...

F# BootCamp – Questions and Answers – part IV – Structural comparison

Thu, 02 Jul 2009 04:37:10 GMT

This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at structural comparison and structural equality.

Question 6: Please describe the terms “Structural Comparison” and “Structural Equality”.

This was a simple question. Basically the answer is F# provides a default implementation for IComparable and .Equals() for all custom types. This default implementation compares all public fields of the two instances. Let’s consider some samples:

Tuples

let a = 3,4,"foo"
let b = 3,4,"bar" printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false

Records

type MySimpleRecord = { a: int; b: int;} type MyCompositeRecord = { x: string; y: int; z: MySimpleRecord} let a = { x = "Test"; y = 3; z = {a = 1; b = 4;}} let b = { x = "Test"; y = 3; z = {a = 1; b = 2;}} // Structural comparison
printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false printfn "Min(a,b) = %A" (min a b)
printfn "compare(a,b) = %d" (compare a b)

Lists

let a = [3; 2; 4; 5]
let b = [3; 2; 4; 3; 3] // Structural comparison
printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false printfn "Min(a,b) = %A" (min a b)
printfn "compare(a,b) = %d" (compare a b)