I am making my way from Django to Rails. So far I just created a new Rails app and found in the Gemfile this line:
# Call 'debugger' anywhere in the code to stop execution and get a
# debugger console
gem 'byebug'
How this supposed to work? Is it as straightforward as it said in the comment? I can put debugger somewhere in code and get a debugger console in my browser?
start rails server
rails s
and monitor the logs.
Now try accessing the page which points to the place where debugger is written in the code
The log will stop at a point where you have put the debugger/byebug word.
You can print out variables at that instant
update for rails 4
On suggestion of Deivid, I would like to quote him here
drop the --debug flag. You don't need to do anything special to make
byebug work in Rails 4. Just require 'byebug' and call byebug
You won't get a debugger in your browser - calling debugger or byebug will drop you into the byebug prompt in the terminal window that was used to run your rails server (note that this is not the same as the rails console - there is a overview of what you can do in the rails debugging guide).
Another tool you may be interested in is the web-console gem (included by default in rails 4.2 and above). This allows you call console (in a controller, view etc.) and will dump you into a browser based IRB session at that point
When working on a web app in python/flask, I am able to import pdb at the top of a file, and then call pdb.set_trace() somewhere in my code to "pause" the web app and open an interactive console in my terminal for debugging. I am looking for something similar in Ruby/Rails. What exists for this purpose, and how do I use it?
Pry (and pry-remote) might be what you're looking for. I have no experience with it, but this is what it's supposed to let you do.
https://github.com/mon-ouie/pry-remote
I have found a solution.
The gem debugger is created for this purpose. To start, run
gem install debugger
After, add the line debugger into your code to "pause" the code at that point. For example:
def hello
#users = Users.all()
debugger
end
Then, when starting the server, call it with:
rails server --debugger
How do you guys debug your Rails apps? I have seen a link to datanoise.com that is supposed to show how to use ruby-debug with Textmate using a bundle.. but it looks like the page is down. Does anyone know how to set this up? Thanks!
#johnmcaliley - I debug my rails apps by simply adding 'debugger' to my code:
method_call
variable = method_call + 5
debugger
#more code
Then start your rails web server with the --debugger option:
script/server --debugger
This requires you have a gem installed, ruby-debug, I think. Check out this screencast for a good demo: http://railscasts.com/episodes/54-debugging-with-ruby-debug
However, it doesn't hook into textmate.
I am a Cakephp developer that is currently doing some work in ruby on rails and one thing i use a lot in cakephp is debug-kit which allows me to see many things within the web page such as request information and variables available in the view.
Is anything like this available for rails as i cant seem to find something similar.
there is ruby-debug which you can use with RoR in order to debug your application.
you need the ruby-debug gem
sudo gem install ruby-debug
after that you have to start the server in debugging mode.
script/server --debugger
now if you put the line
debugger
somewhere in your rails code, the console where you run the server fires up an irb where you can see all the request variables and debug information you need.
WEBrick or Mongrel is currently supported with debugger.
for all the debug options with ruby on rails see http://guides.rubyonrails.org/debugging_rails_applications.html
While I agree with z3cko's answer (+1!), you should also take a look at Rack::Bug:
http://www.brynary.com/2009/4/22/rack-bug-debugging-toolbar-in-four-minutes
Go over the screencast linked from that post.
Great tool
In my main Sinatra controller, I want to debug the params hash after it is POSTed from a form.
I have added:
puts params.inspect
and
set :logging, :true
The params.inspect works if everything goes well. But if an error happens before the controller is executed I'm not getting any information about the error like I would in Rails by default.
What's the best way to get useful debug info?
This example did not work at all (the app wouldn't even start after I added this code):
configure do
Log = Logger.new("sinatra.log")
Log.level = Logger::INFO
end
followed by:
Log.info "#{#users.inspect}"
You could try adding a before filter that prints out the parameters
before do
puts '[Params]'
p params
end
My opinion is that for debug you should use configure :development do because some debugging flags are turned on in this scenario. So, under your configure do block you can enable the flags:
enable :logging, :dump_errors, :raise_errors
and for your logging facility:
log = File.new("sinatra.log", "a")
STDOUT.reopen(log)
STDERR.reopen(log)
From the Sinatra handbook:
dump_errors option controls whether the backtrace is dumped to rack.errors when an exception is raised from a route. The option is enabled by default for top-level apps.
raise_errors - allow exceptions to propagate outside of the app
(...)
The :raise_errors option is disabled by default for classic style apps and enabled by default for Sinatra::Base subclasses.
I also use the
puts "something" + myvar.inspect
method in the middle of my controllers.
As #jshen says, ruby-debug is a very nice tool - if you are using Ruby 1.8.
In order to use it in Sinatra, insert
require 'ruby-debug/debugger'
where you'd like debugging to start.
I recommend using Pry or the Ruby debugger. With Pry, you can use the command line to traverse your methods and variables like you would in bash.
See "How to use Pry with Sinatra?".
In order to find the best way to debug sinatra app, I created a repo at github. The most useful part is step into method debug, which looks like below.
Here is the repo: https://github.com/hlee/sinatra_debugger_example
I'd highly recommend using ruby-debug for Ruby 1.8. It's very easy to setup and use once you learn the four or five basic commands. It will allow you to set a breakpoint where you want to inspect the params and interactively play with it like you would in IRB.
Ruby Debuggers in Sinatra
You are free to use Ruby debuggers for Sinatra. The main issue is that you will need to know which Ruby Gem is used for which Ruby version. For most people now that means Ruby 2.X and byebug.
Ruby Debuggers by Ruby version
Ruby Version Gem Install require add breakpoint
---------------------------------------------------------------------
1.8.X ruby-debug 'ruby-debug/debugger' debugger
1.9.X debugger 'debugger' debugger
2.0.0+ byebug 'byebug' byebug
Once you know that you must install the gem, require it in your code and then add breakpoints by typing a keyword. Taking byebug as an example:
install: gem install byebug
require: require 'byebug'
breakpoint: byebug
Further Reading
Byebug project
Byebug guide to use a terminal debugger
Have you thought about trying something like this article: http://www.gittr.com/index.php/archive/logging-with-sinatra-and-passenger-another-try/
I'm guessing since you mentioned your main Sinatra controller, you have more than one, which means you're subclassing Sinatra::Base rather than using a classic (top-level) Sinatra app. If this is indeed the case, a lot of the default error-handling that Sinatra does is disabled by default.
If you include set :show_exceptions, true if development? in the class definition, you'll get friendly error pages that include a stack trace, params, etc, instead of just an internal server error. Another option is to set :raise_errors, false and then include a error do ... end block that will run whenever one of your routes raises an error.
I'd recommend using the debugger gem for Ruby 1.9.
To use this with your Sinatra app:
Add the gem to your Gemfile
gem "debugger"
Install the gem by running
bundle
In your main sinatra app file, add
require 'debugger'
Now to debug, you just have to add the following line
debugger
anywhere in your code.
When the code is being executed and debugger is seen, code would stop and you can inspect variables, run commands (using eval), etc.