Skip to content

BayHac 2011 Wrap Up

Today was the last day of our Haskell Hackathon and “Learn Haskell Workshop”. I think it would be fair to call it a resounding success!

photo by Bryan O’Sullivan

On Friday we had about 27 hackers: Off to a great start. We hacked until dinner @ La Fiesta (nice walk to and from the Dojo.) In the evening, the other room at the Dojo was host to an Ignite conference. The theme was “better” and I gave a 5-min / 20-slide ignite talk: “Haskell is Better“. Many people from the audience came up to me later and said they were really intrigued and would stop by the next day.

On Saturday we had a four hour “Learn Haskell Workshop” with about 40 new and beginning Haskell programmers. I taught basics and got as far as leading the group to write their own implementation of map, using an alpha version of Barley.

We also had a few advanced sessions (which I didn’t get to see) including Johan Tibell on performance tuning, and Evan LaForge on his music system. The workshop concluded with a presentation on Haskell in Industry from Don Stewart.

After the workshop, everyone, new, experienced and in-between settled into hacking and conversation well into the night. All told, there were 70+ people at the Hackathon that day.

The final day, Sunday saw a few hours of more intensive, directed hacking. At the end of the day, Conal Elliott gave an impromptu seminar on “Denotative Programming” that had a dozen people rapt for over an hour. When I finally left to have dinner with my kids, there were still dozen or so Haskell hackers in the Dojo.

If you were there, thanks for coming out and making this event a great time.! Please leave a comment and let us know what you hacked on, learned, or talked about at the Hackathon.

Advertisements

Learn Haskell Workshop & Haskell Hackathon

Bryan O’Sullivan and I are organizing a S.F. Bay Area Haskell event next month…
Please join us for:

BayHac 2011.02

Learn Haskell Workshop

Saturday, February 12th, 10am – 4pm
Come learn Haskell! No prior Haskell experience needed. Bring your laptop and a willingness to have your brain stretched in enjoyable ways. We’ll be do some web programming in Haskell.

Haskell Project Hackathon

Friday, February 11th, 2pm – Sunday, February 13th 2pm
Come join a group of Haskell hackers. Bring your own projects, or work on ours: It is more fun to do it in a group!

Where: Hacker Dojo
140 South Whisman Road, Mountain View, CA
Cost: Free!
Please Register: on our sign-up form
More Info: Hacker Dojo wiki page & BayHac google group

Haskell Package Layout

I’ve been looking at cabal’s default layout of installed packages, as implemented in Distribution.Simple.InstallDirs. On non-Windows systems this ends up like:

$prefix           -- /usr/local if --global, ~/.cabal if --user
  bin             -- binaries
  lib
    $pkgid
      $compiler   -- libraries & .hi files
        include   -- include files
  libexec         -- private binaries
  share
    $pkgid        -- data files
    doc
      $pkgid      -- documentation
        html      -- html doc
    man           -- man pages

