Key

If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.

Project Ideas

Clojure

Predicate Dispatch

Brief Explanation: A considerable amount of work has been done towards a viable predicate dispatch implementation for Clojure. However quite a few more enhancements to core.match are required before it can be used for this purpose. The work should account for other Clojure dialects ClojureCLR / ClojureScript.

cKanren extensions to core.logic (Constraint Logic Programming)

Brief Explanation: Adding constraint logic programming facilities to core.logic would widen the scope of problems that core.logic can be applied to - including predicate dispatch. We would like to adapt the cKanren extensions to core.logic with an eye for obvious improvements to the their design in terms of generality as well as performance.

Clojure Linter

Brief Explanation: It would be useful to have a simple tool that encourage good Clojure style. Given that we now have three actively developed Clojure implementations - Clojure, ClojureCLR, and ClojureScript - a tool that warned on reliance on host-y features would simplify the design of libraries that are useful across Clojure implementations. It might be useful to take at a look at the new Kibit tool as well as Ambrose's analyzer work (which is being used in Typed Clojure).

Expected Results: A Clojure linter.

Knowledge Prerequisite: Familiarity with Clojure.

Skill Level: Medium

Mentor: Baishampayan Ghose

Leaner Clojure runtime

Brief Explanation: Currently, Clojure has a relatively heavyweight bootstrap process that is troublesome for embedded and hosted environments with limited computing power and for scripting where the JVM/Clojure bootstrap undesirably dominate execution time. There are a number of ideas on how to accomplish this, including removing metadata and the compiler from non-development builds and changing the compiler to generate static method calls instead of invoking functions on function objects. The goal for this project would be to implement and refine one or more of these or similar ideas to help Clojure perform better in lightweight applications and limited environments.

Expected Results: A lightweight build of Clojure that bootstraps more quickly and uses less memory.

Knowledge Prerequisite: Familiarity with Clojure, especially with the Clojure compiler.

Skill Level: Medium to High

Mentor: Daniel Solano Gómez

Enhance primitive vectors

Brief explanation: Clojure includes the vector-of function that creates persistent vectors that store primitives in an unboxed fashion. This makes them more memory-efficient, but still requires boxing operations when adding or retrieving items from the vector. This can significantly hurt performance. With Clojure 1.3, it is no longer necessary to box longs and doubles when crossing function boundaries. For this project, the developer should add to the Vec implementation so that there is a interface for accessing and manipulating the vector without doing any boxing at all.

Expected results: New Vec implementations that support unboxed long and double access.

Skill level: Easy to Medium

Mentor: Daniel Solano Gómez

Native Clojure

Brief explanation: Clojure works perfectly under JVM, but slow startup with large memory usage makes it unsuitable for scripting, older computers and embedded devices. There has been attempts to built Clojure native binary with gcj without success, but it is still possible (gcj with option -findirect-dispatch can build binary from prepared jar file). Also, VMKit can be explored as alternative; VMKit authors already had success building large projects like Eclipse and Tomcat.

Expected results: Clojure native binary, runnable without JVM.

Skill level: Medium to Advanced

Mentor: Sanel Zukan

Clojure code optimizer

Brief explanation: Currently, Clojure does not have (official) optimizer on source level. Clojure built-in bytecode manipulation framework has option to eliminate dead blocks, but things can be improved. LISP's are popular for using tree shakers directly on source level and this option can be explored. As starting point, LispWorks has good tree shaker implementation but is closed source; also there is some alpha shaker for SBCL. Due to language functional nature, optimizer needs to know a bit of Clojure semantics and be able to recognize common patterns, making things challenge-able to implement.

Typed Clojure (Optional Static Type System)

Brief explanation: Clojure currently does not have a static type system. By utilizing the results of the Clojure Compiler's analysis phase (via analyze), we can build a static type checker, provided a la carte, as a library. Typed Racket is an example of adding a satisfying type system to an existing dynamically typed language, while preserving programming idioms and supporting interaction with untyped code. We will test the generality of ideas used in Typed Racket, such as Non-Uniform Variable Arity Polymorphism (typing complex variable arity functions like 'map') and occurrence typing (a type inference strategy).

Typed Racket is divided into two main parts: a type system and a system managing interaction across module boundaries (eg. using typed code from untyped). This project will concentrate on adding a type system to Clojure.

