Ruby 1.9.2 Released | Hacker News Reader

Ruby 1.9.2 Released

blade.nagaokaut.ac.jp

191 pointsmudgemeister68 comments

With 1.9.2 coming out, and Rails 3 too, the last pieces are in place for the Ruby community to move to Ruby1.9 for good.

The last year we had a lot of "choice" due to the transitional period we were in. Hopefully by the end of the year that will be history.

Hurray! :)

I finally made the leap and installed RVM and 1.9.1/1.9.2. It is done.

This seems... erm... stupid:

> == FAQ :The standard library is installed in /usr/local/lib/ruby/1.9.1 This version number is "library compatibility version". Ruby 1.9.2 is mostly compatible with the 1.9.2, so its library is installed in the directory.

This is insane. I have just had to explain 3 people on #ruby-lang why my error log has 1.9.1 in it if I am running purely 1.9.2.

This tangentially breaks the principle of least surprise. I can't see any good reason for doing this. This will result in unnecessary head aches during debugging for months to come.

That always confused me before, but at least I know it's intentional.

It's surprising (though not unwelcome) to see that the only distro at the highest level of support ('Supported') is Debian 5.0 (i.e. Lenny). Some irony here: Lenny currently has Ruby 1.8.7 and 1.9.0 (as a distinct package - 1.8.7 is the default Ruby); Squeeze (Debian 6.0) has 1.8.7-p299 as a Ruby default and 1.9.1 for the 1.9 branch. Since Squeeze just froze, it is unlikely to release with 1.9.2 - though they may make an exception. Point being: the only distro that enjoys the fullest level of support has no stable version with 1.9.2.

OSX, Windows, FreeBSD, Solaris and Symbian make the next level ('Best Effort'), and all other Linux distros only come in at the third level ('Perhaps').

I respect the developers' frankness, and it's not something I have to worry much about, but the names of the support levels don't scream "use me on a multi-billion dollar project" for corporate folks.

We use Debian for the CI machine. CI failures are taken quite seriously, and we have a person maintaining this CI box. I believe that is why Debian is considered highest.

The next level of OS support are core developers that use that OS for work / home, but we don't have CI machines.

I think if we had more CI boxes, then more platforms could join the "highest level" support. I know there was a conversation on the Japanese dev list about this, and I can try to dig it up if people are interested.

When you say "we," I presume you mean ruby-core?

I am on ruby-core. :-)

That's what I thought :-)

What are your CI boxes running? The Hudson team used to have a number of Hudson slaves running various OSs and distros just building Hudson on-demand.

That cluster drifted away, but there are a lot of Hudson servers out there that are mostly idle, and people seem generally happy to donate the CPU time. I've got an Ubuntu one here that could run Ruby slave builds.

akr maintains the CI machine. It is running Lenny.

You can see the output for the latest 1.9.2 build here:

http://www.rubyist.net/~akr/chkbuild/debian/ruby-1.9.2/last....

All of the latest builds can be accessed here:

http://www.rubyist.net/~akr/chkbuild/debian/

I would like to see more CI machines get deployed, but I think there are a couple challenges:

1) We use custom CI software (and the docs are in Japanese): http://github.com/yugui/chkbuild

2) We have no process for people donating CPU time

I can translate the docs, but that still doesn't overcome the burden of running custom CI software. I'll email ruby-core about #2 because I'd really like to see more CI machines go up.

What features does chkbuild offer that Hudson doesn't? Should I put a feature request in?

If there's some stumbling block to adoption, it seems that switching the single CI box to Hudson, then utilizing the numerous Hudson boxes out there as slaves is quicker than trying to get people on board with chkbuild.

That they support any distro is just icing on the cake. Usually these sort of projects don't support OS's at all, that's downstream's problem.

Now I'm wondering how you are taking "support" here. I didn't take it to mean "offer formal support for." That is, there's no phone number or email where someone will respond, is there?

When you say "these sort of projects", I assume you mean open source. When I look at Vim.org or Perl.org, they explain how to get source or binaries and install on various operating systems and distros. There's no differentiation in level of support or otherwise. This may be what you mean by "not supporting", but I found Ruby's explicit division of levels of support surprising.

Tenderlove's note explains things, but again I worry that the wording of the release notice may be off-putting to PHBs. Probably they are not Ruby's target audience - though I see plenty of discussion, books and conferences about Ruby for the Enterprise.

