Strange error when running rails 2.3 on ruby 1.9.1 on FreeBSD

rubyonrails-talk
1

I am trying to run rails on FreeBSD 7.1. I've already installed Ruby 1.9.1 (from ports), apache, passenger (edge version from git), Rails 2.3 RC 1 (using gem --source like described on the weblog.rubyonrails.org). Everything installed smoothly and I am able to run ruby 1.9.1 programs. The problem is when I try to run rails. It fails with this error:

[grzesiu@cratan ~/.gem/ruby/1.9/gems]$ rails undefined method `camelize' for "app":String

I tried to run the bin/rails script manually using irb19, and this script at some points does "load 'rails'", which fails in this line:

Rails::Generator::Scripts::Generate.new.run(ARGV, :generator => 'app')

I didn't manage to track it down further. I would appreciate any help.

A bit about my configuration. I have both, ruby18 and ruby19 installed on my system, but I installed rails from gem19 (I haven't been using ruby18 and I don't even have gem for ruby18 installed, it's only here because portupgrade needs it). These gems were installed from root account:

fastthread-1.0.1.1 (patched version of fastthread-1.0.1) rack-0.9.1 rake-0.8.3

and these from the user account (to local .gem repository):

actionmailer-2.3.0 actionpack-2.3.0 activerecord-2.3.0 activeresource-2.3.0 activesupport-2.3.0 rails-2.3.0

Many thanks in advance if anyone can help with this.

2

Hi, you might want to take a look at my post in regards to installing ruby 1.9.1 and rails 2.3.0 RC1:

http://www.ruby-forum.com/topic/178659

Good luck,

-Conrad

3

I am trying on a fresh FreeBSD and I haven't had rails installed before. Also ruby19 has just been updated to 1.9.1 so I don't think reinstalling everything would make any difference. It is like a fresh install. And your steps worked on my system because I could install rails without problems. It is only that running rails is failing.

But I've just tried the edge version of rails, not the 2.3.0 RC1, and it worked! So it looks like there are some bugs in the RC1 version which have been fixed in the edge version. Thanks for your help. Greg

4

Hi Greg, why are you wanting to install ruby 1.9.1 and rails 2.3.0 RC1?

If this is for a production system, I would recommend using ruby 1.8.6

and rails 2.2.2. Next, how are you trying to run rails? Are you using

passenger/apache 2.2? Mongrel? Thin? What does the following

produce:

rails -v

ruby -v

gem -v

Finally, can you create a simply rails project using the following command?

rails <project_name>

-Conrad

5

If you correctly installed ruby 1.9.1, then

~/.gem/ruby/1.9/gems

isn’t the correct directory for ruby 1.9.1 gems. It should be

~/.gem/ruby/1.9.1/gems

Furthermore, if gem cannot install in the standard repository, then it would install

in the above local repository.

-Conrad

6

Hi Conrad, I am just starting my adventure with rails, so I am trying to start with the most recent versions of ruby and rails to not have to upgrade and struggle later, when it will be the time to deploy the app.

I am using passenger (as recommended on RoR site). In fact, I just discovered that passenger doesn't run very well on FreeBSD. Apache managed to serve the general rails index page, but when I clicked 'About your application’s environment' I got internal server error and the logs show something like: /root/src/passenger/lib/phusion_passenger/abstract_server.rb:125:in `fork': fork() function is unimplemented on this machine (NotImplementedError)

But anyway, at least I am able to generate the project in rails, which means that the rails version from subversion works fine. I used this command to generate the project: "ruby vendor/rails/railties/bin/ rails ." The RC1 version fails when running the bin/rails script.

