Break on application-code only

[sr3d]

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.

[deivid-rodriguez]

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 next when I'm about to step into external code, and step otherwise. It doesn't work that bad I think.

[accessd]

+1

[deivid-rodriguez]

I changed my mind on this. With next/step working as expected, I don't think this is actually necessary.

[deivid-rodriguez]

Changed my mind again after rereading this issue and this stackoverflow question.

[bnolan]

👍 I'd like to be able to do this.

[deivid-rodriguez]

As a tip to anyone wanting to contribute here, debase just added file filtering: ruby-debug/debase@7221579

[sundarv85]

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.

[danielyaa5]

🏏 🏏 🏏

[0x2c7]

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.

[lazyatom]

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?

[0x2c7]

@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.