Skip to content

Ideas List (2024)

Jump to bottom Edit New page
Koichi Sasada edited this page Feb 9, 2024 · 13 revisions

The following ideas are for GSoC 2024.

When adding an idea, be sure you have done the following things:

  1. Be sure to include whether the size of the project
  • 90 hours (small project)
  • 175 hours (medium sized)
  • 350 hours (large project) If it can be either please state that - per idea. Please use the 90 hours, 175 hours or 350 hours designations instead of full time, half time, large, medium, small or any other term.
  1. As stated in the Defining a Project Idea List section of the Mentor guide, please provide the following information for each idea:

a) A project title/description

b) More detailed description of the project (2-5+ sentences)

c) Expected outcomes

d) Skills required/preferred

e) Possible mentor(s)

f) Expected size of project (90, 175 or 350 hours)

g) An easy, medium or hard difficulty rating of each project.

Ruby Interpreter (MRI)

Implement IO::Buffer RubySpec specifications

Ruby's IO::Buffer is a crucial component for efficient input/output operations, providing a buffer between Ruby applications and the underlying operating systems. This project aims to convert existing tests for IO::Buffer into a comprehensive RubySpec specification. RubySpec is a project aimed at writing a complete, executable specification of the Ruby programming language, ensuring compatibility and consistency across different Ruby implementations. By converting existing tests into RubySpec, we can provide a more standardized set of tests which can be executed on different Ruby implementations and thus progress towards a standardised interface for Ruby.

  • Expected Outcome: The successful completion of this project will result in a RubySpec test suite for the IO::Buffer class, covering all its critical functionalities and behaviors.
  • Skills required: Applicants should have a solid understanding of Ruby, including its syntax, semantics, and standard library, particularly the IO classes. Familiarity with test writing, especially in the context of RubySpec or RSpec, is highly beneficial.
  • Possible mentors: @ioquatix
  • Expected size of project: 90 hours.
  • Level of difficulty: Easy. This project is an excellent opportunity for individuals looking to contribute to Ruby's core with a focus on standardization and documentation, without the need for deep technical changes to the language itself.

Improve implementation of IO#close

The IO#close method is a fundamental part of Ruby's IO operations, responsible for closing an IO stream and freeing up system resources. However, the current implementation of IO#close exhibits O(N) complexity, where N is the number of blocking operations. This inefficiency can lead to performance bottlenecks in IO-heavy applications. A past pull request (PR) attempted to address this issue but was only a partial solution. This project aims to revisit the problem, analyze the shortcomings of the previous implementation, and develop a more efficient solution that reduces the complexity of closing IO streams.

  • Expected Outcome: The successful completion of this project will result in a working implementation of IO#close that significantly improves the efficiency of closing IO streams in Ruby. This implementation should demonstrate a noticeable performance improvement in IO-heavy applications, particularly those that involve numerous blocking operations.
  • Skills required: : Applicants should have a deep understanding of Ruby, particularly its IO subsystem and performance optimization techniques. Proficiency in C, as Ruby's core is written in C, is also necessary to implement changes at the interpreter level. Familiarity with algorithm optimization and complexity analysis is essential to successfully redesign the IO#close method for better performance.
  • Possible mentors: @ioquatix
  • Expected size of project: 175 hours.
  • Level of difficulty: Medium to Hard. This project presents a challenging problem that requires a moderate understanding of Ruby's internals.

VSCode Ruby REPL

debug.gem provides REPL functionality on VSCode. However this feature is only used on debugging. This project implement lovely REPL functionality on VSCode with debug.gem.

Ideas:

  • Implement easy way to launch Ruby REPL on VSCode
  • Implement attractive programming features
    • Ruby programming interactive tutorial tour
    • Canvas programming features on VSCode with Processing like features
  • Integrate with Rails console
  • Advanced ideas: Integration with Wasm compiled Ruby with VSCode.
  • And more

The achievements will help Ruby newbies to try Ruby language. If you want to join this idea, please send me your ideas and how to make it.

  • Skills required: Ruby, Rails and VSCode extension. The person who knows what difference with irb console and Ruby debugger's console on VSCode.
  • Possible mentors: @ko1
  • Expected size of project: 90 hours.
  • Level of difficulty: Easy.

JRuby

JRuby home page | JRuby github

There are always projects to work on for JRuby. Stop by our Matrix chat if you have ideas or questions!

General Expectations

  • Prerequisites:
    • Java language familiarity at a Java 8 or higher level (lambdas, etc)
    • Ruby language familiarity, at least beginner to moderate level
    • Ability to install, run, and build JVM-based projects (our build is complicated but well-automated)
  • Programming areas include: Data structures, object-oriented design, cryptography, compilation strategies (as needed per project)
  • Expected outcomes: See project descriptions
  • Estimated difficulty level: Medium/Hard
  • Potential mentors: Charles Oliver Nutter (@headius), Tom Enebo (@enebo), Karol Bucek (@kares)

Ideas

