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 ;-)

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

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.

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")

+1 Thanks, that was easy.

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

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

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

It kind of understates the issue and hides it behind multi-threading.

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.

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

Thanks, I knew about that when it came out, but before I was able to install it, the preview of 1.9.3 came out - which is when I first noticed just how much faster it was.

After running a few tests on the commandline, rake and rails commands are even faster than they were in RC1.

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.

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.

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.

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

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

Good to know! I didn't realize 1.9.1 was considered stable.

Similarly, 1.8.7 is the stable version of the 1.8 series.

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-build was already updated to support 1.9.3-p0, just clone the latest: https://github.com/sstephenson/ruby-build

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

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

Just brew update and upgrade.

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?

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.

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.

rb_thread_select is marked deprecated in 1.9.3... so what's the alternative?

ok... replying to myself here... I think if you're using rb_thread_select the answer may be... use select(2) in an rb_thread_blocking_region callback... still not convinced this is better...

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.

ruby-debug19 is still not updated...

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

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

I've used pry. I like pry, but it really does not fill the need of a debugger.

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

thanks

Yeah! I plan on to start learning Ruby.

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

It's trivial to embed Ruby in C/C++.

Python is a great language too. If I hadn't learned Python before learning Ruby, I guess I'd know Ruby poor.