Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add debug command #446

Merged
merged 1 commit into from
Nov 18, 2022
Merged

Add debug command #446

merged 1 commit into from
Nov 18, 2022

Conversation

st0012
Copy link
Member

@st0012 st0012 commented Nov 18, 2022

This implements and closes #425

@k0kubun
Copy link
Member

k0kubun commented Nov 18, 2022

I've played with this implementation myself for a short while. This seems to be written pretty well. Great job 👍

Some minor feedback:

  • It silently stops the REPL on irb(1). I think we need to support only binding.irb, so we should probably just print an error for the irb(1) case instead of stopping the REPL.
  • It's probably better to avoid the name original_capture_frames since other gems could also do the same thing. Maybe something like capture_frames_without_irb is better.
  • It might be nice if we can avoid method definition/undef on every debug command invocation because it flushes some method caches. However, it seems not straightforward to disable the behavior after the first break if you use Module#prepend to override it. I tried and failed it, so it seems okay to leave it until we come up with a solution.

A question:

  • I wonder if we can go back to the original binding.irb after invoking debug accidentally or when you want to use IRB-only commands again. Sure, you can use irb command on the debugger, but it's a nested REPL and the "quit twice" problem re-appears here; you need to quit the debugger after using IRB. It feels like we're just moving the "quit twice" problem from IRB to debug.gem.
    • Can we implement a debug.gem command to quit the debugger and run binding.irb in the current frame without having the debugger as the parent?

Normally, I would leave it to you to address them before merging it, but I have one idea I'd like to try on this implementation. So let me merge this first, file a pull request to address the first two points myself, and file another one to add one change if that works out.

@k0kubun k0kubun merged commit 30faa13 into ruby:master Nov 18, 2022
matzbot pushed a commit to ruby/ruby that referenced this pull request Nov 18, 2022
@st0012 st0012 deleted the irb-debug branch November 18, 2022 10:05
@st0012
Copy link
Member Author

st0012 commented Nov 18, 2022

This is what I think Ruby development experience could be:

irb is a great entry point for common development activities:

  • It's great for prototyping a method or even a chunk of code. But for actual code editing, editors should still be the best place for it.
  • It's great for checking simple contexts, like variables or methods that are accessible from the current context. But for further debugging, debug is what users should use.
  • It's great for quick benchmarking (with the measure command). But in most cases, we still need and should write a benchmark script later.

If you agree with the above premises, we can see that there's a scene transition in every usage, which is what I want to improve now:

  • For code editing, we can have an edit command to open up the editor (perhaps bring the written code there in some way?).
  • For debugging, that's the debug command.
  • For benchmarking, I haven't thought about what we could do here. But having a command to dump the code and/or the previous measuring result seems to be a way?

(Sorry for sidetracking, now back to your question)

when you want to use IRB-only commands again

In this case, I think the question should be: why doesn't debug have that functionality? If it's helpful for debugging, we should implement it in debug anyway instead of letting people to switch back to irb.

go back to the original binding.irb after invoking debug accidentally

This is a possibility. But before introducing any change to debug, which is a lot more complicated, I'd like to collect users' feedback first:

  • What did they expect when typing debug at the first place. It's not a common variable name, nor is it a common command in other tools (AFAIK).
  • Could we prevent or reduce this accidental entry first? Like
    • debug would ask for confirmation before start debugging, debug! will do what current debug command does
    • The debug gem hints users when the input matches a command, like (rdbg) q! # quit! command. We can do the same for the debug command too.

@k0kubun
Copy link
Member

k0kubun commented Nov 18, 2022

In this case, I think the question should be: why doesn't debug have that functionality? If it's helpful for debugging, we should implement it in debug anyway instead of letting people to switch back to irb.

If we get to support the full functionality of whereami, ls, and show_source that we've recently added to IRB in debug.gem as well, I'll likely not need to go back to IRB. Maybe it's not a problem if debug.gem tries to be a superset of IRB.

off topic: Speaking of making it a superset, I'm still kind of uncomfortable that C-d asks "Really quit? [Y/n]" and I'd like to add a configuration to make it work exactly like continue (or C-d on IRB), but that's a separate discussion :)

@st0012
Copy link
Member Author

st0012 commented Nov 18, 2022

If we get to support the full functionality of whereami, ls, and show_source that we've recently added to IRB in debug.gem as well, I'll likely not need to go back to IRB.

It now has whereami and ls (except aliases and -g option though). I also opened a proposal for show_source but I currently don't have energy to follow through. If you can chime in perhaps we can have all 3 of them in Ruby 3.2 😄

I'd like to add a configuration to make it work exactly like continue (or C-d on IRB)

Personally I'd hope it to be q! (quit without asking). But continue makes sense as well. This does feel like something we can customise. (BTW, this should be the line to change.)

@k0kubun
Copy link
Member

k0kubun commented Nov 18, 2022

It now has whereami and ls (except aliases and -g option though)

I'm talking exactly about @ alias and -G option 🙂

Personally I'd hope it to be q! (quit without asking). But continue makes sense as well.

So, when you put binding.irb and press C-d, do you want to quit the process instead of moving until it hits another binding.irb? binding.irb is like a breakpoint for me, so personally I don't understand why debug.gem just quits it instead of continuing it (unlike pry-byebug) or even asks it.

@st0012
Copy link
Member Author

st0012 commented Nov 20, 2022

In debug, I usually can get the information I need or I can get with one breakpoint. So when I leave it, I usually want to restart the program for a clean state or test my code. With this usage, quit (by typing q! instead of using C-d) is more convenient to me.

But with irb or pry, multiple breakpoints are usually needed to go to different places, so continue would be more convenient than quit here.

@k0kubun
Copy link
Member

k0kubun commented Nov 20, 2022

I also quit irb or pry immediately very often, but still less frequently than C-d to continue. Whether you put a breakpoint by a command or leaving a method call, it doesn't change the fact that you use contiune multiple times and quit only once in one program execution. So somehow a less frequently used command is made easier to input. The "Really quit?" prompt would be very annoying if you need to use it as frequently as contiune.

I heard it's made that way because it's how gdb works. I'm the guy who use pry-byebug or irb more often, and debug is probably designed by people who use gdb more.

@st0012
Copy link
Member Author

st0012 commented Nov 20, 2022

it doesn't change the fact that you use contiune multiple times and quit only once in one program execution

Yeah that's true. But I don't use C-d often so I'm not a valuable data point. Perhaps it's worth doing a small poll within your colleagues or on social media to see how people feel about it?

I'm the guy who use pry-byebug or irb more often, and debug is probably designed by people who use gdb more.

I agree and feel that. And this is another behaviour that I wish it to match byebug instead of gdb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Add a command to activate and switch to ruby/debug console
2 participants