Guidelines

Information for Students

These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at.

Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

Adding a Proposal

Please follow this template. If you don't have Confluence access please submit your idea, following this template to the clojure mailing list with the subject prefix [GSoC Idea]. Also, feel free to add new categories.

Project title (heading level 3)

Brief explanation: A few sentences describing the problem to solved.

Expected results: What should the student have been able to produce at the end of the project. This includes things like tests and documentation.

Knowledge prerequisites: If a student needs to know something to be able to complete the project, be sure to list it.

Mentor: Add your name if you are developer who is willing to be a primary or secondary mentor for the project.

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

Project Ideas

Core Clojure

Lean JVM Runtime

Brief explanation: The current Clojure/JVM runtime is fully-featured, and can become even more fully-featured with projects like core.typed. However, sometimes it is important to have a leaner runtime that is less resource-intensive. This is ideal for instances where Clojure serves primarily as a library or in lean runtime environments like Google App Engine or Android where a quick startup is desirable. The goal of this project would be to create an alternative lean Clojure runtime and associated compiler. The compiler may be based either of the standard compiler or the ClojureScript compiler. Clojure vars would compile to static fields or methods. It will be necessary to find out which subset of the language makes sense (for example, vars would probably not really exist anymore).

Expected results: A lean Clojure runtime and compiler (well, some good progress to this end)

Knowledge prerequisites: A thorough understanding of Clojure and some familiarity with byte code generation for the JVM.

Difficulty: Hard

Mentor: Daniel Solano Gómez

Numerical Clojure

Many of us are working to make Clojure into a great platform for Data Science, Big Data and numerical computing. See the Numerical Clojure Group for ideas and discussions. There are many opportunities to take on exciting projects in this space - a few ideas are listed below:

Linear Algebra for Clojure

Brief explanation: core.matrix provides a powerful and flexible API for array programming and numerical computing in Clojure. To take this to the next level, it is important to implement a suite of linear algebra algorithms - including various matrix decompositions (SVD, QR, Cholesky etc.....), linear system solvers etc. These need to be added both to the core.matrix API, and to one or more core.matrix implementations. A good option would be to add these algorithms to vectorz-clj, which is a well-maintained core.matrix implementation that runs 100% on the JVM. It would be possible to port or adapt existing Java algorithms (e.g. from EJML). Our goal would be to match / exceed the performance of other Java-based libraries - see the Java Matrix Benchmark

Expected results: A clean, well-defined API for linear algebra in core.matrix. Fast working implementations of the API added to vectorz-clj, with performance comparable to the best libraries in the Java Matrix Benchmark

Knowledge prerequisites: Mathematics / linear algebra, Java, Clojure

Skill Level: Hard

Mentor: Mike Anderson

GPU.matrix

Brief explanation: core.matrix provides a powerful and flexible API for array programming and numerical computing in Clojure. It should be possible to create an implementation for core.matrix that performs computations on the GPU. Ideally, matrices would be retained in GPU memory as much as possible, to avoid unnecessary copying to/from main memory.

Incanter + core.matrix integration

Brief explanation: core.matrix provides a powerful and flexible API for array programming and numerical computing in Clojure. Incanter is a platform for statistical computing and graphics. Bringing the two together would create a powerful combination.

Expected results: Incanter modified to take full advantage of core.matrix.

Knowledge prerequisites: Statistics, Mathematics, Clojure

Skill Level: Hard

Mentor: TBC

HDF5 interface for Clojure + core.matrix integration

Brief explanation:HDF5 is a flexible and widely used file format for storing large datasets, in particular in the form of arrays and tables. There is a rudimentary Clojure interface, but it isn't nearly as full-featured and flexible as interfaces for other languages. Ideally, a Clojure interface would integrate with core.matrix to present datasets as arrays-on-disk, following the example of the h5py interface library for Python which succeeds very well at this.

ClojureScript

Quil on ClojureScript

Brief explanation:Quil is a drawing and animation library for clojure. It is basically wrapper over Processing. Currently Quil works only on vanilla clojure (JVM based). It would be cool to have it also on ClojureScript. Processing already have javascript version: Processing.js, so it can be used for our goals.

Expected results: quil clojurescript library capable of running regular quil sketches, documentation how to use it in clojurescript project.

Typed ClojureScript Annotations

Brief explanation: Typed ClojureScript is an optional type checker for ClojureScript. Many annotations are missing for the core ClojureScript libraries, which means using the type checker is more painful than it should be. This project involves annotating these core libraries like cljs.core so most of the core annotations are included in the type checker. This is a great project to get familiar with ClojureScript, Clojure, and/or Typed Clojure.

