Google Summer of Code 2021 results

Google Summer of Code (GSoC) is a global program focused on bringing student developers into open source software development. Students are sponsored by Google to work with a mentoring open source organization on a 10-week programming project during the summer. Over the past 16 years more than 16,000 students have participated in Google Summer of Code.

2021 is the second time that the Dart organization participated in Google Summer of Code as a mentoring organization. Following our call for student proposals in March we received 92 project proposals from students around the world, out of which we were thrilled to accept 3 projects. Today, we are excited to share our results, as described by the students who worked on these projects.

By Soumyadip Mondal

The cronet package is an HTTP package for Dart Native platforms, backed by Chromium’s network engine.

You might ask “why add an HTTP package?” when Dart already has HTTP support in dart:io. One reason is that package:cronet can use the QUIC/HTTP3 protocol, which is a highly requested community feature. Besides that, package:cronet is [faster than d](https://github.com/google/cronet.dart/blob/main/dart_io_comparison.md#performance-comparison)art:io in many scenarios.

A Dart binding of Cronet gives us easy access to its features, such as: reusability of sockets, powerful caching and compression algorithms, request prioritization, and more reliable network connections. Various Google products — including YouTube, Chrome, Google Maps, Google Photos, and the Google App — already depend on the Cronet library for their networking needs. With package:cronet, you get access to the Cronet library using an API similar to dart:io, with little to no code changes in your existing Dart/Flutter app.

Check out github.com/google/cronet.dart for benchmarks, examples, and [comparisons with d](https://github.com/google/cronet.dart/blob/main/dart_io_comparison.md)art:io. Also check this blog post about package:cronet for a technical overview and discussion of the challenges we faced.

By Abdullah Deshmukh

After the beta release of desktop support in Flutter 2, we needed a sample app to demonstrate how to write a Flutter app that can run on Windows, macOS, and Linux. I worked on that sample, in the form of a Flutter linting tool that helps you manage lint rules for your Flutter projects. The app’s source code shows how you might implement basic desktop app techniques like reading and writing files, implementing a responsive layout, using persistent storage, and even how to work with YAML files. Also the sample might be used to test the distribution of Flutter apps to the various desktop app stores.

For more details, visit GSoC ’21: Creating a desktop sample for Flutter.

By Bharat Biradar

A package published on pub.dev is evaluated on various metrics such as whether it follows Dart file conventions, has a CHANGELOG file, etc. This analysis is done by pana (Package ANAlysis for Dart). Pana is also responsible for detecting the license identifier under which the package is published.

Until now the license names displayed on pub.dev were determined through simple regular expression heuristics, and they only supported detection of a few licenses with poor accuracy. The task of this project was to create a license detector for pana to detect SPDX licenses, in line with the SPDX matching guidelines.

The license detector built for pana uses the same approach as v2_licenseclassifier, with modifications made to suit our requirements better.

Given the LICENSE file from a package, pana uses three steps to detect the SPDX license identifiers:

1. Eliminate obvious mismatches from SPDX corpus: Split the text into tokens (basically words), check whether the LICENSE file has a sufficient number of tokens (at least 50%) as compared to a known license, and eliminate all known licenses that do not satisfy the criteria. This step allows pana to quickly rule out a lot of licenses, allowing for more expensive computations in step 2.

2. Find matching substrings in the unknown license and remaining SPDX licenses: For the remaining known licenses, find the substrings in the unknown text that match a known license text. We look for substrings, because the unknown text might contain multiple licenses. When identifying matching substrings, we ignore sequences with fewer tokens than threshold * number_of_tokens_in_known_license, because such sequences do not have sufficient token density to constitute a match. If no substrings with sufficient token densities are found for a given known license, then we know it isn’t a match.

3. Determine confidence scores: This step ****estimates a confidence score (between [0,1] ) to the substrings found. First the substring is diffed, using levenshtain word diff, against the SPDX corpus license in which it was detected. Then license is considered a match if the confidence calculated as follows is above the set threshold:

We hope this gives you some idea of the license detection process. If you want to play with the license detector, you can find it in the pana repository.

Huge thanks to everyone who applied for Google Summer of Code 2021 with Dart, to the students who completed projects this year, and to the mentors who helped make this an awesome summer of code. If you’re interested in hearing more about Dart in Google Summer of Code, check out our 2020 post.