DGPatchMaker is a tool to create patches for the DrumGizmo drum plugin from ready wave-format sample libraries and is now open sourced:
https://github.com/oswald2/DGPatchMaker
Manual will be updated soon as well as an introductionary video is planned.
A compiled binary (Ubuntu 18.04 x86_64) can be found here:
An introduction to using DGPatchMaker can be found here:
William Yao provided a link collection of useful Haskell articles to the topic good design and good testing (see https://williamyaoh.com/posts/2019-11-24-design-and-testing-articles.html) .
Authors: William Yao, Matt Parsons, David Luposchainsky, Alexis King, Jasper Van der Jeugt, Tom Ellis, Michael Snoyman, Sandy Maguire, Oskar Wickström, Scott Wlaschin, Hillel Wayne
A big thanks to all authors!
I compiled all articles into a single PDF in LaTeX book format
you able to penetrate (enter) your partner?The specifications set are suitable. viagra 100mg kaufen preis.
assessment prior to the treatment of ED and regularThe consequences of this antiplatelet action have been investigated. viagra no prescription.
Microvascular arterial bypass and venous ligation surgery5-6 cialis for sale.
Updated Version (contains 2 more articles):
Github link: https://github.com/oswald2/haskell_articles
Have fun!
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
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?
Back from my first ICFP and CUFP, where I had my first talk in the functional languages domain. Here is a link to the recorded talks, mine was “Haskell in the Mission Control Domain”:
Unfortunately, I could not find the recording from Björn’s talk right after me (Edit: Björn sent me a link, here is it: https://www.youtube.com/watch?v=QpRGe5d3ouo)
It was a very good experience and also quite impressive, to see all the creme-de-la-creme from the Haskell community in one place! Also it was nice to get an association from names to actual faces.
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.
There were numerous posts on reddit, SO and the like which were asking for how to architect real world Haskell applications. Well, this is my go at it for an in-house testing tool which is used extensively. I would not claim myself an advanced Haskeller, some of the code is probably not idiomatic Haskell (and also some parts are really, ah well, horrible), it’s (by it’s nature) very stateful (read: imperative), BUT… it works. It even worked out better than I thought initially…
I am working in the space domain and I am mostly concerned with mission control systems, especially the ones from the ESA (European Space Agency) named SCOS-2000. What we needed was a tool to be able to test certain new features implemented in the mission control system with a closed-loop test. The standard tools that come with SCOS are quite limited (and buggy) and written quite verbosely in C++. So why not try to create one in Haskell?