rails -v: Rails 2.3.0 (this is the version installed by gem from sources). ruby19 vendor/rails/railties/bin/rails -v: Rails 2.0.2 (well, that's surprising!!!!! Did I get the version correctly? I issued the command: "svn co http://dev.rubyonrails.org/svn/rails/trunk vendor/rails". How version 2.0.2 could run on ruby1.9.1?) ruby -v: ruby 1.9.1p0 (2009-01-30 revision 21907) [amd64-freebsd7] (no surprise as I changed the /usr/local/bin/ruby file to be a link to ruby19) ruby18 -v: ruby 1.8.7 (2008-08-11 patchlevel 72) [amd64-freebsd7] ruby19 -v: ruby 1.9.1p0 (2009-01-30 revision 21907) [amd64-freebsd7] gem -v: 1.3.1 (I've created gem to be a link to gem19, I was not installing gem for ruby18)

No, whenever I run the gem version of rails it fails with the error as I provided in my email. The only command which seems to be working is rails -v.

I installed ruby 1.9.1 from ports. I don't think there is a way of configuring it. It was installed as 1.9. If it should be 1.9.1 then maybe something is wrong with the port?

Yes, gem installed rails in the local repository because I was installing as an unprivileged user. I didn't want to mess with rails on root. Thanks Greg

7

My suggestion, taken from many years experience as a developer under
FreeBSD: don't use bleeding edge versions when learning a new and
unfamiliar infrastructure, and don't run bleeding edge versions when
developing under a less popular and therefore lesser supported
operating system such as FreeBSD.

There are many caveats in using ruby 1.9 which contains a lot of
fundamental and subtle changes to the ruby language without
introducing an entire framework built originally for an earlier
version. While bleeding edge / beta / candidate release versions of
rails may cope with ruby 1.9, many if not most of the plugins you
might be interested in playing with under rails will not be. And
unless you want to reinvent many wheels, you WILL want to play with
rails plugins. You want to learn the language and framework in a sane,
well defined and tested environment, not in one that breaks easily.

So, start from scratch. Uninstall all current versions of rails and
ruby, go back to 1.8.6pl287 from ports and install the gems (including
rails 2.2.2) also from FreeBSD ports and not via gem directly. This
path avoids many of the problems you will otherwise hit, problems
which have already been solved by the ports maintainers. Those
problems are also easily solvable via google but it takes time, so
best avoided unless you are a developer already very familiar with
ruby, rails and FreeBSD and don't mind getting your hands dirty. Your
life will be far more productive in the short term and you will hit
few if any "strange errors".

Happy developing, /d

8

David Nugent wrote:

Hi Conrad, I am just starting my adventure with rails, so I am trying to start with the most recent versions of ruby and rails to not have to upgrade and struggle later, when it will be the time to deploy the app.

My suggestion, taken from many years experience as a developer under FreeBSD: don't use bleeding edge versions when learning a new and unfamiliar infrastructure, and don't run bleeding edge versions when developing under a less popular and therefore lesser supported operating system such as FreeBSD.

There are many caveats in using ruby 1.9 which contains a lot of fundamental and subtle changes to the ruby language without introducing an entire framework built originally for an earlier version. While bleeding edge / beta / candidate release versions of rails may cope with ruby 1.9, many if not most of the plugins you might be interested in playing with under rails will not be. And unless you want to reinvent many wheels, you WILL want to play with rails plugins. You want to learn the language and framework in a sane, well defined and tested environment, not in one that breaks easily.

So, start from scratch. Uninstall all current versions of rails and ruby, go back to 1.8.6pl287 from ports and install the gems (including rails 2.2.2) also from FreeBSD ports and not via gem directly. This path avoids many of the problems you will otherwise hit, problems which have already been solved by the ports maintainers. Those problems are also easily solvable via google but it takes time, so best avoided unless you are a developer already very familiar with ruby, rails and FreeBSD and don't mind getting your hands dirty. Your life will be far more productive in the short term and you will hit few if any "strange errors".

Happy developing, /d

Hi Conrad, I understand the risk with bleeding edge versions, but in this case the problem is with the first stable version of Ruby 1.9 series, not with the edge versions. As I wrote, almost everything is working fine, besides the not implemented fork in Ruby19 on FreeBSD. This looks serious and may force me to downgrade to to ruby 1.8.6 and rails 2.2.2 anyway.

