Ruby Tip – Interactive debugging without the need for gems | Hacker News Reader

Ruby Tip – Interactive debugging without the need for gems

a-chacon.com

78 pointsamalinovic25 comments

Fun fact, Ruby as a single-threaded language is probably the only way 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 (but that other fibers can proceed, in case you were trying to debug something - you know - actually concurrent - and you really don't want for the world to stop and wait on your debugger!)

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!

Ruby was my first language, I was sorely disappointed when I realized this "super power" wasn't the norm in most languages. ahh to be a junior developer again. :)

Doing the same with pry ALL THE TIME. It basically became my standard programming workflow. Especially you can also do `ls` to inspect objects and classes.

Is there any other language which can do that? And I don’t mean unergonomic debuggers.

Another wonderful helper in Pry is `show-method`. If you type in `show-method Foo.bar`, it will pull up the source code for that method, or class, or whatever you pass to it. Great for looking something up when you don't understand what's going on behind the scenes, especially since it works on code from gems as well.

This is such an amazing pry feature that I never see people use, excellent time saver

I also sometimes use it to then open the gem source code and insert a `binding.pry` to debug but that's... uh... not something I'd really endorse.

I’ve been there too, just don’t forget to remove it! Also would never tell anyone else to do this, unless I trust them not to come to me about “everything getting all weird”

Another pro-tip in this vein is `object.methods` to see a list of the methods to which the object you're messing with will respond. I use this all of the time when I'm diving into something trying to figure out what's going on.

I always do object.methods.sort, otherwise my brain can't consume it

I use `my_object.methods.sort - Object.methods` to help reduce the methods I need to consider.

Subtracting Object.new.methods will remove more of the standard methods than Object.methods.

Even better, thank you!

Pry appears largely inspired by Smalltalk, which Ruby itself also draws heavily on, and which if anything can go much further.

binding.irb is indeed a superpower of Ruby (and its equivalent in a few other enlightened languages).

binding.pry is even better, and worth the gem install.

  irb : sh :: pry : zsh

While this was true for a long time, Ruby's built in irb and debug gems have improved dramatically in the past couple of years. To the point that I've switched to them from pry+byebug that I've been using for years.

One advantage of byebug is that if you do a sleep in something with theeads like capybara tests, the browser becomes functional again. Which is not the case with irb/debug. I couldn't find a way to reproduce this behavior in recent debuggers.

Can you do things like `next`, `step`, `up` or `caller` to go up/down the callstack like you can with pry?

Yes, you can with irb:debug, which you can enter by typing debug one you're inside a binding.irb session.

Tangentially related:

7 minutes of Pharo Smalltalk for Rubyists

https://youtu.be/HOuZyOKa91o

That interface looks so much like VisualAge for Java from the 90s.

Upon lookin into that, VisualAge was written in smalltalk.

Around 2005/2006, a coworker was a fan of both Ruby on Rails and Seaside (smalltalk framework, https://seaside.st/ )

ruby <3

binding.pry

play -l <line_number>

pretty new to this but I thought that irb was a dependency of rails, so when they say "not a gem," it's still a dependency somewhere...

using `binding.b` via the `debug` gem appears to be the path that most of the industry is going since I think it has 100% of these capabilities and more. I might be wrong. Curious what others think

I saw config was identified as an issue. The vanilla config for `debug` is amazing!! It gives me everything I needed from pry

Irb is a "default gem" - if your Ruby install doesn't have Irb, it is broken.

As such, unlike pry or debug you can always assume it's available.

Reply on news.ycombinator.com