Skip to content
gian edited this page Oct 25, 2011 · 71 revisions

SML Hack Day Planning

Hack Day is over!

Thanks to everyone who took part. We have a list of Hack Day Participants. Check back through the usual channels for more details of the next one.

Introduction

In the hopes of spurring on new development, we propose an SML hackday in the near future. We can use this Wiki as a kind of wish-list for things we hope could be achieved during such a hack day. Practical details follow.

Places and Times

###Date: Saturday 22nd of October 2011 ###Time: Appropriately timezone-shifted times TBD.

Current participants are primarily at CMU, the IT University of Copenhagen, or Aarhus University. There's no particular need to be in one place though.

Most of this activity is centered around the IRC channel #sml on FreeNode.

Local Contacts

  • At ITU: Gian Perrone (gdpe at itu dot dk - gianp on #sml)
  • Coordinate with Gian if you're interested in doing file format/library binding sorts of things.
  • At CMU: Rob Simmons (rjsimmon at cs dot cmu dot edu - rjsimmon on #sml)
  • Coordinate with Rob (or locally with Chris Martens) if you're interested in working on the core CMlib library that CMU Hack Day will be hacking on.
  • At Aarhus: Ian Zerny (zerny at cs dot au dot dk)
  • There is some excitement in the SF Bay Area; is there enough to set up a hack day base here?

Local Arrangements

At ITU

  • Time: 12 noon Copenhagen time, Saturday 22nd October.
  • Place: ITU PLS corridor (4C).

Participants who are already at ITU can pretty much fend for themselves. If you're thinking of joining us, we have a few spare desks in the atrium that should be available. Internet access is available through Eduroam. Let Gian know if you're thinking of coming along, 'cause you'll need help getting into the building.

At CMU/Pittsburgh

  • Time: 10 AM Eastern Standard time, Saturday 22nd October.
  • Place: Either GHC 8115 or GHC 9115.

Wish List

Moved to Wish list for SML

Sources of Inspiration and/or code

Things we would like to avoid doing

Preferably we won't work on language changes or compiler hacking. Why? Because that's where most of the effort has gone in the past 10 years, but it was not the lack of quality compilers that killed SML --- it was the lack of quality libraries for performing "real world" tasks. We should focus our attention on getting an eco-system of maintained, discoverable libraries first, and then figure out what else we would like to do longer-term.

How you can help

  • Got some useful SML code rotting away in some obscure corner of the internet? You can drag it out, tidy it up and contribute it.
  • Implement wishlist features or help resurrect abandoned libraries.
  • Don't know SML very well? No problem! Writing FFI bindings for C libraries doesn't require a particularly deep knowledge of SML, but it's kinda tedious and many hands make light work.
  • Also, porting libraries from ocaml is pretty straightforward. Haskell libraries require a bit more care, due to the lazy/strict divide, but are still fairly easy.
  • Write documentation, tutorials etc.
  • Publicity materials for SML. Start an SML community website! Design a front-end for the eventual package manager!
  • ... suggest something!