NuGet BuildMagic: No Binaries in your DVCS

Let me introduce BuildMagic: https://bitbucket.org/IntelliFactory/buildmagic - get 0.0.1 via NuGet

Have you used NuGet? If not, you probably should - with aggressive backing from Microsoft, it's quickly converging to be the default package manager and binary repository for .NET, other similar projects now stand no chance (though they often have more technical merit).

Have you used NuGet package restore? You probably should - pushing binaries into source control is wicked. Especially if you are using DVCS - every fresh pull will have to get all history of your binaries. Especially if you are using Bitbucket which is quite slow on binaries.

Now, have you been disappointed by NuGet package restore requiring you to commit NuGet.exe binary to source control? If so, check out BuildMagic. It is a little workaround for the issue. Unfortunately you still have to commit something redundant (a targets file). But at least now you can say a definite NO to binaries.

A Prettier Printer in ML

To try out something different, I took a shot at writing a pretty-printing module. Of all the papers I found on the subject, perhaps the most accessible is A prettier printer by Wadler. In particular the algebra of documents presented in the paper is very simple and therefore compelling.

I tried to implement these combinators in a OCaml. Unfortunately for OCaml, Wadler's code heavily relies on laziness for searching the exponentially large tree of possible printouts and selecting the optimal one by limited look-ahead and backtracking. The exact same behavior could be obtained in OCaml by mechanically injecting explicit "lazy" everywhere, but it will not be very pretty. I decided to play with a different approach and pre-compute enough information to make every decision on the spot.

The result is ocaml-pretty - see the link for the code and API docs. I tried to maintain the same behavior as in the paper, but have only checked consistency on some small examples. One obvious operational difference is memory use: since the document data structure is strict, pretty-printing cannot help but use O(N) memory in the size of the document. The published Haskell algorithm certainly does better. I did not find an obvious simple fix for this within the approach I adopted, and ended up deciding it does not matter for my purposes.

OCaml standard library has a Format module - this is what you should use for real-world OCaml pretty-printing. Its imperative interface avoids both the O(N) memory overhead and the lazy data structure allocation overhead, and it's always there for OCaml.

WebSharper 2.4.63

WebSharper has seen a few more releases, the latest being 2.4.63.

In a nutshell, you now can:

1. Update HTML templates in sitelets without recompiling the solution and see immediate changes
2. Use VS in Windows Phone 7 and Eclipse in Android templates, taking advantage of more customization opportunities and IDE services such as an integrated debugger
3. Use HttpContext.Current.Session in sitelets and remote/RPC methods
4. Use Visual Studio 2011 Beta, .NET 4.5, Windows 8, F# 3.0, even if you do not have the previous .NET framework or F#

For a full change log, please see here.

WebSharper 2.4.35

WebSharper 2.4.35 is a bugfix release, fixing offline site generation and other important issues. See the complete list of changes.

WebSharper Goes Green: Staph Genome Viz

I have been thoroughly enjoying our latest project at IntelliFactory. Me and Loïc Denuzière, the creator of FPish, are working together for the U Nebraska Medical Center on genetic visualization with HTML5/WebSharper/F#. The organism of interest is Staphylococcus aureus. We have built an interactive chart showing its genome coding sequences and a few thousand transposon insertions performed in the UNMC labs.

You are welcome to play with the latest prototype.

It has been fun to do some graphics and modular arithmetic. We used Raphael to draw SVG, this has worked quite well for us, especially after we "fixed" the Raphael API a little bit for easier use from F# in the latest WebSharper binding. I also am just starting to realize how much I missed in highschool biology.

F# may have a great future in bioinformatics. Type providers easily consuming various data sources, .NET providing decent performance for numerical algorithms, and WebSharper or Silverlight giving a browser-accessible UI.. The only limit is your imagination.

In one of the discussions we had, Loïc made an interesting comment. He said that unlike working in the financial sector, applying F# to bioinformatics is not just interesting, but also useful. And though I have not been an Occupy protester, I cannot help but agree. Realizing that your work may help medical research is definitely a great motivator.

If you are tempted to work with us, please do apply: we are hiring. Interns are especially welcome.

WebSharper Goes Open-Source

WebSharper 2.4, our latest F# web stack based on a F#-to-JavaScript compiler, is out today, and it is open source, with a dual licensing model: you either use AGPL + OSS exceptions or purchase a commercial license. See details at websharper.com, and source at bitbucket.org.

Solving F# Async.StartChild Leak: Futures

I discovered a memory leak in Async.StartChild and here discuss a workaround based on a Future abstraction.

I noticed what appears to be a memory leak in F# standard library function Async.StartChild. This happened in a context of a socket server, where I attempted to perform socket reading and writing in parallel. It seems that memory use slowly grows and memory profiler points to some CancellationTokenSource-related objects not being released.

As a non-leaking alternative, I used my own abstractions. The basic idea is to use synchronizable events. Unfortunately Event is already used in F# to mean something different, so I will use the word Future instead. If you know F# events, the key problem is that subscribing to events after they happen is meaningless, for example this code procuces nothing:

let test () =
    let e = Event<_>()
    e.Trigger(1)
    e.Publish.Add(printf "%i")

In contrast, Future objects retain the value. For simplicity, I allow subscribing and triggering only once. In addition, the sample includes Executor code. I found by experimentation that running short-lived coordination tasks on a single thread instead of the ThreadPool is beneficial. Enjoy: