When I start debugging using:
ruby -rdebug file.rb
and place break points:
b path:linenumber
before it gets to my break point, it stops at many other points in the imported libraries.
Does any one know how to prevent that?
Note: I already know I can place debugger points in the code which works well, but I do not want to do that since I keep forgetting to remove them.
I'm more thinking of a solution like using an option to prevent stopping at any module under /usr/lib/ruby.
I haven't used rdebug at all yet, but I've been having a great experience using Pry (http://pryrepl.org/). You simply stick a binding.pry anywhere in your code and upon execution you'll get dropped into the context of your binding.pry. You can then inspect variables, methods, navigate to different contexts using ls and cd, etc.
Sorry if this isn't what you were looking for!
Related
Is it possible to "blackbox" libraries when using Pry?
I like to walk the stack when I hit a breakpoint, but I really don't care about active-record transactions management and such. In fact, it even makes walking the stack completely useless sometimes.
In javascript, it's easy to add scripts to an ignore list and they are just skipped during debugging. Is there a way to achieve a similar behavior with Pry?
Additionnal details
What i mean by stack walk, is using "up" to move to the calling source code line which moves the source code marker to the previous stack frame.
I want to ignore frames that are outside my own code, like ActiveRecord and most third-party gems. I don't mind using either a blacklist or a whitelist.
Bundle gives me these gem versions:
Using byebug 9.0.6
Using pry 0.12.2
Using pry-byebug 3.4.3
The requested functionality does not exist in pry-byebug. You can add your +1 (or write some code) on the following GitHub issue for pry-byebug:
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.
As well as this GitHub issue:
I think it would be super useful to have a command that lets you run until you hit the next line of non-Rails/non-gem code.
As the original issue has been open for nearly six years, I think your best bet will be to help build the feature vs. adding a +1 on the existing issues.
The author of pry-byebug also offers this workaround in another SO answer to a very similar question:
you need to manually set breakpoints to jump from controller to view and the other way around
As I am learning Elixir/Phoenix, I happen to run into an issue like this often.
The problem is that this comes from a dependency, so normally I do this:
open deps/something/.../thefile.ex
add some debug code like IO.inspect to see what params are being passed
stop server, recompile with mix deps.recompile something
check the documentation to see what types are expected to that function
compare the types and trace down the problem to my code
This works but I'd like to improve my process, I know I can use Iex to start a repl, but I'd like to get much faster in terms of:
having a repl inside of the error page itself started automatically (like in better_errors gem for Rails)
having a way to see what arguments went into that method without me digging around (could be solved by the former point)
being able to see a method's documentation quickly
Also any other tips are greatly appreciated.
Please open up an issue in Plug: https://github.com/elixir-lang/plug
You have some great suggestions, like accessing the docs and make the arguments explicit. I don't think we can provide a REPL at the place of error though.
EDIT 1: I went ahead and opened an issue here since I got excited about those improvements! :D
EDIT 2: I realize that I should probably have used a comment as this is not quite an answer (yet!)
You have some code you want to remove associated with an obsolete piece of functionality from a ruby project. How do ensure that you get rid of all of the code?
Some guidelines that usually help in refactoring ruby apply, but there are added challenges because having code that isn't being called by anything won't break any unit tests.
Update: Has anyone written anything that allows you to guess based on your version control history if there are commits where you have since deleted most, but not all, of the code and can point out the remaining code?
Current thoughts:
Identify the outermost part of the stack associated with the obsolete functionality: the binary script calling it, or the unit tests calling it.
Look for methods that are only called by methods associated with the obsolete functionality. I often use git grep for this.
In theory, running mutation testing and looking for code that used to be mutation resistant when the old test suite applied, but is now mutation prone might help. It only helps if your code was well-tested in the first place! (Or you can use code coverage tools such as rcov rather than mutation testing)
Running test suites will ensure you haven't removed anything you shouldn't have!
Using autotest can save you time if you're constantly running tests.
If your code was well-structured, it should be easier to find related methods that need to be removed.
Especially in a dynamically typed language, there is no easy way to do this. If you have unittests, thank the developer that wrote them because it will help you remove the code correctly. But you're basically SOL. Remove the code, if it breaks, put it back, figure out where it broke, attempt to work around it, and repeat.
Look at your code coverage. Any code which isn't covered may be part of the code you have left to remove (if any). (Just be sure you have removed you tests. =])
I have a Ruby app with a lot of classes/modules, and some of them are not used. Is there an easy way of finding out which?
I was thinking to do a profile, and then work with it's output. Any other ideas?
A coverage tool, like rcov might help.
https://github.com/relevance/rcov
As you find methods that are not covered by tests, you should write tests for them or find out if they are used at all.
Removing unused methods is part of refactoring, if you have too many classes that can be a code smell that needs refactored also.
You can put raise (or raise Exception if you don't want it caught) to the start of the suspect method. If nothing breaks, then it might not be in use (either that, or something's catching the exceptions).
I am trying to find a better way to integrate IRB with my normal ruby devleopment. Currently I rarely use IRB with my code. I only use it to verify syntax or to try something small.
I know I can load my own code into ruby as a
require 'mycode'
but this usually doesn't mesh with my programming style. Sometimes the variables I want to examine are out of scope or inside of a loop. Is there an easy way to fire up my script and freeze at a certain point inside of IRB? I guess I'm looking for an easier way to debug my ruby code without breaking my F5(compile) key.
Maybe a more experienced ruby developer can share with me a more streamlined method of development.
Install the ruby-debug gem. Of course, require it inside your app (only in development/test mode). Now you can write 'debugger' where you want to stop execution.
Once your app stop at your breakpoint, you can type 'help' to know about all commands. One of them is 'irb'. It starts an IRB session in which you have access to all methods in your current context.
I personally mostly use p (print), eval, v i (instance vars) and v l (local vars). Of course, n for next and c for continue.
The command to step out of a given block/method never worked for me though. I never investigated why :-)
I don't tend to use irb directly that frequently, as I tend to be inside rails and so use script/console a bunch, but I do like using the ruby debugger (Ruby Debug gem). It lets you set a breakpoint basically and then step through your code line by line.
Here's a screencast about it that I haven't actually watched, but a quick search pulled it up, and it could be useful:
http://brian.maybeyoureinsane.net/blog/2007/05/07/ruby-debug-basics-screencast/
For Ruby development in Eclipse: there's a much improved version of RDT (ruby development tools) available now. To install it directly in Eclipse, click Help > Software Updates > Find and Install > Search for new features radio button > next > new remote Site > Name = Ruby and URL = http://update.aptana.com/update/rdt/3.2/
Another Ruby plugin is the shiny new Eclipse DLTK (dynamic languages toolkit).
DLTK stable release 1.0.M5 just came out a few days ago.
Here are some useful installation tips.
I just use rdebug to debug any of my ruby or RoR code.
If you're willing to use an IDE for debugging, I know Eclipse (via the Ruby Development Tools) has a relatively straightforward interface. If you're doing rails then there's a specific build of eclipse called RadRails which may also help (though I haven't used it for debugging)