-
-
Notifications
You must be signed in to change notification settings - Fork 327
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
Break on application-code only #47
Comments
Yes, I've been thinking of implementing something like this for a while, and an exclusion list might work. This goes straight to the to-do list! What I normally do to workaround this is |
+1 |
I changed my mind on this. With |
Changed my mind again after rereading this issue and this stackoverflow question. |
👍 I'd like to be able to do this. |
As a tip to anyone wanting to contribute here, debase just added file filtering: ruby-debug/debase@7221579 |
It would be great to have file filter where one can specific the list of files or the directories in the path where it should step through. |
🏏 🏏 🏏 |
I think this could solve your issue: https://rubyjard.org/. It's a wrapper around byebug, with a nice Terminal UI, and plenty of features. One of the key feature is frame filtering that allow you to debug application code only, or include/exclude any gems/ruby libs you want. |
I would really love this too. Rubyjard looks excellent but when not in a terminal (i.e. running a debugger within an editor), it's no longer suitable. From what I can tell, Rubyjard handles this by wrapping the command processor and stepping through until the current file matches a set that it should stop on, or some execution time or depth expires. Is that a suitable solution here, or does it need to be implemented somewhere in the C bindings, like debaser has done? |
@lazyatom Yes, it will be re-implemented in C. However, recently, I'm focusing on feature set instead. Btw, in the roadmap, I will implement DAP protocol to support debugging in VS Code, Vim, or Emacs. |
Hi,
Byebug is great and it seems to be a lot less buggy than debugger so thumbs up! However, the issue I'm running into is that whenever I step in, byebug (and also debugger) would step in too deep, or into a chunk of code that's somewhere deep in the gem. Obviously I don't want to step thru any gem code or external library but focus only on my current application's code.
My question/suggestion is that if there's a way to filter or skip over external library, or a setting to step into the next line that belongs to a script within the current application. For example, step into a method call will skip over any Rails's internal script or any currently-used gem and stop at the next line of the file that's inside the application. This will greatly reduce the tediousness of stepping into the app and help pin-pointing the issue. Currently it's quite time consuming to setup the correct breakpoint, and usually it's a hit-or-miss and having to run the test suite multiple times just to figure out the correct breakpoint placement.
Something like a configuration to list the path or locations to resume the debugger when stepping in automatically would be a great start.
The text was updated successfully, but these errors were encountered: