[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

State of Ruby 1.8.6?

Jeff

8/5/2008 9:41:00 PM

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
18 Answers

Alex Fenton

8/6/2008 12:08:00 AM

0

Jeff wrote:
> 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-20...

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

8/6/2008 12:59:00 AM

0

On Tue, Aug 5, 2008 at 8:08 PM, Alex Fenton <alex@deleteme.pressure.to> wrote:

> 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

8/6/2008 9:18:00 AM

0

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?

--
Nobu Nakada

Marc Heiler

8/6/2008 11:30:00 AM

0

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

--
Posted via http://www.ruby-....

Alex Fenton

8/6/2008 11:53:00 AM

0

Hi Nobu

Nobuyoshi Nakada wrote:
>> 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?

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

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&a...

thanks
alex

Charles Oliver Nutter

8/7/2008 8:58:00 AM

0

Alex Fenton wrote:
> 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

8/7/2008 9:26:00 AM

0

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

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.

--
Nobu Nakada

Alex Fenton

8/7/2008 10:11:00 AM

0

Jeff wrote:

> 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/157...

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

alex

David A. Black

8/7/2008 11:41:00 AM

0

Hi --

On Wed, 6 Aug 2008, Gregory Brown wrote:

> On Tue, Aug 5, 2008 at 8:08 PM, Alex Fenton <alex@deleteme.pressure.to> wrote:
>
>> 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.

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

--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.r... for details and updates!

James Britt

8/7/2008 4:47:00 PM

0

David A. Black wrote:

> 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