The thing you're all missing by installing your own build is the
DTrace functionality included in the build in OSX.
Also Ruby doesn't change "that" much in 2 years. I don't see what the
problem is if I am honest.
···
On 10/27/07, John Wilger <johnwilger@gmail.com> wrote:
On Oct 26, 11:33 am, "Giles Bowkett" <gil...@gmail.com> wrote:
> the Ruby schedule is
> totally independent of the OS X schedule and co-ordinating the two in
> **any way at all** is illogical wasted effort.
<snip>
> we're going to have to manually update our Ruby installs just like we
> had to last time **anyway**, because Ruby will probably change again
> before OS X does. the "gem server" (not gem_server any more) example
> illustrates exactly that problem, because it's already happened - the
> new gems is in pre-release already
In terms of a ruby developer's workstation, I can agree with you. I've
been running the preview releases for a while now, and installing my
own build of Ruby in a different directory was one of the first things
I did.
However, there is a clear benefit to having some version of Ruby
installed by default as a system framework given that we can now
pretty easily use it to provide the guts of native Cocoa applications.
It's nice to be able to write such an app for general distribution
without having to worry about whether your end-user has Ruby installed
correctly (or at all) with the objective C bridge enabled.
boy you nailed that one on the head. They did it for them.
Truth is, anybody seriously doing development in Ruby outside of something OS X 10.5-centric will probably need to create their own install at some point.
If you're doing RubyCocoa, it might be good to go with the stock install, since it is easily and predictably deployable.
If you're doing Rails or something to be deployed on a different platform, you'll be better with a custom setup.
It's no big deal. We still have Hivelogic for reminders!
···
On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
On Oct 26, 2007, at 2:33 PM, Giles Bowkett wrote:
we're going to have to manually update our Ruby installs just like we
had to last time **anyway**, because Ruby will probably change again
before OS X does. the "gem server" (not gem_server any more) example
illustrates exactly that problem, because it's already happened - the
new gems is in pre-release already.
I really don't follow this line of reasoning. Rubygems itself is just a Ruby library and that Ruby library can be replaced/overridden.
If you look at the load paths that Apple set in leopard:
But Laurent moved that on OS X into /Library/Ruby/Site. So, if you install a later rubygems in /Library/Ruby/Site/1.8 then it will override the rubygems that is installed in the OS (and the 'gem' command will use the one you upgraded first)
Gems are the same way. If you gem install/update a gem it will go in /Library/Ruby/Gems/1.8 and higher version gems will always be the ones loaded.
What Apple did was provide a foundation that THEY can build upon (in the OS) and we can update ourselves. I think that is an awesome balance. They also built a bunch of native gems in that are a PITA to build yourself by hand.
Of course if you need within your Mac to always run the latest SVN build of Ruby just download that source and build it and install it wherever you want.
Realize they could have totally screwed this up by reordering the above load paths, but Laurent is a smart guy
The problem is for people working with Ruby for paying clients
everyday. When a security update comes out in two months, and my
production sites all start using it immediately, Leopard's version of
Ruby becomes useless to me. I want to run the version that my
clients are running in production, so I'll end up using macports again
anyways (assuming the port is kept up to date), or just installing
from source.
It seems like Apple could've just preinstalled Ruby via macports,
giving us integrated goodness _and_ the ability to upgrade for power
users. I realize macports as its flaws, but I've used it to bootstrap
3 or 4 machines over the past month with a full Ruby/Rails/mysql/etc
stack and it just works.
- Rob
···
On 10/27/07, Lee Packham <lpackham@gmail.com> wrote:
The thing you're all missing by installing your own build is the
DTrace functionality included in the build in OSX.
Also Ruby doesn't change "that" much in 2 years. I don't see what the
problem is if I am honest.
With a Ruby 1.9.1 release planned for Christmas using an all new virtual machine and having an m17n implementation, this might not be the best time to make such statements.
James Edward Gray II
···
On Oct 27, 2007, at 3:21 AM, Lee Packham wrote:
Also Ruby doesn't change "that" much in 2 years. I don't see what the
problem is if I am honest.
--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
* Advancing With Rails, Edison, NJ, November 6-9
* Advancing With Rails, Berlin, Germany, November 19-22
* Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!
That's because it originated on the mailing list side. The gateway then submitted it to our Usenet host and they declined it, so it never hit comp.lang.ruby.
James Edward Gray II
···
On Oct 27, 2007, at 3:31 PM, David A. Black wrote:
Hi --
On Sun, 28 Oct 2007, James Edward Gray II wrote:
On Oct 27, 2007, at 2:15 PM, Brian Adkins wrote:
On Oct 27, 2:21 pm, Bil Kleb <Bil.K...@NASA.gov> wrote:
John Joyce wrote:
On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
Realize they could have totally screwed this up by reordering the
above load paths, but Laurent is a smart guy
+1
(Haven't seen Rich's original show up in comp.lang.ruby yet.)
Me neither. Possibly an HTML post eaten by the gateway?
Are there any compelling reasons to use the built-in install? I was
just planning on using macports cause it works so well.
Pat
I am wondering the same thing.. I currently compile from source but would gladly switch to the built-in install if it is going to be kept up to date. Is Apple going to be maintaining it so it stays current with the latest version of ruby?
That's because it originated on the mailing list side. The gateway then submitted it to our Usenet host and they declined it, so it never hit comp.lang.ruby.
I'm sure this has been asked before, so apologies for what is
almost surely a repeat question, but ...
Would it be reasonable to just convert all messages to text-only
before submitting them to the Usenet host?
Another mailing list I'm on works that way, and it seems pretty
reasonable. If it modifies a message, it just appends a note,
like "non-text attachments stripped" or such.
Essentially, I'm wondering if the situation is,
- yes we could convert messages if someone volunteers code to do so
- no we shouldn't convert messages because of (some issue)
Thanks,
Bill
···
From: "James Edward Gray II" <james@grayproductions.net>
Are there any compelling reasons to use the built-in install? I was
just planning on using macports cause it works so well.
Pat
The question I haven't seen asked (or answered) is how would I switch
stock versions? I can't just pluck /usr/local/bin out of my PATH,
because there are other things installed there (ImageMagick, Subversion
[well, that's now system installed though], etc.) ?
Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
···
from my /usr/local version of Ruby & Rails (and gems) to the Leopard
--
Posted via http://www.ruby-forum.com/\.
Yes, I'm very curious about this point as well. It'll be terrific if they can bump it to 1.8.6p110 in an early bug fix patch. That's what I'm hoping we gain out of this framework setup.
James Edward Gray II
···
On Oct 27, 2007, at 5:11 PM, Ben Mabey wrote:
Is Apple going to be maintaining it so it stays current with the latest version of ruby?
Pat Maddox wrote:
> Are there any compelling reasons to use the built-in install? I was
> just planning on using macports cause it works so well.
>
> Pat
The question I haven't seen asked (or answered) is how would I switch
from my /usr/local version of Ruby & Rails (and gems) to the Leopard
stock versions? I can't just pluck /usr/local/bin out of my PATH,
because there are other things installed there (ImageMagick, Subversion
[well, that's now system installed though], etc.) ?
Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
you can append /usr/local to the end of your PATH instead. if /usr/bin
is before /usr/local/bin in your PATH ENV then /usr/bin/whatever will
be found/used first.
I'd consider cleaning up your source_cache as well, and removing ~/.ruby_inline.
Also there is an issue with the compiler flags set using RubyInline
that you will want to fix.
I wrote a sed script to do it. Very helpful if you need to fix it on
multiple machines.
That's because it originated on the mailing list side. The gateway then submitted it to our Usenet host and they declined it, so it never hit comp.lang.ruby.
I'm sure this has been asked before, so apologies for what is
almost surely a repeat question, but ...
It's been asked, yes. We went over it again recently. See the thread "Is there a standard pattern for threaded access to a file?" which we sort-of hijacked for a gateway discussion.
Would it be reasonable to just convert all messages to text-only
before submitting them to the Usenet host?
Mostly, yes.
Essentially, I'm wondering if the situation is,
- yes we could convert messages if someone volunteers code to do so
This is pretty much it. I made the gateway code public some time ago to support people hacking on it:
No one has stepped up yet.
To be fair, I think some are waiting on the TMail-based rewrite I've promised in the past. I've worked on it a bit, but just haven't finished it yet. I'll spend some time on it today and see how close I can get it…
The question I haven't seen asked (or answered) is how would I switch
from my /usr/local version of Ruby & Rails (and gems) to the Leopard
stock versions? I can't just pluck /usr/local/bin out of my PATH,
because there are other things installed there (ImageMagick, Subversion
[well, that's now system installed though], etc.) ?
Do I just delete/rename the applications? (ruby, irb, rake, svn*, etc)
If you want to keep using your locally installed commands from
/usr/local/*, but switch back and forth between you custom version of
ruby and the system-provided one, then I'd recommend installing it under
a custom prefix (i.e. not /usr/local), and add/remove that path from
your PATH. At least that's what I would try to do - or play around with
symlinks. However, the PATH method can be switched at will on a
per-process basis, while using symlinks would affect the whole system at
once.
We will provide updates, if the bugs they fix are important enough.
Security issues will also be fixed the soonest possible.
The version in Leopard is 1.8.6 p 36 + the security fixes that were
included in p110. p110 was unfortunately released a bit too late for
us.
Laurent
···
On 10/28/07, James Edward Gray II <james@grayproductions.net> wrote:
On Oct 27, 2007, at 5:11 PM, Ben Mabey wrote:
> Is Apple going to be maintaining it so it stays current with the
> latest version of ruby?
Yes, I'm very curious about this point as well. It'll be terrific if
they can bump it to 1.8.6p110 in an early bug fix patch. That's what
I'm hoping we gain out of this framework setup.
