diff --git a/gsoc/2014.md b/gsoc/2014.md new file mode 100644 index 000000000..0a8d25dde --- /dev/null +++ b/gsoc/2014.md @@ -0,0 +1,514 @@ +--- +layout: page +title: "Google Summer of Code 2014 Scala Projects" +--- + +## Google Summer of Code + +**This year the Scala team applied again for the [Google Summer of + Code](http://www.google-melange.com/gsoc/homepage/google/gsoc2014) + 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](#requirements_and_guidelines) mentioned below. + +### How to get involved + +The best place to propose and discuss your proposals is our +["scala-language"](http://groups.google.com/group/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](http://www.scala-lang.org/gsoc2010#), +[2011](http://www.scala-lang.org/gsoc2011#), +[2012](http://www.scala-lang.org/gsoc2012#) and +[2013](http://www.scala-lang.org/news/2013/03/20/gsoc13.html) page to +get an idea on what we and you can expect while working on Scala. + +## Project Ideas + +Here are some project ideas for you. The list is non-binding and any +reasonable project related to Scala that is proposed by a student will +be thoroughly reviewed. + +* * * + +### Miniboxing for Breeze and Spire + +A very tricky question in compilers is how to translate high level +generic code, such as classes with type parameters to optimized low +level code. Researchers have proposed many translations in the last 25 +years, yet we can't claim to have a perfect solution. This is because +generic code is uniform at a high level, but its low level translation +requires optimized non-uniform representations to obtain good +performance. Thus we have an inherent tension between uniformity and +optimality. + +In the context of the Java Virtual Machine, [miniboxing][mb1] is a new +translation that sidesteps the shortcomings of previous approaches, +while maintaing the optimality of the low level non-uniform code. It +builds on the specialization transformation, which is already included +in the [Scala compiler][mb2], but produces too much bytecode to be +useful in practical applications. Although miniboxing is developed for +the Scala language, the same transformation could also be implemented +in [Java][mb3] and in other JVM languages, such as [IBM's X10][mb4], +[JetBrains' Kotlin][mb5] and [RedHat's Ceylon][mb6]. + +The miniboxing transformation matches optimal performance in +microbenchmarks, but in order to make a significant impact in the +Scala community, it needs to be prove itself on large benchmarks, such +as the [spire numeric abstractions library][mb7] and the [breeze numeric +processing library][mb8]. In this context, the tasks for this project +are: + +- develop the necessary mechanisms around the miniboxing plugin to + allow running the spire and breeze benchmarks +- identify slowdowns caused by the miniboxing translation and +- propose and implement solutions to improve the performance. + +This project requires familiarity with compilers (requirement: having +taken at least one Compilers course), the Scala programming language +(requirement: having taken the [Functional Programming in Scala][mb9] +course) and with [Java bytecode][mb10]. Note that acceptance for this +project is conditioned by the successful completion of a challenge, +which will be explained once you apply for the project. A big plus is +having contributed to OSS software written in Scala. + +**Resources** + +- [the miniboxing plugin website][mb1] +- [a paper explaining the generic code translation challenges and the + miniboxing transformation][mb11] +- [miniboxing plugin on github][mb12] -- a compiler plugin that + introduces the miniboxing transformation in the compiler pipeline +- [spire numeric abstractions library][mb7] on github +- [breeze numerical processing, machine learning and natural language + processing library][mb8] on github + +Keywords: generic code translation, miniboxing, specialization + +Mentored by [Vlad Ureche][mb13]. + +[mb1]: http://scala-miniboxing.org/ +[mb2]: http://github.com/scala/scala +[mb3]: http://docs.oracle.com/javase/7/docs/technotes/guides/language/index.html +[mb4]: http://x10-lang.org +[mb5]: http://kotlin.jetbrains.org/ +[mb6]: http://ceylon-lang.org/ +[mb7]: https://github.com/non/spire +[mb8]: https://github.com/scalanlp/breeze +[mb9]: https://www.coursera.org/course/progfun +[mb10]: http://en.wikipedia.org/wiki/Java_bytecode +[mb11]: http://infoscience.epfl.ch/record/188060 +[mb12]: https://github.com/miniboxing/miniboxing-plugin +[mb13]: http://people.epfl.ch/vlad.ureche + +### MacroGL library + +OpenGL is a cross-language, multi-platform API for rendering 2D and 3D +computer graphics. The API interacts with a GPU to achieve +hardware-accelerated rendering. OpenGL is used heavily in the industry +and is constantly evolving. On the JVM, namely Scala and Java, you can +currently use OpenGL by relying either on the JOGL library (Java +OpenGL) or LWJGL (Lightweight Java Game Library). Both libraries are +low-level bindings on top of OpenGL - these libraries are ports of the +C-like OpenGL API to Java. + +While this is highly configurable, programming with these low-level +constructs may be cumbersome. + +- OpenGL state has to be manually set up before performing the desired + task, and then reverted to previous state once the task is done +- Creating OpenGL objects like buffers, textures or shader programs + requires a large number of API calls and imperative state changes, + while it could be done declaratively for typical programs +- Communicating values to shader programs requires imperative API + calls and dealing with the layout of shader variables in the OpenGL + programs +- Error states have to be queried manually and there are not + exceptions being thrown, let alone error messages other than numeric + error codes. + +All this results in a lot of boilerplate code that is hard to understand, maintain and debug. + +The [MacroGL library](https://github.com/storm-enroute/macrogl) is a +high-level API that allows writing more structured, yet efficient +OpenGL code. Here are some of its features. + +- It provides structured constructs for setting transformation + matrices, OpenGL settings, textures, programs, buffers, and in + general setting up the rendering pipeline + + for { + _ <- enabling(GL_CULL_FACE) + _ <- using.matrix(scene.camera.projectionMatrix) + _ <- using.matrix(scene.camera.modelviewMatrix) + _ <- using.texture(GL_TEXTURE0, shadowChannel) + b <- using.framebuffer(screenBuffer) + _ <- b.attachTexture2D(GL_COLOR_ATTACHMENT_0, screenChannel, 0) + } objectBuffer.render() + + These for-comprehensions use Scala Macros to inline the + state-handling code and avoid object allocations for closures. + +- It prefers convention over configuration when declaratively + instantiating OpenGL objects like shaders: + + val glowFilter = new Program("glowfilter")( + Program.Shader.Vertex(resources("glowfilter.vert")), + Program.Shader.Fragment(resources("glowfilter.frag")) + ) + +- It allows easy communication between the Scala program and the + shaders: + + glowFilter.uniform.width = width + glowFilter.uniform.height = height + +- Supports Vector and Matrix types +- easier error querying +- easy access to many rendering pipeline settings + +The current MacroGL functionality is, however, restricted to core +OpenGL features. We would like to extend the library to completely +cover the OpenGL API. Some of the features missing: +- texture types - 1D, 3D, cube maps, texture arrays, mipmapping +- tessellation and geometry shaders +- implementing missing buffer types and consolidating the existing + buffer types +- facilities efficiently uploading images to textures +- we want to use the quasiquoting features of Scala 2.11 to simplify + macros in MacroGL and bring them more up-to-date +- optional exception throwing when an error state is detected, + governed by ErrorPolicy typeclasses (must be turned off for + performance after development) +- structured constructs for geometry rendering +- allow a richer set of uniform variable types for shaders (currently + MacroGL API only supports integers, floats, float vectors and float + matrices) +- avoiding boxing in some places, such as setting uniform variables + for shaders +- implementing more Vector and Matrix types (e.g. integers), divide + them into mutable and immutable versions +- parsing common 3d model formats and producing buffers + +The goal of this project is to provide a set of higher-level +abstractions and a Scala-based API that works with JOGL, while in the +same time retaining most of the performance and efficiency of +JOGL. This should allow Scala programmer to write safer and more +reliable OpenGL code which is also easier to understand and maintain. + +The final goal is to produce and document a usable, concise and +powerful open source library for writing OpenGL programs more +efficiently in Scala. Deliverables are the following: +- implemented most of missing features described above and merged them + into the main distribution +- MacroGL ported from Scala 2.10 to Scala 2.11, leaving 2.11 as the + development version +- detailed documentation in form of a GitHub page, containing API + docs, overview of different features with descriptions, a getting + started guide, and several example use cases + +Mentored by [Aleksandar +Prokopec](http://people.epfl.ch/aleksandar.prokopec) + +### Generic XML interpolator +Scala features XML literals which desugar to calls of the XML +library. The support for XML literals is part of the parser and the +compiler, and are bound to a single desugared API. Scala 2.10 added +support for generic, customizable string interpolators. Standard ones +are `s"foo = $foo"` or `f"bar = $bar%.2f"`. Quasiquotes, added in +Scala 2.11, show that these interpolators can be implemented by +macros to support compile-time checking of the syntax inside an +interpolator. + +The goal of this project is to design and implement a macro-based +generic XML string interpolator. It should be primarily designed as a +replacement for the XML literal syntax of Scala, and hence would +provide at least all the features of that syntax. For example, the XML +literal + + val name = "John" + val span = { name } + val node =
{ span }
+ +could be rewritten as + + val name = "John" + val span = xml"$name" + val node = xml"
$span
" + +As an additional requirement, this interpolator should be generic with +respect to the actual API that is called by the generated code, called +the "back-end". As a possible example, on [Scala.js][xml1] we would +like to have XML literals that create DOM elements directly instead of +`scala.xml` objects. The details on how to make the interpolator +generic are not specified, and you are encouraged to come up with a +smart idea to solve that requirement. You are not required to actually +provide a second back-end besides that targeting the `scala.xml` API, +but your implementation should allow others to do so without modifying +the code. + +Required skills: +* Good working knowledge of Scala +* Basic knowledge of def macros and quasiquotes in Scala 2.11 +* Good knowledge of XML + +Mentored by +[Sébastien Doeraene](http://people.epfl.ch/sebastien.doeraene) + +[xml1]: http://www.scala-js.org/ + +### Slick: Type-checking of plain SQL +Slick supports the use of Plain SQL queries as a thin execution layer +on top of JDBC. This requires that users not only write their own SQL +code but also know the result type of the query and how to map that +back to Scala types. There is also no compile-time checking for these +kinds of queries. + +The goal of this project is to alleviate both issues with the use of +macros. Plain SQL queries based on string interpolation have all the +necessary information (query string, parameter types) available at +compile-time to allow a macro-based implementation to send the query +to a database for verification, get the result type from the database, +and translate that back into a Scala type. As an implementer of such a +feature you will have to come up with practical solutions for +configuring the database access for the macro, caching the database +results for good performance, and ensuring that the solution would be +usable in environments that cannot expand the macro (e.g. some +IDEs). You will have to work towards these goals with the Slick team +and possibly the Scala Macros implementers. + +Related work has been done previously in +[sqlTyped](https://github.com/jonifreeman/sqltyped). + +Mentored by [Stefan Zeiger](mailto:stefan.zeiger@typesafe.com) + +### Runtime Expansion for Scala Macros +Scala macros are functions called by the compiler during program +compilation. Since their inception in Scala 2.10, macros are widely +used in libraries and domain-specific languages to analyze and +generate code. + +There's always been a number of interesting extensions to our macro +system that we planned to experiment with, and here's one of +them. Even though macros look and quack like normal methods, they are +not first-class. This brings problems when compile-time information +alone is not sufficient to perform macro expansion, preventing macros +from being effectively used for runtime code generation. The main goal +of this project is to remove this restriction and implement runtime +macros - functions that produce executable code during program runtime +using familiar macro APIs. + +When working on the project you will: + +- Design syntax for designating runtime-expandable expressions in code +- Figure out changes to the macro engine and reflection APIs that are + necessary to enable runtime macro expansion +- Experiment with and deliver runtime macro expansion for Scala macros + +Mentored by [Eugene Burmako](http://people.epfl.ch/eugene.burmako) + +### Projects with Breeze +[Breeze][br1] is a high-performance +linear algebra library for Scala that uses . The ideas here generally +require a fairly advanced knowledge of Scala. In general, experience +with frameworks like NumPy or languages like R, MatLab, and Julia +would be immensely valuable as well. Other projects related to +numerical computing and linear algebra are encouraged. Please +introduce yourself on the [group's mailing][br2] list with any ideas. + +All Breeze projects are mentored by +[David Hall](http://www.cs.berkeley.edu/~dlwh/) + +#### Multi-dimensional Arrays +Breeze currently only supports 1-dimensional vectors and 2-dimensional +matrices. Frameworks like [NumPy][br3] support arbitrarily dimensioned +arrays. This is easier in dynamically typed languages that don't +enforce correctness at compile time, because Scala does not provide +mechanisms for abstracting over the "arity" of types. Nevertheless, +we'd like to extend support to arbitrarily dimensioned arrays. This +project would involve the creation of a new high-order array type, +with keys based on a flexible data type, like Shapeless HLists, as +well as support functions for manipulating these arrays, with the +ultimate goal being parity with +[NumPy's multidimensional arrays][br4]. + +More concretely, the student would create the new data structure, +along with array creation (e.g. zeros, ones) and manipulation routines +(e.g. roll, ravel), as well as operator (e.g. addition and +subtraction) and universal function (e.g. exp, sum) support, following +the design patterns used in Breeze. + +The ideal student would have a strong command of Scala, familiarity +with NumPy, and some familiarity with [Shapeless][br5]. The student +would work closely with the maintainers of Breeze. Interested students +should introduce themselves on the [group's mailing list][br2]. + +#### Spire/Algebird Interoperability +There are currently a number of different math libraries for +Scala. [Spire][br6] (and, to a lesser extent, Algebird) have fairly +fleshed out algebraic hierarchies for Rings, Semirings, Monoids, and +the like. Breeze has its own parallel hierarchy, but it is less +developed. In this project, the student would bridge these different +libraries, either by integrating Spire's data types into Breeze, or by +introducing implicit conversions to provide an interoperability +layer. Students should have an intermediate knowledge of Scala +(e.g. how to write implicits to provide implementation), and some +familiarity with or interest in abstract algebra (i.e. what a ring is, +and how it relates to a field). The deliverables for this project +would include + +1. a proposed plan for either interoperability and integration with + Spire and +2. an implementation of the plan. + +If time permits, we would then consider adding interoperability with +other libraries likes Algebird. The student would work closely with the +maintainers of Breeze. Interested students should introduce themselves +on the [group's mailing list][br2]. + +#### GPU Extensions for Breeze +GPUs have recently become popular for scientific computing due to +their high performance and ubiquity. In this project, the student +would extend Breeze to provide wrappers for third-party GPU computing +libraries like [JCublas][br8] or [JavaCL][br9]. Breeze is designed to +be flexible enough to support this kind of extension, so this project +should not require changing too much of the core of Breeze, though of +course it is a large undertaking nonetheless. The student would +propose a design, backed by either of the two implementations, and +then an implementation for common linear algebra operations, along +with a design document for extending their work. + +This project requires intermediate knowledge of Scala (e.g. how to +write implicits to provide implementation), access to either a CUDA- +or OpenCL-compatible device, and some familiarity with GPU +computing. The student would work closely with the maintainers of +Breeze. Interested students should introduce themselves on the +[group's mailing list][br2]. + +#### Visualization Library +Languages for scientific computing are often accompanied by a great +library for visualizing data. In this project, the student would +design and implement such a framework for Scala and Breeze. There is +[some work][br10] in this direction, but this project would require a strong +design sense from the student. Students should have an intermediate +knowledge of Scala, and experience using or implementing visualization +libraries like [matplotlib][br11], [ggplot2][br12], or [gadfly][br13]. + +The deliverables include a specification of the overall design +(e.g. API use cases, proposed architecture and backend), a +proof-of-concept implementation that can be fleshed out into a more +complete library, and a tutorial for using this library. The student +would work closely with the maintainers of Breeze. Interested students +should introduce themselves on the [group's mailing list][br2]. + +[br1]: http://www.github.com/scalanlp/breeze +[br2]: http://groups.google.com/forum/#!forum/scala-breeze +[br3]: http://www.numpy.org/ +[br4]: http://wiki.scipy.org/Tentative_NumPy_Tutorial#head-6a1bc005bd80e1b19f812e1e64e0d25d50f99fe2 +[br5]: http://github.com/milessabin/shapeless +[br6]: http://github.com/non/spire +[br7]: http://github.com/twitter/algebird +[br8]: http://www.jcuda.org/jcuda/jcublas/JCublas.html +[br9]: http://code.google.com/p/javacl/ +[br10]: http://github.com/scalanlp/breeze-viz +[br11]: http://matplotlib.org/ +[br12]: http://ggplot2.org/ +[br13]: http://dcjones.github.io/Gadfly.jl/ + +## 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](http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page) +* 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](http://www.google-melange.com/gsoc/events/google/gsoc2014) + 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"](http://groups.google.com/group/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 +[http://www.google-melange.com/gsoc/homepage/google/gsoc2014](http://www.google-melange.com/gsoc/homepage/google/gsoc2014), +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!**) diff --git a/resources/img/gsoc-2014-scala-logo.png b/resources/img/gsoc-2014-scala-logo.png new file mode 100644 index 000000000..a417916af Binary files /dev/null and b/resources/img/gsoc-2014-scala-logo.png differ