blog.well-typed.com

Don just announced the first release of the Haskell Platform.

The intention of this first major release series is to get up to speed and test out our systems for making releases. We want to have everything working smoothly in time for GHC 6.12, when we hope to take over from the GHC team the task of making end-user releases.

We would like to thank the people who have worked on the release. Mikhail Glushenkov and Gregory Collins have put a lot of effort into the Windows and OSX installers. (We hope the OSX installer will be available in time for the next minor release.) We also received a lot of helpful feedback on the release candidates and the general release process from Claus Reinke, Sven Panne and Bulat Ziganshin. Many other people tested out release candidates on a range of systems. Thanks to everyone for all that.

Schedule

There will be follow-up minor releases 4 weeks and 10 weeks after this initial release. These will incorporate feedback on the installers and packaging. Your comments and feedback will be appreciated.

• 2009.2.0, Monday 4th May (actual release slipped by one day)
• 2009.2.1, Monday 1st June (4 weeks after .0)
• 2009.2.2, Monday 13th July (6 weeks after .1)

Upcoming policy decisions

We have said that major releases will be on a 6 month schedule. Major releases may include new and updated packages, while minor releases will contain bug fixes and fixes for packaging problems.

There are many policy details that we have to sort out however. For example, how do we decide which packages to add to new releases? What quality standards should we demand?

Importantly, these policy decisions are not ones that Don and I want to make ourselves, and indeed we should not be the ones to make them. These are questions for the community to decide. The plan is to discuss them on the libraries mailing list in the coming weeks and months. However, to make sure that necessary decisions do actually get made I’m going to propose a steering committee. The members would have the task of talking to the release team, thinking about what needs to be decided and guiding discussions on the mailing list. They would also have to make sure policy decisions are recorded in the wiki and are communicated to the release team.

So, if you are interested in the direction and success of the platform then now is a good time to get involved. Keep an eye out for the discussions on the libraries mailing list. If you want to do some hacking then we still need more help to organise and automate our release processes.

The Haskell Hackathon last weekend was a great success with more than 50 people attending over the three days. Thanks to the sponsors and local organisers!

If you’ve been to a few of these events you learn that it’s best not to come with too many preconceived ideas for what to work on. Since the point of the hackathon is really collaboration, you end up spending half the time talking and the other half working on cool ideas that other people bring.

I arrived with the general plan to work on the Haskell Platform release, and along with Don Stewart and Lennart Kolmodin we did actually get a bit done. I’m slightly embarrassed to admit that I spent three days at the Haskell Hackathon and wrote no Haskell code, only POSIX shell script and M4 autoconf macros!

Don and I updated the list of packages that will be in the first platform release. There were a few that needed to be bumped after the ghc-6.10.2 release. Our thanks to Ross who had already uploaded all the core and “extra libs” packages to Hackage.

The three of us also worked on making a generic Unix tarball of the platform. The point is for users of distros which do not yet have native packages for the platform to be able to download this tarball and ./configure; make; make install. We even managed to get something working just enough for people to be able to test it (haskell-platform-2009.0.0.tar.gz).

Chris Eidhof and Eelco Lempsink of Tupil designed a cool “Get Haskell” download page

(The silly caption was Chris’s joke in response to Ganesh’s comment about an earlier design)
The idea is that we would put this at http://haskell.org/download/ to provide an easy start for new users. For OSX and Windows, the icons would link directly to a download and a page with install and post-install instructions. The Linux icon would link to another page with instructions for each supported distro, or the generic tarball for unsupported distros.

Outside of the Hackathon people have also been working hard on the platform release. If you’re on the mailing list you’ll know that Mikhail Glushenkov has been making great progress on preparing a Windows installer. He’s got a beta version available (HaskellPlatform-2009.0.0-setup.exe). Report feedback in the platform trac ticket #6.

Gregory Collins has also been working hard on a cabal2macpkg tool to generate OSX packages from Cabal packages. He’ll use this for each package in the platform and then bundle them all together (along with ghc) into one installer. He’s been having difficulty with the fact that the package format for OSX Leopard is woefully under-documented.

If you’re someone who prepares distro packages then now is an excellent time to get started making sure you’ve got the correct versions of all the platform packages and making a haskell-platform meta-package. See the platform trac for more details.

