So, I have a small Ruby program, which is a simple "Hello World" - the code is below
require 'ray'
Ray.game 'Hello world!', :size => [800, 600] do
register { add_hook :quit, method(:exit!) }
scene :hello do
#text = text 'Hello, Ruby!', :angle => 30, :at => [100, 100], :size => 30
render { |win| win.draw #text }
end
scenes << :hello
end
and it worked just fine on my Win7-32 bit machine. However, when I took the exact same program to my Win7-64 bit machine, the Ruby interpreter spitted out the following message:
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': 127:
The specified procedure could not be found. - C:/Ruby193/lib/ruby/gems/1.9.1
/gems/ray-0.2.0/lib/ray_ext.so (LoadError)
From the error message, it seemed like the "ray_ext.so" was missing, but actually it was there:
Both PCs have the exact same version of Ruby (1.9.3), and exact same list of gems installed, yet how come the exact same program worked just fine on the 32-bit Win7 but failed on the 64-bit Win7?
I tried to re-install the gem (ray) again, as well as updating the gem list, but that didn't resolve the issue. From what I discovered from the web, it seemed that this was a "dll" linkage problem (correct me if I'm wrong), but I didn't know how to fix it (excuse me, I'm still a noob in Ruby), except to re-install the gem - which didn't work.
Is there anything else that I can try? Do you think that this is purely the gem's problem (which is not compatible with Win7-64 bit)?
Thank you for your help.
In short, use latest Ruby.
When I install Jekyll on my Windows 7 64bit, I got the same error (Yes, the version of Ruby is 1.9.3）. It didn't disappear until I change my Ruby to 2.0.0 (not 2.0.0-x64).
Although I don't understand Ruby at all, I hope this can solve your problem. Thank you.
I had the problem. I tried setting the right oracle bin path pointing to oci.dll, that didn't work. I copied over the oci.dll to ruby\bin directory and later it gave me another error. I had to copy orauts.dll and there you go...the application worked.
Hope that helps others.
Related
I have the following buildr buildfile segment:
require "buildr/protobuf"
....
define "protobuf-stuff" do
pbs = protoc(
Dir[_("pbsrc/some/pkg/*.proto")], {
:include => [_("pbsrc")],
})
comp = compile.from(pbs).with(PROTOBUF_LIB) # MARK
package :jar
end
Buildr is 1.4.4, installed with the Linux install script on two machnies.
Machine 1: Debian 32bit, ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
Machine 2: Ubuntu 64bit, ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
Machine 1 compiles everything file. Machine 2 fails on the MARK-ed place, with
Buildr aborted!
TypeError : can't convert Rake::FileTask into String
/usr/lib/ruby/gems/1.8/gems/buildr-1.4.4/lib/buildr/core/application.rb:414:in `raw_load_buildfile'
/usr/lib/ruby/gems/1.8/gems/buildr-1.4.4/lib/buildr/core/application.rb:218:in `load_buildfile'
/usr/lib/ruby/gems/1.8/gems/buildr-1.4.4/lib/buildr/core/application.rb:213:in `load_buildfile'
Now I can see that pbs is a FileTask and not a string.. but how come one machine accepts it, the other not? Is there a forced conversion to String?
Some buildr traces are attached at http://pastebin.com/nf4HiYx9 .
Thank you.
The stacktrace on pastebin is very different from the stacktrace pasted here, from what I can see.
Where is the protoc method defined ? Is it part of Buildr core ?
The reason why it fails on one machine and not the other might be the version of Ruby you have, given that the line that fails is "if File.exist? path". path there is supposed to be a String, but is probably converted to a String in one case but not the other.
The overall fix is to add a call after calling protoc(...), protoc(...).map(&:to_s).
I hope this helped.
I figured that adding .to_s helps and everything is fine. But I could appreciate an answer telling where exactly the implicit conversion was lost, and why is it good (if so).
/from my earlier comment/
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!
So, I'm just trying out Ramaze for a new project, and I'm wondering why it won't work with Thin, but will with ramaze start (which is webrick I guess). Here's what it gives me:
/opt/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/request.rb:50: [BUG] unknown type 0x22 (0xc given)
This is the line it's talking about:
#parser = Thin::HttpParser.new
which isn't too helpful.
Does anyone have any ideas? Thanks!
EDIT: Actually, I remember getting this error a while back when I was trying to install the latest version of the MySQL gem. I had to reinstall it being sure to do a "make clean" before "make install". However, thin was installed from a gem, so I'm not sure how I would be able to do that here...
It means your eventmachine was compiled with Ruby 1.8 but runs with Ruby 1.9.
Do you have a parallel installation of 1.8/1.9?
A lot of questions have been asked about gem support in Shoes, but none have answered where to put them. I've got Shoes Raisins 1134 on Windows XP, and I've downloaded dbi-0.4.1.gem and am trying to get the following to work:
Shoes.setup do
gem 'dbi'
end
require 'dbi'
Shoes.app
...
end
When I run this, I get the dialog that says Installing dbi -- Looking for dbi which sits for hours not finding the gem file. I've tried putting it in all of the following places to no avail:
The folder that contains the above script
D:\Program Files\Common Files\Shoes\0.r1134\ruby\gems
D:\Program Files\Common Files\Shoes\0.r1134\ruby\gems\1.8\gems
Which is wrong -- the folder or the code?
EDIT - ANSWER:
Thanks to #Pesto for the answer. I had read the quoted text, but misunderstood it to reference where Shoes PUT the installed gem files, not where it GOT the gem source. In Windows XP, the reference translates to %USERPROFILE%\Application Data\Shoes, and the install worked perfectly. Now to start playing with it ...
The code looks fine. For example, this is just peachy:
Shoes.setup do
gem 'RedCloth'
end
require 'RedCloth'
Shoes.app do
para RedCloth.new('*awesome*').to_html
end
As to where the gems are installed, _why himself answers this:
By putting your gem list in the
Shoes.setup block, you’ll end up
encountering the Shoes popup seen
above if any of the gems happens to be
absent. Gems are installed in
~/.shoes, to avoid needing superuser
rights. (And just to keep Shoes away
from messing with your normal Ruby
stuff.)
Anytime you have trouble checking whether shoes is able to find the gem or not, You can see the gems available to shoes at ~/.shoes/+gem/gems