First let me say that I just got a new MacBook Pro and am looking
forward to developing on it. Let me also say that this is my first Mac,
so please bear with the infantile questions!
I am trying to install RoR with Darwin Ports, this seemed like the best
option for someone like me. I am going through the process just fine,
but when I attempt to install the Rails gem via: "sudo gem install
rails", I get the following error:
opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- sources (LoadError)
I have installed rails via: "sudo port install rb-rails", but the
instructions I was trying to follow called for installing via the gem.
I have read a post that went in to length debating the virtues of
managing things with gems or with MacPorts, I don't really care which I
end up using, as long as it works! I am familiar with the "gem" method
coming from a Windows world, so I guess I would prefer that.
I also tried installing RoR with the Hivelogic tutorial for compiling
and all, but somewhere along the line I hosed it up (I think I was
running software updates concurrently with the ruby build/install
process) and I had to re-install OSX!
Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
breakpointer to work. You're going to use breakpointer a LOT in
developing in Rails.
Let me know if you get stuck. I'll try my best to help.
Don't go this route. It may seem easier, but you're cutting yourself
off at the knees on the learning experience.
Compiling and installing Ruby is NOT hard to do. In fact, it's so easy
that there are fantastic tutorials on how to do it.
If learning to install stuff from source is the goal, following a step-by-step recipe off the net may give some insight. Personally I'd rather just have stuff work, and spend my time on the real issues.
I have ruby, rubygems, postgres, vim and subversion installed from ports. Including dependencies that's 20+ packages, all installed with ~5 lines, and updated in 1. It seems rock solid (I'm new to macs as well - guess ~2 months).
These instructions worked for me:
I stopped after the postgres driver. Should perhaps have gotten that from gems, but it seems to be working fine.
Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
breakpointer to work. You're going to use breakpointer a LOT in
developing in Rails.
Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4?
Well, since I have started this process with Darwing ports, how would I
go about reversing what I have done? Simply delete the directory that I
installed it to and change the file telling my Mac where to look for
files?
I tried the Hivelogic method once before, my Mac froze, wouldn't
re-boot and I had to re-install MacOSX. That isn't too big of a deal,
but I would rather not go through that again!
Thanks for the tips, I will try the Hivelogic method, I do want to
learn how to do things that way anyways.
James H. wrote:
···
Don't go this route. It may seem easier, but you're cutting yourself
off at the knees on the learning experience.
Compiling and installing Ruby is NOT hard to do. In fact, it's so easy
that there are fantastic tutorials on how to do it. I highly recommend
this one as a fellow Mac user: Dan Benjamin
It's pretty straight forward. Make sure you read his article on why
you should compile/install in /usr/local (see Dan Benjamin).
Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
breakpointer to work. You're going to use breakpointer a LOT in
developing in Rails.
Let me know if you get stuck. I'll try my best to help.
> Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
> breakpointer to work. You're going to use breakpointer a LOT in
> developing in Rails.
Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4?
He's saying that breakpointer depended on a bug in Ruby 1.8. This bug
was fixed in Ruby 1.8.5. Breakpointer is being updated with a way to
work in Ruby 1.8.5, but it's not updated yet.
-austin
···
On 9/7/06, Graham Wideman <notarealaddress@nowhere.com> wrote:
James:
Could you please clarify this:
> Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
> breakpointer to work. You're going to use breakpointer a LOT in
> developing in Rails.
Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4?
Well, since I have started this process with Darwing ports, how would I
go about reversing what I have done? Simply delete the directory that I
installed it to and change the file telling my Mac where to look for
files?
If you installed the packages with port, you should probably use that
to remove them as well.
I think something like;
port uninstall -uc installed
should remove all installed ports. If that doesn't work, there's always
"man port", and a lot of other resources on the net.
HTH,
Isak
···
shane.pinnell@gmail.com wrote:
I tried the Hivelogic method once before, my Mac froze, wouldn't
re-boot and I had to re-install MacOSX. That isn't too big of a deal,
but I would rather not go through that again!
Thanks for the tips, I will try the Hivelogic method, I do want to
learn how to do things that way anyways.
James H. wrote:
> Don't go this route. It may seem easier, but you're cutting yourself
> off at the knees on the learning experience.
>
> Compiling and installing Ruby is NOT hard to do. In fact, it's so easy
> that there are fantastic tutorials on how to do it. I highly recommend
> this one as a fellow Mac user:
> Dan Benjamin
>
> It's pretty straight forward. Make sure you read his article on why
> you should compile/install in /usr/local (see
> Dan Benjamin).
>
> Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
> breakpointer to work. You're going to use breakpointer a LOT in
> developing in Rails.
>
> Let me know if you get stuck. I'll try my best to help.
>
> James H.
Once you've installed it, (either with the tarball or gem install call_stack
once the packages have propagated to the mirrors), you can proceed as usual,
the only difference being that you have to run the application being debugged
with
ruby -rbreakpoint185 script/server
instead of
ruby script/server
···
On Thu, Sep 07, 2006 at 11:42:40PM +0900, Austin Ziegler wrote:
On 9/7/06, Graham Wideman <notarealaddress@nowhere.com> wrote:
>James:
>Could you please clarify this:
>> Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was allowing
>> breakpointer to work. You're going to use breakpointer a LOT in
>> developing in Rails.
>Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4?
He's saying that breakpointer depended on a bug in Ruby 1.8. This bug
was fixed in Ruby 1.8.5. Breakpointer is being updated with a way to
work in Ruby 1.8.5, but it's not updated yet.
We're getting a little tangential to the original topic at hand, but is your
call_stack code expected to be integrated directly into Breakpointer so that
this modified calling isn't necessary in the future (i.e. we can eventually
have usage like 'ruby script/breakpointer' again)?
James H
···
On 9/7/06, Mauricio Fernandez <mfp@acm.org> wrote:
On Thu, Sep 07, 2006 at 11:42:40PM +0900, Austin Ziegler wrote:
> On 9/7/06, Graham Wideman <notarealaddress@nowhere.com> wrote:
> >James:
> >Could you please clarify this:
> >> Make sure you use Ruby 1.8.4. Ruby 1.8.5 fixed a bug that was
allowing
> >> breakpointer to work. You're going to use breakpointer a LOT in
> >> developing in Rails.
> >Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4
?
>
> He's saying that breakpointer depended on a bug in Ruby 1.8. This bug
> was fixed in Ruby 1.8.5. Breakpointer is being updated with a way to
> work in Ruby 1.8.5, but it's not updated yet.
I just released call_stack 0.1.0, which contains a workaround to use
breakpointer with Ruby 1.8.5.
Once you've installed it, (either with the tarball or gem install
call_stack
once the packages have propagated to the mirrors), you can proceed as
usual,
the only difference being that you have to run the application being
debugged
with
I just released call_stack 0.1.0, which contains a workaround to use
breakpointer with Ruby 1.8.5.
We're getting a little tangential to the original topic at hand, but is your
call_stack code expected to be integrated directly into Breakpointer so that
this modified calling isn't necessary in the future (i.e. we can eventually
have usage like 'ruby script/breakpointer' again)?
That part of the procedure (running breakpointer) remains the same:
old (no 1.8.5 love) | new (call_stack)
>
* add breakpoint() calls to | * add breakpoint() calls to
your code | your code
* run the breakpointer: | * run the breakpointer:
ruby script/breakpointer | ruby script/breakpointer
* run the application, e.g. | * run the application, e.g.
ruby script/server | ruby -rbreakpoint185 script/server
As you see, only the last point changes. As for whether we can get rid of
-rbreakpoint185 when running the server, that's not for me to decide really.
script/server could be modified to load it by default, but it must be kept in
mind that breakpoint185 introduces some overhead and will make the app run
slower. That doesn't matter when debugging, and nobody should be using
script/server in production, but I guess that adding an option to
script/server would probably be best, so you can do
ruby script/server -b (or --breakpoint).
···
On Fri, Sep 08, 2006 at 01:19:56PM +0900, James Herdman wrote: