Skip to content
Marco Concetto Rudilosso edited this page Apr 3, 2023 · 22 revisions

For GSoC 2023, the program is open to students and expanded to beginners in open source software development that are 18 years and older.

The following ideas are for GSoC 2023.

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

  1. Be sure to include whether the project is a 175 hours (medium sized) or 350 hours (large project). If it can be either please state that - per idea. This is missing from about 25% of the org apps right now. Please use the 175 hours and 350 hours designations instead of full time, half time, large, medium, or any other term.

  2. 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 (175 or 350 hours)

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


Ruby Interpreter (MRI)

Implement IO URing for Windows

I would like to extend the io-event Ruby gem to support non-blocking IO on Windows. I have no idea whether this is possible or how much we can implement, but it looks like this is a thing that exists and in theory works: https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ gives an overview of the new interface in Windows.

I can provide support and experience w.r.t. implementing non-blocking IO across a wide range of platforms, but you will need to have the necessary skills on Windows to build Ruby and the io-event gem extensions + use a preview build of Windows to get access to the relevant interfaces for testing.

  • Expected Outcome: A working implementation of IO URing in the io-event gem for Windows.
  • Skills required: Knowledge of Windows internals, C and Ruby are necessary.
  • Possible mentors: @ioquatix
  • Expected size of project: 175 hours.
  • Level of difficulty: Hard.

Make a new profiler

Profiling is an important technique to improve the software performance. Ruby has several profilers and it has several issues.

Please design your best profiler compare with existing profilers. To apply this development topic, please explain the existing profilers and why your profiler can be better.

  • Prerequisites: Ruby/C/Profiler desgin
  • Programming areas include: Profiler tools
  • Expected outcomes: Standard profiling tool for all Ruby users
  • Estimated difficulty level: Medium/Hard
  • Expected size of project (175 or 350 hour): Both okay (depends on your progress)
  • Potential mentors: @ko1 (ko1 at atdot.net)

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.

  • 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.
  • 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
  • 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.
  • 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
  • Ruby 3.2 features and spec tests - Ruby 3.2 was released in December 2022, shortly after the release of JRuby 9.4. We would like to have support for Ruby 3.2 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
  • 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.
  • 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.
  • 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.
  • 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.

TruffleRuby

See the website if you are not familiar with TruffleRuby.

  • Optimization: Would you like to optimize some Ruby method or operation further than it has ever been? This is possible with TruffleRuby, where you can easily control what the compiler does. One can also analyze the performance of some existing program and optimize it based on built-in profilers (--cpusampler, --cpusampler=flamegraph), compilation graphs and more.
  • Compatibility: Would you like to improve the compatibility of TruffleRuby so it matches CRuby even better and it's possible to run more applications on TruffleRuby? For instance by implementing Ruby 3.1 or 3.2 features? See https://github.com/oracle/truffleruby/issues/2733 for a list of changes.
  • Interoperability with other languages: would you like to enhance TruffleRuby's ability to interoperate with any other GraalVM language and make it more convenient? ExecJS and mini_racer backends based on GraalVM already exist. It would be interesting to add PyCall.rb, or to make more demos based on GraalVM Polyglot support.
  • Hash representation: Would you like to optimize TruffleRuby's Hash representation, to be more compact in memory and faster, similar to how it was done in CRuby? Currently Hash is a doubly-linked list + a buckets array in TruffleRuby, but we'd want something like https://blog.toit.io/hash-maps-that-dont-hate-you-1a96150b492a.

For any of these:

  • Prerequisites: Good knowledge of Ruby is needed, knowledge of Java or a similar language is a plus.
  • Programming areas include: Performance and language semantics
  • Expected outcomes: Should be clear from each description.
  • Estimated difficulty level: Medium/Hard
  • Expected size of project: 350 hours (175 hours is too short)
  • Potential mentors: Benoit Daloze (@eregon), Kevin Menard

Please chat with us on the GraalVM Slack channel #truffleruby if you are interested.

Scarpe

Scarpe is an early prototype to resurrect the shoes library on top of an html/css/js stack. Shoes is a graphical app kit for ruby; we can build GUI apps using it and run it anywhere ruby runs (which is basically everywhere from windows, mac, linux, Raspberry Pi, IoT devices, etc). "Scarpe" means shoes in Italian. "Scarpe" also means Shoes in modern Ruby and webview!

Ideas

Scarpe isn't feature complete with any version of Shoes (yet?). We're initially targeting Shoes Classic.

  • Expected Outcome: Add features to make Scarpe feature complete wrt Shoes Classic and make Scarpe user friendly (docs, examples, website)
  • Skills required: Knowledge of HTML,CSS/JS and Ruby are necessary.
  • Possible mentors: @Maaarcocr
  • Expected size of project: 350 hours.
  • Level of difficulty: Easy.

[For contributors] Propose Your Own?

If nothing on this list interests you, you can always propose your own. Ask a person who is a candidate of the mentor and send an email to Saroj saroj@zoras.me about the project plan and mentor's recommendation.

[For mentor candidates] Propose your project?

Please ask Saroj saroj@zoras.me about it and add your project in this project. Any Ruby-related projects (interpreter, eco-system, documentation, ...) are welcome.