I was going to give it a go and see how many problems I will encounter on the way. On the one side, solving these problems could help me becoming familiar with Ruby/Rails. On the other side, if I could fix some defects on Ruby 1.9 then I could contribute these fixes back to the development branch.

Lastly, even if I wanted I can't install rails from ports, because the port got stuck at version 1.2.6. The only way of getting rails 2.2.2 on FreeBSD is through gems.

As a last thought, I think that I will try to install both versions at once (ruby 1.8.6/rails 2.2.2 + ruby 1.9.1/rails edge). On FreeBSD these rubies sit in different folders and it should be pretty easy to not mess them together. Then I would be able to develop my code in older version and from time to time try if it works in newer version, making some fixes if necessary (i.e. using separated repositories and merging changes in-between). That could work only if the 'fork' problem is solvable.

Anyway, many thanks for your help. Regards Greg

9

David Nugent wrote:

Hi Conrad,

I am just starting my adventure with rails, so I am trying to start

with the most recent versions of ruby and rails to not have to upgrade

and struggle later, when it will be the time to deploy the app.

My suggestion, taken from many years experience as a developer under

FreeBSD: don’t use bleeding edge versions when learning a new and

unfamiliar infrastructure, and don’t run bleeding edge versions when

developing under a less popular and therefore lesser supported

operating system such as FreeBSD.

There are many caveats in using ruby 1.9 which contains a lot of

fundamental and subtle changes to the ruby language without

introducing an entire framework built originally for an earlier

version. While bleeding edge / beta / candidate release versions of

rails may cope with ruby 1.9, many if not most of the plugins you

might be interested in playing with under rails will not be. And

unless you want to reinvent many wheels, you WILL want to play with

rails plugins. You want to learn the language and framework in a sane,

well defined and tested environment, not in one that breaks easily.

So, start from scratch. Uninstall all current versions of rails and

ruby, go back to 1.8.6pl287 from ports and install the gems (including

rails 2.2.2) also from FreeBSD ports and not via gem directly. This

path avoids many of the problems you will otherwise hit, problems

which have already been solved by the ports maintainers. Those

problems are also easily solvable via google but it takes time, so

best avoided unless you are a developer already very familiar with

ruby, rails and FreeBSD and don’t mind getting your hands dirty. Your

life will be far more productive in the short term and you will hit

few if any “strange errors”.

Happy developing,

/d

Hi Conrad,

I understand the risk with bleeding edge versions, but in this case the

problem is with the first stable version of Ruby 1.9 series, not with

the edge versions. As I wrote, almost everything is working fine,

besides the not implemented fork in Ruby19 on FreeBSD. This looks

serious and may force me to downgrade to to ruby 1.8.6 and rails 2.2.2

anyway.

I was going to give it a go and see how many problems I will encounter

on the way. On the one side, solving these problems could help me

becoming familiar with Ruby/Rails. On the other side, if I could fix

some defects on Ruby 1.9 then I could contribute these fixes back to the

development branch.

Lastly, even if I wanted I can’t install rails from ports, because the

port got stuck at version 1.2.6. The only way of getting rails 2.2.2 on

FreeBSD is through gems.

As a last thought, I think that I will try to install both versions at

once (ruby 1.8.6/rails 2.2.2 + ruby 1.9.1/rails edge). On FreeBSD these

rubies sit in different folders and it should be pretty easy to not mess

them together. Then I would be able to develop my code in older version

and from time to time try if it works in newer version, making some

fixes if necessary (i.e. using separated repositories and merging

changes in-between). That could work only if the ‘fork’ problem is solvable.

Anyway, many thanks for your help.

Regards

Greg

Hi Greg, I think that you’re making something easy extremely complex. I had

a working system using rails 2.3.0 RC1 and ruby 1.9.1 up in last than an hour.

Next, you cannot create links the way that you’re doing and expect things to

work. Why? gem19 and gem18 refer to a different library path for their respective