I don't mean to dwell on any of this in a bad way, and again I'm not complaining. I've never seen explicit divisions of support on something like Ruby before, so I posted.

No I mean support in the same sense you do. Their "supported" OS's are obviously just things they have access to, and know that it compiles & tests fine there.

E.g. they only have AIX 5 in "perhaps", that's only in the "Best Effort" category in Perl's case because a few dedicated individuals still build and test on it before release.

Found it! Here is the email describing the support levels:

  http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/41101

Thanks for the link. After reading that, I'm very suprised to see this for the 'Perhaps' category - given that every Linux distro other than Debian falls into that group:

    We think Ruby works on it, however, we do not care about it.
    I sometimes release Ruby even if there are issues on it.

The release part I get, but "we do not care about it" seems awfully dismissive. Maybe it came out differently than it was meant.

I suspect that part of what you are percieving as tone in these statements is an artifact of english not being the author's first language.

backports.org

Right, but somewhat beside the point. That is, assuming you have Debian (at whatever level) and want 1.9.2, there are lots of ways you might get it. Backports is always a good option for newer things, compiled for stable. (In the case of Ruby, I would probably go with rvm first, but that's neither here nor there.)

But the irony is that Ruby says "This is the distro that has our highest level of support." while simultaneously that distro does not (out of the box) support 1.9.2. Just an odd thing, and it struck me. Tenderlove's explanation is perfectly reasonable, and I'm not criticizing. It's just ironic.

This is the first version where conformance to RubySpec was made a high priority. It now passes over 99% of the spec. This is great news for the community because it makes it much easier for alternative ruby implementations to remain compatible.

It's already on rvm, http://rvm.beginrescueend.com

You may need to do this:

  rvm update --head && rvm reload && rvm install 1.9.2

Question: I just installed using:

rvm install 1.9.2-head

and it used: http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_9_2

And:

$ ruby -v ruby 1.9.2p0 (2010-08-18 revision 29034) [x86_64-darwin10.4.0]

So I am good to go, right?

I get this from `ruby -v` (having installed 1.9.2):

    ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]

So, the revision number is very slightly different. Hard to say in this case whether that is worth uninstalling the one and installing the other. Probably not, but hard to say exactly.

Thanks, I am going to re-install.

`--head` is not necessary since it's included in the latest release (0.1.46)

Fair enough (and thanks). I tend to run `--head` reflexively.

Thanks for that - you posted quicker than I could find the instructions on the documentation :D

With 1.9.2, the I18n internationalization module does not update available locales after loading more languages in the backend module. In my app we do this as a plug-in and since it can be done in run-time there may need to be some extra steps taken. I doubt this matters for 99% of the people here but just thought I'd give you a heads up if any of you move to 1.9.2 and use I18n dynamically.

..waits patiently for Heroku to support it ;)

An eagerly anticipated release. I'm really looking forward to utilizing the fibers associated with native kernel threads.

is it just coincidence that this release was on whyday? http://whyday.org/

Now everyone can actually move to Ruby 1.9!

This is really exciting.

Not until distros start shipping it. I don't know about Ubuntu because I don't really use it, but Fedora's still shipping with 1.8 and Fedora 14 will only be released in November.

At this point as a Rubyist the only thing you really need is rubygems (of any version) on your computer. gem install rvm and then rvm install RUBY_VERSION.

indeed. I stopped worrying about native system ruby version since moving to rvm. it is almost the only way to keep you sane while dealing with distros and ruby versions.

Thank God for RVM! I'm soooo happy not to have to deal with distro ruby versions anymore.

Ok, so maybe I should thank Wayne instead ;-)

What's the best way to get rubygems with no other ruby packages on my system? Package manager, or dl and compile it?

My package manager wants to install ruby, irb, and a couple other 1.9.1 packages with it that I'm not sure I'll want after using rvm to install the 1.9.2 versions.

Go with whatever your distro provides as a default. RVM completely segregates your RVM Rubies from your system Ruby, so you're far better off with a "common" system Ruby install than you are trying to hack together a stripped down Ruby install. The package maintainers already know the platform specific idiosyncrasies you'll need to work around, so might as well leverage that. You may also encounter other software that expects a certain system Ruby environment on your system, so there's that too.

Thanks! Will use both the distro default and RVM.

  bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

See http://rvm.beginrescueend.com/rvm/install/

Thanks!

