Google Summer of Code 2015 Scala Projects

Google Summer of Code

This year the Scala team applied again for the Google Summer of Code program to work with enthusiastic students on challenging Scala projects

This page provides a list of project ideas. The suggestions are only a starting point for students. We expect students to explore the ideas in much more detail, preferably with their own suggestions and detailed plans on how they want to proceed. Don’t feel constrained by the provided list! We welcome any of your own challenging ideas, but make sure that the proposed project satisfies the main requirements mentioned below.

How to get involved

The best place to propose and discuss your proposals is our “scala-language” mailing list. This way you will get quickly responses from the whole Scala community.

Previous Summer of Code

We encourage you to have a look at our Summer of Code 2010, 2011, 2012, 2013, and 2014 pages to get an idea on what we and you can expect while working on Scala.

Project Ideas

Here are some project ideas. The list is non-binding and any reasonable project related to Scala that is proposed by a student will be thoroughly reviewed.

Continue work on MongoDB support for Slick

This is will be a tough project. You will need to make major changes to Slick’s API and internals. Last years project implemented connection handling, plain JSON queries and lifted embedding queries for non-nested objects. The missing piece is extending Slick to support nested object like MongoDB does, but relational databases do not. Existing familiarity with Slick internals are welcome for this project.

Supervised by @cvogt and @szeiger

More info at [email protected]

The New Face of Slick

Slick is a modern database query and access library for Scala. It allows you to work with stored data almost as if you were using Scala collections while at the same time giving you full control over when a database access happens and which data is transferred. You can write your database queries in Scala instead of SQL, thus profiting from the static checking, compile-time safety, and compositionality of Scala.

Slick’s interface, uses the type-based deep embedding that imposes some limitations on the interface:

  • Native language constructs can not be used (e.g., == must be replaced with ===).
  • Reported type errors can get nasty.

We propose an new front-end for Slick based on libraries scala-yinyang and direct-embedding that will make Slick queries identical to regular Scala.

By doing this project you will vastly improve the user experience for many Scala users!

Implement a library-style Scala build tool

SBT is the most common build tool for Scala. It has a framework style architecture, where you drop code snippets into an existing structure and it calls you. The task of this project is to do it the other way around - don’t call me, I call you. Create a new build tool, that is a pure scala library. The assumption is that a library style api makes it much easier to understand and extend for Scala developers than a framework for which most people resort to little more than blind copy and pasting. The library will need to integrate ivy for dependency management and zinc the incremental scala compiler. Nice to have would also be being able to keep the jvm running. It is probably wise to just use sbt under the hood and just provide a new interface on top. It could look something like this:

// Compile.scala
import LibraryBuildTool._
object Compile extends App{
  val cc = new CompileConfiguration{
    override def src = src="src/main/scala/"
    override def target = "target/"
    override def dependencies = Seq(
      Dependency("org.scala-lang.modules", "scala-async", "0.9.2")
    )
  }
  incrementalCompile(CompileConfiguration)
}

Obviously the scope of this project is limited to the time frame of the project, but the basic features for making this usable and extensible should be implemented.

Supervised by @cvogt

More info at [email protected]

Implement other backends for Scaladoc

Scaladoc currently only generates a html+javascript output format. In this project you will have to work on the Scaladoc plugin for the Scala compiler and implement additional backends like plain PDF, single page html, multi-page html, chm, dash… . This is not an easy task and will require you to work intimately with fundamental concepts of the Scala language and close to the compiler implementation.

Supervised by @cvogt

More info at [email protected]

Update: Project focus changed to scala meta backed doc tool. Final state of the GSOC project: https://github.com/kolowheel/new-scaladoc/

Data migration tool

The goal of this project is creating a tool for managing data migration scripts based on Slick. We have a rough proof of concept implementation you can base work on at https://github.com/cvogt/migrations . The idea is roughly similar to migrations/evolutions in Ruby on Rails or Scala Play 2. You will need to significantly improve (or re-write) the code of the proof of concept implementation to make it production ready, extend it by futher features and explore some exciting ideas like reliable migrations in a development scenario with branches (like git branches). Your ideas are important to this project. Here is how we see it right now:

Existing features (which all require revision)

  • migration scripts written in Slick/SQL/Scala
  • diagnostic features for reviewing scripts and database

Required improvements

  • make it work with all Slick backends (the proof of concept is hard-coded to h2)
  • make it as production ready as possible
  • improve it based on comparison with other tools and potential user feedback gathered via mailing list, etc.

New feature ideas

  • dumping Slick migration scripts into SQL scripts (desired by potential users)
  • integration with SQL-file-based migration tools like Play or Flyway
  • a version compatibility scheme between generated code and database schema versions
  • support for a convenient work flow for working with databases and git branches
  • support for common industry use cases (like pre, during, post shutdown migration scripts)

What features you need to implement exactly is open and needs to re-evaluated as we go in discussion with you and based on potential user feedback. We want to work with you in an agile, ticket-based development style with frequent communication and coordination.

