Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Google Summer of Code 2012 Project Ideas

Please see the Google Summer of Code 2012 for examples of project ideas.

Project Ideas

Info

Please organise your project idea into a category below. Feel free to create new categories if needed.

Core Clojure

Clojurescript

Optimization

Brief explanation: ClojureScript is in constant need of further optimization and optimizations which are likely to deliver across all the major JavaScript implementations. We need to assess the corners of ClojureScript which seem to lag too far behind Clojure on the JVM and see what can be done. This includes but is not limited to improvements to persistent data structures, function invocation, the EDN reader, and to code size. It would be extremely desirable to generalize the ad-hoc benchmarking that is in currently in place. A web based tool that graphs changes over time that continually run the tests a la Are We Fast Yet? would be extremely beneficial - we imagine highlighting changesets that cause regression with links to GitHub, etc. 

Expected results: Improved performance and comprehensive benchmark suite that is available on and offline.

Knowledge prerequistes: A JavaScript performance nut. Experience with Clojure.

Difficulty: Medium

Mentor: David Nolen

Source Maps

Brief explanation: ClojureScript debugging is still significantly harder than it should be. Source Maps would greatly alleviate the difficultly. A considerable amount of work has been done, but there is more to do during emission in the compiler before the source maps we generate will be truly accurate. Even after Source Maps work, there's the question of step-by-step debugging. Perhaps it's possible to do this via a mixture of source maps and something via the Remote Debugging Protocol in Chrome. We could even imagine editing ClojureScript source in Chrome.  

Expected results: Accurate source mapping in browsers that support.

Knowledge prerequistes: A JavaScript & Programming languages nut. Experience with Clojure.

Difficulty: Medium

Mentor: David Nolen

Extending dogfort for real world use