People still use Ruby packages from their Linux distribution? I've always compiled, especially since Debian cripples RubyGems. Either that or I use ArchLinux, which uses the actual stable version of the software.

The most popular way (and easy, really) has always been to curl and compile yourself.

And these days RVM is growing up on production servers too, because it's really convenient if you have many apps each with the exact version it requires.

I would speculate that anyone doing any real work in Ruby doesn't wait on the distro to provide it. I don't do that with Perl, I compile my own. I would imagine Rubyists are the same way too. Anyway, kudos to the Ruby folks.

Off-topic, but have you tried Gugod's Perlbrew for handling multiple Perl interpreters? It's like rvm, but for Perl. I've been using it for a bit with great results.

http://github.com/gugod/App-perlbrew

When I tried it (earlier this year), it wasn't quite like RVM. RVM is very versatile, powerful and polished. Perlbrew is getting there, but seems good only for particular limited ranges of use. Things I got used to with RVM weren't ready yet in Perlbrew. Various Perl versions wouldn't compile for me successfully. You can also compare the Synopsis of Perlbrew with the range of rvm commands and switches to get a feel for how much is missing in Perlbrew. I really wish Perlbrew gave me a good out-of-the-box experience, because it would be very handy for me, but that wasn't the case.

I have heard of it. Haven't got any "tuits" to check it out at the moment. One of those "back of the brain" things though.

If it was any software but Ruby, I'd agree with you, but Rubyists tend to be into the cutting edge, as well as not using package managers to install Ruby. The conventional wisdom (at least for Ubuntu) has been "don't use apt, compile your own" for a while now. Or even better, use rvm.

Why didn't people move with 1.9.1 ?

Ruby 1.9.1 was never considered stable by many Rubyists. (Find '1.9.1' in this Yehuda Katz interview: http://www.drdobbs.com/blog/archives/2010/06/preparing_for_r... ... which was just the first reference I found.)

Mr. Katz advised in multiple interviews/tweets (if I recall correctly) to wait for 1.9.2, and the community tends to listen. Rails 3 was tested against 1.9.2, not 1.9.1; this provided yet another reason to wait.

Pretty much agree completely.

To add a few more details, it wasn't until 1.9.1 was out that "normal" people really started to look at it. There were quite a few changes that took time to be properly absorbed by the community (e.g. Internationalisation, see James Edwards Gray's blog).

Most gems also only started then to consider 1.9.1 as one of their targets, but it took some time. And anyway Rails was moving even more slowly.

Personally I've been using 1.9.1 for about a year now, but I don't make a living out of Ruby (or Rails) so it's understandable that people who need more reliable support waited a bit.

I can't speak for _everybody_, but I'm waiting to upgrade all of my sites that use Rails until Ruby 1.9.2 and Rails 3 both came out. I don't want to do two large updates, I'd rather do them together, and Rails 3 didn't support Ruby 1.9.1.

Also, there's just general conservatism; Ruby 1.9 was originally Ruby 2.0, but got renamed to 1.9 for reasons I don't quite remember/understand. 1.8 -> 1.9 is a much larger transition than the scheme would imply, roughly equivalent to the Python 2.6 -> 3 change, and we've seen how well that's gone. As time progresses, more people switch over, and each new release makes people decide it's finally time to re-write their scripts.

I have been running 1.9.1 in production for months and used dozens of libraries. Most issues were easily fixed. The move isn't really that difficult.

It's not difficult... but people still complain.

I moved Shoes over to 1.9.1, I agree, it's not bad. Don't underestimate laziness.

same reason lots of companies are still stuck in java 5 land...

Java 5? Heh. Try all the apps still on 1.3 and 1.4.

So they fixed the encoding problems?

Define 'encoding problems'. ;)

JIT for some sweet Rails 3 love!

LOL, at first I thought you meant there was a new JIT compiler with 1.9.2 -- but you're right, this is good timing for those of us excited about Rails 3.

rvm update --head && rvm reload && rvm install 1.9.2 && rvm 1.9.2 --default

(sorry for the duplicate)

encodings, dl, sockets and time improvements - too good to be true! ^_^

cannot build working binary with clang sigsegv in ./miniruby on linux/x86_64 =(

I didnt have any luck compiling ruby trunk this morning with clang on Snow Leopard.

This may help: http://joneslee85.wordpress.com/2010/04/23/howto-compile-rub...

Reply on news.ycombinator.com