I'm always making the same steps when I do:
script/console
do you know some file to edit or something similiar to avoid doing always the same, like for example loading some particular required gem (in my casi 'spawners' :))
Create a file called .irbrc in your home directory and any Ruby code you put in there will be executed at the beginning of your console session. There's lots of cool improvements you can make to the console experience this way, e.g. these from Dr. Nic (the end of that article also has instructions for getting .irbrc working in Windows).
With irb, ~/.irbrc serves for that purpose. Not sure whether Rails console uses it though.
Related
I have a rails which seemed to be working previously but now after some changes when I go to the root page it takes it infinitely to load it, it just doesn't load it. There're nothing useful in the console either. How can I find out what prevents it from loading the main page? Is it about profiling?
Check your Rails logs, eg. development.rb. You can put logger.info, or puts statements in your environment.rb, development.rb and application.rb files to see how far Rails is getting in the boot process. You can also create a dumb initializer named 00_start_init.rb with a logger.info or puts statement to see if you're getting as far as initialization. I've found that useful before.
To really understand where you application is hanging, you need to understand the Rails initialization process. Here is the documentation for Rails version 4.2. http://guides.rubyonrails.org/v4.2/initialization.html. Similar documentation exists for every version of Rails. You can take advantage of understanding the boot sequence by placing log statement at various point in the process.
I'm assuming you're in the development environment. If so, and the console loads, it's likely not a configuration problem. It's more likely a problem with your controllers or models. If the console won't load to a prompt, then it's likely a configuration problem in application.rb, development.rb, an initializer, etc.
You mention profiling, but provide no details about it. I can't even guess what you're referring to, so the answer is "maybe?". If you can post the code changes you made since the app last loaded in the browser, that would make it much easier to help you trouble-shoot.
Please can you share your approach / methodology to debugging in Ruby / Rails.
I'm busy with the Rails tutorial, and am getting the error:
NoMethodError in UsersController#show
undefined method `microposts' for #<User:0x83b43e8>
And that got me thinking about debugging strategies. Does anyone have advice for a new Rails user (and new MVC user) on strategies to approach debugging. What path do you follow? Is there a generally accepted approach? Is there a way to step through the code?
Right now I am using unit testing as a kind of "lint" checker, but that only goes so far.
Although I want to solve it, the actual error I am getting right now is not the main thrust of this question.
(PS: The problem is not a duplicated "show" as documented in elsewhere on Stackoverflow
I haven't seen this mentioned yet but another option is to put a debugger statement in your code. Like this
def some_method
something = 3
debugger
# ... more code
end
If this is in a rails app when the code reaches debugger it will cause the terminal window running the web server to jump into something that looks like an irb session (I'm not exactly sure what it is). From there you can do puts something to see what the value is for example. You can even puts params to see what all the params values are. You can also step through the code, jump to a specific line, etc.
Pry seems to be a better way to go about this but it's how I used to debug before I knew about pry.
Note: You might need to do require 'ruby-debug' if you're doing this outside of rails.
i use a combination of irb, print statements, logging and pry bindings. (pry is a great gem)
irb is a great way to just play around with your ruby or rails app in the console. You could just enter the code from your controller (or similar) and see if it breaks in console for faster feedback loop. But remember you have to do reload! if you change anything in your class/module.
print statements are easy if you're running tests and just want it to output something a different points in your test. But if your testing in a browser I would recommend writing to the logger: Rails.logger.debug "...". But remember to set your logging level in your configuration to DEBUG -or- you can just do Rails.logger.info instead which should show up by default. Then you can just tail or view the logs in my_app/logs/development.rb.
My favorite method for really tricky bugs is that if the error is happening in a test you can just place binding.pry in the preceding line and then it will pause your test at that line and drop you into a console. I recommend watching the rails casts for more in-depth info: http://railscasts.com/episodes/280-pry-with-rails
I do not start Rails project without 'pry' gem.
Add gem to Genfile:
group :development, :test do
gem 'pry'
end
and stop request execution anywhere in your project, just put
binding.pry
to your model, controller, tests ..., or
<% binding.pry %>
in your view's, templates, partials.
Then you can check what ever you want objects, params, variables ...
Type exit to leave pry environment, and request will continue.
The Ruby on Rails Guide would be a great place to start, but there's plenty more.
I always have a rails console session or at minimum an irb session to play with to see if things do what I think they do.
I also use RubyMine which has an excellent integrated debugger http://www.jetbrains.com/ruby/
Beside pry gem, another option would be byebug. This gem enables you to temporarily stop code execution at a breakpoint, which is marked with keyword byebug inside the code. When execution reaches the breakpoint, a marker will be pointing to the current line, and you are able to type in commands.
This Gem offers a huge set of commands, the most commonly used ones are:
next - this command enables you to go to next line
step - goes into each invoked method step by step
break - it stops the execution of code
continue - continues code execution
This is a great article to check for debugging in rails.
I have an object call that is basically initiating a singleton that is needed all over my application. I thought the best place to put this was the environment.rb file, right after the Application.initialize! call. And it had worked with all my tests. But now that I'm running my code in the development environment, I'm finding that it is not getting called. Is there somewhere else I should be putting it, or is there something wrong with my development environment setup?
EDIT: I haven't looked at the answers yet, but I did find out that it's not working in development when I have the config.cache_classes set to false.
Try putting it in an initializer file.
See this link for configuring rails.
Basically, I do use config files written in yml and load these with an initializer.
If you don't want to go into details, use Ryan Bate's gem: nifty-generators
and type in console:
rails g nifty:config
It will install everything for you. Then edit your config/app_config.yml file.
When I run rails c and press the up key when irb starts up, I can see the last commands I entered when my app dropped to irb after encountering a debugger command for the ruby-debug gem. I would not only like to clear these commands out, but I would like it if rails c would pull the last commands I issued during my last rails console session. I think it used to do this but I'm not sure what has changed. I'm on ruby 1.8.7 and rails 3.0.3 on Mac OS 10.6.5 if that helps.
Update
Ray's answer helped me out in the interim. Recently I did a bit more digging to find out more and realized that there are a number of conflicting issues.
IRB checks if you have a ~/.irbrc and if not falls back to /etc/irbrc as Ray mentioned. However, if you are using rvm there is another file to consider ~/.rvm/scripts/irbrc which just loads up ~/.rvm/scripts/irbrc.rb (note the .rb) if you have rvm_path set in your ENV (you should if using rvm).
Interestingly while ~/.rvm/scripts/irbrc.rb was based off of /etc/irbrc they are not the same and differ in a few ways. The most obvious way and easiest way to detect which one is being used on your system is their history file's name. If /etc/irbrc is being used your history file will be ~/.irb_history where as rvm's is ~/.irb-history (Note: _ vs -).
Hopefully this additional information will help you determine what you need to setup your system as you would like.
Pry Concerns
I've since stopped using debugger and have moved to pry-byebug which includes the pry gem. Pry is an alternative to IRB but can also be used along side and within it. The reason I was able to provide the above update is because I was trying to figure out how to keep their respective histories separate. For more information please see my answer to the SO question on "why does pry history keep cloberring irb history?". I've included links there to the known Github issue for Pry as well as my attempt to fix it.
I interpret you question as asking how to turn history on in the Rails Console and off in the Ruby debugger. If this isn't true, please clarify.
IRB, and by extension, the Rails Console, read from ~/.irbrc, or if that doesn't exist, /etc/irbrc, to startup and configure irb. Your history is typically written to ~/.irb_history, but that is dictated by the contents of your irbrc file. The /etc/irbrc on my Mac OS X is set up to write the history from irb, so perhaps you've created a local .irbrc that doesn't have history, or perhaps you have a syntax error in that file.
The debugger reads a file called .rdebugrc on startup. You can turn off history in debug by adding this line to ~/.rdebugrc:
set history save off
Turn it back on with:
set history save on
You could also set your debug output to go to a different file than irb reads from with the command:
set history filename
These also work from the debug prompt, but aren't persistent.
There are a number of tools to help improve the irb experience. Bond and hirb are promising.
Here is Comprehensive list of Irb Tools and some tips on directly editing the .irbrc file.
Hope this help!
Although a very old question I got here by google.
Turns out RVM slightly changed over time.
Currently my IRB history (using rvm) is stored here:
user#host:~$ ls ~/.rvm/rubies/ruby-2.4.2/.irbrc*
/home/user/.rvm/rubies/ruby-2.4.2/.irbrc
/home/user/.rvm/rubies/ruby-2.4.2/.irbrc_history
I'm running Rails 2.2.2. I've read a few articles about ruby-prof and profiling a rails app. And I'm confused as to how things are really working.
I was originally using this tutorial
http://snippets.aktagon.com/snippets/255-How-to-profile-your-Rails-and-Ruby-applications-with-ruby-prof
to profile my app, and it works. This involves writing your own profile environment and running > RAILS_ENV=profiling ./script/performance/request -n 100 profiling/homepage.rb
So here's my confusion. Somehow, this runs ruby-prof and opens up all the stats etc, but I can't see anywhere where ruby-prof is ever actually called.
So then I read further, and it seems 2.2.2 has benchmarking/profiling built in. So I write a test file in the performance section like so
require 'test_helper'
require 'performance_test_help'
# Profiling results for each test method are written to tmp/performance.
class BrowsingTest < ActionController::PerformanceTest
def test_worksheet
get '/reduction/worksheet'
end
end
and run
rake test:profile
Is this equivalent to what I was doing above, but just now it's integrated into the whole rails framework?
My next question is this. The original script ouput a flat file and html file, but I couldn't figure out how to also get a tree file automatically to open up with KCacheGrind, or in my case MacCallGrind. Can I add formats into my script call?
Edit: running the scripts through rake test seem to actually produce a tree file, great. Mac CallGrind however seems to hang when trying to parse it. Anyone know other tools for viewing these tree files?
Turns out, it's exactly the same, I must have been reading an old tutorial. All the benchmarking and profiling is now in Rails which is awesome. And it outputs txt,html and tree files, also awesome. Now if Only MacCallGrind would work, there's no way I'm installing the 4gb of KDE packages needed just to view a tree file.
Brad, you should contact the author of MacCallGrind and see if there's an update, or whether he/she has a fix for your files.
Oh that's right, that's me. Please email at richard at symbol aggmedia.net, as there is an update about to come out, and I'd love to have Ruby/Rails support available.