Feature Request: Push debugger activation to first breakpoint hit instead of `require "debug"`
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start by reading lib/debug.rb and the Kernel#debugger implementation in lib/debug/session.rb, then trace how require "debug", require "debug/prelude", and the open variants initialize sessions. Verify the proposed behavior against activation, TracePoint, thread, UI, and forking-message concerns described in the issue. Done means requiring debug is passive while the first breakpoint activates the debugger without changing the open variants.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Proposal
require "debug"won't activate the debugger. Debugger will only be activated when the first breakpoint is triggered.require "debug"will be the same asrequire "debug/prelude"
require "debug/open"andrequire "debug/open_nonstop"'s behaviour will remain the same.
Why
Side-effects
In apps that have Bundler.require, like most Rails apps, having gem "debug" in Gemfile means the debug gem is always activated when the app is booted.
However, with the debugger's activation, many things will happen in the background:
- Additional
TracePoints would be enabled (example) - A new thread will be spawned
- Additional computation and object allocation that come with the above
To most apps, having them in the background doesn't make a huge difference. But to some, having the debugger activated causes tests to fail.
For example, I tested 5 mid-to-large Rails apps in Shopify, and 3 of them have test failures that only happen when debug is activated:
- Some tests mock
File.readlinesand could break when this line is triggered in the background. - There's also weird
NoMethodErrorexceptions that only happens with the debugger activated.
Therefore, we always have require: false after gem "debug".
Problem Solved?
However, having require: false means users need to manually type require "debug" before start debugging with console. But in the meantime, byebug can be required by default without the same side-effects. So byebug doesn't need that manual require.
This extra require step is quite inconvenient for people considering switching from byebug to debug.
Other Smaller Issues
- The activation and forking messages are noisy and disabling them project-by-project is not trivial.
require "debug"locks the UI to console, so if users want to use the remote UI by requiringdebug/openafter the app is booted,require: falseis also needed.
Possible Change
diff --git a/lib/debug.rb b/lib/debug.rb
index 15ebccb..3489268 100644
--- a/lib/debug.rb
+++ b/lib/debug.rb
@@ -1,5 +1,3 @@
# frozen_string_literal: true
require_relative 'debug/session'
-return unless defined?(DEBUGGER__)
-DEBUGGER__::start no_sigint_hook: true, nonstop: true
diff --git a/lib/debug/session.rb b/lib/debug/session.rb
index a900f89..ffb2604 100644
--- a/lib/debug/session.rb
+++ b/lib/debug/session.rb
@@ -2486,7 +2486,9 @@ end
module Kernel
def debugger pre: nil, do: nil, up_level: 0
- return if !defined?(::DEBUGGER__::SESSION) || !::DEBUGGER__::SESSION.active?
+ if !defined?(::DEBUGGER__::SESSION) || !::DEBUGGER__::SESSION.active?
+ DEBUGGER__::start no_sigint_hook: true, nonstop: true
+ end
if pre || (do_expr = binding.local_variable_get(:do))
cmds = ['binding.break', pre, do_expr]
- Ngôn ngữ chính
- Ruby
- Star
- 1.3k
- Fork
- 146
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ruby/debug
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
-
Support exceptionOptions in setExceptionBreakpoints to catch arbitrary exception classes via DAP Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Issue tương tự
-
SyncEm always forwards a dummy block, so wrapped methods lose their no-block/Enumerator behavior Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
bug P2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
dependabot
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
githubnext/gh-aw-cao#13349 ·
-
user-reported
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Kong/developer.konghq.com#7316 ·