gem repository. Furthermore, ruby 1.9.1 comes with a version of rubygems to

work with it. Also, ruby 1.9.1 and ruby 1.8.6 have their own versions of rake and

rack locations. I mention both rake and rack here because they were required

installs for rails 2.3.0 RC1 to install successfully.

Now, if you are wanting to work with multiple ruby installations, I would recommend

reading the following blog post:

http://www.dcmanges.com/blog/install-multiple-versions-of-ruby-on-osx-leopard?disqus_reply=6142353#comment-6142353

Good luck,

-Conrad

10

Hi Conrad, May I ask on which system you've got rails 2.3.0 RC1 and ruby 1.9.1 installed within an hour? I guess it was MacOS X?

I am not sure if what you write applies to FreeBSD. As I wrote I haven't installed any gems for Ruby18, so all execs such as rake, gem etc refer only to ruby19. Moreover, on FreeBSD all files relevant to Ruby18 and Ruby19 are being installed in different folders, for example:

system files: /usr/local/lib/ruby/1.9 /usr/local/lib/ruby/1.8

local files (nothing is installed for ruby18 in local repositories): /root/.gem/ruby/1.9 (under this folder are bin, cache, doc, gems, specifications) /home/grzesiu/.gem/ruby/1.9 (the same here)

I can run both version of ruby independently i.e. using irb18 and irb19 (irb was a copy of irb18). When I install rails, depending on which version of ruby I am using, it is being installed either to the folder within 1.8 or 1.9, and depending on whether I am using root or a normal user account, either system or local repositories are used. I don't know how is it on other systems but apparently the ruby port on FreeBSD was designed such that you can install both versions of ruby at the same time (there are some system libraries which depend specifically on ruby 1.8.6, so using ruby 1.9.1 would be impossible if it was not done). Even when I installed Passenger it automatically detected that and asked to add this line to httpd.conf:

PassengerRuby /usr/local/bin/ruby19

In my opinion the problem I am having has nothing to do with how I am installing Rails. The unimplemented fork in Ruby 1.9.1 port on FreeBSD suggests problems in the port itself, and that the problem wouldn't disappear if I installed the port differently. The problem is reproducible when I am using irb19 only, without even touching rails or gems.

I wonder what happens when you type this command in irb on your Mac OS X: @pid = fork

I've just checked it in irb18 and it works, which is clearly a proof of problems with the irb19 version only. Regards Greg

11

Hi Conrad,

May I ask on which system you’ve got rails 2.3.0 RC1 and ruby 1.9.1

installed within an hour? I guess it was MacOS X?

Hi, it was Mac OS X and there are some difference but it shouldn’t take

days to have a system up and running. Ruby on Rails is suppose to be

fun and you should be pass the installation process and having that fun.

At a minimum, you should be able to use ruby 1.8.6 and rails 2.2.2 or

ruby 1.8.6 and rails 2.3.0 RC1.

I am not sure if what you write applies to FreeBSD. As I wrote I

haven’t installed any gems for Ruby18, so all execs such as rake, gem

etc refer only to ruby19. Moreover, on FreeBSD all files relevant to

Ruby18 and Ruby19 are being installed in different folders, for

example:

system files:

/usr/local/lib/ruby/1.9

/usr/local/lib/ruby/1.8

local files (nothing is installed for ruby18 in local repositories):

/root/.gem/ruby/1.9 (under this folder are bin, cache, doc, gems,

specifications)

/home/grzesiu/.gem/ruby/1.9 (the same here)

I can run both version of ruby independently i.e. using irb18 and

irb19 (irb was a copy of irb18). When I install rails, depending on

which version of ruby I am using, it is being installed either to the

folder within 1.8 or 1.9, and depending on whether I am using root or

a normal user account, either system or local repositories are used. I

don’t know how is it on other systems but apparently the ruby port on

FreeBSD was designed such that you can install both versions of ruby

at the same time (there are some system libraries which depend

specifically on ruby 1.8.6, so using ruby 1.9.1 would be impossible if

it was not done). Even when I installed Passenger it automatically