There are several problems with this layout:

  1. It doesn’t truly support multiple compilers (or even versions of the same compiler), because while the libraries and .hi files can be multiply resident, things like the doc and the binaries only get the last set built. But, the doc for a package could change depending on which compiler it is compiled for (perhaps not all of the API is available under an older version…)
  2. If you want to remove a package, you’ve got to ferret all the pieces out of global bin, libexec, and man directories, and there are three separate directories named with $pkgid to remove.
  3. If you want to remove a compiler, you need to remove all the $compiler directories out of all the packages. Then, if a package has no other $compiler subtrees, remove that package (see #2).

Most other language library sets on other platforms seem to place things under per interpreter version sub-trees[1]. In keeping with that, and trying to better support the three use cases above, I developed this:

$prefix           -- /usr/local/haskell if --global, and ~/.cabal if --user
  $compiler
    $pkgid
      bin         -- binaries
      lib         -- libraries & .hi files
        include   -- include files
      libexec     -- private binaries
      share       -- data files
      doc         -- documentation
        html      -- html doc
        man       -- man pages

The first big advantage is that a package can be installed for multiple compilers easily, and independently. The second is that removing an older compiler, and all the package versions for it, is really easy. And removing a package is quite a bit easier: just remove the $pkgid under each $compiler. Of course, there is also the nicety that bits of Haskell packages aren’t intermingled throughout /usr/local.

The actual $prefix directories would probably be platform and distribution specific. For example, on Mac OS X the would be /Library/Haskell and ~/Library/Haskell.

This structure is similar to what I proposed for Mac OS X awhile back, and have been running on my systems for about a year. Note that the GHC distribution, uses a somewhat different layout for the packages it includes, but shares with this structure the ordering of $compiler/$pkgid rather than the other way ’round. This structure also has no need for the special $libsubdir and $datasubdir processing.

To Facilitate easy access to binaries and docs, we could add:

$prefix           -- /usr/local/haskell or ~/.cabal
  $compiler
    bin           -- symlinks to binaries in built with this $compiler
    doc           -- doc for packages for this $compiler
      html        -- master index of html
      man         -- symlinks to man pages under this
  current         -- symlink to current $compiler
  bin             -- symlink to current/bin
  doc             -- symlink to current/doc

Users can then put /usr/local/haskell/bin and ~/.cabal on their PATH, or further simlink from those locations to bin directories that already are.

It is relatively easy to set up your own .cabal/config file to do this. But, now with Haskell Platform, more people will be doing their initial installs via these prepackaged means, and they all use the current layout, and default new package installs to that layout as well. If there is consensus that the above layout would improve things going forward, especially in supporting multiple installed compiler versions, then I’d be happy to submit a patch to Cabal for it.

Thoughts?

– Mark

[1] See, for example, how Python installs things under /usr/lib/python$version, and Perl uses /usr/lib/perl5/$version.

Haskell Rapid Transit

In the book Smalltalk-80: Bits of History, Words of Advice the Smalltalk team talks about how important it is get the development cycle of edit/compile/test fast enough that the programmer doesn’t lose focus. While I love a fast compile time as much as the next programmer, I’m always surprised at what a qualitative difference such a change makes.

Take my current Haskell based web project, for example. It’s actually pretty small, so development cycle is pretty quick:

  • In editor: Save source file edits
  • In terminal: cabal build
  • In terminal: ghci -isrc:dist/build/autogen src/Main.hs
  • In ghci: :main start playground
  • In web browser: Reload page

Total time: 1 minute, 10 seconds. That is, if I don’t have to reconfigure, or the long-ish ghci line is not nearby in my history buffer… or I didn’t close the tab so I have retype the URL to the web application.

But it turns out my Haskell based web project is sneaky: It is a small web-based Haskell development environment… And it is mostly self-hosting. So, I only need to do the above sequence when I’m changing something in the core server. Most of the time, when I’m editing the development environment itself, I can do this:

  • In web browser, on page with editable Haskell source, and live preview: Click Save

Total time: 1.4 seconds.

That is a big difference in time, but even more in focus: My mind never leaves the code at hand. I can recompile and view many more times, and so I choose to compile each small change and deal with compilation errors as I’m writing each code snippet. I can iterate many more times on a piece of code without losing context or perspective. And I get to see it running every step of the way.

Starting to feel just like it did when I first coded in Smalltalk-80…

Okay, enough teasing: The project isn’t even at a 0.1 release, but here is a screen shot, and, if you must, a reference to the github repository. Enjoy…

Haddock Revamp

-or- What I Did on my Summer Vacation

My main personal project for the last few months has been the overhaul of the web page output for Haddock, the documentation generation system for Haskell. I gave a talk at the Haskell Implementors Workshop 2010 this morning on it:

It shipped this month with Haddock 2.8.1, and most of the packages on the Hackage repository have had their documentation regenerated with it. You can side-by-side compare Data.Map in old and new versions. Enjoy!

Once more, with feeling…

I used to have a blog. I hardly ever updated it, because I hosted it myself (silly me), and it involved all sorts of machinations to get posts up on it. But there’s some good stuff there, so it hangs around.

Now I’ve got a new blog. This one. Here. It’s hosted and run by WordPress, so now writing for it is easy. My plan is to keep it full of mostly technical writing. Here’s to blogging…