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

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.

Linter based on Ambrose's analyzer work

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

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

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

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

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

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.

Tools

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.