detected that and asked to add this line to httpd.conf:

Yes, I can run ruby 1.8.7 and1.9.1 using the following:

1.8.7: thin, mongrel, and passengrer

1.9.1: thin, and passenger

PassengerRuby /usr/local/bin/ruby19

In my opinion the problem I am having has nothing to do with how I am

installing Rails. The unimplemented fork in Ruby 1.9.1 port on FreeBSD

suggests problems in the port itself, and that the problem wouldn’t

disappear if I installed the port differently. The problem is

reproducible when I am using irb19 only, without even touching rails

or gems.

I wonder what happens when you type this command in irb on your Mac OS

X:

@pid = fork

ruby 1.8: fork == Thread.fork == Thread.start

ruby 1.9: fork == Process.fork

Furthermore, it’s recommended that you pass a block in both 1.8 and 1.9 and it

may be a problem with your installation of rails if ruby isn’t correctly installed on

your system.

I’ve just checked it in irb18 and it works, which is clearly a proof

of problems with the irb19 version only.

This isn’t correct. This works in both 1.8.7 and 1.9.1. Again, there

may be problems with your installation.

Good luck,

-Conrad

12

Conrad, I am sure that the fork command works fine on Ruby 1.9.1. What I meant is that it doesn't work on FreeBSD port of Ruby 1.9.1, whereas it works on that port in version 1.8.7. Both versions were installed in the same way (from ports: make install distclean - next to impossible to make any mistakes). This suggest a problem in the FreeBSD port, not in Ruby 1.9.1 in general.

Another question, do you know if I should expect any problems when using Ruby 1.8.7 and Rails 2.2.2? These the latest versions I can install from ports and gems. Thanks Greg

13

Conrad,

I am sure that the fork command works fine on Ruby 1.9.1. What I meant

is that it doesn’t work on FreeBSD port of Ruby 1.9.1, whereas it

works on that port in version 1.8.7. Both versions were installed in

the same way (from ports: make install distclean - next to impossible

to make any mistakes). This suggest a problem in the FreeBSD port, not

in Ruby 1.9.1 in general.

Another question, do you know if I should expect any problems when

using Ruby 1.8.7 and Rails 2.2.2? These the latest versions I can

install from ports and gems.

Thanks

Greg

Hi Greg, you should be good to go with ruby 1.8.7 and rails 2.2.2.

Good luck,

-Conrad

Good luck,

-Conrad

14

If you really want to learn the latest features as a beginner (might not be a good idea just because the complications might leave a bad taste in your mouth when running with rails is generally a smooth process), then I'd suggest doing what I had to do - track edge. The problem you're having was fixed in edge (I had the same issue as you in FreeBSD and also Mac OS X before I bit the bullet and tracked edge).

I'm only tracking edge because I need features that are only in ruby 1.9.1 in my rails app. It probably won't be too long before 1.9.* and 2.3.* is stable, so I would recommend what the others did - play around with the stable stuff first. Edge has it's own issues. You can upgrade later when these new versions are stable.

15

Grzesiu wrote:

I am trying to run rails on FreeBSD 7.1. I've already installed Ruby 1.9.1 (from ports), apache, passenger (edge version from git), Rails 2.3 RC 1 (using gem --source like described on the weblog.rubyonrails.org). Everything installed smoothly and I am able to run ruby 1.9.1 programs. The problem is when I try to run rails. It fails with this error:

[grzesiu@cratan ~/.gem/ruby/1.9/gems]$ rails undefined method `camelize' for "app":String

Nearly one year later, I'm having the same problem!

16

people

please not use 1.9, with rails 2.3

thanks

Best Regards, dieinzige
17

dieinzige wrote:

people please not use 1.9, with rails 2.3 thanks

Well, everybody is talking about Passenger being patched to be compatible with Ruby1.9, and about Rails 2.3 patches for Ruby1.9 compatibility, and etc. So it's a bit a pity to be hold back to Ruby 1.8.7