Skip to end of metadata
Go to start of metadata

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.

If there is no specific contact given you can ask questions on the general Clojure Google Group - http://groups.google.com/group/clojure

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.

Previous year's Project Ideas

Please see the Google Summer of Code 2012, Project Ideas 2013, and Project Ideas 2014 for examples of project ideas.

Project Ideas

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

Core Clojure

Clojure to Dalvik compiler

Brief explanation: The Android and Java platforms have slowly been evolving away from each other.  Android is now on its second-generation runtime and has released a preview of the next generation of its build toolchain.  As a result, it is becoming increasingly difficult for Clojure to keep up as it depends on compiling to the JVM.  What would be nice to have is a Clojure compiler that can target Android directly.  Ideally, this compiler would be able to accept any valid Clojure/JVM code.  Additionally, it should offer two compilation modes: 1. a development mode with a completely dynamic runtime, and 2. a production mode that can execute as quickly as a standard Java-based application.

Expected results: A functioning compiler that can support the above goals

Knowledge prerequisites: Clojure, Android, Dalvik, JVM, compilers

Mentor: Daniel Solano Gómez clojure at sattvik dot com

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:

Vectorz-Native

Brief explanation: vectorz-clj is a powerful, flexible, JVM based library frequently used with core.matrix for numerical computing. However sometimes it is hard to beat native libraries for high performance (especially libraries like BLAS/ALTAS for matrix multiplication). There is an opportunity to creatre an extension of vectorz-clj that harnesses native code to the full. Some techniques have been demonstrated by neanderthal-atlas (https://github.com/uncomplicate/neanderthal-atlas) and in experimental Vectorz extension classes (https://github.com/mikera/vectorz/blob/develop/src/main/java/mikera/matrixx/impl/BufferMatrix.java)

Expected results: 1) A fully working Vectorz ND-array implementation that harnesses native code and passes all vectorz-clj / core.matrix tests 2) Performance testing and optimisations to achieve competitiveness with other native code approaches. 3) A comprehensive test suite, ideally utilising test.check for generative testing

Knowledge prerequisites: Clojure (moderate level), Linear algebra, Java/native interop, Performance optimisation

Mentor: Mike Anderson

Data Visualisation for Clojure

Brief explanation: There are an increasing number of interesting ways to visualise data - from ggplot to OpenGL. Many tools and libraries exist to visualise data in Clojure (e.g. Incanter, gorilla-repl) , but there is a lack of a consistent way to visualise data that can be easily re-used. The goal for this project is to create a flexible visualisation library for Clojure, and demonstrate its applicability in different contexts.

Expected results: 1) A powerful library for visualisation 2) Demonstrate usage in at least two different contexts (e.g. Interactive at REPL with Incanter vs. data visualisation for the web) 3) Integration with other Clojure tools / libraries

Knowledge prerequisites: Clojure (moderate level), Data Science, Computer Graphics

Mentor: Mike Anderson

Typed Clojure

core.typed Annotations and Macros

Brief explanation: core.typed does not work automatically. It requires annotations for libraries and special macros to help type checking. This project will add annotations and useful macros for core Clojure libraries and 3rd party libraries.

Expectations of student: Type annotations, macros and test cases for Clojure code

Difficulty: Moderate

Expected results: annotations for Clojure/Script libraries, identified required improvements to type checker

Mentor: Ambrose Bonnaire-Sergeant (abonnairesergeant@gmail.com)

Typed CLJS JavaScript Interop

Brief explanation: Typed ClojureScript cannot interact with Javascript as it needs expected types. This project will 1) parse and harvest TypeScript types for JavaScript code, 2) update the type checker to use them and 3) document and unit test the solution.

Expected result: Typed ClojureScript with safe JavaScript interop

Difficulty: Moderate/Hard

Mentor: Ambrose Bonnaire-Sergeant

Typed Fluokitten

Brief explanation: Fluokitten is a library that implements category theory concepts in Clojure. This project will 1) identify what is needed to type check the fluokitten implementation and/or user code, 2) extend core.typed to support as many fluokitten idioms as possible, 3) add tests for supported idioms, and 4) document supported idioms and explain why other idioms are not supported.

Expected result: core.typed's checker extended with better support for higher-kinded types, practical annotations for fluokitten, documentation to use Typed fluokitten.

Difficulty: Hard

Mentor: Ambrose Bonnaire-Sergeant

Typed Overtone

Brief explanation: Overtone is a music generation library for Clojure. Type checking its implementation is a useful exercise to stress core.typed, learn and document about the complex inner workings of Overtone, and as a project for a student to learn about core.typed. Here is a preliminary attempt to type check Overtone, which already reveals interesting aspects about Overtone's implementation.

Expected result: annotations for Overtone's internals

Difficulty: Moderate/Hard

Mentor: Ambrose Bonnaire-Sergeant

core.typed Caching Annotations

Brief explanation: Currently core.typed wipes away all type annotations when type checking a namespace, which means all dependencies are redundantly checked. Type checking could be much fast if we identify which type information is safe to remember and keep it around when appropriate. This project will 1) identify a strategy to categorise expired/safe type information, 2) implement strategy in core.typed, 3) expose faster strategy to the user, 4) document invariants and assumptions of strategy.

Expected result: increased performance for core.typed type checking

Difficulty: Hard

Mentor: Ambrose Bonnaire-Sergeant

Typed Transducers

Brief explanation: Transducers are a new feature in Clojure 1.7. Many core functions have changed and it is not clear if core.typed needs to be extended to support transducers. This project will 1) add annotations for core functions that use transducers, 2) add tests for these functions, 3) document issues in expressing types for transducers.

