Giter Site home page Giter Site logo

gsoc's People

Contributors

carllerche avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

matprec

gsoc's Issues

Crate release automation

Tokio consists of many small, decoupled crates (a crate is a Rust library
package). Releasing changes has become a manual and error prone process. The
goal of the project is to build a set of tools to automate crate releases such
that the entire flow can be done via the GitHub issue tracker.

Expected outcomes

  • Changelog entries are generated based off of data in PRs including title and labels.
  • Crates are released on a weekly (configurable) basis.
  • A bot opens a PR for the release
  • When the release PR is merged, the crate is pushed to crates.io.
  • A Github status check is used to ensure that PRs include enough data to generate a changelog entry.
  • An automated GitHub action that merges master into PRs when there are no merge conflicts.

Skills

  • GitHub
  • TravisCI
  • Bash

Difficulty level

Easy

Tower Web templating engine

Tower Web is a web framework built on top of the Tokio stack. It provides a
macro based API. It currently supports HTML templates using an existing
community handlebars library. However, better HTML templating, both in terms of
features and performance, can be achieved by implementing a custom library.

Expected outcomes

  • A handlebars based templating library is implemented.
  • Templates are compiled ahead of time using a procedural macro.
  • Templates are rendered into a rope data structure.
  • A rope data structure is implemented.

Skills

  • Rust
  • Parsing

Difficulty level

Medium

My application for all the world to see

The GSoC page suggested putting my application as an issue. I think this is what's expected. So, tada!
..
..
..
Connor-McPherson
[email protected]
sites.google.com/mocs.utc.edu/mcpherson-portfolio

Improve Mio Support on Windows
When I first started high school, I was handed an old C++ project my older brother made as a windows multiplayer game made to span a LAN network. Back then we weren’t involved in the open-source community, so we just pulled down the closest socket library we could find.

We used the winsock library, and yes, it’s disgusting.
Here’s a snippet:

 // Create the socket
 SocketFD = socket(PF_INET, SOCK_DGRAM, 0);
 // Fill in my address data
 MyAddr.sin_family = AF_INET;
 MyAddr.sin_port = htons(27000);
 MyAddr.sin_addr.s_addr = INADDR_ANY;
 memset(MyAddr.sin_zero, '\0',sizeof(MyAddr.sin_zero));
 setsockopt(SocketFD, SOL_SOCKET, SO_REUSEADDR, &optionValue, sizeof(optionValue));
 // Bind the socket to the host at the proper port
 bind(SocketFD,(struct sockaddr*)&MyAddr,sizeof(MyAddr));
 // Fill in the peer's address data
 //MyAddr.sin_addr.s_addr = inet_addr("192.168.0.255"); // Broadcasting (Upstairs Network)
 MyAddr.sin_addr.s_addr = inet_addr(FinIP); // Broadcasting (Upstairs Network)
 memset(MyAddr.sin_zero, '\0',sizeof(MyAddr.sin_zero));
 socklen_t StAddrSize = sizeof(struct sockaddr_storage);
 // Make socket nonblocking
 u_long One=1;
 ioctlsocket(SocketFD,FIONBIO,&One);
 // Make the socket capable of broadcasting
 char Broadcast = 1;
 int RV = 0;
 RV = setsockopt(SocketFD, SOL_SOCKET, SO_BROADCAST, &Broadcast, sizeof(Broadcast));
 if( RV < 0)
   printf("Error with Broadcasting Setting.\n");

Ever since last year, I’ve been rethinking how the game communicates and I’ve been looking for a robust communication package. This requires a complete refactoring of the I/O and how the network inputs are set up.

Mio is undergoing a similar change: refactoring its I/O Windows implementation. It will be an involved project to rebuild the wepoll interface in rust. I have first-hand experience with the worst a windows socket system can look like, and I have been introduced to other libraries such as MPI through research at the University of Tennessee at Chattanooga. Although I am still a greenhorn when it comes to rust, I believe my experience with the Windows operating system and networking can help in refactoring the Mio implementation of its I/O.

Schedule of Deliverables
The first milestone will be to set up the environment first. This is because, as shown in test-first development, you can improve your overall efficiency if you verify that tests fail first to prove that it works when it passes. This first milestone would be to add unit tests for I/O. These will initially work because of Mio’s already existing (but not ideal) I/O implementation. Mio already has a testing framework set up using Cirrus CI, making this first deliverable extremely easy. Many of the unit tests may already exist.

The second deliverable will be the rust parallel to wepoll’s epoll_create, epoll_ctl and epoll_close. Functionality of these epoll instances will then be added throughout the first month. Ideally, epoll would be able to receive information from sockets and ports by the end of the first month, even if the order of receiving is not managed concurrently.

