Ruby 1.9.3 released

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/40527

by xal • 15 years ago

183 41 15 years ago

blade.nagaokaut.ac.jp

zmanji2• 15 years ago

Does this include the "fast require" functionality that many people were patching into their Ruby 1.9.2 installs?

goshakkk2• 15 years ago

Yes. "Library loading or locking in multi-threaded program is improved, for example."

zmanji2• 15 years ago

D'oh, I don't understand how I missed that one.

Sapient2• 15 years ago

Maybe there was something wrong with my 1.9.2, but when working with rails projects (rake, rails console etc), this feels a few orders of magnitude faster.

jstepien2• 15 years ago

Here's the whole story behind this speed-up: http://www.rubyinside.com/ruby-1-9-3-faster-loading-times-re...

zanst• 15 years ago

Good news!

lilpirate• 15 years ago

Yeah! I plan on to start learning Ruby.

Game_Ender• 15 years ago

Give Python a look as well. Also, never try to embed Ruby in a C/C++ application it's not designed for it.

Stratego• 15 years ago

ruby-build was already updated to support 1.9.3-p0, just clone the latest: https://github.com/sstephenson/ruby-build

bobbywilson0• 15 years ago

if you have ruby-build already installed and you pull, you need to rerun ./install.sh

kenips2• 15 years ago

Homebrew also updated: https://github.com/mxcl/homebrew/commit/ae9b146fb64cc2db914b...

Just brew update and upgrade.

kron4eg• 15 years ago

grats everyone!

cmer2• 15 years ago

I've never been so excited for an unstable release. 1.9.2's require was painfully slow without the patch.

edit: by "unstable", I mean a dot.uneven number.

jstepien2• 15 years ago

A 'point release' might be the phrase you are looking for.

sirn• 15 years ago

Actually, Ruby used to follows the "unstable odd, stable even" versioning scheme but they seems to quit doing that since 1.9.1 (since both 1.9.1 and 1.9.2 are declared stable[1])

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

EDIT: provide a source about Ruby 1.9.1

sandal• 15 years ago

1.9.3 is not an unstable release. Ruby uses the third version number to represent a point release, i.e. you can expect 1.9.3 to be more stable than 1.9.2 over time.

I think that the versioning policy did work the way you describe it at one point, but it's no longer the case.

judofyr• 15 years ago

As far as I know, x.y.ODD (e.g. 1.8.5) was never an unstable release.

x.ODD.z (e.g. 1.7.1) was unstable up until 1.9 though.

zdw• 15 years ago

Apparently the licensing has changed as well - it's now BSD dual-licensed, rather than GPLv2:

http://svn.ruby-lang.org/repos/ruby/tags/v1_9_3_0/NEWS

travisjeffery• 15 years ago

That was on the linked page:

> Also the license of Ruby has changed. Previously Ruby has been released under GPLv2 and "Ruby" license. But Ruby 1.9.3 is released under a joint 2-clause BSD license and "Ruby" license.

SingAlong• 15 years ago

in case any of you are using rvm, "rvm get head" should update the rvm from the git repository and then you can install ruby the usual way ("rvm install 1.9.3")

mark_l_watson• 15 years ago

+1 Thanks, that was easy.

tibastral2• 15 years ago

to install with rvm : first update rvm,

bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

then

rvm install 1.9.3

and

rvm use 1.9.3 --default

And you are on fire

aeontech• 15 years ago

thanks

tedsuo• 15 years ago

I'm a little unclear about threads in ruby 1.9. I've been told in the past that threads in ruby were problematic. Can anyone illuminate the current state of affairs?

riffraff• 15 years ago

1.8 had green threads and when the interpreter blocked on some operations it would block all the threads.

1.9 uses native threads but it has a global interpreter lock which has known issues.

I am not sure what the improvements to locking in 1.9.3, as the changelog has quite a few commits related to that.

wycats• 15 years ago

In both Ruby 1.8 and 1.9, Ruby code will not cause all threads to block when the CPU is idle. However, poorly coded C libraries that blocked on IO without providing Ruby a file descriptor (via rb_thread_select) could cause all threads to block.

Those libraries have largely been fixed or replaced (e.g. mysql with mysql2). Ruby 1.9.2 also provides a mechanism for C code to release the GIL if it does not involve any Ruby code, which is used Blythe typecasting code in mysql2, for instance.

mperham• 15 years ago

The threading change for 1.9.3 is a scheduler change that just lessens the chance of thread starvation. It's nothing to get excited about.

kenips2• 15 years ago

ruby-debug19 is still not updated...

mrinterweb2• 15 years ago

The lack of a working ruby-debug19 has been the only thing keeping me from using 1.9.3.

catch23• 15 years ago

Just use pry, it's not really a debugger replacement, but it's useful in most cases that ruby-debug19 would be used.

http://rubygems.org/gems/pry

petercooper• 15 years ago

A couple of weeks ago I did a post looking at 1.9.3 and 1.9.4 and the differences involved (including a video presentation by Yugui): http://www.rubyinside.com/ruby-1-9-3-introduction-and-change...

Now, plug alert..

I'm having a 2 day 50% off on Ruby 1.9 Walkthrough to celebrate: http://www.rubyinside.com/19walkthrough/ .. Yes, totally a plug, but there isn't any more up to date walkthrough of 1.9 (which includes 1.9.3) so I'll take my chances ;-)

piggity• 15 years ago

Ruby 1.9.3-rc1 (and presumably -p0) fixed all manner of memory leak issues I was experiencing in Rails apps (Ruby 1.9.2-p290 + Rails 3.1 + Passenger 3.0.9 + Nginx). This was on top of the loading slowness of Ruby 1.9.2 with Rails.

Went from leaking MBs per request to no leakage for days.

Ruby 1.9.3 released

Related Stories