Supporting debug within Rails 7.0

[pixeltrix]

Hi @ko1

We'd really like to make debug the default debugging choice for Rails 7.0 and beyond. We were wondering how we can best make that happen and we've come up with a few questions that I hope you don't mind answering.

1. Is DEBUGGER__.console the final choice for invoking the debugger? We'd like to use something more traditional within Rails 7.0 like debugger, etc. and we're happy to do this within Rails itself but were wondering the best way to achieve that.

2. A lot of opposition people have to using debuggers in their Rails apps is that they end up stepping through gem code that they haven't written and end up either giving up in frustration or getting lost. As a result they fall back on print debugging or using a console. To help overcome that, we'd like to implement a filtering mechanism similar to how Rails cleans backtraces so that when a developer steps through the code they are restricted to their application - is this something that's possible now and if it isn't how can we help make it possible?

3. Is the intention to ship 1.0 before Ruby 3.1 ships? We're not close to shipping 7.0 yet but were wondering whether the intention was to hold back the release until December?

Thanks for all the work you're doing on this. 👍🏻

[ko1]

1. Maybe there is a confusion.

• DEBUGGER__.console starts debugging under MRI. This means enables many debugger features such as entering debugger with Ctrl+C, thread/ractor tracing, eval code collection and so on.
• binding.bp introduces explicit break point (the name is not fixed. binding.debug is one idea). Maybe your question is it.
• I'm not sure what is debugger method, but I think breaking compatibility is not good, this is why I introduced binding.bp new name.

2. Maybe you are talking about "step-in/out" features with filtering. It is possible. The problem is debug command design. If you have good idea (or you can summaries requirements), please make new issue about it. Now I don't have good knowledge to design this feature (simply skipping gem code?).

3. Maybe we release 1.0.0 before 3.1. There is no plan so we can discuss about it.

Thanks.

[pixeltrix]

1. Yes, that's confusion on my part - binding.bp or binding.debug are fine. Is there a way to jump back out to MRI to do things like control threads?

2. As a first step, adding an explicit binding.debug and then being able to use step to skip over frames that are inside gem code would be good. We're pretty early in thinking about this so we'll need to give it some deeper thought.

3. That's good to know - as I said we're not close to shipping but just wanted to clarify things.

Thanks for your prompt responses - I'll open a new issue about point 2 once we've given it some more thought around API and features, so I'll close this issue. 👍🏻

[st0012]

Regarding the 2nd point, I think it can be achieved by injecting a callback at

debug/lib/debug/thread_client.rb

Lines 142 to 143 in a12e1dd

	@target_frames = DEBUGGER__.capture_frames __dir__

With something similar to

      @target_frames = DEBUGGER__.capture_frames __dir__
      @target_frames = @target_frames.select do |frame|
        frame.location_str.match?(Rails::BacktraceCleaner::APP_DIRS_PATTERN)
      end

This should exclude non-app frames from any later operations.

[ko1]

To support filtering "step-in/over/out" more considerations are needed.

[ko1]

@pixeltrix

Is there a way to jump back out to MRI to do things like control threads?

Sorry I couldn't understand the question correctly. What do you want to do with the debugger?

[pixeltrix]

Sorry I couldn't understand the question correctly. What do you want to do with the debugger?

Don't worry - I thought that binding.bp dropped you into an IRB console but that's not the case so it's another confusion on my part.

[st0012]

@pixeltrix do you think the Rails example in #157 is similar what you're looking for?