Expected results: Optional Type System as a Library for Clojure, identification of major obstacles and challenges of type checking Clojure code.

Clojure compiler based on fonc/cola

Brief Explanation: The CoLa Framework(http://piumarta.com/software/cola/) seems like a promising basis for a native Clojure compiler. I have previously tinkered with a simple implementation of Java based on CoLa(http://www.hpi.uni-potsdam.de/hirschfeld/projects/delmdsoc/index.html). The potion language, which is currently maintained by Mr. Fogus is also based on some cola code. Write a Clojure-compiler for cola. The compiler should generate native code, but allow interactive/incremental development. Maybe write a C FFI.

Expected Results:-the persistent Clojure data structures in cola-a Clojure reader in cola-a compiler from Clojure data structures to colaThe cola compiler should pick up from there and do the native code generation.

Forward- and Reverse-mode autodiff

Brief Explanation:There are currently 3 ways to generate a program for function that computes the derivative of another function:-Symbolic: Take the source code of a program and generate the source code of the program that computes the derivative.-Numeric: Take a small epsilon and compute (f(x+epsilon)-f(x))/epsilon-Automatic: Trace the execution of a program, replace the calculations with calculations for the derivative.

Numeric differentiation is inexact, and Symbolic differentiation is tricky because of unpredictable control flow.

An autodiff library for clojure would be very valuable for machine learning and optimisation. At first we should implement forward-mode autodiff in Clojure, then reverse-mode autodiff. The implementation should be composable and avoid this bug: http://eprints.nuim.ie/566/1/Perturbation.pdf. Maybe it should be integrated with Incanter, so we can compute the derivatives of matrix operations quickly.

As a proof-of-concept, learning in SVMs or neural networks would be nice, because reverse mode autodiff is a generalisation of backprop.

Expected Results: A library with differentiation- and gradient- operators.

Knowledge Prerequisite: Some calculus.

Skill level: Easy to Medium.

Overtone

Brief explanation: Currently everyone using Overtone must setup a clojure environment and editor, but it would be great if people who are unfamiliar with software development and/or clojure (e.g. musicians, artists, etc...) could download a single application to easily experiment with pre-existing instruments, sequencers, samplers, fx-racks made for guitars or other external instruments, etc. The app would let someone browse a built-in library of examples, evaluate code, experiment in a repl, open and save text files. The processing.org or SuperCollider applications are examples of this kind of system.

This kind of app would probably be useful for other Clojure projects too, so as part of it there would probably be a number of general purpose elements that could be made available as standalone libraries.

Expected results: An app implemented with the seesaw gui library (and maybe upshot for the JavaFX webkit widget for documentation) with a simplistic text editor that syntax highlights clojure, allows for selecting and evaluating chunks of code, and a repl panel.

Knowledge Prerequisite: Familiarity with Clojure and a bit of swing or other GUI experience.

Mentor: Jeff Rose, Sam Aaron

Skill Level: Beginner / Intermediate

Node based GUI editor for synthesis and bus routing

Brief explanation: While programming synthesizers and setting up a mixing board system are great in Clojure, visual representations can be great for teaching, learning, and performance, because they represent the flow of audio and control data in a direct way that can be easier to follow than tracing a series of nested function calls. It would be great if Overtone had a graphical editor similar to Max/MSP, which allowed someone to choose from a library of unit-generators (DSP functions) and then wire them up together. The ugens in Overtone have extensive meta-data about their types, rates, functionality, and arguments, so this would primarily be a GUI programming and graphic design project.

This widget could also be useful for other projects that want to display or manipulate graph or tree structured data, so some of the underlying functionality could be made available as a separate library.

Expected results: A node editor widget implemented using a 2d scenegraph using Dave Ray's upshot library (https://github.com/daveray/upshot) on top of JavaFX 2. Synth designs could be loaded or saved by the widget.

Knowledge Prerequisite: Programming with Clojure, and ideally some experience using a node based editor (a couple evenings doing Max/MSP or PD tutorials would be sufficient).

Brief explanation: Create a standalone application that any musician could download and use as a pure software effects processor on their computer. The idea is to create a simple to use, open-source platform that lets people easily experiment with and contribute new FX to the application by writing effects synthesizers in Overtone.

Expected results: Implement a library of nice sounding audio effects using Overtone, and then package them up in a simple Swing application using seesaw so non-programmers could plug an instrument into their sound-card and easily apply a chain of effects to the audio.

Knowledge Prerequisite: Programming with Clojure, sufficient knowledge of audio DSP to research and implement a collection of audio effects.

Mentor: Jeff Rose, Sam Aaron

Skill Level: Intermediate / Advanced

Audio Testing Suite

Brief explanation: Currently Overtone is lacking any end to end testing. This is because the Overtone's output is audio and we don't currently have a way of automating the verification of audio produced. This isn't so much the verification of "yeah, that sounds great" but more "yeah, that's the sound my synth should make with these params". Achieving this doesn't require as much voodoo as you expect. As audio is represented with buffers of floating point data, it would be sufficient to test the data produced by a synth with a 'master' version to see if they were similar. However, in order to make this automated it would be necessary to build the test machinery to automatically create audio buffers, pipe the synth audio into said buffer and then test it against a known buffer.

Expected results: A simple set of test synths with 'master' audio data and a lein plugin to run them against the current Overtone source.

Knowledge Prerequisite: Programming with Clojure

Mentor: Sam Aaron, Jeff Rose

Skill Level: Intermediate / Advanced

Synth Design Verifier

Brief explanation: Synths in Overtone are essentially directed graphs of ugens (unit generators). Given that there are over 450 ugens the space of possible combinations is daunting. In addition, SuperCollider server makes no attempt to sanity check the synth designs Overtone sends it. The result being that 'bad' synth designs can easily crash the SuperCollider server process. We'd like to start building tools to help us start detecting classes of synth designs that will result in server crashes before sending them to SuperCollider. This is essentially a graph analysis problem.

Expected results: A basic framework for describing and detecting error-classes of synth designs.

Knowledge Prerequisite: Clojure skills, Graph analysis

Mentor: Sam Aaron, Jeff Rose

Skill Level: Advanced

Ugen Metadata

Brief explanation: Ugens in Overtone are simple building blocks for designing synthesisers. There are over 450 of them and are implemented in C in the SuperCollider source code. In order to use them, Overtone maintains a metadata map for each ugen. This metadata is then used to generate the ugen functions and all the documentation that is so essential to a live programming environment. We would like to explore ways to improve the ugen metadata - both in terms of the accuracy of our version and also the kind of information we store. For example, we don't currently store which of each ugen's arguments is required by SuperCollider - something that would be very useful to report to the user and also to help reduce errors by raising a warning when a ugen is used without required args.

Expected results: A documented process with which to work through each ugen's C source to harvest the appropriate information. The more automated his process, the better - but we acknowledge that much of it may need to be done manually. The process should therefore be clear enough for other members of the community to execute concurrently.

Expected results: Much of the functionality provided in D3.js will be implemented in pure Clojure. Rather than a naïve port, the new functions will take advantage of Clojure's facilities for object-orientation. Workflow/toolchain for optimal sharing and testing of pure Clojure code between JVM Clojure and ClojureScript will also be established.

Knowledge Prerequisite: Familiarity with statistical graphics, SVG and HTML DOM helpful but not essential. Familiarity with JavaScript and the D3.js source code very helpful.

Mentor: Kevin Lynagh (Portland, OR, USA. Local mentees will be provided with a fixed gear bicycle and rock gym membership for project duration)

Constraint-based UI layout

Brief explanation: Constraint-based layouts allow one to declaratively specify a user interface without having to manually perform arithmetic related to element width, height, separation, &c.The Cassowary constraint solver has already been ported to JavaScript and given a small ClojureScript wrapper.Cassowary is the solver used in OS X's Autolayout and a similar high-level API to its string-based DSL for UI layout is needed.

Expected results: A friendly API for doing declarative layout; e.g. the string "[el1]-12-[el2(==2*el1)]" suffices to calculate the absolute positions of two elements separated by 12 pixels with the second element always twice as wide as the first. Primary target is the web via ClojureScript, but ideally can be implemented in pure Clojure and used on the JVM (Cassowary is already written in Java). Also provide examples of using the system for impossible-with-CSS layouts (e.g. positioning of SVG children). This work may be published in an academic statistics journal (with GSoC candidate authorship, of course).

Knowledge Prerequisite: Familiarity with Clojure. Background in logic programming and creation of domain-specific languages also helpful.

Mentor: Kevin Lynagh (Portland, OR, USA. Local mentees will be provided with a fixed gear bicycle and rock gym membership for project duration)

Tools

HTML5 Repl

Brief explanation:

Browser-based repl, where output of repl evaluations render as html5. Components include

Emacs IDE

Brief explanation:Clojure has a critical need for a good novice-friendly IDE.Counterclockwise certainly has its advantages but Emacs is just toogood "Lisp IDE" to ignore that fact. Things like Slime/Swank, CDT(http://georgejahad.com/clojure/cdt.html), Paredit being alreadydeveloped greatly simplify the creation of a very functional IDE. Whatis required is to bring them altogether, write glue code fromdifferent sides (both Emacs and the above-mentioned tools) and providea click-and-go distribution (both in the form of an Emacs "meta"plugin and a complete Emacs for Clojure build). More specific ideasfor the beginning:- better Emacs-CDT integration - visible breakpoints, understandabledistinction between program and debug REPLs (something like Eclipseperspectives may be useful)- better Emacs-lein integration - something like package-list-packagesfor clojars might be awesome when choosing dependencies for a project.- better project experience - bolster the feeling of working with aspecific project rather than a bunch of files (can take some CEDETstuff for this).- better immersion experience - docs, guides, screencasts - the usualkind of new users support.

Expected results:Emacs that acts as a Clojure IDE on a level how Eclipse handles Java

Knowledge Prerequisite:Familiarity with Clojure and Clojure/Emacs development tools.Familiarity with Emacs Lisp.

Clojars

Brief explanation:

Similar to rubygems.org, Clojars is a critical component of the Clojure community library ecosystem.

HTTP-based deployment to Clojars

Signed artifacts

Expose more details about projects and how they are connected

Host documentation

Separate snapshots from releases

Lucene-based search

Expected results:

Improved and simplified Clojars experience for the Clojure community

Knowledge Prerequisite:Familiarity with Clojure

Mentor:

Phil Hagelberg

ClojureScript

Performance enhancements

Brief Explanation: ClojureScript has numerous areas where the performance can be dramatically improved. These include but are not limited to removing use of arguments in multiple arity function dispatch, adding persistent data structures, and using type inference. A benchmark suite similar to test.benchmark for tracking improvements and regressions would be desired, the benchmark suite should provide idiomatic JavaScript as the baseline.

Introspection support

Brief Explanation: ClojureScript currently has very limited introspection support. Currently it's impossible to view macroexpansion, to examine docstrings, examine vars or namespaces, etc.

Expected Results: Improved introspection facilities more in the line with those provided by Clojure.

Knowledge Prerequisite: Familiarity with Clojure.

Skill Level: Medium

Mentor: David Nolen

Debugger support

Brief Explanation: ClojureScript currently provides very little support for precise debugging. Source mapping would be an initial step. All the mature JavaScript runtimes provide APIs for stepping through JavaScript. A robust interface for integrating with these different APIs is desirable. A concrete implementation for Chromium or Node.js would be extremely useful to ClojureScript developers. An ambitious take on this project would be s-expr level stepping of ClojureScript code.

Expected Results: A clean interface for integrating with existing JavaScript debugging APIs. A concrete implementation for a popular JavaScript platform - Chromium, Node.js.

Knowledge Prerequisite: Familiarity with Clojure.

Skill Level: High

Mentor: David Nolen

Pluggable backend

Brief Explanation: The ClojureScript compiler is currently very JavaScript-centric. It would be beneficial to make the compiler pluggable. This would allow ClojureScript developers to easily target other platforms - Lua, Python, Java, etc.

Expected Results: A compiler that can easily be extended to generate source / bytecode for other languages.

Knowledge Prerequisite: Familiarity with Clojure.

Skill Level: Medium

Mentor: David Nolen

Android

Add Android support to Clojure

Brief explanation: There is currently a fork of Clojure designed to support Android. This fork is designed to support dynamic compilation on the Dalvik virtual machine. It also contains some workarounds to ensure that Clojure will work (even without dynamic compilation) on older versions of Android. It would be great to have some of these changes integrated into the main Clojure repository. Also, Clojure 1.3 and newer do not work with versions of Android older than Gingerbread.

Expected results: Integrating Android-friendly features into Clojure and ensuring newer versions of Clojure work with Android platforms Eclair and newer.

Knowledge prerequisite: Clojure, Dalvik VM.

Skill level: Medium to hard.

Mentor: Daniel Solano Gómez

Clojure/Android Toolkit

Brief explanation: There is the start of a library for Android development using Clojure. It is quite incomplete and needs significant enhancements, for example adding macros such as defactivity to help ease the boilerplate for generating new Android component subclasses, creating utilities to help manage coordination between the UI and background tasks in a Clojure-friendly way, or even creating a Leiningen plug-in to help developers get started.

Expected results: The developer will need to propose a series of enhancements to the toolkit, implement them, and provide documentation on how to use them.

Skill level: Easy to medium

Mentor: Daniel Solano Gómez

Web

appengine-magic enhancements (for Google App Engine)

Brief explanation: appengine-magic is a library for writing web applications in Clojure and deploying them on Google App Engine. App Engine has some interesting scalability characteristics which some applications may find desirable. Unfortunately, appengine-magic has lagged behind Google's releases. It also does not fully support the features of the App Engine SDK.

Expected results: Feature parity between the latest releases of Google's App Engine SDK and the appengine-magic project. All changes to appengine-magic must be thoroughly documented.

Noir static site generator

Brief explanation: Noir is a clojure microframework for creating websites. This project would use Noir's route table to output static websites from a simple command much like how jekyll creates static blogs.

Expected results: A leiningen command that takes a simple configuration file and outputs a completely useable fully static version of a noir website.

Knowledge Prerequisite: Clojure, some understanding of the web

Skill level: easy to medium

Mentor: Chris Granger (San Francisco, CA)

Korma

Korma for other datastores

Brief explanation: Korma currently enables you to easily write queries for use with SQL, but the syntax is more generally applicable to any kind of relationally oriented data. This project seeks to bring the semantics of korma to other potential data sources, whether it be with some key-value datastore or just a collection of objects in memory.

Expected results: A subset of the Korma semantics working over data in memory and the beginnings of applying those semantics to something like mongo.

Skill level: medium to insane (the extrapolation of this is to build one set of semantics to rule them all)

Mentor: Chris Granger (San Francisco, CA)

Resiliency to vendor specifics

Brief explanation: Korma up to this point has explicitly not tried to abstract away the differences between DB providers (Postgres vs. MySQL vs Oracle ...) and as such requires some knowledge of how the vendor specifics affect your queries. This project revolves around creating a general purpose mechanism that allows the semantics of Korma to remain oblivious to the underlying implementation, but still manage to do the right thing for different vendors. More than the simple abstraction, the important part here is the ability to add these in over time by creating a very robust extensibility mechanism.

Expected results: A general extensibility framework for Korma's SQL compiler that enables replacement/addition/subtraction of SQL parts in different cases.

Knowledge Prerequisite: Clojure, SQL

Skill level: medium

Mentor: Chris Granger (San Francisco, CA)

Clojure(Script) tooling

Live game editor

Brief explanation: Based on Bret Victor's "Inventing on Principle" talk, I built a live game editor for ClojureScript. This project would focus on making what's built even more general, allowing any game to be built this way. It also seeks to add the ability to further manipulate time and adjust values through sliders and color pickers. The ultimate goal, however, is to go well beyond that and begin to think of what more could be done in a world where you can touch and instantly manipulate the elements of your game.

Expected results: A generalized version of the editor that allows you move forward and back in time, select elements to project, and has the ability to quickly adjust values using widgets.

Knowledge Prerequisite: Clojure, a love for games, a whole lot of imagination

Skill level: medium to insane

Mentor: Chris Granger (San Francisco, CA)

Browser-based Clojure(Script) editor

Brief explanation: Taking the editor out of my live game editor for ClojureScript, we could create a more general purpose code editor for use with Clojure/ClojureScript. Emacs, VIM, and CCW certainly work wonderfully for editing clojure, but their UI paradigms don't allow for more complex interactions. With the recent creation of code analysis tools, we can start to add much more interesting visual signals that can help you write better code. For examples of what can be done in this space, take a look a Dr. Racket.

Expected results: A fully capable editor that can save, read, compile files from a browser interface. Also, the beginnings of work on in-place UI to help with coding, e.g. visualizing the call stack when an exception occurs.

Knowledge Prerequisite: Clojure, creativity, a love for code, some understanding of code analysis would probably be useful