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?
Just what do you think you're doing, Dave?
I finally got around to taking a look at the Kinect SDK
the other day, partly because I was interested to see how the API looked from F#. Unfortunately getting it going turned out to be more of a pain than I was expecting.
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.
Lock; literal images 'r' us
While Googling for an obscure Windows function the other day, I came across this
fantastically useful repository of undocumented WinAPI functions, put together by Geoff Chappell. I’m not sure how I hadn’t discovered it before.
One of the functions that immediately caught my eye was LdrLockLoaderLock. I’d previously spent quite a few frustrating hours trying to figure out how to determine whether some code was being executed from DllMain, i.e. while in the loader lock, so I could avoid doing anything dodgy – or indeed, anything at all.
The case I was looking at was some logging library code that was used, amongst other things, to record the fact that DLLs were being unloaded. Unfortunately when this was called from DllMain, it sometimes caused a deadlock, for all the reasons we already know about. The library code was called from lots of DLLs, so it wasn’t feasible to fix all of the call sites, instead I had to make the logging a no-op when it’s not safe.
OK, quick Async pop quiz: How long does the
run function below take to execute?
module Test =
let work i =
let run _ =
[1..1000] |> List.map work
(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?
If it were a perfect world, we’d all exist in a happy little bubble of our favourite programming language and you’d never have to worry about the nasty details of interacting with something written by – gasp – someone else in a – double-gasp – different language. But unfortunately that’s precisely what we have to do all the time. And that means that one day all of your fancy-pants algorithmic, highly parallel, functionally pure F# code is going to meet the world of “enterprise” C# development head-on.
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#.
Well, the title says it all really. I just wanted to let everyone know that I’m not dead – despite what you may be thinking based on my lack of blog output – it’s just that I’ve been insanely busy on a project in the day job. Yep, it’s that old excuse of real paying work getting in the way of the fun stuff again.
Hopefully soon I’ll manage to post some new stuff, possibly more ‘transitioning to F#’ posts and bit more iOS development malarkey. In the meantime, keep on keeping on.
(or “Discriminated unions for dummies like me”, or “Tagged unions for the rest of us”)
Discriminated unions are one of those things in the lexicon of functional programming that can often sound baffling to “outsiders”; it’s almost up there with monads and currying. But in practice they’re simple and incredibly useful. I thought I’d try and show a concrete example of where they can be used in a way which is more powerful and robust than the equivalent OO approach.
I’ve been a fan of onedotzero – the forward-looking moving-image festival – for many years. I always try and make it to at least one of the screenings, normally wow+flutter, but with a couple of kids it’s been getting a bit difficult to find the time recently. The content could be pretty “dark”, so it’s definitely not a good idea to bring them along, in fact you have to be 16 years old to get into the screenings.
But this year, much to my surprise and delight, they introduced a special, Sunday-afternoon screening especially for kids, called “Sprites”; excellent! Now I had an excuse to bring the whole family along too! Was it a co-incidence that Shane Walter, curator of the festival, and his lady wife have had a baby this year…? Maybe…
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.
Posted in .NET, F#
Tagged .NET, cecil, DGML, dll, F#, gac, mono
I’ve recently been experimenting with the Bullet physics library on iOS. It’s a great way of adding 3d collision detection and realistic looking movement to your OpenGL apps and games. I’m working on a full blog post with all the details, but in the meantime, here’s a quick look at what I’ve been doing: a simple 2.5d ragdoll character running on the iPad simulator.