State of Ruby 1.8.6?

[Jeff]

Can anyone provide an update to the state of Ruby 1.8.6?

I tried to follow the threads on ruby-core, but it seemed discussions
were happening in multiple places (some mailing list, some irc, etc.)
and I can't understand where we're at.

The official Ruby website now lists 1.8.7-p22 has the latest stable
build, with nary a link to 1.8.6, but the Rails folks had earlier
stated that 1.8.7 has flaws that are revealed by the Rails framework
and they don't support 1.8.7 for now.

Last I heard 1.8.6-p230 was still buggy and not recommended for use.
We're on 1.8.5 (RHEL) and we want to upgrade to 1.8.6 (or higher) but
I'm unsure of what to do next.

Jeff

 

[Alex Fenton]

Can anyone provide an update to the state of Ruby 1.8.6?

I tried to follow the threads on ruby-core, but it seemed discussions
were happening in multiple places (some mailing list, some irc, etc.)
and I can't understand where we're at.

The official Ruby website now lists 1.8.7-p22 has the latest stable
build, with nary a link to 1.8.6, but the Rails folks had earlier
stated that 1.8.7 has flaws that are revealed by the Rails framework
and they don't support 1.8.7 for now.

Last I heard 1.8.6-p230 was still buggy and not recommended for use.
We're on 1.8.5 (RHEL) and we want to upgrade to 1.8.6 (or higher) but
I'm unsure of what to do next.

Yep, you're not the only one. If your RHEL machine is exposed to public
use, my personal recommendation would be to use ruby 1.8.6-p111 with a
security patch applied; see
http://blog.phusion.nl/assets/r8ee-security-patch-20080623.txt

This should provide you with a ruby that is secure but also compatible
with the widest range of libraries. I've been using that version (as
provided by OS X 10.5) with absolutely no problems.

Ruby 1.8.7 is a dead-end experimental release and I wouldn't waste your
time with it. For some reason the core ruby development team see the
"stable" 1.8 branch as the perfect place to tinker around with cute new
features and needless changes to the underlying extension API. As a
result 1.8.7 (and possibly later versions of 1.8.6?) don't only break
certain Rails versions but also any library that uses certain SWIG
features to generate extension code.

a

 

[Gregory Brown]

Ruby 1.8.7 is a dead-end experimental release and I wouldn't waste your time
with it. For some reason the core ruby development team see the "stable" 1.8
branch as the perfect place to tinker around with cute new features and
needless changes to the underlying extension API. As a result 1.8.7 (and
possibly later versions of 1.8.6?) don't only break certain Rails versions
but also any library that uses certain SWIG features to generate extension
code.

Though I might put it more humble, I couldn't agree more. I wish that
1.8.7 was actually just a special branch of 1.8 that could be checked
out of svn, rather than an official release. I need to work around my
package managers to keep things stable by running 1.8.6, and for my
1.9 enabled work, I need to really run Ruby 1.9 to check if things are
working properly, so 1.8.7 does nothing to help me.

It's a neat experiment, but maintenance and purity wise, I hate it.

-greg

 

[Nobuyoshi Nakada]

Hi,

At Wed, 6 Aug 2008 09:08:31 +0900,
Alex Fenton wrote in [ruby-talk:310305]:

Ruby 1.8.7 is a dead-end experimental release and I wouldn't waste your
time with it. For some reason the core ruby development team see the
"stable" 1.8 branch as the perfect place to tinker around with cute new
features and needless changes to the underlying extension API. As a
result 1.8.7 (and possibly later versions of 1.8.6?) don't only break
certain Rails versions but also any library that uses certain SWIG
features to generate extension code.

What is "the underlying extension API"? Has it been reported,
or I'm missing it?

 

[Marc Heiler]

As a result 1.8.7 (and possibly later versions of 1.8.6?) don't

only break certain Rails versions but also any library that
uses certain SWIG features to generate extension code.

In all fairness I do not trust Rails code too much. In my experience
it was always lagging behind in Ruby versions.

 

[Alex Fenton]

Hi Nobu

What is "the underlying extension API"? Has it been reported,
or I'm missing it?

I was thinking of, for example, making "object allocation during garbage
collection phase" throw an rb_bug. It was this change:
http://redmine.ruby-lang.org/repositories/revision/ruby-18?rev=15429

