You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Scala Center organisation and its team are dedicated to moving the needle towards a more diverse community, (amongst other) by providing easy-to-access first experience and introduction to the Scala ecosystem. GSoC is a fantastic opportunity to engage with students all around the world and onboard new generations, as well as underrepresented groups in tech!
Scala is a part of Google Summer of Code since 2010. With 65 projects & students, ~70 mentors over the years, many of whom continued contributing to Scala, we are happy to announce that in 2021 the Scala Center will reignite the collaboration and commit to providing an awesome experience going forward.
These are especially exciting times: Scala 3-RC1 has been released mid-February 2021, after 8 years of development. We invite you to chose your project and enjoy the fresh new approach!
More about the history
In the past LAMP, the lab behind the
development of Scala at EPFL, invested a lot of time and effort into GSOC,
mentoring an average of 8 students every year and having participated in 9
editions of the program starting as early as 2010. In the last 2 editions a
lack of human resources and the development of Scala 3 prevented Scala from
participating in GSOC.
The Scala Center, a not-for-profit organization with the mission of open
source and education, decided to take over and restart the long tradition of
students entering our community thanks to GSOC. We collected as much
experience and advice as possible from LAMP and from both students and
mentors from previous editions and we are organizing the 2021 edition.
We hope that our project list will inspire a motivated, diverse and
open-minded team of students to become part of our community by spending a
few months working on major open source projects focusing on topics such as
developer tooling, data science, concurrent computing, metaprogramming, user
interfaces, education and functional programming.
The following organisation of projects ideas by topic provides a quicker way
to help you find the most interesting project for you. Some projects appear
in multiple categories.
Scala-native-bindgen is an sbt plugin used to generate Scala Native bindings code based on input C headers. The goal of this project is to enhance its functionality to generate C headers for libraries build using Scala Native as well as align it with syntax changes done in Scala Native.
Expected outcome
Bindgen should be usable with Scala Native 0.4 changed syntax. It should allow to generate header files for libraries created using Scala Native based on NIR input.
scalajs-jfe is a proof-of-concept Java compiler front-end for the Scala.js Intermediate Representation (IR, .sjsir files). Its purpose is to be able to use libraries written in Java from Scala.js projects. The compiler misses support for a few language features, but the main missing piece is integration in a build tool, so that it can be used in an actual project. The goal of this project is to bring scalajs-jfe to the masses, by providing an integration in sbt (the Scala build tool) and address the few missing features in the compiler.
Expected outcome
scalajs-jfe should be usable in a real project, both to use Java source files in a Scala.js project, or to publish a library written in Java as a Scala.js-enabled jar.
Prerequisites
basic Scala knowledge; basic knowledge about compilers; having used a build tool in a project; git basics.
Ideal prerequisites
larger compiler experience; sbt knowledge; possibly having written a build tool plugin before; and/or larger Scala experience.
Scala.js recently added support for module splitting. Instead of producing one .js file, it can be configured to produce multiple .js files. However, scalajs-bundler eventually bundles all the modules into a single .js file, making it impossible to produce multiple modules. Producing multiple modules could be useful in some scenarios, as explained in webpack’s documentation. The goal of this project is to support generating multiple modules in scalajs-bundler.
Expected outcome
Scalajs-bundler should support the scenarios that require producing multiple bundles. The documentation should be updated accordingly.
Shapeless is a library that pioneered type class derivation facilities. It has been powering a large number of libraries that derive type classes (e.g. data type serializers). The underlying mechanisms on which shapeless is built to provide its type class derivation facilities do not exist anymore in Scala 3. Nevertheless, the next major version of Shapeless will support Scala 3. However, this means that libraries that work with the current stable version of Shapeless will have to upgrade to the next major version of Shapeless to support Scala 3. The story might become even more complicated for libraries that cross-compile with several versions of Scala. The migration effort for these libraries would be significantly reduced if the current stable version of Shapeless was available on Scala 3. The goal of this project is to implement the current version (2.3) of Shapeless on Scala 3. A meta-issue summarizing the tasks to achieve this has been created here.
Expected outcome
Libraries that use Shapeless 2 can compile with Scala 3.
Prerequisites
Familiarity with Scala, meta-programming, type class derivation.
Add synthetics and symbol information for semanticdb in Scala 3
Title
Add synthetics and symbol information for semanticdb in Scala 3
Brief description
semanticdb is a format that saves additional data about symbols within files as a results of compilation. These additional artifacts enable Scala editors and tools to provide additional functionalities. Currently, Scala 3 only emits basic symbol occurrences without the information about the specific symbol signatures and additional synthetic symbols generated by the compiler.
Expected outcome
Scala 3 compiler generating fully filled new sections.
Automatically rerun tests on code changes within Metals LSP server
Title
Automatically rerun tests on code changes within Metals LSP server
Brief description
Currently Metals LSP server supports the Debug Adapter Protocol via code lenses or launch.json configuration. The output from the tests goes to the basic Debug Console within Visual Studio Code. To make it all more usable we need to create a basic UI that would enable users to trigger watch , which would recompile and run tests on changes, and would present the information from tests to the users. It should also include some basic work to make this possible to implement in other editors.
Expected outcome
VS Code Metals extension with the possibility to watch tests.
Currently Metals LSP server does not support Java files, so in workspaces with mixed sources users will be unable to get full support. It should be possible to delegate some of the functionalities to a java language server and combine the results with those for Scala files
Expected outcome
Working textDocument/definition , textDocument/references , textDocument/rename and textDocument/completions within Java files.
It should be possible to automatically suggest to users what they need to import in case of missing givens (implicits) or extension methods in their code. The base functionality should be implemented for Scala 3 and if time allows we could extend it to work with Scala 2.
Expected outcome
Code action to suggest imports on error and completions that will automatically add those.
The scala-debug-adapter is the server side implementation of the Debug Adapter Protocol (DAP) for the Scala language. It is used inside editors like VS Code to debug a Scala program. Mill is a build tool of the Scala ecosystem. The goal of this project is to integrate the scala-debug-adapter inside the Mill build tool so that it is easy to debug a Mill project from within a text editor.
Expected outcome
Tested integration of the scala-debug-adapter in a fork of the Mill repository that is ready to be submitted upstream.
Prerequisites
Knowledge about Scala and JVM; familiarity with a build tool (sbt, Maven, Gradle, Mill…)
Sbt is the most used build tool of the Scala ecosystem. It relies on Zinc to compile Scala projects incrementally (when you change your code, only the impacted files are re-compiled). Zinc can also report progress (in %) during compilation but sbt does not yet use that information. The goal of this project is to add a compilation progress reporter in sbt. This reporter can print the compilation progress to the shell or send progress notifications through the network (BSP).
Expected outcome
Add some sort of CompilationProgressReporter interface to sbt and give a default implementation.
Prerequisites
Knowledge about Scala; familiarity with a build tool (sbt, Maven, Gradle, Mill…)
Scaladex is the catalogue website of the Scala open source projects. It is populated by data from Maven Central and Github. The goal of this project is to modernize the Scaladex frontend by leveraging the Scala.js technology. It will be encouraged to experiment with Scala.js framework and libraries, like scalajs-react, laminar or others.
The Course Management Tools (CMT) is a toolset that allows one to manage exercises source code in an efficient manner. The tooling has been designed to manage Scala or Java exercises where the ‘s project build tool is sbt. CMT is an open source project and can be found here.
Expected outcome
Adapt the tooling to: create and publish an sbt plugin that can be used for a so-called ‘studentified’ project, adapt the tool to support Maven based projects
The CLI of Coursier has a number of commands to interact with artifacts from Maven repositories: listing transitive dependencies, fetching full class paths, starting an application, … These commands take Maven dependencies as input, such as 'org:name: X. Y. Z', but also repository names, application names, Scala versions, main class names, etc. Yet, Coursier doesn't allow to complete these arguments via bash or zsh completion, even though its API has the ability to complete Maven dependencies.
Expected outcome
Allow users to install bash and zsh completions for the coursier CLI, offering completions for: options that each sub-command accepts, application names, Maven dependencies, repositories, Scala versions, main classes.
Prerequisites
Knowledge of Scala, Coursier, auto-completion driven from a command shell
Write a compatible ExplicitResultTypes rule for Scala 3
Title
Write a compatible ExplicitResultTypes rule for Scala 3
Brief description
Scalafix provides rules that rewrite or lint your code. One of them is ExplicitResultTypes, that add explicit types to def/val/var. This rule is linked to Scala 2 compiler. We need to rewrite it to interface with the Scala 3 compiler.
Expected outcome
A working ExplicitResultTypes
Prerequisites
Required: some experience with Scala, eagerness to learn more about Scala 3. Preferred: some familiarity with Scalafix and Scalameta.
Implement support for some scientific computing libraries in Scala 3
Title
Implement support for some scientific computing libraries in Scala 3
Brief description
There exist a number of projects important to scientific computing in Scala 2 that have not yet been ported to Scala 3. Some known such libraries are: ScalaPy, Almond, Spire. Having these in Scala 3 would contribute to the adoption of Scala 3 as a language for scientific computing. The goal of this project is to implement the Scala 3 support for some of these libraries and their dependencies (if there is such a need).
Expected outcome
One or more library from the list is ported to Scala 3.
Prerequisites
Required: some experience with Scala, eagerness to learn more about Scala 3. Preferred: some familiarity with compilers and scientific computing.
Exhaustivity check is the safety belt for pattern matching on ADTs in functional programming. However, the safety guarantee is compromised in a programming style that uses types as safety guarantees based on abstract types and opaque types (SIP-35). One concrete example is to support exhaustivity check for the Peano example.
Scala 3's new Scaladoc comes with built-in support for static sites. Here's one way we can use this to enable static sites of Scala libraries: add backlinks and smart code snippets. The idea is to let people easily jump from the static site to API documentation and back again. To help the "back again" part, we can automatically detect what static pages link to a definition, and list them on the definition's page. This is "backlinking" as implemented by Roam and Notion. With this, someone viewing the documentation for Cats' Functor#map will easily notice that there's a static page explaining the ideas behind the definition. Beyond that, we can also add backlinks when a definition is mentioned in a code snippet (note that Scaladoc will compile code snippets). Then, when we get some experience working with code snippets, we can add hyperlinks to all the definitions in the snippet. This will make the connection between static pages and definition pages even more seamless.
Ammonite is a batteries-included REPL and script runner for Scala, and Almond is a Scala kernel for Jupyter built on top of Ammonite. ScalaPy is a Scala library that allows Scala code to invoke Python code and use Python libraries. We'd like to make it easier to use ScalaPy from Ammonite and Almond, by adding options to Ammonite and Almond so that ScalaPy can be used straight away from them, without requiring new dependencies or new imports, by offering completions right after the 'py' object.
Expected outcome
Users can pass an option to Ammonite to start it with ScalaPy already loaded, and start to tap into Python libraries straightaway. Ammonite offers completions when accessing the 'py' object. Users can install Almond with an option to have it load ScalaPy when kernels start, so that users can use ScalaPy right from the first cell, and Almond offers completions when accessing the 'py' object and relies on the _repr_html_ / _repr_png_ / ... methods of Python objects to display them.
Support for Jupyter-aware Python libraries in ScalaPy
Title
Support for Jupyter-aware Python libraries in ScalaPy
Brief description
ScalaPy is a Scala library that allows Scala code to invoke Python code and use Python libraries. Python has a rich ecosystem of scientific computing libraries, and, if we want to facilitate their usage in Scala, it is important for ScalaPy to cater to the needs faced by the scientists. One of such needs is reproducible research as e.g. implemented in Jupyter Notebook. A lot of Python libraries know how to communicate with Jupyter Notebook via the API of the latter. If we want ScalaPy-powered ports of these libraries to also fully support Jupyter Notebooks, we need to port this API to Scala using ScalaPy.
Expected outcome
Jupyter Notebook API is ported to Scala using ScalaPy. Ensure that Python libraries that rely on that API can still use it when utilised from Scala code using ScalaPy.
ScalaPy is a Scala library that allows Scala code to invoke Python code and use Python libraries. One of the important features in Scala programming is its versatile type system. And so, to utilise Scala's potential to the fullest with the Python libraries, we need to declare the Scala types for the Python libraries before using them from ScalaPy. This process, however, can be automated. This is because Python has a limited support for type declaration via type hints. ScalaPy can read these hints and generate the appropriate Scala types from them via macros.
Expected outcome
It is possible to automatically generate typed Scala APIs when working with Python libraries from ScalaPy.
Monix is a popular library for concurrent and parallel programming in Scala, building on top of the abstractions provided by Cats Effect. The goal of this project is to port Monix to Scala 3. Additionally, time permitting, it could also be ported to Cats Effect 3.
Expected outcome
Monix cross-building for Scala 2.12, 2.13 and 3. Monix supporting Cats Effect 3
Spire, Cats and a few other libraries provide syntactic sugar for common type class operations, such as addition on monoids. Spire provides built-in macros to inline such operations, avoiding allocations and improving performance. Cats provides no such mechanisms. In this project, you should build a Scala 3 library for inlining operator calls.
Expected outcome
Scala 3 library for efficient type class operations
Scastie is an online REPL for Scala. The tool does not provide a good way to embed snippets within websites containing documentation, tutorials or blosposts. Tools such as scaladoc should be able to precompile and embed the snippets with provided settings like classpath or compiler options. Compiling and running many snippets may require quite a lot of resources so some effort should be put to create a set of caches or to offload parts of work into tools such as scaladoc.
Expected outcome
Ability to embed Scastie-powered snippets into any web page as well as integration with scaladoc 3.x
Prerequisites
Knowledge of Scala as well as front-end development
Implement support for Bazel in Metals using bazel-bsp to take advantage of JetBrains’s efforts to have a build server protocol integration (BSP) for Bazel. This would entail adding support to globs to BSP, ironing out integration quirks and benchmarking performance. The Bazel IJ plugin is often many versions behind the current Bazel version. This effort would enable us to support new versions quickly for all tools that require Bazel integration such as metals.
Expected outcome
A working proof of concept which uses Metals with bazel-bsp and a roadmap for how to productionize the support.
Creative coding is the practice of writing code for some artistic result. Scala has a creative coding 2D graphics library called Doodle. The goal of this project is to extend Doodle to allow more creative coding possibilities. There are many enhancements that would both benefit Doodle and form a well-defined project, such as: adding support for bitmap graphics; adding basic support for data visualisation; building backend specific features, such as converting fonts to paths in the Java2D backend, or adding filters in the SVG backend.
Expected outcome
A complete implementation of the chosen project, including code, tests, and documentation.
Prerequisites
Intermediate Scala knowledge, interest in creative coding or data visualisation, and interest in functional programming idioms.
Programming Skills
Most of Doodle is standard Scala. There are two areas that require some specialist knowledge (which I expect students could pick up): 1. backend specific knowledge (e.g. SVG, Java2D) and 2. tagless final style.
ScalaBridge aims to increase diversity within the Scala community by teaching Scala to people who are currently under-represented. Now in its third year, it is clear that ScalaBridge would benefit from a more structured curriculum. The goal of this project is to define that curriculum.
Expected outcome
There are 3 expected outcomes: 1. Define what a lesson plan looks like for ScalaBridge. 2. Define a curriculum plan covering learning goals and exercise concepts to take students from complete beginners to having sufficient Scala knowledge to work as junior developers. 3. Develop content for at least a portion of the curriculum. This will include software development, written content, and possibly video content.
Prerequisites
Intermediate Scala knowledge, good standard of written English, and an interest in pedagogy and teaching.
Ideal Prerequisites
Some familiarity with web technologies (HTML, CSS, etc.) may be useful to present course material.