In the second of an unknown number of parts in my series of Beginning F# posts, I’ll be talking about record types. They’re a useful and powerful F# feature that you’ll probably find yourself using very widely. I’ll take a look at what they are, how they’re used and how they integrate with the rest of the language.
Continue reading Beginning F#: Records
Tag Archives: .NET
.NET DLLs Loaded Twice
If, like me, you’re still squeezing yourself into 32-bit Windows processes, you’re probably, also like me, constantly keeping an eye on the virtual address space usage of your application. If you happen to have used something like vmmap to take a peek at your memory contents, maybe you’ve noticed something strange with some .NET assemblies: they’re loaded twice! What’s going on…?
Continue reading .NET DLLs Loaded Twice
Looking back at 2011
Well, we’re a few days into 2012 and no armageddon yet, so it’s probably safe to take a quick glance back over our shoulder at some of the technical stuff that’s flashed past in the preceding 12 months.
Continue reading Looking back at 2011
C++: The oldest new kid on the block
Nobody could have failed to notice the recent resurgence of interest in the C++ programming language. In particular, the recent Build conference was the most we’ve seen Microsoft talking about C++ for several years. Why has a language that’s been languishing in the “prehistoric irrelevance” category for so long suddenly come back into vogue?
Continue reading C++: The oldest new kid on the block
Kinect SDK with F#
The first bit was easy: I’m “lucky” enough to have one of the older Xboxes, which meant I’d had to get a Kinect with separate power, which is the one required by the SDK. Now all I needed was a Windows machine to develop on.
Continue reading Kinect SDK with F#
F# Async: Plays well with others?
OK, quick Async pop quiz: How long does the run function below take to execute?
module Test =
let work i =
async {
System.Threading.Thread.Sleep(500)
return i+1
}
let run _ =
[1..1000] |> List.map work
|> Async.Parallel
|> Async.RunSynchronously
(Waits for people to start FSI and paste in the code…)
My guess would’ve been something just over 500ms; each of the 1000 async tasks would surely sleep in parallel, and then the operation itself is trivial. The additional elapsed time would be dominated by the overhead of thread management, and depend on the number of threads that can physically run in parallel (I’m using an 8-core machine). But still, something close to 500ms…
The actual result? 28000ms. Yes, you read that right: 28 seconds. What on earth did we do wrong?
Continue reading F# Async: Plays well with others?
Mixing it up: when F# meets C#
Of course the idiomatic way to avoid problems at the boundary between your F# code and the outside world is to ensure that you only expose a small set of compatible types. This works pretty well if your clients are also .NET languages. For instance you can do things like exposing your collections as seq, rather than say, a native F# list, and this will mean your collections can be consumed as IEnumerable. The only problem is it means you’ve got the added burden of maintaining this mapping layer, because you’ll no doubt want to use the F# “native” types internally.
So, what options do we have if some of our F# types happen to leak into our public API? Luckily, lots. Let’s take a look at how some of the common F# constructs can be called from C#.
Continue reading Mixing it up: when F# meets C#
Quick post: Using Mono.Cecil and F# to get assembly dependencies
One of the tools I use a lot when doing C++ development and debugging is “dependency walker”; an app that displays all the static dependencies of an executable. These are dependencies created by referencing functions from an import library (.lib file) at compile time. If any of the imported DLLs are missing at run-time, the executable will fail to load, normally with error 2: file not found. Obviously pretty disastrous in production. The .NET equivalent is the binding failure. You can track down what went wrong at runtime using fuslogvw, but I’ve often wished for a tool like ‘depends’ to work out up-front what dependencies are required. Luckily because assemblies includes a list of dependent libraries in the form of a manifest this information can be accessed using reflection.
I’m a big fan of the Mono.Cecil library for doing reflection (and more!) with .NET. I’ve had issues in the past where the built-in .NET reflection (using Assembly.ReflectionOnlyLoad) attempts to load dependent libraries as you iterate over exposed types, even though it’s not supposed to (unfortunately I don’t have a repro to hand). This makes it very difficult to work on an assembly without having all of its dependencies available. Cecil doesn’t have this problem because it accesses the assembly in a lower-level way.
Continue reading Quick post: Using Mono.Cecil and F# to get assembly dependencies
Minilight renderer in F#
Continue reading Minilight renderer in F#
.NET 4.0 Type Equivalence causes BadImageFormatException
I recently discovered a nasty backward compatibility problem with the new type equivalence feature in .NET 4.0. Luckily it’s relatively difficult to hit it if you’re in a pure-C# environment, but if you happen to generate any assemblies directly using IL, you should watch out. Read on for all the gory details.
Continue reading .NET 4.0 Type Equivalence causes BadImageFormatException