[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Installing ROR with Darwin Ports

shane.pinnell@gmail.com

9/7/2006 3:19:00 AM

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!

Thanks in advance for any and all help.
12 Answers

James Herdman

9/7/2006 3:49:00 AM

0

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:
http://hivelogic.com/articles/2005/12/01/ruby_rails_lighttpd_m...

It's pretty straight forward. Make sure you read his article on why
you should compile/install in /usr/local (see
http://hivelogic.com/articles/2005/11/29/using...).

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.

Isak Hansen

9/7/2006 6:56:00 AM

0

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.

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:
http://www.nshb.net/install-ruby-and-rails-on...

I stopped after the postgres driver. Should perhaps have gotten that
from gems, but it seems to be working fine.


Afraid I can't say quite what your gems issue is, but google does have a
few interesting links on the first page:
<http://www.google.com/search?client=opera&rls=en&q=rubygems+no+such+file+to+load+--+sources&sourceid=opera&ie=utf-8&oe...


HTH,
Isak

Graham Wideman

9/7/2006 6:58:00 AM

0

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?

Graham


James Herdman

9/7/2006 1:00:00 PM

0

Yes. Use Ruby 1.8.4 for now if you're doing Rails development. See
http://eigenclass.org/hiki.rb?breakpoint+breakin... for details.

James H.

Graham Wideman 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?
>
> Graham

Austin Ziegler

9/7/2006 2:43:00 PM

0

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.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Mauricio Fernández

9/7/2006 3:11:00 PM

0

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.

http://eige.../hiki.rb?call_s...

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

--
Mauricio Fernandez - http://eige... - singular Ruby

Mauricio Fernández

9/10/2006 8:40:00 AM

0

On Fri, Sep 08, 2006 at 01:19:56PM +0900, James Herdman wrote:
>>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).

--
Mauricio Fernandez - http://eige... - singular Ruby

shane.pinnell@gmail.com

9/14/2006 2:11:00 AM

0

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:
> http://hivelogic.com/articles/2005/12/01/ruby_rails_lighttpd_m...
>
> It's pretty straight forward. Make sure you read his article on why
> you should compile/install in /usr/local (see
> http://hivelogic.com/articles/2005/11/29/using...).
>
> 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.

Isak Hansen

9/14/2006 7:38:00 AM

0


shane.pinnell@gmail.com wrote:
> 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




> 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:
> > http://hivelogic.com/articles/2005/12/01/ruby_rails_lighttpd_m...
> >
> > It's pretty straight forward. Make sure you read his article on why
> > you should compile/install in /usr/local (see
> > http://hivelogic.com/articles/2005/11/29/using...).
> >
> > 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.

SamFord

10/30/2011 7:09:00 PM

0

Hi I'm the media studies egg in question. The quote is absolutely
right, but what's lost here is the context I said it in. I was
speaking about it from the industry's perspective. The problem soap
operas are struggling with is that a.) Nielsen ratings don't account
at all for how passionate an audience is and b.) the industry has a
very narrow definition of the who "the only audience is that matters."
After all, the business of TV is that we the audience are a commodity
that's being sold to advertisers, and soap operas have been sold as a
way to attract 18-49 females. And soaps, as we've seen, are willing to
forget about the audiences they actually have in an unending effort to
find the audience they need more of, because they are the only ones
many advertisers want to pay for (Polydent ads aside...)

But let's tackle part "A" of that. Here's what we are seeing happen.
"Passions" is dropped for a fourth hour of "Today." "Guiding Light" is
canned for a game show. "As the World Turns" is taken off the air for
a talk show. AMC and OLTL are dropped for reality lifestyle
programming. And now these rumors swirling about GH for yet another
talk show. While Katie Couric might have a following to a degree, the
others are examples of shows that I'd argue almost no one would
actually get excited about. They are much cheaper to make, with
sometimes one or at most a handful of talents to pay, rather than a
whole cast of a daytime drama.

In reality, it seems crazy, because you have extremely passionate fans
of soap operas, and you're scrapping them for shows that no one's
going to feel that excited about. But it becomes lowest common
denominator programming. It's stuff people can have on the air in the
background. And Nielsen ratings don't pay any attention to the
difference between background noise and "must see TV." So a show with
a passionate following gets no advantage in the ratings. That points
to a major problem in the industry, but it's one they haven't figured
out how to tackle. Until television finds a way to focus on how
passionately people watch and not just what channel the TV is on,
genres like soap operas will be hurt, because they are more expensive
to make than a "food lifestyle programming" show.

Here's more to elaborate on just this point that I hope puts my
comment into more context for you all:
http://www.fastcompany.com/1771027/broadcast-networks-race-to-the-lcd-...

"There's no extra reward based on how passionate people are about a
show, especially when it might not be the right audience," says Sam
Ford, an academic and co-editor of the book The Survival of Soap
Opera.