Tag Archives: C++

Binding to a C++ CORBA interface in Haskell

This post is mostly a reminder on how I did this, so that I have a place to look it up.

Ok, so basically, I work on the mission control system GECCOS for DLR (Deutsches Zentrum für Luft- und Raumfahrt), which is currently flying seven missions with it. The MCS is not an isolated system, but connected to a number of other systems around it (e.g. SSB –  network routing to the ground stations, SATMON for having pretty displays, mission planning, flight dynamics etc). In our company, we don’t have these systems available, so we need to somehow simulate them.

This is the point, where Haskell comes into play. Over the course of the last years I developed several tools in Haskell which help me with this (see blog posts: Architecture of a Real World Haskell Application and Architecture of a Real World Haskell Application part II

The Problem

I needed to implement a new interface from the MCS to SATMON. The interface is via the EXIF (external interfaces), which work via CORBA. So to be able to test the new interface, I needed an application which can interface CORBA. That’s where it starts.

Unfortunately, there is no CORBA implementation for Haskell available. The system uses omniORB, which is a C++ ORB but also provides a python implementation.

Creating a new CORBA implementation would be quite a lot of hassle, as this would involve an IDL parser, generating lots of Haskell code and so on. Just in case you are not familiar with CORBA: it is a middleware with remote method invocation. The interfaces are specified in an interface definition language (IDL), which are then translated by the IDL compiler into the used target language (in omniORBs case into C++ or Python).

So a direct binding to the existing C++ interface would be an option. After looking around a bit and playing sometimes with C++ binding generators like fcixx, I came across hoppy, which was used to generate the Haskell binding for the QT library. Ok, I thought, let’s give it a try.

But we are not ready yet. The MCS is compiled and running on a SuSE Linux Enterprise Server 11 system, which is really old. Even worse, the MCS uses legacy libraries, which can only be used with a gcc < 3.4.0, because with 3.4.0 there was a change in the ABI (application binary interface) and the code is not linkable with other stuff. Well, turns out, C linking is still possible, but C++ libraries not.

So, how get this working?

Continue reading

Architecture of a Real World Haskell Application part II

OK, did take some time since the last post, but I am really busy now.

Last time we looked at the general structure of the application in terms of threads and model/interface separation. For this post, I want to write a little bit about the protocol handling and parsing and how it evolved. While this is not the most central part of the application, it is the oldest and therefore I think good to show some historical development.

Ok, so the tool began as a command line application which could only receive telecommands and send back correct responses (which on itself is not as simple as it sounds). Also at that point in time I just more or less started learning Haskell while my main language at that time was C++, so of course the first solution was a lot C++ like. So let’s see how it goes.

Continue reading