This year the Scala team has been accepted for the Google Summer of Code program to work with enthusiastic students on challenging Scala projects. 

• 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" mailing list (instructions to subscribe are here). This way you will get quickly responses from the whole Scala community. Please include "GSoc" or "summer of code" in the subject line so that we don't miss your messages.

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

Project ideas

Here are some project ideas for you:

1. Scalable network back-end for remote actors

This project could include:

• Scala wrappers for core NIO classes of Java 5
• Use Scala classes for non-blocking I/O instead of existing synchronous I/O
• Redesign networking kernel to allow for very large number of simultaneous connections to remote actors

Sources of ideas/code:

• Unmaintained remote-actors branch:
  http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/remoteactors
• Network kernel of the Akka project
  http://akkasource.org

Skills: Scala actors, Java NIO, threads, serialization

Mentor: Philipp Haller
 

2. An IO toolkit based on Java NIO and continuations

Highly scalable applications such as web servers cannot afford to block threads in order to await completion of IO operations. However, asynchronous IO packages such as Java's NIO or Python's Twisted force programmers into a callback-oriented programming style that is significantly more complex than using blocking IO primitives. Continuations are a language feature that, among other things, can express a notion of blocking in terms of callbacks and thus enable greatly simplified asynchronous APIs.

The goal of this project is to build a toolkit of scalable IO primitives using the recently introduced support for continuations in Scala (http://www.scala-lang.org/node/2096). There are several directions this project could take. One is more on the library side, closely working with other community members towards a general Scala IO library. Another direction could take the form of building a complete, usable web server in Scala and doing extensive performance tuning and evaluation.

Prerequisites: Experience with asynchronous IO (preferably Java NIO), understanding of continuations.

Mentor: Tiark Rompf
 

3. Code Coverage for Scala

The Scala programming language and its class library are being tested with a large regression test suite (currently 1170 test files). The test suite is executed once after every change to the compiler or the class library, and multiple times on various system configurations during the nightly testing.

When a change successfully passes the test suite, chances are that the most important components of the system will not break. However, there are clearly parts of the language and library for which only very few tests have been written so far, and a breaking change would not be detected.

In order to find out which parts of Scala are not tested enough, we plan to use a code coverage tool. However, it turns out that none of the existing tools just works with Scala and our test suite:

• Some tools work with Java only because they instrument the source code before compilation, which is language-dependent (Clover, CodeCover).
• Coverage tools instrumenting the bytecode (Cobertura, undercover) technically work with Scala bytecode, but they fail on our test suite. The problem is that we execute tests in parallel, which causes the tools to generate one report per test. We need a report for the entire test suite.
• Some of the tools have unexpected bugs when working with Scala bytecode and source files.
• The generated reports are often cluttered because Scala generates a lot of anonymous classes to implement its functional features.

The goal of this project is to provide the Scala test suite with a working code coverage tool. The main steps to achieve this goal are:

• Evaluate existing code coverage tools to see how they work with Scala and our test suite
• Improve existing open-source bytecode-level coverage tools, or
• Write a Scala compiler plugin to emit code coverage instructions, generate coverage data in a standard format (e.g. Cobertura xml)
• Modify our testing infrastructure to integrate code coverage

A successful completion of this project signifies a valuable contribution to the Scala programming language, its community and its users.

Required knowledge: Scala, Compilers, Testing & Code Coverage

Mentor: Lukas Rytz
 

4. Collaborative Scaladoc

We want to simplify the contribution of Scala API documentation. The goal of this project is to design and write a collaborative editor for API documentation, most likely based on wiki technology. A secondary goal is to explore specific social issues related to collaborative editing of API documentation.

Outline of possible implementation: The existing Scaladoc 2 web frontend is extended into a web application (possibly using Lift) that offers in-place, wiki-like editing of comments. The underlying server collects edits. An IDE plugin (based on the existing XML-Scaladoc patching tool) or a standalone tool is used to select acceptable edits, patch the source code, and resolve conflicts.

Required Skills: Scala programming is required. Web-application programming in Scala (for example, using Lift) is highly recommended. An interest in usability or social collaboration is a plus.

Mentor: Gilles Dubochet
 

5. Scala Method Search

A very useful addition to the Scaladoc API documentation would be a mechanism for searching for methods. Such method search could include (but is not necessarily limited to) regex/wildcard matching on method name, match based on method argument types (including supertypes), match based on method return type, and combinations of the above. For searches based on argument type, polymorphic instantiations of methods should be included. For example, the result of a search for methods with type Int => Int should include methods with type A => A (where A is a type variable).

The search code should be general enough that it can be plugged in to various front-ends (e.g., link to Scaladoc html page, show in Eclipse search pane, etc.). The speed of current search engine that looks only for classes would have to be improved by for example including more advanced indexing engine, since current implementation would not be able to handle searching on fields and methods. There are many more other requests for the Scaladoc engine that could be included in this project (see http://lampsvn.epfl.ch/trac/scala/wiki/Scaladoc/Todo for still unresolved problems). 

Required Skills:  Scala programming. Familiarity with using ASTs and symbol tables.

Mentor:  Donna Malayeri
 

6. Scala Test Suite on .NET

We are currently working on porting the Scala language to the Microsoft .NET / Mono platform. So far we have a working cross-compiler, i.e. the Scala compiler running on the JVM can emit .NET bytecode. The next major development will be to bootstrap the Scala compiler on .NET, i.e. compile the compiler to .NET bytecode and then, running on .NET, compile everything again.

One issue we're facing right now is that we have no clear indication on the quality of the generated bytecode because no tests are performed on Scala.NET. The reason is that our testing tool "partest" which executes the Scala test suite (currently ~1170 test cases) is not able to execute .NET programs.

The goal of this project is to extend "partest" with the functionality required to execute and test Scala.NET programs. Note that this version of partest will continue to run on the JVM since it uses the cross-compiler for compiling tests. The execution of tests and interpretation of results however has to be adapted.

Mentor: Lukas Rytz
 

7. Extending scala.swing

There are a number of Swing component wrappers that are missing in the scala.swing package, such as the text/document or the drag and drop subsystems. Moreover, one could further wrap useful components from the SwingX project (http://swinglabs.org/). Applicants should be proficient in Scala, have some experience with Java Swing and a good sense for API design.

Mentor: Ingo Maier
 

8. Hardware Accelerated 2D Graphics

The Java platform provides a relatively sophisticated 2D graphics interface that can target different GPU accelerated backends. Unfortunately, there is no API to these backends so that clients can make use of GPU shaders directly. The task for this project would be to develop a 2D graphics API that implements most of Java2D's functionality on top of OpenGL (LWJGL/JOGL) that lets programmer make use of fragment shaders (and possibly geometry/vertex shaders as well) for visual effects. Applicants should have basic Scala knowledge and a strong OpenGL background.

Mentor: Ingo Maier
 

9. A new backend for the Scala.Net compiler to generate C# sources

The IT policies of some corporations make difficult the early adoption of innovative languages like Scala. Already in the JVM world, the case has been made a few times about having a Scala to Java translator to act as "safety net". For .NET similar arguments are expected. The good thing about this scenario is that the conversion into C# is easier than its Java counterpart, for an accidental reason: the Scala compilation pipeline transforms Abstract Syntax Trees (ASTs) early on to use a restricted form of jumps. These ASTs have a straightforward formulation in terms of C#'s goto but are more difficult to express in terms of Java constructs for structured control flow.

A few write-ups at The Scala Compiler Corner have addressed most of the subproblems involved in transforming the language of the Scala backend (ICode) into C#, as follows:

• the conversion from ICode into three-address form is covered in Towards a typed 3-address IR from ICode
• the ICode language itself is described in Notes on GenICode

The proposed conversion into C# can be performed by a single backend phase. The input language (3-address ICode) is already typed, invocations to .Net libraries are to be left as-is, and all ICode instructions have direct counterparts in C#. The conversion of (stack-based) ICode into its 3-address counterpart is therefore the subproblem that requires more concentration. Techniques to solve this problem appear in the write-ups above (these techniques are already in use in the Soot framework for JVM bytecode analysis and transformation, which is open-source).

Mentor: Miguel Garcia

10. Testing framework for semantically driven features of the Scala IDE for Eclipse

Many of the most valued features of Scala IDEs are the ones which provide semantic information about and enhancements to the source code being worked on: hovers showing inferred types and associated documentation; keyword and identifier highlighting; hyperlinks to and indexes of definitions; references to implemented or overridden methods; marginal scope indicators, etc.

Unfortunately these features currently lack any systematic testing framework. When bugs are found they are fixed on an ad hoc basis, and there is no mechanism for testing for regressions once fixed. This is due to a number of characteristics which make automated testing awkward: the problems manifest themselves in interactive GUIs; and
particularly when incorrect code is allowed for, there is an huge space of possible scenarios to test, in many cases human inspection being required to determine the correct behaviour, at least on the first encounter.

The problems notwithstanding, it would be highly desirable to have some framework which automates as much of the verification and regression testing process as possible, ideally by separating off a non-GUI non-interactive component. It would also be very desirable to have some means of crowd-sourcing the human inspection required for verification.

As such this project naturally falls into two parts: the testing framework, which would require applicants to have some feel for programming language implementation and test automation; and the crowd sourced verification front end, which would require applicants to have some feel for the design of tools for web-based collaboration.

Mentor: Miles Sabin

11. Advanced semantic annotations for the Scala IDE for Eclipse

The Scala programming language has a number of features which would benefit from additional feedback in programming tools and IDEs. It would be very desirable to have support in the Scala tooling for Eclipse for,

• A mechanism for showing inferred type hovers for expressions (currently inferred types can only be shown for simple terms).
• Visual indicators of the application of implicit conversions and the provision of implicit parameters.
• A mechanism, possibly similar to code folding, for transiently expanding inferred types and implicit conversion and parameters inline in source text.

or any other interesting language feature which applicants might propose. Applications should have some feel for programming language implementation, and some experience of developing for Eclipse.

Mentor: Hubert Plociniczak
 

12. Adding LINQ-awareness to Scala.Net

A productivity feature that seasoned .NET developers want to keep from C# is LINQ, not so much because of its notational convenience (Scala supports comprehensions since day one) but rather due to the accompanying tooling that realizes most of what we perceive as "LINQ power" (e.g., Object- Relational Mapping, query shipping and server-side optimization, etc.) It makes sense thus make Scala.Net play a good host for embedded LINQ queries by:

• desugaring LINQ syntax into plain method calls, i.e. into Standard Query Operators (SQO) invocation and by
• reifying SQO expressions into the "format" expected by (third-party) authors of Query Providers

There's a way more detailed description of this topic at The Scala Compiler Corner, listing resources needed for the tasks at hand. If you're more familiar with internals about the Scala compiler, you may consider tackling the first subproblem above. If you've ventured instead more into .NET compilation internals, you may consider applying for the second subproblem. There's a clear interface between both, as well as with the rest of the LINQ ecosystem in .NET. In both cases, know-how about transforming Scala ASTs (say, before they reach the CleanUp phase) is essential.

Mentor: Miguel Garcia

13. Lift and SBT template engine

1. SBT-templating A template engine that would allow sbt-processor-writers to easily generate and delete source-files. The engine will be able to handle existing files and things, as well as option parsing to ease the work-load of potential users. A processor using this engine would look like this: 

   > processor-name   

2.  Lift-SBT A SBT-processor that uses the template engine to manage lift specific *thing-to-create-or-delete*. The processor would be able to manage (At-least) the following things: 'app-blank','app-basic', 'snippet' and 'model'

Requirements and Guidelines

General Student Application Requirements

This is the first time the Scala project has applied to the Summer of Code, but from the previous experiences of other mentor organizations we expect a high number of applications. Keep the following in mind:

• 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 24th as the official start of coding, but if you have time you are encouraged to research your proposals anytime before that.

Student Application Guidelines

• 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. Please follow the application template below.

• Proposals should be about 1200-2500 words.

• 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.

• If you are unsure whether your proposal is suitable, feel free to discuss it on our "scala" mailing list (registration instructions are at http://www.scala-lang.org/node/199#scala). Please include "GSoc" or "summer of code" in the subject line so that we don't miss your messages.

Application Template

• Name and contact details

• Proposal title and abstract

• Describe your idea, in detail. Why is it innovative? What contribution do you expect to make to the Scala community?

• What are some possible high-level designs? (i.e., how would you go about solving this problem?)

• What relevant skills/experience do you have?  Have you programmed in Scala or functional languages?  Have you contributed to other open-source projects?  Have you taken programming languages courses?

• How do you plan to interact with the wider Scala community (e.g., what if your mentor can't help you with something?  how will you get people interested in your contribution?)

• Do you have any other commitments during SoC that may affect your work? (e.g., planned holidays, etc)

• Why are you the best person for the project?