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.
Bryan O’Sullivan and I are organizing a S.F. Bay Area Haskell event next month…
Please join us for:
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!
140 South Whisman Road, Mountain View, CA
|Please Register:||on our sign-up form|
|More Info:||Hacker Dojo wiki page & BayHac google group|
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:
- 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…)
- 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
- If you want to remove a compiler, you need to remove all the
$compilerdirectories out of all the packages. Then, if a package has no other
$compilersubtrees, remove that package (see #2).
Most other language library sets on other platforms seem to place things under per interpreter version sub-trees. 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
$prefix directories would probably be platform and distribution specific. For example, on Mac OS X the would be
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
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
~/.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.
 See, for example, how Python installs things under
/usr/lib/python$version, and Perl uses
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:
- 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…
-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!