After having seen Brent Yorgey’s blog post, I started hacking-up a simple Happstack webapp to display factorization diagrams. This has been pretty straight forward, although the code isn’t really clean nor idiomatic. I just felt like quickly putting something up and running during the little free time I have had this weekend. You can play with the app at diagrams.alpmestan.com. Here is an example of generated SVG.

1235’s factorization

Functor AB is looking for enthusiastic, highly skilled and experienced Haskell developers for our core technology, who are interested in a challenging opportunity partly at the JET fusion reactor (Oxford) and in collaboration with some renowned researchers.

Functor collaborates with the JET fusion reactor run by EFDA CCFE outside Oxford, UK. JET is currently the largest reactor in the world of its kind and there is an on-going technology transfer at JET to the emerging ITER project, which is some decade ahead as far as operation is concerned. You will be part of this collaboration and have a key role in the development of new programming tools for a new programming paradigm known as the constructive programming paradigm.

At Functor, almost all development is done in Haskell but also to some extent also C and Scala. Although Functor AB is based in Stockholm, Sweden, work may be carried out e.g. in Oxford or otherwise. The developers we look for will be working closely with some senior / well-known researchers within the disciplines of computer science and mathematical logic, collaborate with staff at the JET plant including highly experienced key software engineers at that facility and will face interesting and challenging problems. Developers at Functor can contribute to fusion energy research in the sense of being involved in new technology for software that concerns the stabilisation of the plasma inside a reactor.

A solid background in computer science, documented experience and/or strong academic education in advanced functional programming in Haskell are assumed. Knowledge of type systems, Martin-Lof type theory, dependent types, formal methods, static analysis, Spec#, Coq, Agda, Idris, Epigram, Twelf or other similar tools, languages, theorem provers is desirable but not required. Knowledge of parsing, skills also in other programming languages including experience from C, C#, C++, Objective-C and also Scala, is also desirable but not required. Higher academic degrees such as a PhD in computer science are not required but certainly taken into account. Entrepreneurship skills or industrial experience is not required here - but if such exists it is considered to be a strong merit as well. Knowledge in UNIX and Linux is required. Finally, experience in using Visual Studio, Eclipse or other IDEs is relevant.

To apply, please send your resume, references and other relevant documentation to . If you have any questions, they can be sent to the same address.

It’s that time of the year, again, when the community talks a lot about what is wrong with cabal and hackage. A few discussions happened on reddit (see 1, 2 and 3 for example). So, we all know what the issues are (if you don’t, reading the comments on these links will certainly help you realize what the issues are). This post is about what can be done from different point of views.

Using other people’s libraries or programs in your projects

So, you have a project, and that project has a .cabal file, listing the dependencies. But when you want to build your project, you install the dependencies in your user package database. Just having a couple of projects may be enough to introduce conflicts and get you a one-way ticket to the dependency hell. For that kind of issues, there is a solution. There are several of them, actually, but the most popular one probably is cabal-dev. You can learn how to use it on its github page.

Basically, you will have per-project package databases. The big disadvantage in that approach is that your projects tend to always use libraries like bytestring, text, etc and that you will have to build them once per project, but I do not find this to be that big a problem with today’s hardware. So, with that solution, unless different dependencies of the same project use conflicting versions of some package, you should be fine.

An important note is that the next release of cabal-install will have sandboxes (just like cabal-dev) built-in. This is the result of a hard work during the GSoC this year, and even after the end of it. So what you’ll be used to do with cabal-dev will be possible with the usual ‘cabal’ program. However, this isn’t about importing some code from cabal-dev. It provides better sandboxes than cabal-dev. For instance, cabal-dev only take snapshots of dependent packages whereas cabal-install will support live source trees.

The Cabal/cabal-install developers have a lot of ideas to improve the situation. Also, the code is on github. They even provide a HACKING file and their issue tracker has an awful lot of open issues (483 right now). This provides pretty much all you need if you want to help on the Cabal front.

The Hackage mess

So, you are looking on Hackage for a library that provides some specific functionality. You find 5 of them that seem to offer it, but don’t know which one to choose? Do you really have to test all of them to figure out their ease of use, their performance characteristics and whatnot? Well, except when the package is one that is known to be a reference, that’s pretty much your only solution, yes. However, many of you may be aware that a new version of Hackage is being worked on, but probably don’t know where that work is happening, who is working on it, what needs to be done, etc.