Most projects could be either medium or large scale (175 or 350 hours) but priority will be given to students that commit to larger projects.

  1. Fixing Rails test failures - Ruby on Rails is a large and complex framework that exercises a huge portion of Ruby's features. Because of this, it serves as one of the key compatibility tests for a Ruby implementation. JRuby runs most of Rails' own test cases, but we have never achieved 100% compatibility. Sometimes this is due to small behavior differences (float rounding, for example) and other times it's due to features that JRuby has never implemented. Start at the top and work your way down, and improve JRuby's compatibility for Rails users.
    • Level of difficulty: Moderate to advanced, depending on the test failures and work required.
  2. Update the Warbler app-in-a-WAR-file utility - Because it is a JVM-based application, JRuby makes it possible to package up an entire Ruby application in a JAR or WAR file, including all dependencies. This is usually done using the Warbler library, but Warbler has not been updated in many years. We would like to work with a student to clean up, update, and get a fresh release of Warbler out for users deploying JRuby apps in a single file.
    • Level of difficulty: Moderate
  3. Optimization of unoptimized call paths - JRuby performance has been very good for many years, but there remains a large number of Ruby patterns that are unoptimized. These have started to become more important as users lean heavily on features like prepend, refinements, and Java integration. This project would take key benchmarks and profile them for method calls and allocations, looking to find opportunities to optimize code that has not been given much attention. The full complement of JVM profiling tools will work fine with JRuby.
    • Level of difficulty: Advanced, will require the use of Java's bytecode, method handles, and invokedynamic. Work will be in JRuby's JIT compiler.
  4. Missing features from Ruby 2.7-3.1 - The current version of JRuby, 9.4, is compatible with Ruby 3.1. The previous version was compatible with 2.6, so we had to implement three versions worth of features to release 9.4. Some of those features were left behind: 3.0, 3.1. This project would choose a few major features to implement. Java or Ruby would be acceptable implementation languages for most features.
    • Level of difficulty: Moderate to advanced, depending on the features
  5. Ruby 3.2 and 3.3 features and spec tests - Ruby 3.2 was released in December 2022, shortly after the release of JRuby 9.4. Ruby 3.3 was released in December 2023. We would like to have support for Ruby 3.2 features and Ruby 3.3 features in our next big release, currently planned as JRuby 9.5 later this year.
    • Level of difficulty: Moderate to advanced, depending on the features
  6. Comprehensive benchmarking suite and reporting system - The focus of the JRuby team has always been compatibility first and performance second, but we have a need for a more complete, trackable benchmarking rig. There are many available benchmarks spread across many repositories. This project would leverage those repositories and work done by other Ruby implementations to build a trackable benchmark report we can use to measure progress on optimization goals.
    • Level of difficulty: Moderate; many solutions exist, so part of this project will evaluate options, setting something up for JRuby and part will be increasing the set of benchmarks.
  7. Multi-backend Ruby Hash - Currently JRuby has a single bucket-style Hash implementation. Many times in recent years we have had a need for other implementations: small hashes for passing keyword arguments; concurrency-safe hashes for threaded environments; Java Map-based hashes to wrap standard Java Maps with Ruby logic; direct-addressing hashes for memory locality and compactness. These would all require that our Hash be broken into an abstract base and child implementations that can vary depending on needs.
    • Level of difficulty: Moderate to advanced; knowledge of Java refactoring tools and patterns will be necessary.
  8. Specialized String types - JRuby implements string in one way, as a wrapper around a ByteList that contains an array of bytes, a length, and a starting offset. We have a need for a way to wrap other types of String data with the same Ruby API, such as for passing Java String around without converting to bytes, or implementing "packed" Strings that contain all of their characters within the object itself. This project would require breaking our String into an abstract base and child implementations to suit different situations.
    • Level of difficulty: Moderate to advanced; Refactoring etc.
  9. Conversion of JRuby's OpenSSL library away from Bouncy Castle - JRuby has an API-compatible Ruby OpenSSL API (jruby-openssl that heavily leans on the Bouncy Castle cryptography library. However, Bouncy Castle maintenance has slowed in recent years, and we would like to get closer to a pure JDK solution or use one of the available wrappers around the real OpenSSL or other commonly used equivalents. Project scale would be partial conversion, since there's a lot of library here.
    • Level of difficulty: Advanced; knowledge of cryptography, public/private keys, certificate validation may be necessary.

Implement a Native IO Event Loop for the io-event Gem for JRuby

The io-event gem currently lacks a native IO event loop for JRuby, which is essential for efficient non-blocking IO operations. This project aims to implement a native IO event loop by adapting the efficient selector code from the NIO4r codebase to the io-event gem. This implementation will not only enhance the performance of non-blocking IO operations in JRuby but also expand the implementations functionality to include features such as efficient process_wait, efficient context switching of fibers, and handling ready lists.

  • Expected Outcome: The successful completion of this project will result in the io-event gem having a native IO event loop for JRuby, significantly improving the efficiency and performance of non-blocking IO operations. In addition, the full interface of the io-event selector interface should be implemented.
  • Skills required: : Applicants should possess a strong understanding of Ruby, particularly JRuby, and its IO subsystem. Experience with Java, as JRuby runs on the JVM, is crucial for integrating native extensions. Familiarity with the NIO4r codebase or similar event-driven IO libraries will be highly beneficial.
  • Possible mentors: @ioquatix
  • Expected size of project: 175-350 hours.
  • Level of difficulty: Medium to Hard.
Add a custom footer
Clone this wiki locally