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

[Tanaka Akira]

This is an excerpt from a previous version of your code:

DICTIONARY = RegexpGroup.new({
:OPERATOR => /return|typeof|[\[(\^=,{}:;&|!*?]/.source,
:CONDITIONAL => /\/\*@\w*|\w*@\*\/|\/\/@\w*|@\w+/.source,
:COMMENT1 => /\/\/[^\n]*/.source,
:COMMENT2 => /\/\*[^*]*\*+([^\/][^*]*\*+)*\//.source,
:REGEXP => /\/(\\[\/\\]|[^*\/])(\\.|[^\/\n\\])*\/[gim]*/.source,
:STRING1 => /\'(\\.|[^\'\\])*\'/.source,
:STRING2 => /"(\\.|[^"\\])*"/.source
})

Symbol#hash is fragile.

% ruby-1.8.6p287 -e 'p :a.hash'
104738
% ruby-1.8.6p287 -e ':x; p :a.hash'
104818

The :x expression, which seems have no side-effect, affects
:a.hash.

This is because Symbol#hash depends on how many symbols
known when the symbol first appeared.

This value affects the bucket of a hash. So it affects the
iteration order, until ruby 1.8.

It also depends on ruby version.

% all-ruby -e 'p :a.hash'
ruby-1.4.6(2000-08-16) 8593
ruby-1.6.0(2000-09-19) 2281742
ruby-1.6.1(2000-09-27) 2281742
ruby-1.6.2(2000-12-25) 2291982
ruby-1.6.3(2001-03-19) 2294030
ruby-1.6.4(2001-06-04) 2294030
ruby-1.6.5(2001-09-19) 2294030
ruby-1.6.6(2001-12-26) 2296078
ruby-1.6.7(2002-03-01) 2302222
ruby-1.6.8(2002-12-24) 2308366
ruby-1.8.0(2003-08-04) 2605326
ruby-1.8.1(2003-12-25) 2609422
ruby-1.8.2(2004-12-25) 2619662
ruby-1.8.3(2005-09-21) 2625806
ruby-1.8.4(2005-12-24) 2625806
ruby-1.8.5(2006-08-25) 104018
ruby-1.8.5p52(2007-06-07) 104178
ruby-1.8.5p113(2007-09-23) 104178
ruby-1.8.5p115(2008-03-03) 104178
ruby-1.8.5p231(2008-06-20) 104178
ruby-1.8.5head(2008-06-20p231) 104178
ruby-1.8.6p0(2007-03-13) 104738
ruby-1.8.6p36(2007-06-07) 104738
ruby-1.8.6p110(2007-09-23) 104738
ruby-1.8.6p111(2007-09-24) 104738
ruby-1.8.6p114(2008-03-03) 104738
ruby-1.8.6p230(2008-06-20) 104738
ruby-1.8.6p287(2008-08-11) 104738
ruby-1.8.6head(2009-02-13p330) 104738
ruby-1.8.7p0(2008-05-31) 109218
ruby-1.8.7p17(2008-06-09) 109218
ruby-1.8.7p22(2008-06-20) 109218
ruby-1.8.7p72(2008-08-11) 109218
ruby-1.8.7head(2009-02-13p116) 109218
ruby-1.8(2009-02-05r22080) 109938
ruby-1.9.1p0(2009-01-30r21907) 117848
ruby-1.9(2009-02-14r22297) 118088

It seems ruby-1.8.7 changes the value, as well as other many
versions.

The changes are because the number of symbols used
internally, algorithm changes, etc.

Symbol#hash is fragile. Too dangerous to depend.

In general, the algorithm of #hash methods (not only
Symbol#hash) is ruby internal. Don't depend on that.

 

[James Coglan]

[Note: parts of this message were removed to make it a legal post.]

I don't know git, but if you tell me how, I can send you the two bug
fixes and the working hash sequences. I'd suggest that you take a
careful look at those sequences, whether they are as you want them to
be, because they look really weird.

That would be wonderful, thank you. Just email patches to
(e-mail address removed), or send me an archive with all the working code if
diffs are a problem.

Seems I somehow gave the impression that I think my code is perfect and that
Ruby is broken. All I wanted to do was point out a change and ask for help
fixing my code. Shooting down assertions as untrue when they're based on
working code is not helpful. I realise it's easy to misappropriate the cause
of bugs sometimes but it's far more helpful to help the author investigate
the cause, rather than just telling them their examples are wrong and
questioning their knowledge. This list is usually in the friendly and
helpful end of the spectrum but this thread seems to have taken the tone
down a couple notches.

One final thing: someone mentioned that ordered hashes had been backported
to 1.8.7 but others disagree. Could someone from the core team settle this
one?

 

[David A. Black]

Hi --

One final thing: someone mentioned that ordered hashes had been backported
to 1.8.7 but others disagree. Could someone from the core team settle this
one?

1.8.7 can settle it

irb(main):001:0> RUBY_DESCRIPTION
=> "ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-solaris2.11]"
irb(main):002:0> {3,4,1,2}.first
=> [1, 2]


David

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

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

 

[aks]

This one is for those who wish that Ruby 1.8 would go *back* to being
1.8.6 compatible in Ruby 1.8.8.   If you agree with this, share your
thoughts or at least a simple '+1'.

+1000

We have a reasonable-sized body of code on 1.8.7, in production, that
we will not expect to upgrade for a minor release.

We expect _some_ compatibility issues with an 1.8 -> 1.9 upgrade.

We expect there will be many issues with an 1.8 -> 2.0 upgrade.

I have been developing software and managing the development process
for almost 30 years, and this issue of an incompatible minor release
is a huge violation of the Principle of Least Surprise.

If this trend is followed, that of capriciously breaking compatibility
on minor point releases, then the language usage rate will diminish,
adoption rate will decrease, and the language will become
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.

 

[M. Edward (Ed) Borasky]

+1000

We have a reasonable-sized body of code on 1.8.7, in production, that
we will not expect to upgrade for a minor release.

We expect _some_ compatibility issues with an 1.8 -> 1.9 upgrade.

We expect there will be many issues with an 1.8 -> 2.0 upgrade.

I have been developing software and managing the development process
for almost 30 years, and this issue of an incompatible minor release
is a huge violation of the Principle of Least Surprise.

If this trend is followed, that of capriciously breaking compatibility
on minor point releases, then the language usage rate will diminish,
adoption rate will decrease, and the language will become
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:

1. The current 1.8.6
2. 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.

 

[Charles Oliver Nutter]

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

 

[Nobuyoshi Nakada]

Hi,

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory Brown 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?

 

[Pit Capitain]

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory Brown 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

 

[David A. Black]

Hi --

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory Brown 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.

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 (http://manning.com/black2)

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

 

[Nobuyoshi Nakada]

Hi,

At Sun, 15 Feb 2009 21:44:25 +0900,
Pit Capitain 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.

 

[Pit Capitain]

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.

Regards,
Pit

 

[David A. Black]

Hi --

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.

I'm probably just on auto-pilot It feels like a kind of perfect
storm of small-to-medium issues, that emerge as one big issue, if that
makes sense.


David

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

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