These last few months, Duncan Coutts and Ian Lynagh have been working hard on improving the performances of the current Hackage2 code, on some refactorings and on getting it closer and closer to being deployed to replace the current hackage.

This new version of Hackage will have a huge amount of new features, eventually, that will help sorting out “the mess” that we see when looking at this page. And it will bring a lot more than just this. However, obviously that requires a lot of hacking, so how about joining the effort? There are many simple tasks that one can do to get Hackage2 closer to a deployment. For instance, I am working on adding some code to back-up some data the Hackage2 server stores in memory while running, and on the corresponding import code. Really, right now, most of the tasks are about filling in some gaps: making sure we can import the old data, making sure backups will work, etc. It’s about getting it ready for the switchover. The initial version of Hackage2 will be similar to the current one, but will be a much better basis for adding all the features needed to improve our experience as a community (number of downloads and reverse dependencies as empirical “quality” metrics? attaching “getting started” code snippets to your package’s page? etc).

If you want to help with this, you can find a lot of information about the Hackage2 project here. That includes where you can find the code, the tasks that need to be done, the people you can contact to talk about what you should do, etc.

Maintaining a project is hard

A lot of package maintainers know this situation: a dependency of your project introduces some breaking change, and someone sends you a message on IRC or by email to tell you they can’t install your package. You thus either have to adjust the version bounds for that dependency, or make your code compatible with the changes (or you write different code for the two different version ranges, but that of course scales badly). The former keeps you from benefiting from all future improvements to this dependency, the latter keeps your code from working with all the previous versions. And you can’t do anything about it anymore, because the new version of your dependency is released on Hackage.

Another scenario: you introduce some breaking change in your package. All your reverse dependencies (packages using yours) may now be broken. What can you do about that? Maybe luckily some of them had the right version bounds for you in their .cabal file (this isn’t that hard to get right, if you follow the PVP). But then again, every now and then, some package doesn’t follow it. Or the version bounds for some dependency of a package are just wrong and that pretty much keeps you from being able to install that package, unless you figure out the exact problem, which… let’s be honest, is tiresome and not always reasonable to do.

These scenarios (among many others) are something Jeremy Shaw (Happstack’s lead dev) and I were so tired of that we decided to start the scoutess project. For more information about it, please visit this post and visit us on #scoutess on ‘irc.freenode.net’. This aims at being a build-bot-on-steroids for cabal-powered projects. There’s still plenty to be done before we can get a first release out, and we would benefit a lot from having a few more hands to help us write down some more code to get us closer to a release. So if you’re interested, contact us, by email, IRC, or the fresh mailing-list, take a look at the code on darcshub (although it may change drastically soon).

A side note about this: there will be a feature in the new Hackage that will let package maintainers or Hackage trustees adjust dependencies after a release without having to update the tarball. cabal-install’s latest release has the client-side code for this, and the server-side code is partly written too.

Conclusion

There is yet another interesting and related project, about a nix-style persistent package store. You can read about it here and watch the Haskell Implementors Workshop talk about it here. This may be a key for opening the door of the dependency paradise. So do not hesitate to take a look at what Philip did and whether you can help.

You can do a lot to improve the situation. Just contributing a tiny feature to one of the projects I talked about is already a huge win for that project’s authors, and almost-directly for the whole community. We know the problems, so it’s not that helpful to keep talking about it on Google+, reddit, twitter and whatnot without doing anything to solve them. The people working on all of these projects know the technical details to improve the situation, but do not have an awful lot of time to spend working on it. Anyone in the community can make a difference, can bring us closer to a state where we do not hear/read complaints every single day about cabal, hackage, broken packages, dependency hells, etc. Pretty much all the Hackage/Cabal/Scoutess devs would be delighted to welcome new contributors, whatever the size of the contribution is, may it be good bug reports, some documentation improvements, bug fixes and of course new features. And contributing to these projects may seem scary, but you will figure out that there are an awful lot of simple tasks that need to be done. For instance, I have something like 10 of them in mind for Scoutess. So if you’re interested, please come talk to us, let us know what you want to work on, we’ll most likely give you a few advices/directions, and you’ll be good to go!

Many thanks to Duncan Coutts for the many helpful comments on the drafts of this post. I definitely owe you a beer or two!