This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Rails 3.0 & Ruby 1.9.2rc: Rake commands return 'already initialized constant' & stack level too deep errors. Any ideas
Am using Ruby version 1.9.1 on windows vista. Am getting the rake aborted error for any rake commands am using. This does not happen in all my app folder. Its happening only on a specific app folder.
C:\rails_project\stunetwork>rake db:reset
(in C:/rails_project/stunetwork)
rake aborted!
stack level too deep
C:/Ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rak
efile'
(See full trace by running task with --trace)
try placing bundle exec in front of the rake command.
bundle exec rake -T
You need to update your gem.
I met this error with gem '1.8.10', and fixed by upgrading to 1.8.16
gem update --system
I only had this problem with ruby-1.9.2-p180 via rvm.
Switching to ruby-1.9.2-p0 fixed the problem.
try "rvm use 1.9.2-p0"
The stack of the calls can depend on the gems you install (some gems monkeypatch the rails tasks) which explains why you would encounter this on a specific app and not on others.
On a unix system you could try using the ulimit command to increase your stack size. On the windows side I haven't found a solution yet.
Depending on which release of ruby you use on windows you may want to ask the maintainers how to increase the stack.
For ruby installer you will need to install the mingw compile environment, clone the github repository and recompile the ruby you use (not very sexy I admit).
I just encountered this exact error message on Ubuntu, and was able to solve it by downgrading rubygems from 1.8.3 to 1.7.1.
There is nice post by Yehuda Katz that explains why without bundle exec there can be version conflicts:
http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/
There is also bundle install --binstubs command that allows to version-safely run rake db:reset like this: bin/rake db:reset.
Related
I am patching a script, and want to run code from a repo I manage that has patches.
The gem in question is not installed through a published gem but through a github link
When requiring any gem that is normally installed. The script works. But requiring any gem that is installed through a github link fails. Any suggestions?
If I understand the problem correctly, there are a few solutions:
Clone the gem that's only available via the github link, build the gem locally, install it. You should be able to require it
You might be able to manage the project with bundler and a Gemfile. Instructions here for the syntax. Bundler basically does what I suggested above, for you. I don't think gem can install a gem from a remote natively?
Would love to see some more clarification, and if you're using a Gemfile the relevant snippets
So the issue was I was running the script in question using ./bin/path/script
This will not work if the script includes github referenced gems, you need to prefix this with bundle exec which is not immediately obvious, given that when you use non-github referenced gems, it works fine without it.
Now running bundle exec ./bin/path/script will work for both, it's probably just better using that wherever possible.
While trying to install Capistrano, I got an error message that rake was not available. since rake is included with ruby, what do I need to do?
Loading files require extra working memory. Cutting off some features and loading them only when necessary with explicit load command will save memory.
Simple mistake, but I will post the answer in case anyone else has had the same frustration - the version of Ruby I was using, 1.9.3, has a 9.x version of Rake bundled with the Ruby installation; Capistrano 3 requires a 10.x version. I installed Rake 10.4.2; problem solved.
Note: If you install a 2.1.x or later version of Ruby, you will automatically get a 10.x version of Rake.
I am currently having a strange issue with bundler and ruby.
if I type:
$ which ruby
I get:
/home/martinos/.rubies/1.8.7-p370/bin/ruby
And when I type:
$ which bundle
I get
/home/martinos/.gem/ruby/1.8.7/bin/bundle
But for some reason when I run
$ bundle exec rake db:migrate
The task is run with ruby 1.9.3 (I have written a puts RUBY_VERSION in environment.rb)
Any one as an idea why this happens?
Here is more infos:
When I type:
$ which rake
I get:
/home/martinos/.gem/ruby/1.8.7/bin/rake
But if I
$ head -1 `which rake`
I get:
#!/usr/bin/env ruby1.9.1
There are a variety of pieces that could be in play. The first is that it could be a conflict between your Ruby version management tools and your global gems. Meaning, I suppose it is possible that you only have a Rake version that can work on Ruby 1.9.1 that is in your global set. So when you fire up Rake it is forced to run in Ruby 1.9.1.
What you may want to do is create a directory specific gemset. If you're using RVM you can see the documentation on how to do that by looking at their Gemset documentation. Once that is in place with the Ruby version you want to test with, then do a gem install of Rake at the version that will work with that Ruby version. At that point you should find that the Ruby version being used to run Rake in that directory will be the same as the version you have running.
I apologize if this does not answer your question, or if you have thought of this approach already. Trying to wrap my head around this without the ability to reproduce the problem is a tricky deal.
I've been working on this issue for quite some time now and I did not come up with an solution so far. I have installed redmine via a bitnami stack. I set up git via gitosis as well, and now I'm trying to install the gitosis plugin for redmine. But when I try to activate the plugin with "rake redmine:plugins:migrate RAILS_ENV=production" I get the following error:
rake aborted!
No such file to load -- lockfile
Tasks: TOP => db:migrate_plugins => redmine:plugins:migrate => environment
(See full trace by running task with --trace)
I ran the command with the use_redmine script. I already installed lockfile via "gem install lockfile". bundle check returns that all dependencies are satisfied, but I still can't get this thing to work.
After reading some similar questions here, I guess it could have something to do with the passenger module.
I figured it out now. Sorry, I forgot about my post here.
The solution was kinda dumb. I did install the required packages, but I did not include them in my Gemfile.
Developing Rails and even installing Rails Applications can be a real pain in the butt -.-
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Rails 3.1 and Ruby 1.9.3p125: ruby-debug19 still crashes with “Symbol not found: _ruby_threadptr_data_type”
I run this:
gem install ruby-debug19
And in my cucumber env.rb file, I have this:
require 'ruby-debug'
When I try to run, though, I get this exception:
/home/skendall/.rvm/gems/ruby-1.9.3-p0/gems/ruby-debug-base19-0.11.25/lib/ruby_debug.so: undefined symbol: ruby_current_thread - /home/skendall/.rvm/gems/ruby-1.9.3-p0/gems/ruby-debug-base19-0.11.25/lib/ruby_debug.so (LoadError)
What do I need to do to get ruby-debug to work with 1.9.3-p0?
UPDATE: ruby-debug19 is not maintained anymore. This question and my answer have become irrelevant, it's far easier to use the 'debugger' gem instead.
See Debugging in ruby 1.9
I also ran into this, and found the solution in Ruby 1.9.3 and ruby-debug. You need to install not-yet-officially-released versions of ruby-debug-base19 and linecache19. The currently released versions indeed cause the exception you had.
Use this gist.
#To install ruby-debug on Ubuntu ruby-1.9.3 you need to download from http://rubyforge.org/frs/?group_id=8883
linecache19-0.5.13.gem
ruby_core_source-0.1.5.gem
ruby-debug19-0.11.6.gem
ruby-debug-base19-0.11.26.gem
#Then in your console
export RVM_SRC=/your/path/to/ruby-1.9.3
# Note, your source path should be something like /home/user/.rvm/src/ruby-1.9.3-p0
gem install archive-tar-minitar
gem install ruby_core_source-0.1.5.gem -- --with-ruby-include=/$RVM_SRC
gem install linecache19-0.5.13.gem -- --with-ruby-include=/$RVM_SRC
gem install ruby-debug-base19-0.11.26.gem -- --with-ruby-include=/$RVM_SRC
gem install ruby-debug19-0.11.6.gem -- --with-ruby-include=/$RVM_SRC
This is a known bug. There's reportedly some work arounds here, here and finally here.
If the workarounds are annoying and/or impossible due to your rvm/bundler setup, which is the case with me, consider pry, and optionally the pry-debug plugin. Pry might be a more generally useful tool than ruby-debug anyways.