Ruby 1.9.2 RC1 is released | Hacker News Reader

Ruby 1.9.2 RC1 is released

ruby-lang.org

50 pointsifesdjeen22 comments

>Time is reimplemented. There is no longer the year 2038 problem.

Great. Hopefully this time all those problems will be fixed well in advance of the deadline.

NO WAY! http://redmine.ruby-lang.org/issues/show/3140 Is still not closed in 1.9.2 :(

Gist confirming that issue http://gist.github.com/461930

This is a pretty big bummer. Yehuda Katz on Twitter called it an "epic show-stopping bug" and in the linked thread says he says it will prevent him from recommending 1.9.2.

For reference, the open bug is http://redmine.ruby-lang.org/issues/show/3140

Yup, Yehuda, i've stated it in my post... any news on that one? I can see from bug-tracker that it seems to be fixed, but are they going to release it?..

I should also add that it looks as though the bug has been put back into the 1.9.2 milestone and Shyouhei has asked to make it a 1.9.2 blocker. For the moment, I am cautiously optimistic.

The $: change seems bizarre.

why so?.. i don't really get your point

Because almost everywhere else (other languages, the shell, etc), the current working directory is searched first. This makes it arbitrarily simple to package up a set of scripts in a directory, which can be unpacked and run.

That seems bizarre to me as well.

Agreed. I wonder if it's cosmetic or if you can't actually require files in the same directory as __FILE__ via the load path.

Then again, this will probably only break snippets outside of projects, where lib/ is in the load path.

Use require_relative if you want to require files relative to __FILE__, that way you don't have to worry about $LOAD_PATH and keep your sanity :)

Having . in the load path led to some weird outcomes, especially to beginners. One example is if you write a script called twitter.rb that relies on a library also called 'twitter'. The require would attempt to pull in the current file rather than the library. I got stuck for a good 15 minutes with this one myself a few years ago ;-)

for those of you using rails 3, are you going to be using this rc candidate, or the ruby 1.9.1-p429. I've ran into a lot of issues using ruby 1.9.1 and are either fixed using ruby 1.8.7 or ruby 1.9.2 .. so just wondering ?

I will personally be switching my apps over to Rails 3 and 1.9.2, when they're both ready to go.

Might as well do it all at once, you know?

The way I understand it, the Rails team recommends not trying to use 1.9.1 with Rails 3 -- too many problems. Recommended versions are 1.8.7 and 1.9.2 pre-releases.

1.9.1 isn't supported: http://edgeguides.rubyonrails.org/3_0_release_notes.html#rai...

That said, I am using 1.9.1 in production (non-Rails project) and have had almost no issues so far, apart from a few libraries that had to be updated, but that was mostly minor issues (e.g. #methods returns strings in 1.8 and symbols in 1.9).

I'm using 1.9.1 right now for development, but may make the switch to 1.9.2 - the only issue I've encountered on 1.9.1 with Rails 3 are problems with encodings and multibyte characters.

Yes, we absolutely will be. We were running 1.9.1 (can't remember which patch level off hand) in a stable config with Rails beta 1, but as the Rails beta progressed, we were unable to move forward with ruby 1.9.1 underneath. This morning, we moved our staging environment to ruby-1.9.1-rc2 and rails-3.0.0.beta4. All our testing since this morning has gone 100% smoothly (thank god!). Every increment in beta before this point has been a nightmare.

I've been using 1.9.1 with sinatra / datamapper for a few months with no problems.

duplicate.

Didn't see the original. But even if I had, I imagine I'd be much happier to see a duplicate of this than yet another "original" news story about the iPhone's antenna.

Reply on news.ycombinator.com