This year the Scala team applied for the second time for the Google Summer of Code program to work with enthusiastic students on challenging Scala projects and we got accepted again!

• What is Google Summer of Code

Google invites students to come up with interesting, non-trivial problems for their favourite open-source projects and work on them over the summer. Participants get support from the community, plus a mentor who makes sure you don't get lost and that you meet your goals. Aside from the satisfaction of solving challenging problems, students get paid for their work. But wait, there's more! Successful participants also receive an official Google Summer of Code t-shirt! This is an incredible opportunity to get involved in the Scala community and get helpful support along the way.

• Project Ideas

Below we have collected 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 here below.

• How to get involved

The best place to propose and discuss your proposals is our "scala-language" mailing list (scala-language @ Google Groups, instructions to subscribe are available at http://www.scala-lang.org/node/199#scala). This way you will get quickly responses from the whole Scala community.

• Summer of Code 2010 experience

This is the second time Scala team will apply for the GSoC. Last year we got approved and we had 6 very successful projects that were widely accepted by the Scala community. We encourage you to have a look at our Summer of Code 2010 page to get an idea on what we and you can expect while working on Scala.

Please make sure to read carefully the instructions at the end of this page for requirements and submission details.

Project Ideas

Here are some project ideas for you (our community members have posted more on the mailing list so have a look there as well):

The Scala Index

• PyPI: http://pypi.python.org/pypi
• HackageDB: http://hackage.haskell.org/packages/hackage.html
• CPAN: http://search.cpan.org/
• RubyGems: http://rubygems.org/
• LuaRocks: http://luarocks.org/en/Documentation

• https://github.com/languages/Scala
• http://implicit.ly/
• http://www.scala-lang.org/node/1209
• http://www.planetscala.com/

Scala-aware Eclipse Memory Analyzer

The aim of the project is to add support for Scala programs to Eclipse MAT. There’s a small project already providing text viewers for some Scala types on github, but the really interesting bit is hooking the Scala interpreter in the query builder.

MAT supports OQL, an SQL-like query language for Java heaps. Unfortunately, it has virtually no abstraction or reuse mechanisms. This project should add support for writing queries in Scala giving:

• for-comprehension syntax for queries

• all the abstraction mechanisms available in Scala, for instance to save queries or filters, to refine existing results, etc.

Porting Node.js to Scala

Node.js (nodejs.org) is a successful event-driven IO framework for building scalable network application like webservers. Currently Node.js targets Google’s V8 Javascript engine but it would be incredibly useful to see such framework in Scala. Since Node.js relies on non-blocking IO then it seems a natural use case for the Scala continuations (introduced in 2.8.0) and Java NIO. Therefore students are expected not only to port the framework to Scala language but also use the new extensions to provide good performance.

Targeting both JDK and .NET from a single codebase (jdk2ikvm tool)

We have developed a tool (jdk2ikvm, http://lamp.epfl.ch/~magarcia/ScalaNET) to automate the migration of Scala sources from JDK to .NET (once migrated, those sources can be compiled by Scala.NET against the IKVM library to obtain .NET assemblies). Our experience with this tool is based on porting the Scala compiler itself and the Scala library. However, the API migration that jdk2ikvm performs is general in nature, and thus it would be interesting to field-test it with other large Scala applications (for a non-exhaustive list, see https://github.com/alacscala/scala-corpus ) “Field testing” means more than just running jdk2ikvm and hoping for the best, it includes for example running the (migrated) test suite of the application on .NET. An expected by-product of these case studies are additional conversion rules, for example gathered for JDK APIs that have not yet been addressed as part of the conversion.

Embedded DSL for database-query

Existing embedded DSLs for database-query allow the Scala compiler to statically check many (but by no means all) aspects of query well-formedness. This topic aims at improving on both the expressiveness, checking, and optimization of embedded database queries by: (a) extending the current syntax for for-comprehensions with notation for group-by and order-by,  along the lines of Haskell’s “comprehensive comprehensions”; (b) use lightweight modular staging to realize the query optimization capabilities of Ferry and Pathfinder: http://hackage.haskell.org/package/DSH ; and finally (c) develop a benchmark suite.
Because this is a demanding project, good knowledge of Scala is a prerequisite.

REPL in your browser

Spice up the proof-of-concept dhtml repl interface http://github.com/tiarkrompf/replhtml and turn it into a useful development tool. Interface to the presentation compiler to add completion, hovers, etc. Some aspects of GUI would also need to be redesigned. Finally, it would be useful to include a launcher interface so that it integrates into Mac/Linux/Windows desktop environments.

REPL extensions

Devise an interactive Scala shell that merges to the extent possible command prompt facilities (e.g. bash), scala prompt (scala), and interactive debugger (such as ocamldebug). As part of this, devise a mapping from file system into a web of objects that represent directories and files. For example, a directory could be presented as an object whose fields are other files and directories. Then, provide a convenient way to inspect objects, through the notion of current object that generalizes current directory.

There are many other different ways in which current REPL would benefit. We welcome any ideas proposed by students which are backuped up with a reasonable plan. For possible extensions you can also look for inspiration in bash integration or porting some of the features of popular Windows PowerShell to Scala REPL.

Simple Scala presentation compiler

Build a simple presentation creator in Scala.
The primary input mode should be free-form drawing and text. You are encouraged to use (or port) the open-source http://detexify.kirelabs.org/classify.html to provide some mapping of hand-written latex symbols into the corresponding Unicode characters. Use context to improve the precision of symbol recognition.

Distributed abstraction layer for active objects

Project aims at providing a distributed abstraction layer for active objects such as actors and transactors, to ease development of such computational models in a distributed setting. This layer should allow starting active objects transparently. It builds upon a message passing layer. It should meet the following prerequisites:

- taking care about load-balancing, transparently starting active objects on remote nodes, and moving them dynamically to different nodes as needed

- support distributed garbage collection of non-cyclic data, active objects, as well as regular ‘network objects’

Finally, the project should extend an existing actor implementation to use this abstraction layer (Scala remote actors, see successful project from GSOC 2010 for instance).

.Net- and Mono-aware Scaladoc

The goal of the project is to extend Scaladoc to emit API documentation that follows .NET and Mono conventions. The newly redesigned Scaladoc 2 has greatly improved the ability to generate different type of styles of documentation and with the upcoming release of Scala.Net it would be useful to immediately have the ability to generate .Net-compatible documentation. Further details can be found at: http://lamp.epfl.ch/~magarcia/ScalaNET/2011Q1/ScaladocNET.pdf.

Scaladoc integrated documentation

An API’s Scaladoc documentation may refer to external API documentations (for example the standard library API) to create an integrated documentation of multiple APIs.

There are many ways to successfully finish this project and students will be expected to provide a firm plan to accomplish it. Possible outline as follows. When building a documentation site (i.e. the result of running Scaladoc on a set of source files), the user can specify dependency URLs to remote Scaladoc sites. The documentation for any entity that is referenced in the sources and for which documentation is available in a dependent site is linked to that site. Optionally, the index of the site is completed with the entries of the remote site’s own index to create an integrated documentation site. To support this feature, it may be necessary to modify the Scaladoc client to be more dynamic (i.e. closer to an AJAX web application), and have the Scaladoc compiler generate a reusable data representation (JSON) of the documentation rather than static sites.

The student doing this project will be expected to take on stewardship of Scaladoc for the duration of his summer of code. To familiarize yourself with Scaladoc 2 (introduced in 2.8.0) we suggest you have a look at the following website: http://lampsvn.epfl.ch/trac/scala/wiki/Scaladoc. It also contains other ideas to improve the infrastructure of Scaladoc 2 which you may find interesting and propose as a separate GSOC project.

Technologies: Scala, JSON, JavaScript, CSS/HTML.

Colladoc collaborative features

The goal of the project is to build up the Colladoc community by extending and improving the system’s collaborative features, and tackling key usability issues.

Advanced collaborative features, in particular those concerned with tracking and reverting changes, are not yet mature in Colladoc. To improve those, the student will observe existing use patterns on the deployed Colladoc tool, while helping nurturing its community. He or she will analyse key missing collaborative features, will implement and deploy them and, in an iterative process, observe the resulting effect on the community. Because collaborative documentation is still new, a part of this project will be to understand the specific dynamic of this process. This includes the interaction between documentation contributors themselves, and between contributors and the developers of the documented sources (the Scala team).

The student doing this project will be expected to take on stewardship of Colladoc (in cooperation with Petr Hosek) for the duration of his summer of code.

More information and source code for the GSOC 2010 Colladoc project can be found at: http://code.google.com/p/collaborative-scaladoc/

Technologies: Scala, Lift web framework, JavaScript, CSS/HTML.

Akka-specific GSoC ideas

Akka is the platform for the next generation event-driven, scalable and fault-tolerant architectures on the JVM. Akka is one of the most successful projects written in Scala which propagates the concept of Actors on the JVM platform. More infomation about Akka can be found at its website http://akka.io, including growing documentation at http://doc.akka.io. For more information about the projects we suggest asking either the scala or akka mailing list, http://groups.google.com/group/scala-language and http://groups.google.com/group/akka-user respectively.

ZeroMQ transport for Akka Remoting

Akka currently has remoting support based on Netty NIO library. This project would implement a new transport based on ZeroMQ. First support the DIRECT pattern but if time permits also other patterns like PUBSUB, PIPELINE etc.

Remote class loading for Akka

Implement remote class loading for Akka Remoting. This means the ability to start up other JVMs without the user code on the class path, send them arbitrary actors and see the classes for these actors be loaded across the network in a transparent fashion.

Remote Scala REPL for Akka

Being able to attach a Scala REPL to a running system to inspect and modify code at runtime.

Reimplement Dataflow and add Dataflow Streams for Akka

Akka currently has a naive implementation of Dataflow Concurrency though Dataflow Variables. This project will reimplement them in a more performant fashion and also add support for Remote Dataflow Streams. If time permits also make these work across the network utilizing Akka Remoting.

ScalaCheck for FSM-based Akka Actors

Implement a ScalaCheck-style testing framework for testing state-machines. In particular Akka FSM module.

Scala Protobuf compiler

Create a plugin for Google’s Protobuf compiler (or stand-alone compiler) to emit Scala ‘case classes’ that supports serialization to and from Protobuf’s binary format.

Of course the list is non-binding and any reasonable project related to Scala that is proposed by student will be thoroughly reviewed. 

Requirements and Guidelines

General Student Application Requirements

This is the second 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 23rd 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 (registration instructions are at http://www.scala-lang.org/node/199#scala). We have many community members on our mailing list who will quickly answer any of your questions regarding the project. 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 http://socghop.appspot.com,  therefore plain text is the best way to go. We expect your application to be in the range of 1200-2500 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!)