I tried to update the Ruby version of a Sinatra website I am working on to 2.1.3. When I tried to bundle I had some errors. Then I removed the Gemfile.lock and bundle install proceeded. But when I ran the website I noticed some thing like
NoMethodError at /auth/login
undefined method `join' for #<String:0x000000062d3830>
My observations are as below.
Downgraded to Ruby 2.1.2 - problem preserved
Checked out the project as it was before (Ruby 2.1.2 with the old Gemfile.lock) worked
The error showed up with a yield_content(:head) tag.
Removed all yield_content tags
Error showed up rendering the slim file for the page - slim :index, :layout => :layout, :locals => body_locals
What could be the error? I created a diff off the state of the Gemfile.lock before and after: https://gist.github.com/ziyan-junaideen/fb903abbdafdc2d4a02f
Error output from the terminal: https://gist.github.com/ziyan-junaideen/54bff4f05a5a7beeedff
I thought it was some SLIM error and downgraded Slim to 2.0.3 which used to be before the bundle install, but had no luck.
Any suggestion is highly appreciated.
Thanks
I have solved it by reinstalling slim and temple in versions slim: 2.0.3 and temple: 0.6.8,
it's probably in temple, 'cos downgrading slim is not enough
I've got this error as well.
After some research I've found that it is happening because 'output buffer' for template rendering is an instance variable (its default name is #_out_buf), thus it is overwritten when each (sub)template rendering completes (because partials are being rendered in the same scope as main template)
There are a few ways to fix this without downgrading sinatra/slim/temple:
Make default outvar value equals to _out_buf (local variable) # lib/sinatra/base.rb#L814
Pass an outvar option to slim method like this: == slim :sub_template, outvar: '_out_buf'
I've also opened an issue at sinatra's repo at github: https://github.com/sinatra/sinatra/issues/939 (let's see what authors will say about this)
Related
Environment
Rails 3.2.11
Ruby 1.9.1
utf8-cleaner gem
I am struggling with this issue for over a year now, and I am not able to reproduce it on my dev environment, which makes it rather difficult for me to understand why this is happening and how I can resolve. Here is the error notification I am getting (via email using ExceptionNotifier):
A ArgumentError occurred in home#index:
invalid byte sequence in UTF-8
.bundle/gems/ruby/1.9.1/gems/rack-1.4.5/lib/rack/utils.rb:104:in `normalize_params'
Apparently caused by Chinese spider:
HTTP_USER_AGENT : Mozilla/5.0 (compatible; EasouSpider; +http://www.easou.com/search/spider.html)
I have tried to a couple things, see my earlier question where I was attempting to catch the error.
I have also installer utf8-cleaner gem but that doesn't seem to resolve, unless I missed a step.
How can I reproduce the issue? Note the URL causing the problem is perfectly correct when I access it (?)
UPDATE 20140721 - use rack-utf8_sanitizer
Add gem 'rack-utf8_sanitizer' in Gemfile
Add config.middleware.insert 0, Rack::UTF8Sanitizer in application.rb
$ bundle install
That worked perfectly on DEV but FAILED on my Heroku PRODUCTION, with the following issue:
$ heroku run rake middleware --a test-app
Running `rake middleware` attached to terminal... up, run.4846
WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.7.6
rake aborted!
uninitialized constant Rack::UTF8Sanitizer
/app/config/application.rb:71:in `<class:Application>'
I am still investigating why I should be getting this.
I managed to fix it (on a Rails 3.2.18 app) as described in this gist:
https://gist.github.com/joost/ca4eda8f31655cf6095a
Reproduce the issue caused by
HTTP_USER_AGENT : Mozilla/5.0 (compatible; EasouSpider; +http://www.easou.com/search/spider.html)
Create a ruby script
#!ruby
invalid = "data\xed\xe5\xed\xe0".force_encoding('ASCII-8BIT')
`curl localhost:3000 -d #{invalid}`
Add the rack-utf8_sanitizer gem to your Gemfile
This resolved for my Dev environment, but wouldn't work on Heroku. I updated my question accordingly.
UPDATE:
I added require "rack/utf8_sanitizer" in my application.rb file and that seems to resolve, the Heroku issue.
I'm making a basic Sinatra app to play around with the Passbook gem.
My app runs fine on localhost, but when I try and run it on Heroku I get this error message:
/app/vendor/bundle/ruby/2.0.0/gems/passbook-0.2.1/lib/passbook/pkpass.rb:122:in `outputZip'
/app/vendor/bundle/ruby/2.0.0/gems/passbook-0.2.1/lib/passbook/pkpass.rb:60:in `stream'
/app/vendor/bundle/ruby/2.0.0/gems/sinatra-1.4.4/lib/sinatra/base.rb:1593:in `call'
NoMethodError - undefined method `write_buffer' for Zip::ZipOutputStream:Class:
This happens when I call the line passbook.stream.string in my app file.
I don't think Passbook is the problem here - it seems that the class method write_buffer exists in the version of Zip::ZipOutputStream on my local machine but isn't there on Heroku. Why is this? How can I get around it?
I've tried including both zip and rubyzip in my Gemfile, individually and at the same time, and neither of them solve the issue.
Whenever I see something like this, I always ask myself Do you have Dev/Prod parity?.
So:
What Ruby version do you use locally, and does it differ from what you're using on Heroku?
Do you specify a Ruby version in your Gemfile?
How do you run locally? Do you use bundle exec to ensure you run in the same way, with the same gems?
Finally figured it out.
When I ran ruby app.rb, things worked locally, but when I ran bundle exec ruby app.rb, I got the same error as I did on heroku.
I upgraded to the latest version of passbook (which was just updated today to handle the latest changes to rubyzip), but things still didn't work.
Turns out I needed to remove gem 'zip' from my Gemfile and just include gem 'rubyzip' - previously I had both.
I've set up Globalize2 on a rails app however I'm getting the following error when I put translates on the model:
undefined method `translates' for
Is anyone else getting this error? It's on rails 3 by the way.
You will have to use globalize3 if you run rails3.
You can download it from https://github.com/svenfuchs/globalize3 or by adding
gem "globalize3"
to you Gemfile and running bundle install.
I'm quite new to Ruby language (up to now I developed in Groovy + Grails) but since I was curious about it I wanted to try Sinatra on Ruby 1.9.2-p0.
I have a trivial website that is contained in /mywebpage and has 2 files:
# blog.rb
get '/' do
'Hello World!'
end
get '/impossible' do
haml :index
end
and
#config.ru
path = File.expand_path "../", __FILE__
$LOAD_PATH << (File.expand_path ".") + "/views"
require 'haml'
require 'sinatra'
require "#{path}/blog"
run Sinatra::Application
then in the same folder I have a /views/ folder that contains index.haml.
I try to run the server with rackup -p8080 but when I try to get /impossible I receive the following error:
Errno::ENOENT at /impossible
No such file or directory - /home/jack/mywebpage/<internal:lib/rubygems/views/index.haml
By searching over internet it seems that this maybe caused by "." not being included in $LOAD_PATH so I tried to add it or add directly views ./views so that actually $LOAD_PATH.inspect gives me correct path: ..., "/home/jack/mywebpage/views"]
But still it doesn't seem to work. Being quite new to the framework and the language I was wondering if I'm doing something wrong. any clues?
Running Sinatra with Ruby 1.9.2 the template directory is no longer implicitly 'views', you need to set it yourself.
set :views, File.dirname(__FILE__) + "/views"
Note that currently Ruby also has Kernel#__dir__() method that is equivalent to File.dirname(__FILE__).
This, and other issues with 1.9, will be have been solved in Sinatra 1.1. You could use this fork: http://github.com/rkh/sinatra/tree/1.1
I ran into a similar problem, and solved it like this. I didn't dig into the problem, but this is what I found and it works. It'll supposedly be fixed in the next version of Sinatra (which they should really get out the door, just to fix these few 1.9.2 bugs).
#!/usr/bin/env ruby
require 'rubygems'
require 'sinatra'
enable :run
get '/' do
"Hello, world!"
end
Edit: It seems there are multiple bugs with Sinatra on 1.9.2. This one will fix Sinatra apps not starting on 1.9.2. I don't use a views directory (I like to keep my apps single-file), so I didn't run into your particular problem. This fix most likely won't help you at all. I probably should have read your problem more closely..
gem install sinatra --pre
I ran into that last week and didn't find a suitable fix on the Sinatra site short of tweaking the sinatra code. I'm using rvm for my development and switched to try sinatra on Ruby 1.8.7 and it works fine again, so that's where I left it.
Oh, since you're new to Ruby, you might not know about rvm, so here's the lowdown. RVM is Mac only and highly recommended for managing your Ruby version and gems. It makes it trivial to have multiple Ruby versions and alternate groups of gems for development and testing. Everything is stored in your ~/.rvm directory so it's easy to blow it all away if you need to.
http://rvm.beginrescueend.com/
I just looked at the Sinatra site again about the problem to see if there was anything new, but it appears they consider the following to be an acceptable fix:
http://github.com/sinatra/sinatra/issues/#issue/50
I'm a bit adverse to having to edit the source of Sinatra as recommended by issue #50, but it's not real hard to do. I'd like to see them put out an update so we'd have an official fix but I haven't seen anything yet:
gem env will tell you the "GEM PATHS". Sinatra's gem will be in one of those. The line mentioned in issue #50 goes into base.rb. On my machine it's something like ...gems/ruby-1.9.2-p0/gems/sinatra-1.0/lib/sinatra/base.rb.
Insert:
/<internal:/, # ruby 1.9.2-p0 hacks
at line 1020.
Save the file and you should be good to go.
Here's the stack: Sproutcore 1.0.1046. Ruby 1.9.1, in RVM. Thin 1.2.7. Thor 0.13.8. Rack 1.2.1. Eventmachine 0.12.10. Erubis 2.6.6.
When I start the sc-server on any application, my first request to this server produces this in the console log:
ArgumentError: invalid byte sequence in US-ASCII
...followed by this stack trace. (I've listed gems which appear in the stack trace above, but there's a complete gemset list in the same gist as the stack trace.)
Research on the error message points out that this is a common problem with Ruby 1.9, but the stack trace suggests that the problem is in one of the gems somewhere.
I have:
Upgraded my OS (Mac OS X 10.5 to 10.6) in order to get the latest gcc Apple provides.
Reinstalled RVM.
Reinstalled Ruby.
Reinstalled all the relevant gems.
And yet I still have this problem on one system, but not on another. (N.B. there are several devs working on this code, and I'm the only one seeing this problem. I'm 99% certain it's not our code.) I guess what I'm saying is that I've cleared and rebuilt a lot of gems to try to isolate or remove this glitch, and yet I still haven't gotten rid of it.
Where should I look next?
You have some special setting in your bash environment that is setting ruby to use US-ASCII , this happened to me trying to execute sc-server from a remote terminal... I'm not really sure what it is, but it doesn't use UTF-8 and that's when it runs into trouble.
You can probably also change Encoding.default_external
Thanks so much for the Encoding.default_external suggestion. I was having the same problem, despite correctly set magic comments and environment variables. In Rails 2.3.9 I added this before_filter in application_controller.rb, resolved the issue:
def set_encoding
Encoding.default_external = 'UTF-8'
end
I had the same issue with RSS Feeds that I was displaying in a Rails 2.3.8 app with Ruby 1.9.2. My issue wasn't solved by the application_controller.rb before_filter technique mentioned here. The fix was to put the following into "RAILS_ROOT/config/initializers/string_encodings.rb":
Encoding.default_external = 'UTF-8'
That worked for me site-wide, instead of on a controller level.
In my case the ArgumentError occurred during a Capistrano deploy call that envolves ruby's net-ssh (ruby 1.9.2p290, net-ssh 2.3.0). None of the solutions afore mentioned worked and none of the other reasons I've read about so far: i.e. "strange character in key file", etc..
Finally, I found a none ASCII-character in a comment(!) line in my ASCII encoded ~/.ssh/config file. BINGO!