Support IRB console

[st0012]

Motivation

Currently, the irb command always opens up a fresh IRB session, which means:

• Users won't have access to debug's commands in this mode.
• To use debug commands, users need to leave the IRB session first, which means losing IRB commands or feature like multi-line input.
• Moving between the 2 modes is not practical and doesn't provide a good experience.

So in this PR, I enhanced the irb command by making it activate IRB's new irb:debug integration.

And if users want to always activate the new IRB console, without constantly typing irb command manually, they can achieve this by setting CONFIG[:irb_console] to true.

Closesruby/irb#712

Changes

When the new irb command is executed, it will:

• Open a new irb:rdbg console, which is achieved by replacing debug's UI_LocalConsole UI with IRB's IRB::Debug::UI.
• In addition to replacing the UI class, it also performs a few setups like:
  • Making the debug gem skip IRB's frames.
  • Patch IRB's Context#evaluate method so when it evaluates IRB commands frozen threads will be temporarily unfroze.

Furthermore, if users set RUBY_DEBUG_IRB_CONSOLE or CONFIG[:irb_console] to true, then the irb:rdbg console will be opened automatically in the sessions.

Main differences

• In this new session, users can access both IRB and debug's commands, instead of just IRB's.
• Since users have the features of both tools in the session, I didn't implement a way to "exit" back to debug's default console.
  • I'll be happy to make a follow up PR for it if it's proven useful in some cases.
• In the irb:rdbg console, users get hint when their input is going to be processed as a debug command:

Screen.Recording.2023-12-04.at.21.41.35.mov

[jon-sully]

Excited for this one! 😁

[ko1]

Is this intentional?

[master]$ RUBY_DEBUG_IRB_CONSOLE=true exe/rdbg -O target.rb
DEBUGGER: Debugger can attach via UNIX domain socket (/run/user/1000/ruby-debug-ko1-223275)
/home/ko1/ruby/install/trunk/lib/ruby/gems/3.3.0+0/gems/debug-1.8.0/lib/debug/color.rb:22: warning: already initialized constant DEBUGGER__::Color::SUPPORT_COLORABLE_OPTION
/home/ko1/ruby/debug/lib/debug/color.rb:22: warning: previous definition of SUPPORT_COLORABLE_OPTION was here
[1, 10] in target.rb
1|
=> 2| n = 10
3| p 1
4| p 2
5| p 3
6| p 4
7| p 5

and

irb:rdbg(main):002> n
[1, 10] in target.rb
1|
2| n = 10
=> 3| p 1
4| p 2
5| p 3
6| p 4
7| p 5
8|
9|
10| __END__
=>#0 <main> at target.rb:3
irb:rdbg(main):003>

(n as next command)

[ko1]

For the remote connection, hmm... ignore this option?
It is safer strategy for VSCode (DAP).

[st0012]

@ko1 great catch on the doc and remote mode issue. I've fixed both now.

(n as next command)

Yes this is expected. The irb:rdbg integration only handles IRB commands and passes other types of input to debug.

[ko1]

Yes this is expected. The irb:rdbg integration only handles IRB commands and passes other types of input to debug.

This is why I could not allow to input Ruby expression directly (and allow with Reline prompt changing).
Could you consider to use escaping such as , next which is used on VSCode DAP REPL?

[st0012]

Thanks for raising this 🙏 I talked to a few users during RubyConf and some said they did experience the issue before.
But we all think it's better not to add the comma prefix. Because it means users will need to constantly be aware of which commands are from IRB (without comma) and which are from debug (with comma), which increases the learning curve for the feature.
Alternatively, I think we can add an input hint to let user know the current input will be treated as a debug command through ruby/irb#768.

[ko1]

Alternatively, I think we can add an input hint to let user know the current input will be treated as a debug command through ruby/irb#768.

It is one idea. How to know the string is debug command or not?

[st0012]

@ko1 In IRB v1.10, I added hint to irb:rdbg session, which only show up when the input will be processed as debug command. And it will be removed once the user hits enter so it doesn't pollute the output history. Finally, it will be disabled if the user has no_hint set for debug.

I've bumped the PR's IRB requirement to v1.10 to take advantage of this feature. Here's a short demo:

Screen.Recording.2023-12-04.at.21.41.35.mov

[ko1]

Thank you. It's great.