debug VS Byebug

I've written Ruby for coming up on 20 years, so to be honest I haven't paid attention to what is written on that subject in recent years.

Bundler shouldn't be running inside a trap context, but you might be running into a situation where standard input/output from the actual process triggering your breakpoint has been redirected. In that case, ruby-debug[1] is a good option, as you attach to it from outside[2]. Basically, run "rdbg --open yourscript.rb" and then use rdbg -A from another terminal.

You use Pry remotely too[3] if you prefer.

[1] https://github.com/ruby/debug

[2] https://github.com/ruby/debug?tab=readme-ov-file#remote-debu...

[3] https://github.com/Mon-Ouie/pry-remote

what is ruby debug not able to do that you want it to do?

https://github.com/ruby/debug

a nice ide integrated experience:

https://code.visualstudio.com/docs/languages/ruby#_debugging...

https://github.com/ruby/vscode-rdbg

https://code.visualstudio.com/docs/editor/debugging

Execution is paused at the breakpoint (which has a little arrow pointing at it). You can then enter commands to the rdbg prompt to control the debugger. For a list of the different commands you can use, visit the documentation for the debug gem.

In 2017, I wrote a toy language called Goby[1] to learn how Ruby works. A few folks contributed quite a bit to it and one of them later referred me to my previous job (as a backend developer).

Fast-forward to 2021, I got interested in debugging tools so I started contributing to the then newly created Ruby debugger[2]. In less than a year I opened more than a hundred PRs and became the 2nd biggest contributor of it. And that eventually landed me a job to work on Ruby's development tools, like LSP servers, REPLs, and of course, the debugger :-)

[1] https://github.com/goby-lang/goby

[2] https://github.com/ruby/debug

Fun fact, Ruby as a single-threaded language is how most people experience it, but Ruby has a rich cooperative multitasking called Fibers that hopefully is getting more exposure, in amongst a bevy of competing implementations and other also-ran concurrency primitives (besides the usual contenders like Threads, Process fork, foreman that just runs several processes alongside one another...)

https://github.com/ruby/debug/issues/486#issuecomment-157531...

If you want to use debugging and multi-threaded or multi-fiber Ruby at once, you can! You just have to get a bit creative. I always refer back to this thread on the Ruby `debug` gem (though the advice applies to any other REPL you can use) about applying a Mutex. You can use the built-in Fiber.blocking to prevent other fibers from running at the same time as yours, or you can use a Mutex to just ensure that you don't hit the debugger multiple times in the same process IO that would mean you've got multiple REPLs all grappling for the StdIO at once.

For a long time Ruby dev who almost never did concurrency unless it was facilitated by the OS, or before being exposed to it directly in other languages like Go, the Ruby "super power" remains intact, it's just a bit more mysterious with the concurrency stuff added. Ruby has amazing diversity in its concurrency tools, which is a nice way of saying "the language authors decided not to pick a king concurrent runtime/winning gem whilst all of the competing implementations were all a bit nascent and un-fully-formed!"

I like the bruno/fiber-scheduler but it looks like it is not the winner. It should be easy to switch to another fibers implementation, I think async is the crown champion now, but I still haven't been motivated to switch - the fiber-scheduler that is named fiber-scheduler has been good enough for me, despite shortcomings!

Debuggers are powerful tools that allow you to step through your code line-by-line, inspecting variables and understanding the flow of execution. Using debuggers is a whole topic unto itself, and getting into the weeds with that would balloon the scope of this post. If you want more information on using them, I recommend reading the README for rdbg. This is the debugging solution for modern Ruby/Rails development. It's in Ruby's stdlib as of v3.1, and Rails 7+ apps include it in the Gemfile by default. I also recommend this section of the Rails guides for exploring how to use the debug gem with Rails applications.

Trace Inspector, a tool that displays Ruby trace logs with pretty UI while debugging in VS Code, has recently landed in debug.gem. debug.gem is a Ruby standard debugger library and the default debugger in Rails. Since debug.gem supports VS Code, you can debug Ruby programs in vscode-rdbg.

For newer versions of Rails (introduced in v7): Debug Gem

While pry is nice Ruby 2.6+ includes the debug gem in the standard library which avoids the need to install another dependency.

Have you tried ruby/debug's catch command? You can do catch Exception to achieve the same effect.

Just pry or with byebug? If the latter: https://github.com/deivid-rodriguez/byebug/issues/564

Byebug is not fully compatible with Zeitwerk, I was getting random NameError exceptions failing to load constants in development and tests until I removed this gem.

byebug - this elevates debugging Ruby applications. It allows you to run a program line by line, add breakpoints, and evaluate and track values at runtime. If you still use puts for debugging, it's time you get to know Byebug's features and commands.

Immune from the compatibility issue with Zeitwerk

For debugging purposes, I recommend a few gems that will get you started and allow you to play with ruby code in your terminal and manage ruby gems. Gems like bundler pry and byebug do it good and you can check out the official docs, Pry, Byebug, Bundler, These gems need to be accessed globally.

Byebug is a helpful and easy-to-use debugger made for Ruby. It allows developers to use traditional debugging features to help identify what is happening in a program while it's running. Byebug was created by David Rodriguez in hopes of building a better Ruby debugger.

Others have been suggesting byebug, but for us it started causing random constant loading errors on Ruby 3 in Rails, due to Zeitwerk compatibility issues. So I'm quite happy that the debug gem came in as a replacement. I did like that pry-byebug allows stepping in a normal Pry console, I expect the debug gem will require some getting used to.

As far as debugging tools go, the Byebug and Pry are two of the best gems I have found. They are used in different contexts, but for all intents and purposes, including them in your code will halt an operation and allow you to access whatever point in the code you halted within your terminal with a REPL.

We commonly use byebug for debugging our code which is an easy-to-use, feature-rich ruby debugger. This gem is introduced in Rails 5. It offers features like Stepping, Breaking, Evaluating and Tracking.

Looking forward to this, byebug's Zeitwerk incompatibility is currently causing nondeterministic constant loading errors in our app when used with pry-byebug.