If you've found this page, you use Haskell, and live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell Hackathon some time during the middle of 2010, and this where it shall be organised.
If you're interested in coming, please put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).
What we've got so far
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!
A few dates have been discussed, mainly taking into account when the university holidays are for various universities:
- ANU: 7 June -> 18 July
- UNSW: 29 June -> 18 July
So so far we need a weekend between the 28th of June and the 18th of July.
We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).
Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.
If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).
|Name||IRC Nickname||Availability||Preferred date||Comment|
|Alex Mason||Axman6email@example.com||Probably any weekend during the ANU holidays||-||Organiser... sort of|
|Ivan Miljenovic||ivanm||Ivan <dot> Miljenovic <at> gmail <dot> com||*shrug* lazy PhD student, so whenever||<===||ditto|
|Tony Morrisfirstname.lastname@example.org||Nothing specific||-||Tentative, depending on health|
|Manuel Chakravarty||TacticalGraceemail@example.com||I'm away 4-11 July; will probably not be able to attend all of it regardless of date||Probably weekend of the 18th July||Will help getting a room at UNSW|
|Mark Wottonfirstname.lastname@example.org||flexible, but weekend|
|David Tereiemail@example.com||I'm away from April - start of August. Probably can't attend given proposed dates||Any weekend after August 19th|
Generic graph class
What: I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.
Who: Ivan M
What: Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)
Who: Ivan M, Alex M
GHC LLVM backend
What: The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.
Who: Alex M, Manuel
What: Accelerate is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.
What:  is a bridge between ruby and haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either