Expected result: practical annotations for transducers

Difficulty: Hard

Mentor: Ambrose Bonnaire-Sergeant

Typed Transients

Brief explanation: core.typed has limited support for transients in Clojure. This project will 1) add annotations for core functions and data structures that use transients, 2) add tests for these functions, 3) document issues in expressing types for transients.

Expected result: practical annotations for transients

Difficulty: Hard

Mentor: Ambrose Bonnaire-Sergeant


ClojureScript

ClojureScript on Android

Brief explanation: There has been some interesting work on using ClojureScript to build native Android applications.  One approach is to use Rhino to run ClojureScript natively.  React Native, which has been recently announced, is also an exciting avenue for exploration.  A student pursuing this project choose an approach and make ClojureScript on Android a practical alternative.

Expected results: A working toolchain and libraries for ClojureScript on Android.  This could either be built into Android's Gradle-based build system or using Leiningen.

Knowledge prerequisites: ClojurScript, Clojure, Android, Leiningen, Gradle

Mentor: Daniel Solano Gómez, possibly others

cljs.core.async 

Brief explanation: clojure.core.async has been significantly enhanced by leveraging tools.analyzer. The semantics of the language is correctly supported in go blocks and and accurate source location information is generated significantly simplifying the process of debugging. cljs.core.async however lags in this regard. The project would involve bringing over the enhancements by leveraging the CLJS support provided by tools.analyzer.

Expected results: cljs.core.async experience comparble to clojure.core.async

Knowledge prerequisites: ClojureScript, Clojure, core.async, tools.analyzer

Mentor: David Nolen <dnolen dot lists at gmail dot com>, Nicola Mometto <brobronsa at gmail dot com>

ClojureScript & Google Closure

Brief explanation: there are many deeper impactful enhancements we would like to make to the ClojureScript compiler, particularly with respect to Google Closure Compiler. While we provide a significant amount of reasoning about ClojureScript source we do very little with respect to JavaScript interop or better integration with the wider non-Closure JavaScript ecosystem such as CommonJS, AMD, or ES6 modules. Google Closure Compiler has powerful facilities we could leverage to check interop (validate js/foo against known externs for example) as well as provide a seamless compilation story for non-Closure compatible libraries.

Expected results: basic JavaScript interop validation, CommonJS/AMD/ES6 module support

Knowledge prerequisites: ClojureScript, Clojure, Java

Mentor: David Nolen

tools.reader.cljs

Brief explanation: A significant hurdle to an optional bootstrapped ClojureScript compiler is a version of tools.reader that can run on popular JavaScript runtime such as Node.js. Supplying a version of tools.reader that can compile to JavaScript through ClojureScript would be a big step forward for ClojureScript applications that would benefit from running without the JVM (Atom Shell, OS X JSC based applications, etc.)

Expected results: a version of tools.reader that runs under Node.js

Knowledge prerequisites: ClojureScript, Clojure, JavaScript, Node.js

Mentor: David Nolen, Nicola Mometto

 

Light Table

Tooling

Better Clojure/Android integration

Brief explanation:  A long time ago, Neko provided Clojure support for integrating Clojure compilation into the Android build system.  Since then, lein-droid has made Android development for Clojure programmers much easier by allowing them to leverage knowledge of the tools they already use.  However, in the past year or so, Android has started shifting to using Gradle as the main build tool  The Android plugin for Gradle has features that are not supported by lein-droid, but would be nice to have.  Unfortunately, because the Android plugin replaces the Java plugin, the current Clojure plugin doesn't work for Android.

Expected results: A fully functional Gradle plugin for Clojure that is compatible with the Android plugin which can be used independently.  Additionally, lein-droid should be enhanced to be able to use the new build system.

Knowledge prerequisites: Android, Clojure, Gradle, Leiningen

Mentor: Daniel Solano Gómez

 

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.  Some suggested dynamic checks that could be made, if they are not already implemented, are described in Github issue #5.

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

Knowledge prerequisites: None

Difficulty: Easy

Mentor: Ambrose Bonnaire-Sergeant

 

Source metadata information model 

Brief explanation: Currently there are a number of tools that analyze Clojure source and produce some API-related output (autodoc, codox, code underneath sites like Grimmoire, crossclj.info, etc). All of these tools re-index the same projects with different partially complete code and produce human output, but no re-usable data (with the possible exception of Grimmoire). An opportunity exists to create a standard information model describing source from an API perspective. We can then index projects once, publish the output, and reuse it in a variety of ways.

Defining the information model has a number of interesting problems - capturing all aspects of a Clojure API for use (functions, macros, records, types, protocols, multimethods, namespaces) as well as ways to capture commonly used extensions (via def... macros) like Prismatic Schema, etc. This implies a model that is open to extension.

Expected results: A model for Clojure source metadata and one or more of the following:

  • A serialization of the information model that can be archived and published. (Other serializations may also be useful.)
  • An indexing library to generate a serialization of the model for an existing project.
  • Build plugins to produce and deploy artifacts of this data for a project (similar to the -source and -javadoc jars in Java land). Making this tooling easy to use is important to encourage existing projects to produce these artifacts as part of their build and deploy process.
  • Library to produce static html docs for one or more doc models.
  • Build plugins to automatically find and retrieve metadata artifacts for dependencies.
  • Library and/or build plugins to query one or more metadata artifacts.

Knowledge prerequisites: None

Difficulty: Easy

Mentor: Alex Miller

Labels: