DEV Community

Koichi Sasada
Koichi Sasada

Posted on

debug.gem blog: initial commit

About this series of articles

This series introduce features of ruby/debug: Debugging functionality for Ruby now I'm working on. debug.gem will be introduced into Ruby 3.1 which will be released Dec/2021.

This article introduce about debug.gem, the background and the motivation.

BTW see the recent article A Sneak Peek of Ruby's New Debugger! by @st0012 . His great article introduces debug.gem from Ruby on Rails developer perspective.

Background and motivation

debug.gem is a debugger for Ruby. It is new replacement of lib/debug.rb which is installed from ancient Ruby 1.3.1 (!!). However, lib/debug.rb is not maintained well long time and nobody uses it. Surprisingly, most of features works on recent Ruby versions. However, it introduce performance penalties to the application and it lacks important features like flexible breakpoint setting or remote debugging or IDE integration (it can integrate with emacs, though) and so on. Also it doesn't have cosmetic features like coloring.

Maybe byebug (deivid-rodriguez/byebug: Debugging in Ruby 2) is most famous Ruby's debugger in recent years. byebug has enough features, however it doesn't utilize recent added TracePoint features for debuggers, so it is slow when some breakpoint is set.

byebug supports threading. However Ruby 3.0 introduced Ractor (ruby/ractor.md at master · ruby/ruby). Ractor enables to make parallel program in Ruby, but the parallel programming is difficult and it needs support for debugging. However, it is hard to support ractors by existing debuggers.

Hidden but the most important motivation is I (Koichi) likes to make a developer support tools. I feel that using debugger is difficult for the programmers. It is challenging topic to provide useful features for many Rubyists.

Making a new gem

We talked about replacement plan of lib/debug.rb. Fortunately we can reserve "debug" gem name in rubygem.org so we decided to make a new gem and replace with lib/debug.rb

Conclusion

This article introduces the background and the motivation of debug.gem.

There is no debugger implementation to utilize MRI's new features for debuggers and no debugger supports Ractors. This is why we decided to make a new debugger.

I really appreciate any feedback about debug.gem. Next I will introduce basic features of debug.gem.

Acknowledgements

  • This work is supported by Cookpad, an employer of me (Koichi). In recent months Cookpad allowed me to focus on the debugger development.
  • Naoto Ono helps us to prepare testing framework on Google summer of code project (Ruby | Google Summer of Code).
  • Stan Lo contributes appealing features like text coloring and tells us the debugger experience on his projects.
  • And all contributors!

Discussion (0)