Brief explanation:  Node.js provides a lightweight and fast server implementation, that’s commonly used for real time applications. Although its possible to make clojurescript applications targeting nodejs, the current experience is far from pleasant. Partly due to node’s heavy use of callback hell, and partly because most existing node libraries are heavily object oriented and imperative. Dogfort (https://github.com/bodil/dogfort) is a nice proof of concept , inspired by ring and compojure, that abstracts out quite a few of these issues.

Expected results: An improved version of dogfort that can be put to real world use. New features include:
- sessions
- cookies
- authentication middleware
- socket.io abstraction
- route filtering middleware
 
Knowledge prerequisites: Familiarity with nodejs

Mentor: Bodil Stokke

core.match

refactor and documentation

Brief explanation: core.match provides ML & Racket style extensible pattern matching to Clojure & ClojureScript. The project is in need of refactoring and extensive internal documentation. In order to aid debugging the pattern matrix transformations, a tool for stepping through the pattern compilation process would be very desirable.

Expected results: An core.match with fewer bugs and a code base that welcomes internal contributions and simplifies external extensions.

Knowledge prerequisites: Familiarity with at least one functional programming language that includes pattern matching as a feature.

Difficulty: Medium-Hard

Mentor: David Nolen

core.logic

CLP(FD) enhancements

Brief explanation: core.logic now ships with a basic support for efficient constraint logic programming over finite domains. However this work could be taken considerably further. For example new constraints could be added that would allow core.logic to solve FD equations much, much more efficiently. It's also not clear precisely what kinds of classic FD problems core.logic excels at and on which ones we perform poorly on. It would be informative to take the problems found in mature solvers like GeCode and port them over to core.logic so a more disciplined comparison could be made. It would also be interesting to discover if core.logic can be made to defer FD constraint solving to external solvers like GeCode or JaCoP if that is desirable to the user.

Expected results: Improved performance and benchmark suite.

Knowledge prerequistes: Experience with Clojure, though significant functional experience in Common Lisp, Scheme, Racket, Haskell, OCaml, Scala is OK too if Clojure experience is lacking. Experience with Prolog or another language that supports constraint solving well is a big plus.  

Difficulty: Hard

Mentor: David Nolen

CLP(Set)

Brief explanation: CLP(Set) would greatly widen the applicability of using core.logic for various forms of static analysis. It would also make core.logic programming more natural for more kinds of problems for Clojure programmers.

Expected results: Basic support for CLP(Set). If CLP(Set) work begins in earnest by core.logic developers, we expect the student to tackle the various significant subproblems we expect to encounter.

Knowledge prerequistes: Experience with Clojure, though significant functional experience in Common Lisp, Scheme, Racket, Haskell, OCaml, Scala is OK too if Clojure experience is lacking. Experience with Prolog or another language that supports constraint solving well is a big plus.  

Difficulty: Hard

Mentor: David Nolen

CLP(Prob)

Brief explanation: core.logic with probabilistic programming features would be a powerful extension to core.logic with a high degree of real world applicability.

Expected results: Basic support of CLP(Prob).

Knowledge prerequistes: Experience with Clojure, though significant functional experience in Common Lisp, Scheme, Racket, Haskell, OCaml, Scala is OK too if Clojure experience is lacking. Experience with Prolog or another language that supports constraint solving well is a big plus.

Difficulty: Medium-Hard 

Mentor: David Nolen

core.matrix

NDArray Implementation in Clojure

Brief explanation: Clojure's core.matrix (https://github.com/clojure-numerics/core.matrix) provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. An innovative feature of this API is that it is designed to support  multiple back-end implementations via Clojure protocols, which allows various mature Java-based matrix libraries to be used in idiomatic Clojure code. However, we do not yet have a comprehensive N-dimensional Array (NDArray) implementation written in Clojure itself. This is important because a) It would become the de-facto standard matrix implementation for core.matrix and b) It has the potential become the base format for multi-dimensional numerics in Clojure and c) It would enable core.matrix to work "out of the box" without needing a separate matrix library implementation.

Expected results: At the end of the project, core.matrix should include a NDArray implementation written in Clojure that conforms fully to the core.matrix API and passes all relevant test suites.

Difficulty: Medium/Hard

Mentor: Mike Anderson (core.matrix maintainer)

Algebraic Expressions

Brief explanation: Clojure's core.matrix (https://github.com/clojure-numerics/core.matrix) provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. There is an opportunity to research and implement a system for representing and optimising mathematical expressions so that they can be executed efficiently via core.matrix. There is significant opportunity to explore advanced features, e.g. finding solutions to systems of equations, compiling strategies for numerical optimisation, analysing expressions to determine opportunities for distributing or parallelizing computation etc.  It is proposed that the solution should exploit core.logic for manipulating expressions / solving formulae. Some experimental implementation ideas exist at https://github.com/clojure-numerics/expresso

Expected results: At the end of the project, core.matrix should include a system for representing mathematical matrix expressions, and optimising them for efficient execution in core.matrix.

Knowledge prerequisites: Advanced Linear Algebra, Logic Programming (core.logic), Experience with Clojure

Difficulty: Hard

Mentor: Mike Anderson (core.matrix maintainer)

Incanter support

Brief explanation: Clojure's core.matrix (https://github.com/clojure-numerics/core.matrix) provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. Incanter is a Clojure-based, R-like platform for statistical computing and graphics. Historically, Incanter used some legacy matrix code that bound it to specific matrix implementations, and it would be a great improvement to have full core.matrix support in Incanter. However core.matrix is relatively new and does not yet have all the features required to meet Incanter's needs. The goal of this project is to make this integration happen, which will unify two of the major projects in the Clojure numerical computing space.

Expected results: At the end of the project, core.matrix should include support for all functionality required to support Incanter, and there should be a patched version of Incanter that uses core.matrix as the primary matrix library. Ideally, Incanter should adopt the core.matrix version as the master branch going forward (subject to approval with Incanter project leads).

Knowledge prerequisites: Linear Algebra, Statistics, Experience with Clojure

Difficulty: Medium

Mentor: Mike Anderson (core.matrix maintainer)

API Contract Validation

Brief explanation: Clojure's core.matrix (https://github.com/clojure-numerics/core.matrix) provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. An innovative feature of this API is that it is designed to support multiple back-end implementations via Clojure protocols, which allows various mature Java-based matrix libraries to be used in idiomatic Clojure code. However, this presents the challenge of validating that different back end implementations adhere to the contract implied by the core.matrix API. The goal of this project is to implement a robust system for specifying and validating these contracts, so that any core.matrix implementation can prove that it correctly supports the API, and any defects / regressions can be detected and understood. The problem is interesting because of the variety of options in the core.matrix API that the implementations may support (e.g. double vs int arrays, arrays of different dimensionality, optional linear algebra features, ability to fallback to default implementations etc.) - so it is not simply a case of pass / fail but understanding what combination of features an implementation supports and validating these.

Expected results: At the end of the project, core.matrix should include a robust system for declaring and validating API contracts. This should have been tested successfully against all internal core.matrix matrix implementations, and at least one external core.matrix implementation (e.g. vectorz-clj).

Knowledge prerequisites: Linear Algebra, Test-Driven Development, API Design, Experience with Clojure

Difficulty: Medium/Hard

Mentor: Mike Anderson (core.matrix maintainer)

Mobile

Tooling

Enhancing Clooj IDE

Brief explanation: Clooj (https://github.com/arthuredelstein/clooj) is already a good IDE for Clojure beginners to start with, if they do not already have a preferred development tool set.  It is the easiest to install.  There are ideas for enhancements in the Issues tab of the project.

Expected results: An enhanced version of Clooj that fixes existing issues, adds new features, etc.

Knowledge prerequisites: The student would need to know or learn Clojure, and something about GUI development using Java Swing, the GUI library currently used by Swing.

Mentor: Arthur Edelstein, the developer of Clooj, would be an ideal mentor, if he has the time and interest in doing so.  No one has yet approached him with this possibility that I am aware of.

Refactoring feature for CCW & other IDEs

Brief explanation: Counterclockwise ( code.google.com/p/counterclockwise/ ) is the de facto Clojure plugin for Eclipse. It currently lacks any Clojure-specific refactoring feature, while Eclipse already provides a generic Framework for Refactoring. The idea would be to create refactorings for Clojure code.

Expected results:  A handful of common refactorings implemented, integrated with the Eclipse Refactoring Framework. A simplified integration layer for adding more refactorings in the future. Clojure the language will be used to write the refactorings. As few java as possible. Everything that is not IDE related separated in a "headless" layer so that it can be reused in other contexts (other IDEs, command line, leiningen plugin, etc.).

Knowledge prerequisites: The student would need to already know Clojure. Existing experience with Eclipse development would be a plus, since it's a framework with kind of a barrier to entry.

Mentor: Laurent Petit, developer of Counterclockwise.

Program analysis suite, based on Rich Hickey's Codeq

Brief explanation: Rich Hickey, inventor of Clojure and Datomic, created Codeq (http://blog.datomic.com/2012/10/codeq.html) as a prototype framework for program analysis.  It harvests multiple information sources (eg, Git metadata, source code), and stores the results in a graph database (eg, Datomic).  The results are thus available for querying, processing, visualization, etc.

Although Codeq is very promising, it is only a proof of concept, lacking analyzers, a control framework, and presentation tools. Turning Codeq into a production suite would be a substantial software engineering effort, with corresponding visibility.  The student would extend the base that Codeq provides, producing a compelling and robust example of the power of this approach.

Expected results: The suite should be ready for "drop-in" installation in typical Clojure shops.  It should do continuous harvesting of code bases. It should extend the current Clojure analyzer to harvest names of called functions and methods, use of global state, etc.

Stretch goals might include other analyzers (eg, Java), queries for common use cases, analysis and visualization software, etc.

Knowledge prerequisites: Interest in mechanized program analysis.  Experience with Clojure.

Difficulty:  Medium

Mentor:  Rich Morin (mechanized documentation enthusiast), Tom Faulhaber (author of Autodoc, clojure.pprint, etc.)

core.typed

Improve and document core.typed

Brief explanation: Optional type systems are more effective when only a small subset of code needs to be tailored to its needs (3-6%). Currently several important Clojure idioms are not understood by core.typed.

Documentation for core.typed is sparse, making the transition to it much harder than necessary for users.

Expected results: 

Type check more expressions and idioms:

  • More complete multimethod support
    • eg. multiple dispatch
  • Support for function keyword arguments
  • More core functions/methods assigned types
  • Completed: Should understand common control flow idioms across body expressions (in progress)
    • eg. function preconditions, assertions bound to throwaway locals like _
  • Improve Java method inference for method calls that the Clojure compiler does not already infer
  • Namespace management tools
    • eg. typed-require, typed-use, typed-load
  • Contract generation from types
    • Useful for preserving static type invariants when using typed code from untyped code.
  • More comprehensive handling of complex operations
    • eg. assoc, dissoc, update-in, assoc-in, get-in
  • Be able to successfully type check the current ClojureScript compiler
  • Design "Wrapper" types
    • eg. SQLSafeString
    • Might not fit with core.typed
  • Better design metadata types
    • especially for `with-meta`
  • Add support for Clojure Records
    • implement correct behaviour for when all base keys are dissociated (a record loses it's type)
  • Completed: Design solutions to correctly handle macros with complicated expansions.
    • especially `for`, `dotimes`, `doseq` etc.
  • Design a type generalising scheme to help better guess the type of loop variables
    • eg. (loop [a 1] ...) ; a should probably be Long, not the type (Value 0)
    • harder: (loop [a nil] ...) ; should be (U nil (Seqable Any)) ?
  • Design a sound solution for boxed/unboxed positions
    • Often doesn't make sense to give a function a primitive return.
    • eg. `int` should probably be something like `(MaybePrimitive int)`
    • Target Clojure 1.5 boxing semantics
  • Understand common higher-order functions in non-higher-order contexts
    • eg. juxt, every?, comp, partial, etc
  • Investigate and (perhaps) prototype an implementation of Alms type inference
Documentation:
  • Comprehensive user guide
  • Untyped -> typed migration guide
  • Code examples
    • Complete typed CLJS compiler

Knowledge prerequisites:

  • Reasonably complete knowledge of core.typed or Typed Racket internals

Mentor: David Nolen

Student: Ambrose Bonnaire-Sergeant

Previous GSoC Student Partiticipation: Typed Clojure (GSoC 2012, Clojure organisation)

Mentor-Student relationship: 

  • 2011 - core.match + core.logic development & docs
  • 2012 - Mentor-Student for Typed Clojure GSoC 2012

Clojure in Clojure

Complete CinC implementation

Brief Explanation: After the success of the CLJS compiler, rewriting the JVM compiler in Clojure has been on the menu for a while now. CinC has made a great start, but needs work to be a viable alternative to the JVM compiler.

Expected Results: Reliable alternative Clojure compiler to clojure.lang.Compiler

Knowledge prerequisites: Good Java and Clojure knowledge. Previous work with compilers a plus, especially CLJS.

Mentor: Aaron Cohen

Web


 

Data structures

RRB-Trees (flexvec)

Brief explanation: Polishing https://github.com/michalmarczyk/flexvec, the Clojure implementation of persistent vectors with support for efficient slicing and concatenation, based on Bagwell, Rompf, "RRB-Trees: Efficient Immutable Vectors", EPFL-REPORT-169879, September, 2011.

Expected results: Optimized implementation of concatenation (to replace the current high-level implementation using Clojure's seq functions extensively), full test coverage (currently there are (separate) probabilistic tests in place for concatenation and slicing, however a complete test suite for the basic vector operations, as well as concat-after-slice etc. is needed), performance tuning (e.g. fixing performance degradation arising when flexvec vectors of different element types are used in the same JVM; the overall performance profile needs to be closer to that of c.l.PersistentVector – this requires major profiling effort and possibly tweaks to the compiler), ClojureScript version (using whichever method of code sharing becomes standard during Clojure 1.6 development cycle if that happens prior to end of the GSoC period).

Knowledge prerequisites: Familiarity with algorithmic details behind RRB-Trees, experience with Clojure and ClojureScript performance tuning.

Mentor: David Nolen