I understand the reason for the patch [ruby-bugs:11859] but it
substantially altered extensions' expectations of how to interact with
GC, and so broke a considerable number (eg libxml, wxruby, ruby-gnome2,
cairo...)

Anyway, the problem is now SWIG's and individual authors.
http://sourceforge.net/tracker/index.php?func=detail&aid=2034216&group_id=1645&atid=101645

thanks
alex

 

[Charles Oliver Nutter]

Ruby 1.8.7 is a dead-end experimental release and I wouldn't waste your
time with it. For some reason the core ruby development team see the
"stable" 1.8 branch as the perfect place to tinker around with cute new
features and needless changes to the underlying extension API. As a
result 1.8.7 (and possibly later versions of 1.8.6?) don't only break
certain Rails versions but also any library that uses certain SWIG
features to generate extension code.

Largely this general opinion of 1.8.7 is what's kept us from moving to
1.8.7 compatibility in JRuby as well. For what it's worth, JRuby
currently supports JRuby 1.8.6 patchlevel 114 or so, and is not subject
to the security problems that the C implementation has. So it may be an
option for folks concerned about security.

When we do start adding 1.8.7 features, they'll probably be optional,
just like we have a --1.9 feature to enable 1.9 compatibility...

$ jruby -h
...
--1.8 specify Ruby 1.8.x compatibility (default)
--1.9 specify Ruby 1.9.x compatibility
$ jruby -v
jruby 1.1.3 (ruby 1.8.6 patchlevel 114) (2008-08-07 rev 7398) [i386-java]
$ jruby --1.9 -v
jruby 1.1.3 (ruby 1.9.1 patchlevel 114) (2008-08-07 rev 7398) [i386-java]

(ok, the patchlevel is a little fuzzy there, but you get the idea)

$ cat ~/sun/fiber_demo.rb
require 'fiber'

f = Fiber.new do
loop do
puts "Hello inside fiber!"
Fiber.yield "Yielding!"
end
end