Supervised by @cvogt

More info at [email protected]

Update: Successfully implemented: https://github.com/lastland/scala-forklift

ScalaMeter Extensions – JMH Frontend and Binary Compatible Benchmark Data Format

  • implement a binary-compatible Persistor for ScalaMeter, which will correctly persist data across ScalaMeter versions
  • implement a custom executor, which serves as front-end for JMH
  • add measurers for other performance metrics, such as method invocations and boxing
  • propose and implement data-types and algebra for performance metrics, so that Measurers produce more generic and functional objects, in additional to only Doubles

The goal of this project is to provide various extensions to ScalaMeter, as described above. The first part is fairly simple, while the second and the third part require investigating what the best solution is. The final part will involve a design phase and an implementation, and require more creativity on your part.

Supervised by @axel22

TASTY support for Scala

Proposed in the scala.meta project, the idea of AST persistence recently gained traction in the Scala ecosystem. Last fall, the Dotty team has adopted TASTY, a typed AST pickling format, as its primary interchange format, and its implementation is already making its way into the Dotty compiler.

The goal of this project is to implement serialization and deserialization of Scala compiler trees into TASTY to help us establish the new metaprogramming platform for the Scala ecosystem. This will facilitate interoperability between Scala and Dotty, will enable advanced metaprogramming techniques with scala.meta and provide the potential to improve code optimization facilities for Scala.

When working on the project you will:

  • Implement a TASTY serializer, which takes scalac ASTs after the typer phase and produces TASTY binaries
  • Write a TASTY deserializer, which unpickles TASTY binaries into attributed scalac ASTs
  • Develop test infrastructure as well as a suite of tests that ensure correctness and compatibility of produced binaries

Mentored by Eugene Burmako

Requirements and Guidelines

General Student Application Requirements

This is the fifth time the Scala project has applied to the Summer of Code, and from last years experience, increased popularity of the language and stories of other mentor organizations we expect a high number of applications. First, be aware of the following:

  • Make sure that you understand, fulfill and agree to the general Google Summer of Code rules
  • The work done during GSoC requires some discipline from the students as they have to plan their day-to-day activities by themselves. Nevertheless we expect regular contact with the mentors by the usual forms of communication (mail, chat, phone) to make sure that the development is going according to the plan and students don’t get stuck for weeks at a time (3 months may seem long, but in reality it is very easy to run out of time).
  • The official SoC timetable mentions May 19th as the official start of coding, but if you have time you are encouraged to research your proposals even before that (and definitely learn the basics of Scala, if you haven’t done that already).

Student Application Guidelines

  • Student proposals should be very specific. We want to see evidence that you can succeed in the project. Applications with one-liners and general descriptions definitely won’t make the cut.
  • Because of the nature of our projects students must have at some knowledge of the Scala language. Applicants with Scala programming experience will be preferred. Alternatively, experience with functional programming could suffice, but in your application we want to see evidence that you can quickly be productive in Scala.
  • You can think of Google Summer of Code as a kind of independent internship. Therefore, we expect you to work full-time during the duration. Applicants with other time commitments are unlikely to be selected. From our previous experience we know that students’ finishing their studies (either Bachelor, Master of PhD) are likely to be overwhelmed by their final work, so please don’t be too optimistic and carefully plan your time for the project.
  • If you are unsure whether your proposal is suitable, feel free to discuss it on our “scala-language” mailing list. We have many community members on our mailing list who will quickly answer any of your questions regarding the project. Mentors are also constantly monitoring the mailing list. Don’t be afraid of asking questions, we enjoy solving puzzles like that!

General Proposal Requirements

The proposal will be submitted via the standard web-interface at https://www.google-melange.com/gsoc/homepage/google/gsoc2015, therefore plain text is the best way to go. We expect your application to be in the range of 700-1500 words. Anything less than that will probably not contain enough information for us to determine whether you are the right person for the job.

Your proposal should contain at least the following information, but feel free to include anything that you think is relevant:

  • Please include your name (weird as it may be, people do forget about it)
  • Title of your proposal
  • Abstract of your proposal
  • Detailed description of your idea including explanation on why is it innovative (maybe you already have some prototype?), what contribution do you expect to make to the Scala community and why do you think your project is needed, a rough plan of your development and possible architecture sketches.
  • Description of previous work, existing solutions (links to prototypes, bibliography are more than welcome!)
  • Write us about yourself and convince us that you are the right person for the job (linking to your resume/CV is good but not sufficient)
    • Mention the details of your academic studies, any previous work, internships
    • Any relevant skills that will help you to achieve the goal (programming languages, frameworks)?
    • Any previous open-source projects (or even previous GSoC) you have contributed to?
    • Do you plan to have any other commitments during SoC that may affect you work? Any vacations/holidays planned? Please be specific as much as you can.
  • Contact details (very important!)
Contents
Problem with this page?
     Please help us fix it!