Skip to content

Update GSoC 2016 page links #408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 16, 2016
Merged

Update GSoC 2016 page links #408

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 21 additions & 18 deletions gsoc/2016.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ title: "Google Summer of Code 2016 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/gsoc2016)
Code](https://summerofcode.withgoogle.com/)
program to work with enthusiastic students on challenging Scala
projects**

Expand All @@ -19,7 +19,7 @@ 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.
requirements](#requirements-and-guidelines) mentioned below.

### How to get involved

Expand Down Expand Up @@ -50,7 +50,8 @@ reviewed.
There is a long list of smaller and medium sized open tickets for the Slick code generator.
Time to tackle them and give it another overhaul. This is going to be a very useful and somewhat easier project.

https://github.com/slick/slick/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Atype-providers
[https://github.com/slick/slick/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Atype-providers
](https://github.com/slick/slick/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Atype-providers)

Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://github.com/szeiger)

Expand All @@ -60,7 +61,7 @@ There are lots of open tickets in the Slick issue tracker. Some which have long
be about tackling as many of them as time permits. It will be a good chance to learn about the Slick code base
and have an impact in this successful project. Some issues may be simple, but many issues may be challenging to fix and will require someone smart, dedicated and persistent enough to learn the details of how Slick works.

https://github.com/slick/slick/issues
[https://github.com/slick/slick/issues](https://github.com/slick/slick/issues)

Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://github.com/szeiger)

Expand All @@ -69,7 +70,7 @@ Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://githu
Super-charged for-comprehensions are an effort to implement an alternative direct-style dyntax for monadic comprehensions in Scala.
The goals are reduction in syntax, enabling more control flow expressions, inline Monad value extraction and transformer operations on the Monad context (as in Comprehensive Comprehensions). At the time of writing the project is in heavy flux. Depending on its status there will likely be interesting idea how to take the project further. One likely topic would be exploring type changing comprehensive comprehension transformers, such as groupBy or aggregations. The implementation heavily relies on macros and will require learning how to work with Scala's compiler ASTs and make changes to the AST transformation stages.

Work in progress: https://github.com/cvogt/flow-comprehensions
Work in progress: [https://github.com/cvogt/flow-comprehensions](https://github.com/cvogt/flow-comprehensions)

Supervised by [@cvogt](https://github.com/cvogt)

Expand Down Expand Up @@ -100,7 +101,7 @@ Supervised by [@axel22](https://github.com/axel22)

### Better Scripts in Scala

There are several hacky, ad-hoc ways to write scripts in Scala already, e.g. SBT's script-runner, and the Ammonite REPL's script loader. Your task in this project would be to improve the experience writing scripts using Ammonite to be on-par with the experience writing scripts in any other language, as well as on-par with the experience writing Scala code in a large project. This includes:
There are several hacky, ad-hoc ways to write scripts in Scala already, e.g. SBT's script-runner, and the [Ammonite REPL](https://github.com/lihaoyi/Ammonite)'s script loader. Your task in this project would be to improve the experience writing scripts using Ammonite to be on-par with the experience writing scripts in any other language, as well as on-par with the experience writing Scala code in a large project. This includes:

* Improving startup time: SBT is terribly slow, and even Ammonite scripts take 1-2 seconds to boot up, This is speed-up-able.
* Improved error reporting: Ammonite's scripts currently report line-numbers and file-names based on the mangled compilation-unit. We should report based on the location within the source file a user wrote.
Expand All @@ -112,13 +113,13 @@ Supervised by [@lihaoyi](https://github.com/lihaoyi/)

### Flexible Fast Parser Combinators

The FastParse library is a modern replacement for Scala's old parser combinators library. It provides similar API, drops a lot of redundant operators, and runs 50-100x faster. However, right now it only parses Strings.
[The FastParse library](https://github.com/lihaoyi/fastparse) is a modern replacement for Scala's old parser combinators library. It provides similar API, drops a lot of redundant operators, and runs 50-100x faster. However, right now it only parses Strings.

This project would be to extend FastParse to parse other things. Cases to cover include:

* Binary data: Array[Byte], ByteBuffer, ByteString, letting us parse things like binary files, network protocols, or other formats
* Streaming data: Iterator[String] and Iterator[Char], letting us parse files while not materializing the entire contents in memory
* Pre-tokenized data: Seq[T] for an arbitrary T, letting you re-use a pre-written lexer before your parser
* Binary data: `Array[Byte]`, `ByteBuffer`, `ByteString`, letting us parse things like binary files, network protocols, or other formats
* Streaming data: `Iterator[String]` and `Iterator[Char]`, letting us parse files while not materializing the entire contents in memory
* Pre-tokenized data: `Seq[T]` for an arbitrary `T`, letting you re-use a pre-written lexer before your parser

Using virtual classes, we should be able to extend FastParse to do this while still re-using most of our code. Your task would be to:

Expand Down Expand Up @@ -162,7 +163,8 @@ the REPL experience in Dotty. In this project you're going to expand
current minimalistic REPL with advanced functionality to improve
end-user's experience.

https://github.com/lampepfl/dotty/issues?utf8=✓&q=is%3Aissue+is%3Aopen+repl
[https://github.com/lampepfl/dotty/issues?utf8=✓&q=is%3Aissue+is%3Aopen+repl](
https://github.com/lampepfl/dotty/issues?utf8=✓&q=is%3Aissue+is%3Aopen+repl)

Supervised by [@densh](https://github.com/densh)

Expand All @@ -173,31 +175,32 @@ exposes user-controllable memory management to Scala programmers. At the moment
it has fairly limited array-based collection API. Your goal in this project
would be:

* Expand existing functionality of combinator methods on off-heap arrays
* Port new collections (Set[T] and Map[K, V]) to the off-heap world
* Expand existing functionality of combinator methods on `offheap.Array[T]`
* Port implementation of maps to scala-offheap (`offheap.Map[K, V]`)
* Port implementation of sets to scala-offheap (`offheap.Set[T]`)

Supervised by [@densh](https://github.com/densh)

## Requirements and Guidelines

### General Student Application Requirements

This is the fifth time the Scala project has applied to the Summer of
This is the sixth 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/gsoc2016/help_page)
[Google Summer of Code rules](https://summerofcode.withgoogle.com/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](http://www.google-melange.com/gsoc/events/google/gsoc2016)
mentions May 19th as the official start of coding, but if you
* The [official SoC timetable](https://summerofcode.withgoogle.com/)
mentions May 23 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).
Expand Down Expand Up @@ -231,7 +234,7 @@ number of applications. First, be aware of the following:
### General Proposal Requirements

The proposal will be submitted via the standard web-interface at
[http://www.google-melange.com/gsoc/homepage/google/gsoc2016](http://www.google-melange.com/gsoc/homepage/google/gsoc2016),
[https://summerofcode.withgoogle.com/](https://summerofcode.withgoogle.com/),
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
Expand Down