The second month would deal with using Rust and Tokio’s concurrency software to optimize the epoll system, as well as adding additional I/O functionality, such as the variety of uses associated with epoll_wait.
Open Source Development Experience
Though I am ashamed to say, I have not yet taken part in the open-source community, as much as I wish I had. Most of my work has been to add to the MocsArcade code base, a project based at my university to make a library of student-made games. This repository can be found on github (github.com/mocsarcade). Beyond that, the rest of my free time is invested in the private repo my older brother left me, the one written in C++ using winsock.
Academic Experience
I am majoring in Computer Science and currently studying COBOL, Perl, software engineering practices and Numerical Analysis. I am double-minoring in writing and math. I believe the duality of science and humanities helps me gain a more well-rounded education and gives me a more diverse set of skills. In my freshman year, one of my professors taught me that the purpose of the computer science degree is to teach students how to learn, not how to do everything in computer science. He encouraged me to teach myself beyond what I’m told in class. Even when I graduate in a year and a half, I plan to continue learning throughout my entire life, and through that gain a fuller understanding of the field of computer science as a whole. I desperately wish to learn rust and I am well versed in DevOps. Even if I’m not accepted into a GSoC internship, I plan to take part in the open-source community with what free time I carve out for myself. My goal is to learn through making.
Why Me
I believe my experience with networking, although still small, can add to the project by helping to build the system with concurrency in mind. My experience with sockets and MPI together can help me better understand Tokio and Mio as the project advances.

Still, I would recommend at least one other student that is more familiar with Rust. I know I’m not making a great case for myself, but I am neither familiar nor confident when it comes to Rust. I have experience in Python, Java, C++, COBOL and PhP, and I believe I will be able to pick up Rust quickly, but the hands-on activities needed for this project will require a deeper understanding of Rust than I currently have. I’m afraid the unique aspects of concurrency in Rust are still new to me… for now!
In Conclusion
I am not a professional at Rust, nor do I pretend to be. I plan to become one over the space of this summer, while being able to improve Mio as I improve. I believe my interest and experiences in I/O networking will be able add to Mio and improve its current implementation.

Tokio console

Tokio provides an instrumentation API using Tokio Trace as well as a number of
instrumentation points built into Tokio itself as well as the Tokio ecosystem.
The goal of the project is to implement a subscriber to these instrumentation
points that exports the data out of the process via a gRPC endpoint. Then,
implement a console based UI that connects to the process and allows the user to
visualize the data.

Expected outcomes

  • A Tokio Trace subscriber that listens to all events
  • A gRPC server that exports instrumentation data to connected clients.
  • A console based UI that allows users to query and visualize the data.

Skills

  • Rust
  • gRPC

Difficulty level

Medium

Improve Mio windows support

Mio is a low level abstraction on top of the operating system's evented I/O
APIs. It is used by Tokio to integrate with the operating system and perform the
I/O operations. The current Windows implementation is not ideal. A better
solution is outlined in
piscisaureus/wepoll.

Expected outcomes

The windows Mio implementation is rewritten using the strategy used by wepoll.

Skills

  • Rust
  • Windows networking

Difficulty level

Medium

Loom - A concurrency checker used by Tokio

Loom is a model checker for concurrent Rust code and is used to test Tokio's
concurrency primitives. It explores the behaviors of code under the C11 memory
model, which Rust inherits. It attempts to avoid combinatorial explosion by
pruning the state space. Currently, loom checks can take a long time as it does
an exhaustive search of all possible executions.

The goal of the project is to make it possible to use loom to check concurrent
code in 10 seconds or less. This requires:

  1. Making the loom runtime faster
  2. Implement bounded exploration.

Expected outcomes

Tokio's loom based tests complete in 10 seconds or less on a modern personal computer.

Stretch goals

  • Add atomic fence support.
  • Increase C11 memory model coverage.

Skills

  • Rust
  • Concurrency

Difficulty level

Hard

Improve gRPC server

Tower gRPC provides a gRPC client / server implementation on top of the Tokio
stack. Currently, the server API is tedious to use and has some limitations. The
goal for the project is to implement a procedural macro to remove the
boilerplate when defining gRPC server services. Also, a routing layer should be
implemented in order to allow multiple gRPC services to respond on the same
socket.

Expected outcomes

  • A procedural macro generating server related boilerplate.
  • Multiple services are able to respond on a single socket.

Skills

  • Rust
  • gRPC

Difficulty level

Medium

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.