If you are unhappy with the direction of Ruby 1.8.7+, respond

naething · February 14, 2009, 8:23pm

On Sat, Feb 14, 2009 at 10:03 AM, aks [email protected] wrote:

We expect some compatibility issues with an 1.8 → 1.9 upgrade.
marginalized.

People only have so much time and effort to work on problems. A
programming language is a tool to solve those problems. If the tool
causes MORE work, then another tool will be chosen instead.

It’s really pretty simple.

Yeah … my vote is for two production versions of the Ruby syntax
and semantics:

The current 1.8.6
The current 1.9.1

I think 1.8.7 was a failed experiment – an evolutionary dead end –
that unfortunately got picked up by Linux distributors. I’m not sure
who else picked it up. Maybe that’s the question we should be asking
– who absolutely positively must have the Ruby 1.8.7 syntax and
semantics?

Also, please note that I specifically called out syntax and semantics.
I think platform-dependent optimizations, such as what Ruby Enterprise
Edition has for 32-bit Linux and what Sun has been doing with JRuby
are fair game. In fact, I encourage them and hope at some point to
have the free time to contribute a few to the 1.9.1 branch. And I
certainly agree with Matz that the Ruby Enterprise Edition
optimizations should somehow get into the main 1.8.x tree and not
continue to live on as a fork. As far as I know they’re open source,
so it’s “just a matter of merging patches.”

I didn’t make it to RubyConf 2008, but I was involved in 2006 and
2007, and I was under the impression that the planned “workflow” was
that the alternative implementers would stay with the 1.8.6 syntax and
semantics and that the core team would push ahead with the new syntax,
semantics and YARV engine, with a 1.9 intermediate release and a 2.0
“final” release. I think that’s what Rubinius and JRuby have done,
although JRuby seems to have also embraced 1.9 as a fully-functional
implementation as well. I have no idea what’s happening with IronRuby.
Is it even relevant any more?

So yes, my vote is for Ruby 1.8.8 to have Ruby 1.8.6 syntax and
semantics, all accumulated security patches, all accumulated bug fixes
and all accumulated platform-dependent optimizations to the MRI core.
But I’m only going to vote +1 because I’m trying to personally stay on
the 1.9.1 → 2.0 branch.

–
M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.

naething · February 15, 2009, 6:22am

Hi,

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory B. wrote in [ruby-talk:327704]:

I am setting up two threads in the hopes that we can see names
attached to opinions about the decision to break backwards
compatibility between Ruby 1.8.6 and Ruby 1.8.7+

Could anyone summarize compatibility issues which really exist
now?

naething · February 14, 2009, 11:09pm

James C. wrote:

Regardless of whether they’re supposed to, the Rubies I’ve used before
1.8.7 actually do iterate in insertion order. Could be machine/OS specific,
a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
the order that keys appear in a literal, at least on my machine. If this is
supposed to now be defined behaviour I’ll investigate further and file a bug
if necessary.

They only appeared to be ordered in the cases you saw, especially in
cases of smaller hashes (fewer possible permutations of unordered). They
never were actually ordered. This is the Truth.

Naturally, unordered or “order unspecified” hashes may sometimes produce
what seems to be ordered iteration. But it is entirely by chance.

And this has come up countless times…someone will iterate their
three-element hash and it will come out in insertion order. Then they’ll
expand to a larger hash or a different implementation and it stops being
ordered. They cry foul, ruby-talk intervenes, and they learn hashes are
not ordered in 1.8.6.

I don’t know what 1.8.7 does. 1.9.1 and JRuby (1.8.6 and 1.9.1 modes)
both maintain hash keys in insertion order. Maintaining insertion order
is simply a special case of unspecified ordering, so it’s valid moving
forward to add ordering, but not valid to take it away.

Charlie

naething · February 15, 2009, 6:57am

Christopher D. wrote:

may mean some code just called GC.start for some other reason.
True, but that doesn’t change the conclusion.

naething · February 15, 2009, 1:47pm

2009/2/15 Nobuyoshi N. [email protected]:

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory B. wrote in [ruby-talk:327704]:

I am setting up two threads in the hopes that we can see names
attached to opinions about the decision to break backwards
compatibility between Ruby 1.8.6 and Ruby 1.8.7+

Could anyone summarize compatibility issues which really exist
now?

The only things I remember from this long discussion are:

The new String#chars clashed with a method of Rails
with the same name
It is not allowed anymore to create new objects during
garbage collection (the SWIG problem)

Both are at least questionable to being categorized as breaking
backwards compatibility and seem to have been fixed. Everything else
that had been said here and in other threads had to be withdrawn.

Regards,
Pit

naething · February 15, 2009, 1:58pm

Hi –

On Sun, 15 Feb 2009, Pit C. wrote:

The only things I remember from this long discussion are:

The new String#chars clashed with a method of Rails
with the same name

It is not allowed anymore to create new objects during
garbage collection (the SWIG problem)

Both are at least questionable to being categorized as breaking
backwards compatibility and seem to have been fixed. Everything else
that had been said here and in other threads had to be withdrawn.

I would just add that most of the issues brought up about 1.8.7
(questions as to why a “stepping stone” to 1.9 is needed, the
unprecedented quantity of change for a teeny number (which I think is
not in dispute; the core team has said that a decision was made to
redefine the meaning of the numbering), the unprecedented amount of
backporting, the impact on non-MRI interpreters, and, in particular,
the dramatically increased likelihood that code being developed on the
later version (1.8.7) would be completely, deeply incompatible with
the earlier version (1.8.6)) – these issues, and many of the others
that have been raised, are still there.

If it were all just a matter of a few bumps along the way in running
older code on the newer version, I’m sure we would not have been
having all these discussions. Lots of the people who perceive problems
have also gone through other 1.6 and 1.8 transitions; it’s not a crowd
that likes to stir up problems for their own sake. So something is
different this time around. I hope we’ll be able to move through it
smoothly and with creative solutions, but there are definitely
complexities to this set of transitions that were not present in every
previous transition.

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

http://www.wishsight.com => Independent, social wishlist management!

naething · February 15, 2009, 2:20pm

Hi,

At Sun, 15 Feb 2009 21:44:25 +0900,
Pit C. wrote in [ruby-talk:328269]:

The only things I remember from this long discussion are:

Thank you.

It is not allowed anymore to create new objects during
garbage collection (the SWIG problem)

This is an old issue which has been already fixed.

naething · February 15, 2009, 2:51pm

2009/2/15 David A. Black [email protected]:

I would just add that most of the issues brought up about 1.8.7
(…) – these issues, and many of the others
that have been raised, are still there.

Yes, this is a nice summary of the concerns. Maybe I read Nobu’s
question too limited when he asked about problems with backwards
compatibility. Maybe he meant general problems with adopting 1.8.7.
Thanks for the reminder.