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:
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):
On Sat, Feb 21, 2009 at 4:36 PM, Grzesiu <x...@poczta.onet.pl> 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
> 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:
> 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):
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
On Sun, Feb 22, 2009 at 5:15 AM, Grzesiu <x...@poczta.onet.pl> wrote:
> 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
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?
On Sun, Feb 22, 2009 at 6:24 AM, Conrad Taylor <conra...@gmail.com> wrote: > On Sun, Feb 22, 2009 at 5:15 AM, Grzesiu <x...@poczta.onet.pl> wrote:
>> 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
> 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
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.
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
David Nugent wrote: > On 23/02/2009, at 8:04 AM, Grzesiu 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.
On Sun, Feb 22, 2009 at 3:34 PM, Grzegorz Junka <x...@poczta.onet.pl> wrote:
> David Nugent wrote:
> > On 23/02/2009, at 8:04 AM, Grzesiu 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:
> 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".
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
On Mon, Feb 23, 2009 at 8:36 AM, Grzesiu <x...@poczta.onet.pl> wrote:
> 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.
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
On Tue, Feb 24, 2009 at 6:34 AM, Grzesiu <x...@poczta.onet.pl> wrote:
> 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.
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. -- Posted via http://www.ruby-forum.com/.
|