5.times do
puts f.resume
end
$ jruby fiber_demo.rb
/Users/headius/fiber_demo.rb:1:in `require': no such file to load --
fiber (LoadError)
from /Users/headius/fiber_demo.rb:1
$ jruby --1.9 fiber_demo.rb
Hello inside fiber!
Yielding!
Hello inside fiber!
Yielding!
Hello inside fiber!
Yielding!
Hello inside fiber!
Yielding!
Hello inside fiber!
Yielding!

Fun stuff.

- Charlie

 

[Nobuyoshi Nakada]

Hi,

At Wed, 6 Aug 2008 20:53:25 +0900,
Alex Fenton wrote in [ruby-talk:310354]:

I was thinking of, for example, making "object allocation during garbage
collection phase" throw an rb_bug. It was this change:
http://redmine.ruby-lang.org/repositories/revision/ruby-18?rev=15429

Yesterday I twisted GC code and guess the failure would
disappear now.

I understand the reason for the patch [ruby-bugs:11859] but it
substantially altered extensions' expectations of how to interact with
GC, and so broke a considerable number (eg libxml, wxruby, ruby-gnome2,
cairo...)

They were just so lucky.

 

[Alex Fenton]

Last I heard 1.8.6-p230 was still buggy and not recommended for use.
We're on 1.8.5 (RHEL) and we want to upgrade to 1.8.6 (or higher) but
I'm unsure of what to do next.

You might also find this post on ruby-core helpful; it describes how
different distros have adapted to 1.8.6/1.8.7:

http://www.ruby-forum.com/topic/157392#695504

Sorry if my previous reply seemed splenetic... I do appreciate the work
of the core team etc

alex

 

[David A. Black]

Hi --

Though I might put it more humble, I couldn't agree more. I wish that
1.8.7 was actually just a special branch of 1.8 that could be checked
out of svn, rather than an official release. I need to work around my
package managers to keep things stable by running 1.8.6, and for my
1.9 enabled work, I need to really run Ruby 1.9 to check if things are
working properly, so 1.8.7 does nothing to help me.

It's a neat experiment, but maintenance and purity wise, I hate it.

My understanding of 1.8.7 is that it mainly exists to facilitate
transition to 1.9. The problem, for me, is that it's an extra step:
when I move to 1.9, I will just move in one step. 1.8.7 is too big a
change from 1.8.6, and not enough of a change to really be 1.9. It's
definitely much bigger than any other third-digit change I've seen in
Ruby, and is causing more confusion and ambivalent feeling than any
other.

One problem is that the default API docs are now 1.8.7, which means
they're really almost 1.9-compliant, and that means that people are
getting confused when their installed Ruby is so different from the
docs.

I'm not saying that the third digit changes should not really change,
but in my opinion 1.8.7 is too different from 1.8.6, and really isn't
what I think of as a "full-blooded" version of 1.8 -- meaning, it
feels like a development version of 1.9 and not an incremental step
from 1.8.6. My current plan, which of course might change, is to use
1.8.6 until there's a 1.9 that I am fully comfortable with, and then
switch to 1.9.

I say all of this somewhat reluctantly, because it could be
misunderstood as saying that the work done on 1.8.7 should not have
been done or is flawed. I think it's fine that it's been done, but my
current belief is that it should not be called 1.8.7.


David

 

[James Britt]

My understanding of 1.8.7 is that it mainly exists to facilitate
transition to 1.9. The problem, for me, is that it's an extra step: when
I move to 1.9, I will just move in one step. 1.8.7 is too big a
change from 1.8.6, and not enough of a change to really be 1.9. It's
definitely much bigger than any other third-digit change I've seen in
Ruby, and is causing more confusion and ambivalent feeling than any
other.

One problem is that the default API docs are now 1.8.7, which means
they're really almost 1.9-compliant, and that means that people are
getting confused when their installed Ruby is so different from the
docs.

Would it be better if ruby-doc.org defaulted to showing the 1.8.6 docs,
with a distinct link to the 1.8.7 docs for those who want to see them?

I updated the site shortly after 1.8.7 was released, but I'm sensing
that for most people 1.8.6 is really the de facto current version. (I,
too, am using 1.8.6.)

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[Gregory Brown]

Would it be better if ruby-doc.org defaulted to showing the 1.8.6 docs, with
a distinct link to the 1.8.7 docs for those who want to see them?

I updated the site shortly after 1.8.7 was released, but I'm sensing that
for most people 1.8.6 is really the de facto current version. (I, too, am
using 1.8.6.)

Definitely seems like a good idea to me.

The trouble I see with 1.8.7 is that although it is forward
compatible, it's not backwards compatible. So if I write my code
against 1.8.7, my users need to upgrade. Writing code on 1.8.6
ensures me that *most* of what I do will run on any old version of
1.8, but not necessarily 1.9.

I love 1.8.7 as a stepping stone, but I don't think it should have
become the head of the API-stable 1.8 branch. It just creates too much
confusion.

-greg

 

[James Gray]

Would it be better if ruby-doc.org defaulted to showing the 1.8.6
docs, with a distinct link to the 1.8.7 docs for those who want to
see them?

I updated the site shortly after 1.8.7 was released, but I'm sensing
that for most people 1.8.6 is really the de facto current version.
(I, too, am using 1.8.6.)

I would sure prefer that.

James Edward Gray II

 

[David Masover]

So if I write my code
against 1.8.7, my users need to upgrade.

I guess it depends how much is really different in 1.8.7. For example, I
really, really like Object#tap -- started using it in 1.9, and I see it's now
in 1.8.7. But at work, we use 1.8.6. My solution:

unless Object.new.respond_to? :tap
Object.class_eval do
def tap
yield self
self
end
end
end

The "unless" is because, of course, both 1.8.7 and 1.9 write this method in C,
and I assume their version is faster than mine.

I'd be much more concerned if there was 1.8.6 code that didn't run properly in
1.8.7, which I think is what started this discussion.

 

[Gregory Brown]

I guess it depends how much is really different in 1.8.7. For example, I
really, really like Object#tap -- started using it in 1.9, and I see it's now
in 1.8.7. But at work, we use 1.8.6. My solution:

unless Object.new.respond_to? :tap
Object.class_eval do
def tap
yield self
self
end
end
end

The "unless" is because, of course, both 1.8.7 and 1.9 write this method in C,
and I assume their version is faster than mine.

Yes, and this works fine for internal code. Releasing this sort of
stuff is sub-optimal, as you are then risking competing with the N
other libraries trying to do the same thing. Though with luck,
conflicts won't occur, but it wouldn't surprise me at all if people
miss edge cases when they try to implement upcoming Ruby features on
their own.

That having been said, we do this for a couple features in Prawn, to
ensure backwards compatibility from 1.9 to 1.8.x
It feels nasty, but since these things are centrally located in a
prawn/compatibility.rb file, it'd be a one line patch to disable them.
If people doing these sort of tricks, I definitely recommend this
approach of keeping your modifications separated out cleanly, so it's
easy to work around them.

-greg

 

[David Masover]

Yes, and this works fine for internal code. Releasing this sort of
stuff is sub-optimal, as you are then risking competing with the N
other libraries trying to do the same thing.

Well, given my example, the only possible conflict would be if someone else
got it wrong. The point is to go for the very simple ones, get them right,
and only apply them if they don't exist already.

it wouldn't surprise me at all if people
miss edge cases when they try to implement upcoming Ruby features on
their own.

Now, that is very true -- I know I've gotten it wrong, at least once -- and
for that reason, I'd love it if someone would create a
1.8.7/1.9-compatibility gem.

Not everything, of course -- unfortunately, we can't assume the wonderful
JSON-compatible hash syntax yet, and I doubt Fibers would be fun to
backport -- but we could at least get some of the simple, idiomatic changes
done right.

I've never released a gem before. I'd be happy to start one, but I can't
promise it'll be done quickly or well.

 

[Jeff]

Yep, you're not the only one. If your RHEL machine is exposed to public
use, my personal recommendation would be to use ruby 1.8.6-p111 with a
security patch applied; seehttp://blog.phusion.nl/assets/r8ee-security-pa= tch-20080623.txt

This should provide you with a ruby that is secure but also compatible
with the widest range of libraries. I've been using that version (as
provided by OS X 10.5) with absolutely no problems.

Ruby 1.8.7 is a dead-end experimental release and I wouldn't waste your
time with it. For some reason the core ruby development team see the
"stable" 1.8 branch as the perfect place to tinker around with cute new
features and needless changes to the underlying extension API. As a
result 1.8.7 (and possibly later versions of 1.8.6?) don't only break
certain Rails versions but also any library that uses certain SWIG
features to generate extension code.

Thanks for the info! I'll try to apply 1.8.6.-p111 and apply the
patch you've suggested.

But let me say this to any ruby core members who may be listening:
This is sad and humiliating at the same time.

Does Matz realize how foolish the Ruby community is looking right
now? It's one thing to have a tough time fixing code; it's entirely
another to do absolutely no communication whatsoever with those of us
trying to support Ruby and use it on a daily basis. I've been trying
to hard establish Ruby as a first-class citizen at my day job, and
this episode is undoing all the effort I've been putting into it.

<rant />

 

[M. Edward (Ed) Borasky]

Definitely seems like a good idea to me.

The trouble I see with 1.8.7 is that although it is forward
compatible, it's not backwards compatible. So if I write my code
against 1.8.7, my users need to upgrade. Writing code on 1.8.6
ensures me that *most* of what I do will run on any old version of
1.8, but not necessarily 1.9.

I love 1.8.7 as a stepping stone, but I don't think it should have
become the head of the API-stable 1.8 branch. It just creates too much
confusion.

I agree. I don't see the need for syntax or semantics changes to either
1.8.6 or 1.9.x, nor do I see the need for a "bridge" between 1.8.6 and
1.9.x. 1.8.7 should be bug fixes and performance improvements to 1.8.6,
keeping the same syntax and semantics. The same goes for 1.8.8, and
presumably 1.8.9.

As far as I'm concerned, if you want the performance, syntax and
semantics of 1.9, *use* 1.9! Beat on it, find workarounds for its
issues, file bugs against it, make your code work with it, write new
stuff for it that doesn't work with 1.8.x, etc.
--
M. Edward (Ed) Borasky
ruby-perspectives.blogspot.com

"A mathematician is a machine for turning coffee into theorems." --
Alfréd Rényi via Paul Erdős

 

[Avdi Grimm]

Well, given my example, the only possible conflict would be if someone else
got it wrong. The point is to go for the very simple ones, get them right,
and only apply them if they don't exist already.

Or if someone else got it *different*. This is how 1.8.7 broke
Rails/ActiveSupport 2.0 - ActiveSupport already had a String#chars,
and 1.8.7 introduced an incompatible String#chars (it returns an
Enumerator instead of an Array).

--
Avdi

Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com