

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

======
petercooper
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...](http://www.rubyinside.com/ruby-1-9-3-introduction-and-
changes-5428.html)

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

------
zdw
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
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
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
+1 Thanks, that was easy.

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

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

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

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

------
cmer
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.

~~~
sandal
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
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.

------
piggity
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.

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

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

~~~
kenips
Homebrew also updated:
[https://github.com/mxcl/homebrew/commit/ae9b146fb64cc2db914b...](https://github.com/mxcl/homebrew/commit/ae9b146fb64cc2db914bf2a3253a98580c5dacee)

Just brew update and upgrade.

------
tedsuo
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
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
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.

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

~~~
taf2
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...

------
tibastral2
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
thanks

------
kenips
ruby-debug19 is still not updated...

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

~~~
catch23
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>

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

------
kron4eg
grats everyone!

------
zanst
Good news!

~~~
lilpirate
Yeah! I plan on to start learning Ruby.

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

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

