Feature #17863
closedrewrite lib/debug.rb with latest API
Description
I rewrite lib/debug.rb (called old debug.rb) with recent TracePoint APIs (called new debug.rb).
It has several incompatibility but maybe nobody uses lib/debug.rb so there is no compatible issues. In fact I tried several features of lib/debug.rb and it doesn't work nowaday.
You can see the doc on https://github.com/ruby/debug
Compare with existing other debuggers, it has several advantages:
- Fast: No performance penalty on non-stepping mode and non-breakpoints.
- Remote debugging: Support remote debugging natively.
- UNIX domain socket
- TCP/IP
- VSCode/DAP integration (TODO)
- Extensible: application can introduce debugging support with several methods
- By
rdbg
command - By loading libraries with
-r
command line option - By calling Ruby's method explicitly
- By
- Misc
- Support threads (almost done) and ractors (TODO).
- Support suspending and entering to the console debugging with
Ctrl-C
at most of timing. - Show parameters on backtrace command.
And do not need to write it on Gemfile because it will be a default gem from Ruby 3.1.
Important differences:
-
require 'debug'
is only a way to enable old debug.rb, but new debug.rb can be enabled with:- require
-
rdbg
command (like bybug) -
binding.bp
method likebinding.irb
- Support remote debugging
- Support several options like non-stop mode and so on
- old debug.rb evaluate unrecognized command as Ruby script, but new debug.rb doesn't allow this spec.
-
obj.foo
will be evaluated as Ruby script on old debug.rb (and byebug) - new debug.rb shows
unknown command
because it is typo safe and extension safe. - To see the result, you need to use
p
command likep obj.foo
.
-
Now you can try on 2.6-master with gem install debug --pre
.
Updated by byroot (Jean Boussier) over 3 years ago
I tried it with our app, and it crashes weirdly, maybe because of Thread.report_on_exception = true
?
(rdbg) c
#<Thread:0x00007fa3421f4630 ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:78 run> terminated with exception (report_on_exception is true):
~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/source_repository.rb:13:in `read': No such file or directory @ rb_sysopen - eval (Errno::ENOENT)
from ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/source_repository.rb:13:in `add'
from ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:825:in `on_load'
from ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:88:in `block in initialize'
["~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/thread_client.rb",
599,
#<Errno::ENOENT: No such file or directory @ rb_sysopen - eval>,
["~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/source_repository.rb:13:in `read'",
"~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/source_repository.rb:13:in `add'",
"~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:825:in `on_load'",
"~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:88:in `block in initialize'"]]
~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/source_repository.rb:13:in `read': No such file or directory @ rb_sysopen - eval (Errno::ENOENT)
from ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/source_repository.rb:13:in `add'
from ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:825:in `on_load'
from ~/.gem/ruby/3.0.1/gems/debug-1.0.0.beta3/lib/debug/session.rb:88:in `block in initialize'
Updated by Eregon (Benoit Daloze) over 3 years ago
binding.bp
What does bp
mean? It seems hard to guess. Why not binding.debugger
or binding.debug
?
Updated by byroot (Jean Boussier) over 3 years ago
"Break Point" I presume. But yes, my 2 cents of feedback is the same. Might just be habit, but I had a hard time remembering it just during my 10 minutes session of trying the gem.
I'm very used to Kernel#debugger
/ Kernel#byebug
.
Also on another note I figured the bug above: https://github.com/ruby/debug/pull/10
Updated by ko1 (Koichi Sasada) over 3 years ago
I want to avoid Kernel#...
for compatibility.
If binding.debug
makes sense, I prefer it.
Updated by ko1 (Koichi Sasada) over 3 years ago
ko1 (Koichi Sasada) wrote in #note-4:
I want to avoid
Kernel#...
for compatibility.
Ifbinding.debug
makes sense, I prefer it.
or both? (#bp
and #debug
). mame-san said binding
is too long and he doesn't want to write it :p
Updated by Eregon (Benoit Daloze) over 3 years ago
I think binding.debug
is best. It's not that long to type, and people are already used to e.g. binding.irb/pry
.
Too short feels cryptic and easier to get accidentally committed.
Updated by hsbt (Hiroshi SHIBATA) almost 3 years ago
- Status changed from Open to Closed
- Assignee set to ko1 (Koichi Sasada)
debug.rb was replaced debug gem at https://github.com/ruby/ruby/pull/4804