Expectations of student: The student is not expected to make changes to the type checker, but rather identify areas that need improvement to meaningfully annotate the libraries and report them to the Typed ClojureScript maintainers. No particular prior experience with Clojure, ClojureScript, Typed Clojure or type systems is required, but the student is expected to learn quickly from their mentor who will bring them up to speed with any relevant area.

Brief Explanation: React.js provides a natural model for transforming declarative data into interactive interfaces. Om is a powerful Clojurescript interface to React. This project will develop reusable Om components for data visualization, which could be used in conjunction with libraries like Incanter, or for stand-alone applications. React supports SVG out-of-the box, so that will be the initial visualization target.

Expected result: A set of standard visualization components covering the common types, built using Clojurescript and Om. If time allows, the student will have the option of either A) extending the React model to Canvas to achieve higher-scale visualization, or B) develop a visualization subarea in greater detail, for example map projections.

Difficulty: Variable, accommodates to any skill level. Some components will already be in place for the student to follow as an example.

Mentor: Kovas Boguta (kovas.boguta@gmail.com)

Typed ClojureScript Checker

Brief explanation: Typed ClojureScript is a type system for ClojureScript. It shares many of the same building blocks as Typed Clojure, which is much more complete. This project involves developing Typed ClojureScript with the goal of achieving a similar usefulness to Typed Clojure.

Expected result: A usable implementation of Typed ClojureScript

Difficulty: Hard

Mentor: Ambrose Bonnaire-Sergeant

Light Table

BOT browser

Brief explanation: The BOT system used in LT keeps all application state in a globally accessible index. A browser tools could use this to show lists of object types, objects, behaviours and tags updating in real time and filterable by type and key/value search. This would let new developers browse through state to get an overview of where things are stored and then drill down to watch the objects they are interested in and see how they change over time.

Expected results: A UI for browsing and searching behaviours, objects and tags that updates in real time

Knowledge prerequisites: Familiarity with clojurescript and experience with building interactive HTML apps

Mentor: Jamie Brandon

Connection manager

Brief explanation: Currently, running a daemon for eg background code analysis is painful. See node.cljs for an example of the boilerplate required. The manager will need to handle asking the user for arguments (eg which virtualenv to use), starting a process or connecting to an existing one, piping stdout/stderr into the console, displaying meaningful error messages to the user, displaying restart buttons for failed connections etc

Expected results: Creating a connection to eg tern or ensime is as simple as passing the executable path and arguments. The connection manager handles updating the UI, reporting errors and restarting the connection. Connections that want to override defaults can do so (probably via adding/removing behaviours).

Knowledge prerequisites: Familiarity with clojurescript and experience with async IO in node.js

Mentor: Jamie Brandon

Javascript API

Brief explanation: Currently, writing a plugin for LT requires learning clojurescript. Joshua Cole has written a basic wrapper (ltrap) and a few javascript plugins but manually wrapping the LT core is not a sustainable solution. We need to come up with some standards for communicating between cljs and js that don’t involve converting everything by hand.

Expected results: Developers can write plugins in javascript. This includes defining behaviours/objects, modifying objects and raising triggers. The javascript code is clean and idiomatic (no lt.object.__GT_behavior_name). The bindings do not require constant effort to keep up to date when we modify LT core.

Codexes

Brief explanation: In the original Light Table videos we showed the ability to edit functions outside of the files that they are stored in. The end result was a ‘codex’ - a kind of virtual document made up of text from multiple different source documents. This idea didn’t make it into the current version of Light Table but it is still regularly requested. CodeMirror (the editor on which LT is based) already has the ability to create linked documents so the remaining work is mostly in parsing function boundaries and exposing an intuitive UI.

Expected results: Users can create a codex and add text from other files. When either the codex or the source file is modified, both are updated immediately. Rather than manually selecting a region of text to add, the user can run an ‘Add function to codex’ command which parses the text around the cursor position to find function boundaries.

Knowledge prerequisites: Familiarity with clojurescript, knowledge of parsing algorithms and experience with building interactive HTML apps

Mentor: Jamie Brandon

Tooling

Dynalint: Improved Core Clojure errors and warnings

Brief explanation: Error reporting has been identified as a common complaint of Clojure in the latest Clojure Survey. In many cases, addressing these concerns directly in the core Clojure implementation would degrade performance, while an explicit "strict" or debug mode for Clojure would require extensive changes to Clojure core. Dynalint takes another approach: it is an external tool that can "instrument" core Clojure functionality to emit warnings and better errors. This approach has some limitations, but it can quickly make headway in an area that Clojure struggles with.

Expected results: A comprehensive suite of useful warnings and errors for the (near) latest version/s of Clojure.