Suppose you wanted to do something rash like release a new version of some important piece of infrastructure like Cabal, haddock or indeed ghc itself. Of course you worry that your sparkling new release might have hidden regressions. If only you could check that you’re not breaking anyone’s code. Well, you can!

We can use the cabal command line tool to do regression testing. Basically we build all of Hackage with the old and new releases and then we compare the build reports to find regressions. Simple!

Let’s look at the details…
(more…)

After months of work, GHC 6.10.1 is finally released!

The headlines include a parallel garbage collector, extensible exceptions, haddock 2, Data Parallel Haskell as an extralib, and much more besides.

Well-Typed is pleased to have been able to play its part in making this release happen, with Ian working with the Simons at GHC HQ and many other developers across the world to bring this release together.

Meanwhile, Duncan visitied Galois to team up with Don Stewart for some extensive pre-release testing. Their experiments with building all of the packages on Hackage give us confidence that this will be a solid release.

Thanks to everyone who played a part, be it development, testing or otherwise, in this release. We couldn’t have done it without your help!

I’m talking about the Haskell Platform at the London Haskell Users Group this Thursday.

It is an extended version of the 10-minute talk Haskell: Batteries Included that Don Stewart and I presented at the recent Haskell Symposium.

• Slides from the talk

Abstract:

Some people pick a programming language because it has the best type system, the best facilities for abstraction or perhaps the fastest compiler. Most people however pick a whole programming platform that lets them solve their problem the quickest or best. A programming platform consists of a language, a compiler, and a set of standard libraries and tools. Other popular programming languages have a standard platform that puts together everything you need to get started.

This talk is about the Haskell Platform. We’ll cover what the Haskell Platform is and who it is for. We’ll also look at the technical infrastructure and the social aspects of how it will be managed.

Not all of the details are set in stone. We need to have a discussion within the Haskell community about how the platform will be managed and extended, especially since it needs buy-in from package maintainers. My hope is to use this talk to kick off that discussion.

I presented a “Tech Talk” today at Galois on some ideas relating to Cabal

• Slides (pdf)

We discussed two topics. Here’s the abstract:

A language for build systems

Build systems are easy to start but hard to get right. We’ll take the view of a language designer and look at where our current tools fall down in terms of safety/correctness and expressiveness.

We’ll then consider some very early ideas about what a build system language should look like and what properties it should have. Currently this takes the form of a design for a build DSL embedded in Haskell.

Constraint solving problems in package deployment

We are all familiar, at least peripherally, with package systems. Every Linux distribution has a notion of packages and most have high level tools to automate the installation of packages and all their dependencies. What is not immediately obvious is that the problem of resolving a consistent set of dependencies is hard, indeed it is NP-complete. It is possible to encode 3-SAT or Sudoku as a query on a specially crafted package repository.

We will look at this problem in a bit more detail and ask if the right approach might be to apply our knowledge about constraint solving rather than the current ad-hoc solvers that most real systems use. My hope is to provoke a discussion about the problem.

I’ve covered similar ground to the first topic before in a previous blog post on make. This time we looked in a bit more detail at what a solution might look like and what properties it should have. In particular we discussed what the correctness properties of a build system might look like.

I promised to post the slides from our talk on the Haskell Platform which Don and I presented at the Haskell Symposium yesterday.

Haskell: Batteries Included

• Slides
• Summary paper

Malcolm did us all a great service by videoing the talks. Unfortunately he had to catch his flight home before our talk so there is no video for that one.

Don did the talk with the slides and I did the live demo. Fortunately the demo worked. We ran the new hackage server on my laptop and we invited people to connect. I demoed uploading a new package and within a few seconds people in the audience were able to download and install it using cabal-install. That of course is old hat to the open source Haskell hackers but part of what we were trying to do is to persuade the academics to make better use of Hackage to publish libraries and tools that they develop as part of their research.

One new thing we demoed was generating build reports and uploading them back to the hackage server. In fact we had several people in the audience upload report for the new package within 30 seconds of me uploading it. The build reporting is part of the plan for testing the packages in the Haskell Platform but more generally to gather information on what packages build in what environments.