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

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+
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'.  If you disagree, please find the
other thread titled 'If you are happy with the direction of Ruby
1.8.7, respond'.  If you are in the middle, I don't know what you
should do... write two posts?

My goal is to survey ruby-talk so that the core Ruby team has a chance
to see what people really want.  I'm curious to see if this is as
one-sided as I think it is.

-greg

On Feb 11, 2009, at 11:10 AM, Gregory Brown wrote:

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

I'm bothered by the new versioning scheme.

The new releases involve big changes and even if they are fully
backwards compatible about what they will run, they are still creating
pretty big compatibility gaps.  Code using any of the new 1.8.7
features won't run on 1.8.6 and lower.  It sounds as if 1.8.8 intends
to take this farther, so code written to that won't work in the
different 1.8.7 branch or the earlier 1.8.6 and lower stuff.  Thus I
feel we now have three different versions of Ruby 1.8 on the table
(counting the not yet released 1.8.8).

James Edward Gray II

2009/2/11 Gregory Brown <gregory.t.brown@gmail.com>

> 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+
> 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'.  If you disagree, please find the
> other thread titled 'If you are happy with the direction of Ruby
> 1.8.7, respond'.  If you are in the middle, I don't know what you
> should do... write two posts?



I'm not sure whose problem this really is, but it's worth bearing in 
mind
that in certain Linux package systems, there is just one 'ruby1.8' 
package
and one 'ruby1.9' package, each of which ships the latest from that 
branch.
The same goes for the 'gem' executable, so you only get one gem repo per
'major' version -- you don't get a 1.8.6 gem repo and a 1.8.7 repo, you 
just
get one for all 1.8.x releases.

Keeping 1.8.x back-compatible with prior 1.8.x seems like it would 
minimise
confusion for a lot of people and reduce the burden of testing libraries
against multiple Rubys.

Gregory Brown wrote:
> 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+
> 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'. 

Gregory - thank you for raising this here. I read this ruby-core thread:
http://www.ruby-forum.com/topic/178191#new

last night, and in particular Akinori MUSHA's statement:

"Yes.  Backporting syntactic changes is a big part of the plan for ruby
1.8.8"

Luckily I was in bed else I'd have fallen off my chair. This seems to me
the most bonkers development plan I've seen in a long while.

Stable releases are meant to be *stable*; minor point releases are meant
to be *API compatible*, backwards and forwards. I can't think of any
other serious open-source project that would even contemplate adding
random bits of syntax and API calls in minor releases.

I expressed the same opinion at length and with some fervour regarding
the release of 1.8.7: http://www.ruby-forum.com/topic/150251#663291

so I won't go on again. However one of the main reasons for allowing
1.8.7 to cherry-pick backports was that, at the time of the decision,
(Nov 2006) 1.9.1 seemed a while off, and some didn't want the language
frozen until then. That seemed impatient to me then, but now there's a
release version of 1.9.1 on the table, I can see no justifcation at all.

The progression to 1.9 isn't that hard anyway; the language hasn't
changed so much. And I can't see that having a whole load of
incompatible 1.8.x mongrel releases washing about (as they end up in
distros etc) helps anyway.

Just to say again, I'm grateful for the work of the core developers and
maintainers - but it seems like 1.8 branch is being treated like a
personal playground rather than a stable version. There's not even a
statement of what features might be backported.

Ooops, I've gone on at length again.

Anyway, +1 for Ruby 1.8.8 being a bugfix release implementing the same
API as 1.8.6

alex

+1

1.8 should keep its final branch release as fully 1.8 compatible for
posterity.  (Keep it legacy compatible)
Ventures into the future can take place inside the Newer 1.9 and 2.0
branches without breaking what we could call "1.8 Legacy" code.

2009/2/11 James Gray <james@grayproductions.net>

I'll write two posts.

Now that 1.9.1 is released, hopefully people will start porting to it,
and 1.8 can remain stable. For the people who still need all their old
gems to work, there should be a stable version -- apparently, 1.8.7
broke a lot of things.

On top of which, if 1.8.8 is an easier upgrade than 1.9, people won't be
as encouraged to port to 1.9.

I wrote it on ruby-core and I write it again: I'm very worried and
confused with Ruby versioning policy.
I'm very unhappy with all 1.8.7 and possibly 1.8.8 version.

+1

--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

2. There are two "de facto" standards for the Ruby language at present.
    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
"Programming Ruby 1.9" and "The Ruby Programming Language".

   All other versions are irrelevant and a waste of precious developer
energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two
"de facto" standard versions have designated numbers already, why not
keep them as they are?

4. Since I don't personally have a large installed base of Ruby code,
I am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
documentation, performance tune, etc.
--
M. Edward (Ed) Borasky

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

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

2. There are two "de facto" standards for the Ruby language at present.
    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
"Programming Ruby 1.9" and "The Ruby Programming Language".

   All other versions are irrelevant and a waste of precious developer
energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two
"de facto" standard versions have designated numbers already, why not
keep them as they are?

4. Since I don't personally have a large installed base of Ruby code,
I am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
documentation, performance tune, etc.
--
M. Edward (Ed) Borasky

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

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

2. There are two "de facto" standards for the Ruby language at present.
    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
       "Programming Ruby 1.9" and "The Ruby Programming Language".

   All other versions are irrelevant and a waste of precious developer
   energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two "de
facto" standard versions have designated numbers already, why not keep
them as they are?

4. Since I don't personally have a large installed base of Ruby code, I
   am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
       documentation, performance tune, etc.
--
M. Edward (Ed) Borasky

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

I'm very unhappy. Come on people! Use standard versioning:

1.MAJOR_VERSION.MINOR_VERSION

Should mean that after each MINOR_VERSION change I won't loose 
compatibility of my code, and only known bugs will be fixed or 
performance improved! Backporting is unnecesary and confusing. Most 
people will stay on 1.8.6 (including me on my servers) until most of 
applications will work with 1.9.1.

Leave alone 1.8 branch, don't do such stupid things like You want to!!


+1 is not enough!
+666!  ;}

+1

#include <all the other comments so far>

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & 
Windows
Those who would give up essential Liberty, to purchase a little
temporary Safety,
deserve neither Liberty nor Safety.
    -- Benjamin Franklin

As a new Ruby user coming to the language, I've found it fairly
confusing as to which Ruby I should be using. I understand that 1.8.6
via Pickaxe is a standard and so is 1.9.1 via David Black's upcoming
book.

Coming from other projects, it would seem to me that making changes to
1.8.x that aren't backwards compatible is a confusing message. I don't
like the idea of have parts of 1.8.x incompatible with the rest of it.
Thats nonsense.

+42 for not breaking backwards compatibility. 1.8.x made it this far,
no need to introduce changes that are already in place in 1.9.x.

-Zac

+1

I had a brief foray into 1.8.7 and had problems deploying code to some
servers that were running 1.8.6 so now use 1.8.6.

Will switch to 1.9.x when all the stuff I need works with it, but
until then I'd really appreciate a proper and consistent 1.8.x branch
that didn't diverge into being a halfway house.

Backported stuff isn't what I want at all - when I want 1.9.x features
(and everything works with them) I'll move to 1.9 but please leave 1.8
alone!

Rupert

At work, we've already been bitten by 1.8.6 -> 1.8.7 problems.
I can't tell you how much I don't want to see 1.8.8 move even
further away from 1.8.6.

Please, leave the 1.8 line as compatible as possible, leave
the API breakage to the 1.8 -> 1.9 migration.

> Now that 1.9.1 is released, hopefully people will start porting to it, 
> and 1.8 can remain stable. For the people who still need all their old 
> gems to work, there should be a stable version -- apparently, 1.8.7 
> broke a lot of things.

If it has to use parts of the new parser, can it use Ripper??

On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:

> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>
> 1. The Ruby community should proceed with all deliberate speed towards
> ISO standardization of the language.

Yeah, look what it did to Forth.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.

On Wed, Feb 11, 2009 at 2:47 PM, Matt Lawrence <matt@technoronin.com> 
wrote:
> On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:
>
>> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>>
>> 1. The Ruby community should proceed with all deliberate speed towards
>> ISO standardization of the language.
>
> Yeah, look what it did to Forth.

Don't just say it, show it.

http://vividpicture.com/aleks/atari/forth.jpg

-greg

Gregory Brown wrote:
> My goal is to survey ruby-talk so that the core Ruby team has a chance
> to see what people really want.  I'm curious to see if this is as
> one-sided as I think it is.
> 
> -greg
> 


+1

Matt Lawrence wrote:
> On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:
> 
>> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>>
>> 1. The Ruby community should proceed with all deliberate speed towards
>> ISO standardization of the language.
> 
> Yeah, look what it did to Forth.

The process of ANS standardization focused the Forth community and
produced a syntax and semantics that are well-regarded in today's Forth
community. I wouldn't be using Forth today if it weren't for the ANS
standard!

--
M. Edward (Ed) Borasky

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

On 11 Feb 2009, at 19:55, Gregory Brown wrote:
>> Yeah, look what it did to Forth.
>
> Don't just say it, show it.
>
> http://vividpicture.com/aleks/atari/forth.jpg

Too many old Forth hands on here ;p

With all this back-porting it's as if the foreshadowed magnitude of
Ruby 2.0 is making the core team nervous of turning 1.9 into a genuine
stable branch, so instead they're forcing the stable features into 1.8
instead. I'm sure this is a complete misreading of their intent on my
part but it is a worrying path to be heading down.

I'll admit that so far I've not had any problems with 1.8.7 but my
colleague Romek has been having a horrible time with its OpenSSL
support and quite a few of the tools he's written with 1.8.6 no longer
work. We're currently debating whether or not to bite the bullet and
move to 1.9.1 - assuming the current crop of books are an accurate
representation.

Anyway if I or another developer want 1.9 features and/or syntax we'll
use 1.9 and the fact that some of us choose not to do so at this time
is something I'd like to see respected by the core team.

+1


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

I am not happy.

Ruby 1.8.7 and Ruby 1.8.8 are attempts to bridge the gap between 1.8.6
and 1.9, but they change the 1.8 line in much more drastic ways that is
warranted by a minor version number change. That's one point against 
them.

A similar approach in the Python community has led to 2.6, 2.7 releases
stepping toward 3.0, but those are major release version number changes
and they're only doing them if the community demands them. In this case,
1.8.7 and 1.8.8 are moving forward whether the community wants them or
not. Another point against.

Minor version releases should certainly not break things except as
needed to fix bugs. Ruby 1.8.7 did this initially. They should not add
entirely new APIs incompatible with other minor releases. They should
not add new syntax incompatible with other minor releases. Ruby 1.8.7
does the former, and 1.8.8 syntax backports will do the latter. More
points against.

I still feel like Ruby 1.9 should have been 2.0. Then 1.8.7 could have
been 1.9, 1.8.8 could be 1.10, and so on, and people depending on "Ruby
1.8" to behave like "Ruby 1.8" would not be forced to upgrade.

In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine
standalone releases, but making them be minor version number changes
essentially forces everyone to upgrade eventually, whether they want to
or not, since Ruby distributors generally don't expect a 0.0.x release
to be filled with incompatible changes or additions. Ubuntu, for
example, now installs 1.8.7 by default, so Ubuntu users are now much
more likely to write code that doesn't work on 1.8.6.

And note also that Ruby core has only a few resources to maintain Ruby
versions...which means the existence of 1.8.7 and plans for 1.8.8 will
eventually force 1.8.6 to be abandoned like 1.8.5 and 1.8.4. How would
you feel about 1.8.6 being EOLed because of 1.8.7 and 1.8.8 taking up
resources?

- Charlie

On Wed, Feb 11, 2009 at 6:10 PM, Gregory Brown
<gregory.t.brown@gmail.com> wrote:
> My goal is to survey ruby-talk so that the core Ruby team has a chance
> to see what people really want.  I'm curious to see if this is as
> one-sided as I think it is.
>
> -greg
>
Good idea Greg, now that Ruby1.9 is out I really fail to see the
advantages of this.
I am writing lots of compatibility code between 1.8.6 1.8.7 and 1.9
and that really is time not too well spent.

I would like 1.8.6-->1.8.8 so that I can just drop 1.8.7 support

1.8.7, 1.8.9 not really a strong opinion here, those could follow the
rule of dev. releases: use on own risk.
1.9 of course is great no complaints.

Cheers
Robert

On Feb 11, 2:04 pm, "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
> The process of ANS standardization focused the Forth community and
> produced a syntax and semantics that are well-regarded in today's Forth
> community. I wouldn't be using Forth today if it weren't for the ANS
> standard!
>

The process of ANS standardization decimated the Forth community and
produced a syntax and semantics that are grudgingly accepted by some
in today's tiny Forth community.

He wouldn't be using Forth today if it weren't for the ANS
standard!  (A strong argument against standardization.)

On Wed, Feb 11, 2009 at 12:10 PM, Gregory Brown
<gregory.t.brown@gmail.com>wrote:

> My goal is to survey ruby-talk so that the core Ruby team has a chance
> to see what people really want.  I'm curious to see if this is as
> one-sided as I think it is.
>
>
+1024!

Others have pointed out the folly of having a teeny version number 
change
carry API breaking changes.

Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

On an aside do any of the OS X users know if there's a way in Macports 
to
pin the version number of a package?  The whole Ruby 1.8.7 thing has 
made me
very paranoid of doing an errant port upgrade.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On 11.02.2009 18:27, James Gray wrote:
> The new releases involve big changes and even if they are fully  
> backwards compatible about what they will run, they are still creating  
> pretty big compatibility gaps.  Code using any of the new 1.8.7  
> features won't run on 1.8.6 and lower.

Well, but this is usual, isn't it?  If you want exact 1.8.6 then take
1.8.6.  Or do you see changes in the third number as sole bug fix 
changes?

>  It sounds as if 1.8.8 intends  
> to take this farther, so code written to that won't work in the  
> different 1.8.7 branch or the earlier 1.8.6 and lower stuff.

But if I understand this correctly, 1.8.6 code will also run on 1.8.7
and later.

>  Thus I  
> feel we now have three different versions of Ruby 1.8 on the table  
> (counting the not yet released 1.8.8).

That seems to be the case.  Maybe 1.8.7 should really have been 1.9.0
but that version is taken already...  IMHO the changes in 1.9 are big
enough to warrant a 2.x but I guess Matz et al. have put quite a bit of
thought into the version numbers - so maybe we should hear that before
we make any judgments about what fits in a release and what not.

Kind regards

  robert

On Wed, Feb 11, 2009 at 1:42 PM, M. Edward (Ed) Borasky 
<zznmeb@gmail.com>wrote:

> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>
> 1. The Ruby community should proceed with all deliberate speed towards
> ISO standardization of the language.


Matz and his team announced that they were beginning and effort towards 
this
end at RubyConf 2008.

However, I'm not sure I understand if their approach of doing this under 
the
aegis of (IIRC) the Linux Foundation gets us to an ISO standard, based 
on my
experiences of the ANSI/ISO process when I worked on standards like 
X3J20
for Smalltalk.


> facto" standard versions have designated numbers already, why not keep
> them as they are?


As others point out, there are a lot of packaging systems which make the
assumption that a minor version number change is compatible.  When the 
ruby
team breaks that assumption, it can cause havoc for those who install 
and
maintain their system with standard tools like dpkg/apt-get, ports, etc.

Some of the maintainers of packaged software don't really work with the
packages they maintain, and aren't necessarily aware of or appreciative 
of
philosophical differences like these. When the upstream developers break 
the
assumptions of the package maintainers, it can lead to as much trouble 
as
when the package maintainers disagree with the philosophy of the 
upstream
developers and do things their own way. I'm talking about what 
debian/ubuntu
do/did to rubygems here.



--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

I've seen many people claiming this, and they might be right of
course, but no one has shown any examples yet. If it is so hard to
find 1.8.6 code that doesn't work with 1.8.7, the backward
compatibility of 1.8.7 seems to be pretty good.

Regards,
Pit

On Wed, Feb 11, 2009 at 4:13 PM, Robert Klemme
<shortcutter@googlemail.com>wrote:

>>
>> I'm bothered by the new versioning scheme.
>>
>> The new releases involve big changes and even if they are fully  backwards
>> compatible about what they will run, they are still creating  pretty big
>> compatibility gaps.  Code using any of the new 1.8.7  features won't run on
>> 1.8.6 and lower.
>>
>
> Well, but this is usual, isn't it?  If you want exact 1.8.6 then take
> 1.8.6.  Or do you see changes in the third number as sole bug fix changes?


That's the industry practice, a minor version number change normally 
means
that there should be no or very little impact on the installed base of
'legacy' code.




  It sounds as if 1.8.8 intends  to take this farther, so code written 
to
> that won't work in the  different 1.8.7 branch or the earlier 1.8.6 and
> lower stuff.
>

But if I understand this correctly, 1.8.6 code will also run on 1.8.7 
and
> later.


I must say that I'm not entirely up to date with what NOW works on 
1.8.7,
the stuff which used to break, e.g. rails and many gems has been 
catching up
to the changes, but that is cold comfort for those who are faced with a
broken deployment and either have to back-level dependencies, or go 
through
a sometimes painful process of migrating  a large application from the
version of, say rails, they were using to the new one which runs on 
1.8.7.

It's not so much of a problem for folks writing standalone code, or code
with a small set of dependencies, but it has, and I suspect it continues 
to
have, a large impact on a lot of folks trying to maintain their bread 
and
butter.


>
As I remember it, Matz didn't want to have a version number like 1.8.10, 
and
since there was danger of 'running out' the version numbering scheme was
changed to make 1.9.0  the 'unstable' development release, and use a 
teeny
number greater than or equal to 1 to indicate stability.  This was OK as 
it
stood, but then 1.8.7 came along and introduced incompatible changes
backported from 1.9.0.

Regardless of the percentage of gems and frameworks which have been 
updated
to work with 1.8.7. I still maintain that the backporting in 1.8.7 was a 
bad
idea, and pushing it further would compound the problem.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:

> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>
> I've seen many people claiming this, and they might be right of
> course, but no one has shown any examples yet.

This is trivial to prove.  This code:

   Object.new.tap { |o| p o }

runs on 1.8.7 and not 1.8.6.

James Edward Gray II

Pit Capitain wrote:
> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
> 
> I've seen many people claiming this, and they might be right of
> course, but no one has shown any examples yet. If it is so hard to
> find 1.8.6 code that doesn't work with 1.8.7, the backward
> compatibility of 1.8.7 seems to be pretty good.

Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

But this misses the main point - that there is no assurance that code
developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of
checking, other than scrutinising the ChangeLog. This is a huge
disservice to library authors and users.

a

On Wed, Feb 11, 2009 at 4:53 PM, James Gray 
<james@grayproductions.net>wrote:

>
> This is trivial to prove.  This code:
>
>  Object.new.tap { |o| p o }
>
> runs on 1.8.7 and not 1.8.6.
>

True, although the real issue is that there is code which runs on 1.8.6 
and
doesn't run 'correctly' on 1.8.7.

The real problem is when the semantics have changed, and this breaks
frameworks and gems and such.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

Le 11 février 2009 à 22:53, Alex Fenton a écrit :

> 
> But this misses the main point - that there is no assurance that code 
> developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of 
> checking, other than scrutinising the ChangeLog. This is a huge 
> disservice to library authors and users.

Somehow, I was wondering why the "new" code in 1.8.(7|8) isn't made
available through a library.

Something like :

require "compat-1.9"

Object.new.tap { |o| p o }

I guess that it's a lot of work if it's implemented in C, but maybe the
work that went into backporting the functionality was misdirected and
could have been more useful in doing a few ruby-written libraries to
help smoothen the transition...

My 2 euro-cents.

Fred

2009/2/11 Alex Fenton <alex@deleteme.pressure.to>:
> Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

AFAIK 1.8.7 introduced a method that Rails was using. This could have
happened in previous Ruby upgrades as well. I don't see why this is
something special with 1.8.7.

As for the C extensions: do you have more information about what was
changed in the Ruby internals that lead to those problems?

> But this misses the main point - that there is no assurance that code
> developed using 1.8.7 (or 1.8.8) will run on 1.8.6.

Again, this is nothing special with the 1.8.7 release. It has been
like this since I'm using Ruby, which is since 2000. The important
point is that (most) 1.8.6 code still runs on 1.8.7.

The only thing I understand you having problems with is that for other
software projects you can expect that for example no new methods are
introduced between a.b.c and a.b.d, so that the Rails problem wouldn't
have occurred there. But, again, Ruby version numbers have never been
working like that. Despite this we have been able to arrive at 1.8.6,
and I still don't see what's so special with 1.8.7 that we should stop
at 1.8.6.

Regards,
Pit

2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:

> True, although the real issue is that there is code which runs on 1.8.6 and
> doesn't run 'correctly' on 1.8.7.
>
> The real problem is when the semantics have changed, and this breaks
> frameworks and gems and such.

But this is because the former was consider a bug or for another
reason? For example, (taken from
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/NEWS )

* Date.parse

    '##.##.##' (where each '#' is a digit) is now taken as 'YY.MM.DD'
    instead of 'MM.DD.YY'.  While the change may confuse you, you can
    always use Date.strptime() when you know what you are dealing
    with.

Looks like a really strange change to me. In fact, it confuses me. Ok,
I know I can use Date.strptime when I know what I'm dealing with, but
I still don't get the point.

Someone can enlighten me, please?

Regards,

Serabe

M. Edward (Ed) Borasky wrote:
>    All other versions are irrelevant and a waste of precious developer
>    energy as far as I'm concerned.

But what if they want to waste their energy there?

To maintain an old piece of crap like MRI cannot be nothing but boring. 
Every
precious developers you can think of is precious just because he/she can 
create
a bright new idea. No one wants to nurse a dead-ended product.

+1 if 1.8.7 can't run 1.8.6 code. I don't so much care if they *add*
abilities to bridge to 1.9.

That said, I have a simple solution. Move to 1.9.1 as fast as your
fingers will allow. Do not pass go. Do not collect $200. Get'r done.

T.

2009/2/11 Pit Capitain <pit.capitain@gmail.com>

> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
> > Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>
> I've seen many people claiming this, and they might be right of
> course, but no one has shown any examples yet. If it is so hard to
> find 1.8.6 code that doesn't work with 1.8.7, the backward
> compatibility of 1.8.7 seems to be pretty good.



Requires hoe, ZenTest and 1.8.6 and 1.8.7 installed using multiruby:

git clone git://github.com/jcoglan/packr.git packr
cd packr
git co -b 3.1 origin/3.1
git co 4cc307
rake multi

This is not using any new 1.8.7 features, it's using 1.8.6 behaviour 
that
broke. Under 1.8.6, hashes had keys inserted in the order in which they
appear in the source, which is not true of 1.8.7. Granted, this ordering 
was
never explicitly intended for 1.8.x, but still it introduced major bugs 
in
my code. PackR still has a bug I'm unable to fix on 1.8.7, though 
thankfully
it's not a show-stopper, it's a nice-to-have 'bonus feature' that 
doesn't
work.

I for one do not want to pull updates to ruby1.8 from my package manager 
and
have even more of my code break, esp. as I maintain various libraries 
and
it's hell having to explain to people that my code is broken because 
their
package manager is not fine-grained enough and they need to install 
stuff
from source. I expect stuff to not be 100% on 1.9, but my experience so 
far
is that 1.9 has caused me fewer and more easily fixable bugs than 1.8.7.

[climbs to the top of the pile-up]

This is like an argument about what to do with the tricycle you rode as 
a kid.  Sure you may disagree about the current condition of the 
tricycle, but really, who cares?  You are grown up now.  You can avoid 
the issue entirely if you just stop riding the tricycle.

F. Senault wrote:
>
> Object.new.tap { |o| p o }
>
> I guess that it's a lot of work if it's implemented in C,

I don't see why it would be -- wouldn't be the first C extension -- but
it's possbile I just don't understand the issue.

Regardless, many of these are just trivial.

class Object
  def tap
    yield self
    self
  end
end

class Symbol
  def to_proc
    proc {|x| self.send(x) }
  end
end

There are a few, like public_send (which I really should be using there)
-- actually missing from 1.8.7, but I've actually got my own implemented
somewhere. In fact, the above don't really even need to be aware of
version numbers -- just something like:

unless Object.new.respond_to? :tap
  class Object
    def tap
...

unless :to_proc.respond_to? :to_proc
  class Symbol
    def to_proc
...

That would allow such libraries to be distributed as gems, and they'd do
no harm if run under 1.9 -- if there's already a C version in place, use
that, otherwise, add our own ruby version.

In fact, this is already how I develop things. I test on 1.8.7 and
1.9.1, but anything I build should work on 1.8.6 as well -- so far,
there's been nothing added to 1.8.7 that can't be added to 1.8.6 as
well, using plain old Ruby.

On Wed, Feb 11, 2009 at 6:44 PM, Mike Gold <mike.gold.4433@gmail.com> 
wrote:
> [climbs to the top of the pile-up]
>
> This is like an argument about what to do with the tricycle you rode as
> a kid.  Sure you may disagree about the current condition of the
> tricycle, but really, who cares?  You are grown up now.  You can avoid
> the issue entirely if you just stop riding the tricycle.

You're right. So then perhaps the whole 1.8 series should be
end-of-lifed.  I'd be fine with that.
But Ruby 1.8.7 is more like thaking the old tricycle out and putting a
car engine on it.

Cute, but not a very useful tricycle or car at that point.

-greg

On Wed, Feb 11, 2009 at 12:53 PM,  <w_a_x_man@yahoo.com> wrote:
> The process of ANS standardization decimated the Forth community

I don't think that's the case. What "decimated" the Forth community
was the emergence of microprocessors powerful enough to run languages
other than Forth and usable optimizing compilers for the C language
for less-powerful microprocessors that previously could only be
effectively programmed in Forth. Yes, the standardization process was
contentious, and I have no doubt Ruby's will be as well. But I think
it's something the community needs to do. Maybe the outcome of this
thread / discussion will be to establish an on-line "standards
committee".

--
M. Edward (Ed) Borasky

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

Charles Oliver Nutter wrote:
> And note also that Ruby core has only a few resources to maintain Ruby
> versions...which means the existence of 1.8.7 and plans for 1.8.8 will
> eventually force 1.8.6 to be abandoned like 1.8.5 and 1.8.4. How would
> you feel about 1.8.6 being EOLed because of 1.8.7 and 1.8.8 taking up
> resources?

This can of course be avoided if someone else follows me to continue 
supporting
1.8.6.  Merging back upper stream changes into 1.8.6 is actually easy; 
it is an
automated process and you do not have to write C until "svn merge" 
conflicts
something.  The harder part is to decide which one to merge.

On Wed, Feb 11, 2009 at 3:03 PM, Trans <transfire@gmail.com> wrote:
> +1 if 1.8.7 can't run 1.8.6 code. I don't so much care if they *add*
> abilities to bridge to 1.9.
>
> That said, I have a simple solution. Move to 1.9.1 as fast as your
> fingers will allow. Do not pass go. Do not collect $200. Get'r done.
>
> T.
>
>

That's exactly *my* plan, but I don't have legacy Rails apps or large
RSpec test suites to maintain.


--
M. Edward (Ed) Borasky

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

Hi Greg et al,

I'd really love to have only 1.8.6 (or compatible) then 1.9.x.

Having more seems like a waste of efforts and will (I'm afraid) make
it more difficult to ensure various plugins/gems do work properly. As
a consequence the ruby/rails/merb etc applications maintainers will
meet more trouble.

+1 for 1.8.x staying compatible with 1.8.6, absolutely.

-- Thibaut

On 11/02/2009, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

>  In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine
> standalone releases, but making them be minor version number changes
> essentially forces everyone to upgrade eventually, whether they want to or
> not, since Ruby distributors generally don't expect a 0.0.x release to be
> filled with incompatible changes or additions. Ubuntu, for example, now
> installs 1.8.7 by default, so Ubuntu users are now much more likely to write
> code that doesn't work on 1.8.6.

+1

On 11/02/2009, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
>  a bright new idea. No one wants to nurse a dead-ended product.
That's completely fine but then mark the bright new idea as such, not
as a version of a dead-end product. It will do good service to both
the bright new idea and the dead-end product if they are labeled
correctly.

Thanks

Michal

Pit Capitain wrote:

> AFAIK 1.8.7 introduced a method that Rails was using. This could have
> happened in previous Ruby upgrades as well. I don't see why this is
> something special with 1.8.7.


That's the point: library authors should be able to write against a
'stable' version of the language, without fearing that a Ruby branch
maintainer is going to happen to fancy to add a clashing method.

As a library author, it's fair to ask me to track pre-release versions
of 1.9, if I want to ensure timely compatibility with that. But it's not
reasonable to ask me to track changes on a 'stable' branch.


> As for the C extensions: do you have more information about what was
> changed in the Ruby internals that lead to those problems?

http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645

>> But this misses the main point - that there is no assurance that code
>> developed using 1.8.7 (or 1.8.8) will run on 1.8.6.
> 
> Again, this is nothing special with the 1.8.7 release. It has been
> like this since I'm using Ruby, which is since 2000. The important
> point is that (most) 1.8.6 code still runs on 1.8.7.

A folly repeated is not a folly reduced. I've suffered from this before
1.8.5 -> 1.8.6, and been critical of it before.

I guess that 1.8.7 has just happened to make the silliness of adding a
random pot-pourri of features more apparent to more people.

alex

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, 
respond"
    on Thu, 12 Feb 2009 06:54:09 +0900, Alex Fenton 
<alex@deleteme.pressure.to> writes:

|> compatibility of 1.8.7 seems to be pretty good.
|
|Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

We know the Rails issue (and solved), but could you elaborate on
issues with wxRuby and SWIG?

              matz.

Yukihiro Matsumoto wrote:

> In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, respond"
>     on Thu, 12 Feb 2009 06:54:09 +0900, Alex Fenton <alex@deleteme.pressure.to> writes:
> 
> |> compatibility of 1.8.7 seems to be pretty good.
> |
> |Well, Rails. And many SWIG-based C-extensions - eg wxRuby.
> 
> We know the Rails issue (and solved), but could you elaborate on
> issues with wxRuby and SWIG?

http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645

a

Urabe Shyouhei wrote:
> M. Edward (Ed) Borasky wrote:
>>    All other versions are irrelevant and a waste of precious developer
>>    energy as far as I'm concerned.
> 
> But what if they want to waste their energy there?

Then they have picked the wrong place for their energies. People should
be branch maintainer because they have pride in good engineering, not to
acquire a private laboratory for what they think are 'cool' features.

> To maintain an old piece of crap like MRI cannot be nothing but boring.  Every
> precious developers you can think of is precious just because he/she can create
> a bright new idea. No one wants to nurse a dead-ended product.

People - including me - do, on many open-source projects. Of course it
is a bit boring to have to work with old structures, when the future can
be seen. But people do so because they see it's important work to give
confidence in the broader project.

If someone thinks it's *so* boring, then they should work on the
bleeding edge, not become "stable" maintainer. I'd rather 1.8 stagnate
than change so randomly.

a

From: "Rick DeNatale" <rick.denatale@gmail.com>
> 
> As I remember it, Matz didn't want to have a version number like 1.8.10

For what it's worth, my recollection is that matz wasn't
_conceptually_ opposed to it, but rather it was not considered
acceptable to break the existing code in the field which performed
version checks based on string compares:

>> "1.8.9" > "1.8.8"
=> true

>> "1.8.10" > "1.8.9"
=> false


Regards,

Bill

On Wed, Feb 11, 2009 at 5:03 PM, Michal Suchanek <hramrach@centrum.cz> 
wrote:
> On 11/02/2009, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
>>  In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine
>> standalone releases, but making them be minor version number changes
>> essentially forces everyone to upgrade eventually, whether they want to or
>> not, since Ruby distributors generally don't expect a 0.0.x release to be
>> filled with incompatible changes or additions. Ubuntu, for example, now
>> installs 1.8.7 by default, so Ubuntu users are now much more likely to write
>> code that doesn't work on 1.8.6.
>
> +1

I haven't checked Fedora recently, but openSUSE 11.1 ships Ruby 1.8.7 as 
well.
--
M. Edward (Ed) Borasky

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

Bill Kelly wrote:
>>> "1.8.9" > "1.8.8"
> => true
> 
>>> "1.8.10" > "1.8.9"
> => false

I remember that... did anyone ever suggest other number bases?

irb(main):001:0> "1.8.9" > "1.8.8"
=> true
irb(main):002:0> "1.8.A" > "1.8.8"
=> true

Nah, too weird!

Alex Fenton wrote:
>> But what if they want to waste their energy there?
> 
> Then they have picked the wrong place for their energies. People should
> be branch maintainer because they have pride in good engineering, not to
> acquire a private laboratory for what they think are 'cool' features.

I don't intend to attack but for instance _why hasn't been touching his 
yaml
stdlib for years, in spite of yaml bugs continuously reported.  If _why 
had
such pride you say, can that be possible?

Again, I'm not attacking _why.  It's a nature of geek being that they 
get
interested in a new thing than old ones.  Some people like you may be 
able to
maintain existing codes, but not everyone.  Do not expect others to 
behave as
you do.

>> To maintain an old piece of crap like MRI cannot be nothing but
>> boring.  Every
>> precious developers you can think of is precious just because he/she
>> can create
>> a bright new idea. No one wants to nurse a dead-ended product.
> 
> People - including me - do, on many open-source projects. Of course it
> is a bit boring to have to work with old structures, when the future can
> be seen. But people do so because they see it's important work to give
> confidence in the broader project.

Of course not everyone ignore bugs.  In fact most bugfixes aren't 
possible
without many helps of core developers.  It's hence important for us not 
to
prevent core people to pray with Ruby.  Bugfixes and new features are 
both
sourced from a developer brain and are dripped into Ruby 1.8 source code
altogether. To filter bugfixes only isn't easy, palming off that job to 
them
should drastically decrease their amount of output.  That shouldn't make 
us happy.

> If someone thinks it's *so* boring, then they should work on the
> bleeding edge, not become "stable" maintainer. I'd rather 1.8 stagnate
> than change so randomly.

I suspect that's why no one but me is touching 1.8.6 now.

Urabe Shyouhei wrote:

> I don't intend to attack but for instance _why hasn't been touching his yaml
> stdlib for years, in spite of yaml bugs continuously reported.  If _why had
> such pride you say, can that be possible?

+1

> Again, I'm not attacking _why.  It's a nature of geek being that they get
> interested in a new thing than old ones.  Some people like you may be able to
> maintain existing codes, but not everyone.  Do not expect others to behave as
> you do.

I expect people to unit test their libraries and leave them open for 
others to
fix. YAML can't recover from syntax errors, can't accurately report 
them, and
experiences a stray pointer bug when it tries. Yes the lexer is awesome, 
but
libyaml is riiiight around the corner...

> I suspect that's why no one but me is touching 1.8.6 now.

I do 1.8.6, and so does my shop.

Joel VanderWerf wrote:
>>
> irb(main):002:0> "1.8.A" > "1.8.8"
> => true
>
> Nah, too weird!
>

I was looking at Erlang the other day.
On the front page of erlang.org:

"Erlang/OTP R12B-5 released*"*



-Justin

Gregory Brown wrote:
> I am setting up two threads
...
> 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'.

I think it's too late to go back now, but +1 to wishing 1.8.7 had never 
existed. It causes all sorts of confusion even on this mailing list as 
to what features do or do not exist in ruby 1.8, and gives admins an 
unnecessary dilemma: upgrade all production boxes to new and relatively 
untested code which may break existing applications? Or suffer the 
complaints from new applications which start to rely on the new 
features?

This was all handled much better in the 1.6 -> 1.8 transition.

* 1.6 was stable
* 1.7 was developmental, and added a bunch of features
* finally it was released as 1.8
* there was no meddling with 1.6
* A separate "shim" library was released which included a number of 
useful new features from 1.8 (e.g. StringIO), which allowed some code 
written using 1.8 features to run under 1.6, thus extending the lifetime 
of 1.6

Under this model: 1.9 would have been experimental, it would have been 
released eventually as 1.10 (or as 2.0, I don't care). 1.8 would have 
been a stable production branch, and for those people who wanted 
1.10/2.0 features, there would be an optional compatibility library.

As for numbering, it's not so important, but the current scheme is silly 
and appears to be based on an irrational fear of exceeding 1.9. AFAICT, 
this is either because the string "1.10" doesn't sort after "1.9", or 
because 2.0 would somehow imply the language is especially "blessed" or 
"finalised".

On that basis, 2.0 will never be released. IMO, YARV was a big enough 
change to warrant a new major number. If you want to see numbering done 
properly, look at FreeBSD's release process.

Anyway, I look forward to running ruby version 1.9.9.9 in future years 
:-)

Bill Kelly wrote:
>>> "1.8.9" > "1.8.8"
> => true
> 
>>> "1.8.10" > "1.8.9"
> => false

I remember the discussions. I stand by my assertion that this is a bug.

- Charlie

In article <Y2Ekl.10025$cg.1125@newsfe24.ams2>,
Alex Fenton  <alex@deleteme.pressure.to> wrote:
>last night, and in particular Akinori MUSHA's statement:
>
>"Yes.  Backporting syntactic changes is a big part of the plan for ruby
>1.8.8"

It boggles the mind to read that. I have an enormous respect for you
Akinori-san for both your FreeBSD and Ruby work but that's poppycock.

>Luckily I was in bed else I'd have fallen off my chair. This seems to me 
>the most bonkers development plan I've seen in a long while.
>
>Stable releases are meant to be *stable*; minor point releases are meant 
>to be *API compatible*, backwards and forwards. I can't think of any 
>other serious open-source project that would even contemplate adding 
>random bits of syntax and API calls in minor releases.

+1000

I feel 1.8.7 is the biggest mistake the Ruby developers have made, it 
muddies
the water about what are 1.8 and 1.9 (as if the problem about 1.9 not 
being
ruby2 or rite or whatever it is called was not enough!), don't encourage
people to move over to 1.9 at all.

I also think this is an software engineering mistake as well. You 
*never*
introduce API or language changes in a stable branch, ever. Worse, it 
was done
in a *minor* revision. What are you guys smokin'?

We don't need any glibc-like crazyness in Ruby, thanks. It is already
difficult enough to advocate Ruby over Python already with the almost 
non
existent Unicode/UTF-8 support (and quirky when something exist)...

I also think m17n is way too complicated in 1.9 but that's another 
windmill to
fight for.

>I expressed the same opinion at length and with some fervour regarding 
>the release of 1.8.7: http://www.ruby-forum.com/topic/150251#663291

So did I, several times.

Sorry for ranting but seeing my favorite language go these ways is 
taking on
me.

In article 
<deb2337a0902111303o7a281d6bw1b7368db82b83864@mail.gmail.com>,
Rick DeNatale  <rick.denatale@gmail.com> wrote:
>On an aside do any of the OS X users know if there's a way in Macports to
>pin the version number of a package?  The whole Ruby 1.8.7 thing has made me
>very paranoid of doing an errant port upgrade.

Following a ticket I opened a few weeks ago, someone has created a 
ruby186
port.

On Feb 12, 4:21 am, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
>
> >>> "1.8.9" > "1.8.8"
> > => true
>
> >>> "1.8.10" > "1.8.9"
> > => false
>
> I remember the discussions. I stand by my assertion that this is a bug.

I don't know about the discussions relating to this behavior, but I
find it dismaying that anyone would seriously say that this isn't
desired string comparison behavior. I mean, these are *strings*, not
anything special. They just happen to contain a certain pattern of
characters.

Or maybe you meant the bug was that people were comparing strings at
all, which is understandable (though a strange word choice).

Maybe we should start up the Perl v-string[1] debates in the Ruby
community. Actually, if Ruby core (or stdlib) had v-strings, that
would be a part of rubygems that could by set free from its cold, dark
p4 prison.


[1]: For a good time: 
http://search.cpan.org/~ferreira/Data-VString-0.000004/lib/Data/VString.pm

Hi --

On Thu, 12 Feb 2009, Yossef Mendelssohn wrote:

>>> acceptable to break the existing code in the field which performed
> I don't know about the discussions relating to this behavior, but I
> find it dismaying that anyone would seriously say that this isn't
> desired string comparison behavior. I mean, these are *strings*, not
> anything special. They just happen to contain a certain pattern of
> characters.
>
> Or maybe you meant the bug was that people were comparing strings at
> all, which is understandable (though a strange word choice).

I think Charlie meant that a version comparison algorithm that didn't
understand that ".10" was greater than ".9" was buggy.


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!

Le 12 février à 15:25, Yossef Mendelssohn a écrit :

> I mean, these are *strings*, not anything special. They just happen 
> to contain a certain pattern of characters.

Any Ruby string can become special :

>> RUBY_VERSION = RUBY_VERSION.dup
(irb):5: warning: already initialized constant RUBY_VERSION
=> "1.8.6"
>> class <<RUBY_VERSION ; def <=>(b)
>>    self.split(/\./).collect { |x| x.to_i } <=> b.split(/\./).collect { |x| x.to_i }
>>    end ; end
=> nil
>> RUBY_VERSION.freeze
=> "1.8.6"
>> RUBY_VERSION < '1.8.10'
=> true

But not '1.8.10' > RUBY_VERSION, alas !

:)

Fred

2009/2/11 James Gray <james@grayproductions.net>:
>
>  Object.new.tap { |o| p o }
>
> runs on 1.8.7 and not 1.8.6.

1.8.x releases always introduced new methods.
If Ruby releases were done how the mob here wants
them, we wouldn't have a single new method since
1.8.0 was released in 2003.

Important is backwards compatibility and Ruby 1.8.7
is backwards compatible. Nobody so far has shown
where 1.8.7 is not backwards compatible.

That Rails broke was their own fault. They extend core
classes, so clashes are to be expected. If they had
tested with an 1.8.7 release candidate, I'm sure they
could have worked out a solution with the 1.8 maintainers.

Stefan

Stefan Lang wrote:

> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.

What a great way to lead people into your viewpoint!

> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.

require 'rubynode'

2009/2/12 Phlip <phlip2005@gmail.com>:

>> Important is backwards compatibility and Ruby 1.8.7
>> is backwards compatible. Nobody so far has shown
>> where 1.8.7 is not backwards compatible.
>
> require 'rubynode'

From http://rubynode.rubyforge.org/:
  "RubyNode is a library that allows read only access to Ruby's
  internal NODE structure."

It's cool that such libraries exist, but AFAIK MRI's
internal AST is  not part of its public API, much
less part of Ruby 1.8, the language.

Stefan

>
>
> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.



See my earlier demonstration:

git clone git://github.com/jcoglan/packr.git packr
cd packr
git co -b 3.1 origin/3.1
git co 4cc307
rake multi

No monkey-patching on my part, just existing 1.8.6 behaviour that 
changed in
1.8.7. I'm all for additions, as long as established behaviour is 
stable.
Additions should not break existing code if you're not monkey patching.

@_why I'm not interested in joining a mob and I'm not going to be mad at
Matz et al if they disagree with me. Just responding to a question, hope
none of this appears mob-like.

On Fri, 13 Feb 2009, Stefan Lang wrote:

>> This is trivial to prove.  This code:
>>
>>  Object.new.tap { |o| p o }
>>
>> runs on 1.8.7 and not 1.8.6.
>
> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.

There's no mob. I wish people would stop using that word in this
thread. These are, to a large extent, friends of mine, and friends of
the core team members, discussing an exceptionally important Ruby
issue with ardency but with collegiality.

Much, much more has been said about the issues involved in the recent
version policy than that it's bad to introduce any new methods in
teeny versions (and that, as far as I can see, has *not* been said).

My main problem with it is that, while I understand the idea of 1.8.7
and 1.8.8 as stepping stones to 1.9.1, I don't think we need any
stepping stones. I've been learning 1.9 pretty intensely over the past
year, and I have never felt the need to have a 1.8 version that had
1.9 features. 1.9 has kept me quite busy.

I also love 1.8.6, and while I think a lot of 1.9 features are great,
I've never felt like I can't go another day (week, month, whatever)
without them.

So the whole backporting thing has been a puzzle to me. I think, in
any case, that there's no one thing (1.8.7 not running 1.8.6 code;
1.8.x ceasing to mean what a.b.x has generally meant in the past;
1.8.>6 leading to more, rather than less, trepidation about moving to
1.9; the issues with non-MRI implementations that Charlie and Evan
have talked about, etc.) responsible for the misgivings. It's a kind
of perfect storm of all these things.

I don't see any long-term way out of it except to focus on the move to
1.9.1. I don't mean that as a repudiation of anyone's work. It's my
assessment of where things stand, however they got there.


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!

2009/2/12 James Coglan <jcoglan@googlemail.com>:
> git clone git://github.com/jcoglan/packr.git packr
> cd packr
> git co -b 3.1 origin/3.1
> git co 4cc307
> rake multi
>
> No monkey-patching on my part, just existing 1.8.6 behaviour that changed in
> 1.8.7. I'm all for additions, as long as established behaviour is stable.
> Additions should not break existing code if you're not monkey patching.

It would be helpful to see exactly what fails.

Stefan

On Fri, 13 Feb 2009, David A. Black wrote:

> Much, much more has been said about the issues involved in the recent
> version policy than that it's bad to introduce any new methods in
> teeny versions (and that, as far as I can see, has *not* been said).

A followup to this:

I think there are two important points to keep in mind. First, it's a
matter of degree, not kind. In other words, no one is saying that
1.8.7 should be indistinguishable from 1.8.6. It's more the quantity
of change that's at issue. Here's a very crude metric, showing the
results of instance_methods(false) for various classes and modules
across three 1.8 versions:

1.8.2
String: 83
Array: 71
Hash: 45
Range: 15
Enumerable: 22

1.8.6
String: 83
Array: 71
Hash: 45
Range: 15
Enumerable: 22

1.8.7
String: 91
Array: 83
Hash: 47
Range: 15
Enumerable: 43

(Gotta love Range :-)

Of course there's no cut-off point where it ceases to be good, or
whatever. It's a matter of judgment.

The second important point is that it's not so much a matter of 1.8.7
not running 1.8.6 code, as the degree to which people expect teeny
versions to behave the way they always have -- and that means, in the
main, developing 1.8.7 code and expecting no more than a few bug-fixes
and maybe the necessity to shim a couple of methods when running it on
1.8.6 installations.

I don't think there's any question about the fact that 1.8.7 redefined
the teeny method semantics, and that it all goes back to the 1.10
issue. And of course the numbering is arbitrary and human-made, and a
given sequence of digits isn't inherently better or worse than another
sequence. It's about expectations and how the changes, once made, play
out.


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!

> > No monkey-patching on my part, just existing 1.8.6 behaviour that changed
> in
> > 1.8.7. I'm all for additions, as long as established behaviour is stable.
> > Additions should not break existing code if you're not monkey patching.
>
> It would be helpful to see exactly what fails.



The cause of the failing tests is a change to Hash ordering between
versions. See the fix patch for a better idea:

http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849

2009/2/12 James Coglan <jcoglan@googlemail.com>:
>> > No monkey-patching on my part, just existing 1.8.6 behaviour that changed
>
> http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849
>

What do you mean with "Hash ordering"?
An order for Hash instances? Hash doesn't define a <=> method.
Or iteration order of Hash elements? That wasn't defined
in 1.8.6 (I don't know if it is in 1.8.7).

Stefan

Engine Yard is willing to step up as the official maintainer of
ruby1.8.6. We can provide the right amount of human resources as well
as server and QA resources with automated CI running the rubyspecs.

  I feel that it is very important to keep a stable ruby 1.8.6 lineage
for some time to come.

  Matz has stated that he is willing to pass the torch on maintenance
of ruby1.8.6 and we would like to step up to the plate for the whole
ruby community. Please respond here if you think Engine yard would
make good maintainers of the ruby1.8.6 lineage

Thanks

Ezra Zygmuntowicz
ez@engineyard.com

Ezra Zygmuntowicz wrote:
> the whole ruby community. Please respond here if you think Engine yard 
>
+1.

--
 Ola Bini (http://olabini.com)
 Ioke creator (http://ioke.org)
 JRuby Core Developer (http://jruby.org)
 Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
 Practical JRuby on Rails (http://apress.com/book/view/9781590598818)

 "Yields falsehood when quined" yields falsehood when quined.

On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com> 
wrote:
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

I think that's a great idea.  Restating what I said on ruby-core:

This would give those of us who need a stable legacy 1.8 to follow a
place to look for bug fixes and stablizations.   We would be free to
choose whether we want to support this sort of next-generation Ruby
1.8 that ruby-core provides, and no matter what side of the fence
you're on, you can always follow Ruby 1.9.1 as well if you wish.  In
my case, I'd likely be supporting EYRuby (or whatever you'll call it),
and Ruby 1.9.1 from the core team for my projects.  Others could mix
and match as they please, but they will have the luxury of not having
to dig down into a single release of a branch that has diverged from
it.  That's cool all around.

Just one question:  Have you though about version numbering / naming
schemes yet?

-greg

On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz 
<ezmobius@gmail.com>wrote:

> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage
>
>
+1

Although, I'm at a loss as to what you'd use for the version number on 
the
first maintenance release.


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

* Ezra Zygmuntowicz <ezmobius@gmail.com> [2009-02-13 02:22:55 +0900]:

> community. Please respond here if you think Engine yard would make good 
> maintainers of the ruby1.8.6 lineage

+1

Thanks,
Jan

On Thu, Feb 12, 2009 at 12:36 PM, Rick DeNatale 
<rick.denatale@gmail.com> wrote:
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com>wrote:
>
>>
>>         Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6. We can provide the right amount of human resources as well as
>> server and QA resources with automated CI running the rubyspecs.

> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.

Just a thought...

RUBY_VERSION #=> "1.8.6"
EY_RUBY_VERSION #=> "1.0.0"

-greg

On Thu, Feb 12, 2009 at 10:22 AM, Ezra Zygmuntowicz <ezmobius@gmail.com> 
wrote:
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

Ezra, this would be an incredible step.  Please, please do it.

>
>
>
> What do you mean with "Hash ordering"?
> An order for Hash instances? Hash doesn't define a <=> method.
> Or iteration order of Hash elements? That wasn't defined
> in 1.8.6 (I don't know if it is in 1.8.7).



In 1.8.6, iteration order would be the same as the order that the keys
appear in the source. To work with 1.8.7, you need to create an empty 
hash
and add keys one by one rather than putting them all in a hash literal 
(see
the patch).

On Feb 12, 2009, at 11:36 AM, Rick DeNatale wrote:

> Although, I'm at a loss as to what you'd use for the version number  
> on the first maintenance release.

1.8.6.1 perhaps?  It still sorts well.

James Edward Gray II

Rick DeNatale wrote:
>>        Matz has stated that he is willing to pass the torch on maintenance
>
>
>   
What about 1.8.6.1?

--
 Ola Bini (http://olabini.com)
 Ioke creator (http://ioke.org)
 JRuby Core Developer (http://jruby.org)
 Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
 Practical JRuby on Rails (http://apress.com/book/view/9781590598818)

 "Yields falsehood when quined" yields falsehood when quined.

On Thu, Feb 12, 2009 at 10:39 AM, Gregory Brown
<gregory.t.brown@gmail.com> wrote:
>
> Just a thought...
>
> RUBY_VERSION #=> "1.8.6"
> EY_RUBY_VERSION #=> "1.0.0"
>

which probably means Ruby 1.8.6.1 or Ruby186 1.0

Ezra Zygmuntowicz wrote:
>
>      Engine Yard is willing to step up as the official maintainer of 
> ruby1.8.6. We can provide the right amount of human resources as well 
> as server and QA resources with automated CI running the rubyspecs.

+1

Personally, I'd rather see a 1.9-compatible Merb, but it's looking like
I'll have to wait for Rails 3 for that.

On Feb 12, 2009, at 3:03 AM, Brian Candler wrote:

> As for numbering, it's not so important, but the current scheme is  
> silly
> and appears to be based on an irrational fear of exceeding 1.9.  
> AFAICT,
> this is either because the string "1.10" doesn't sort after "1.9", or
> because 2.0 would somehow imply the language is especially "blessed"  
> or
> "finalised".

I have no problems with the 1.9 release.  I feel like the reasoning
has been well explained and I understand it.

Essentially, a lot was promised for 2.0.  About half of it has been
built.  We could have kept waiting for the other half, or release what
was done.  It's not all of 2.0 though, so it's instead called 1.9.

Also, it was decided that it's silly to lose an entire branch for
development (like 1.7).  Thus x.x.0 now means development and we only
lose one version number.  That's why 1.9.1 is the first stable release
of the 1.9 branch.

I feel like that all makes sense.

James Edward Gray II

Hi --

On Fri, 13 Feb 2009, James Coglan wrote:

> In 1.8.6, iteration order would be the same as the order that the keys
> appear in the source. To work with 1.8.7, you need to create an empty hash
> and add keys one by one rather than putting them all in a hash literal (see
> the patch).

Hashes aren't ordered at all in 1.8, as far as I know. This works the
same in 1.8.6 and 1.8.7:

irb(main):002:0> h = {3,4,1,2}
=> {1=>2, 3=>4}
irb(main):003:0> h.each {|*x| p x }
[[1, 2]]
[[3, 4]]
=> {1=>2, 3=>4}

and here's a 1.8.7 case with individual key insertion:

irb(main):001:0> h = {}
=> {}
irb(main):002:0> h[3] = 4
=> 4
irb(main):003:0> h[1] = 2
=> 2
irb(main):004:0> h.each {|*x| p x }
[[1, 2]]
[[3, 4]]


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!

2009/2/12 James Coglan <jcoglan@googlemail.com>:
> In 1.8.6, iteration order would be the same as the order that the keys
> appear in the source.

Iteration order is undefined, even for hash literals.
This is on *my* machine:

    $ ruby -v -e '{2 => 0, 1 => 0}.each_pair { |k,v| p k }'
    ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
    1
    2

Your code happened to work by chance.

> To work with 1.8.7, you need to create an empty hash
> and add keys one by one rather than putting them all in a hash literal (see
> the patch).

Do I understand that the code relies on insertion order now?
Then it's still working by chance in case it works at all.

Stefan

On Thu, Feb 12, 2009 at 9:22 AM, Ezra Zygmuntowicz <ezmobius@gmail.com> 
wrote:
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

Thanks!! Yes, I think you'd be ideal for this. I do have some questions, 
though:

1. Would there be a chance of merging the efficiencies of Ruby
Enterprise Edition, especially copy-on-write friendliness, into the
"Engine Yard 1.8.6 stack?"

2. Will this impact Rubinius?

3. Will there be a contribution to the Windows One-Click Installer
project as part of this?

4. Will there be some "community management" / "marketing" effort
associated with interfacing to the major Linux distros?
(Debian/Ubuntu, Fedora/Red Hat/CentOS, openSUSE/SLES/Novell for sure,
and probably Gentoo as well)


--
M. Edward (Ed) Borasky

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

On Thu, Feb 12, 2009 at 12:55 PM, pat eyler <pat.eyler@gmail.com> wrote:
>>> Although, I'm at a loss as to what you'd use for the version number on the
>>> first maintenance release.
>>
>> Just a thought...
>>
>> RUBY_VERSION #=> "1.8.6"
>> EY_RUBY_VERSION #=> "1.0.0"
>>
>
> which probably means Ruby 1.8.6.1 or Ruby186 1.0

Yeah, I think maybe 1.8.6.1 is a better idea than what I offered, 
actually.

-greg

I really feel that Ruby1.8.6 "deserves" more respect. It will probably
be in use for a long time yet.
Now I will not say to whomever is doing this great job on Ruby1.8 you
have to do this or that, I am not *that* stupid.
But those of us, who simply express their sincere opinion on the
subject should not be treated as a mob, or somebody too stupid to
follow to 1.9.1 neither, hopefully most of us agree with this?

Cheers
Robert

+1, because things have broken.

I am happy with 1.8.6 and 1.9. It's just that 1.8.7 introduces a lot
of noise, anyone would expect it to be compatible with 1.8.6, as
mentioned.

Justin Collins wrote:
>>> version checks based on string compares:
>> => true
>> irb(main):002:0> "1.8.A" > "1.8.8"
>> => true
>>
>> Nah, too weird!
>>
> 
> I was looking at Erlang the other day.
> On the front page of erlang.org:
> 
> "Erlang/OTP R12B-5 released*"*

Someday, they'll get up to 27B-6.... (sorry, way too off-topic now).

2009/2/12 Ezra Zygmuntowicz <ezmobius@gmail.com>:
> Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

That'd be great!

Rupert

On Thu, Feb 12, 2009 at 12:54 PM, Ola Bini <ola.bini@gmail.com> wrote:

>>>
>>>
>
As long as the downstream packagers pick up on it, but without 
additional
help, I think that most systems would treat 1.8.7 as compatible with, 
and
'better' than 1.8.6.x.

Examples.

Debian only uses the major and minor to differentiate different 
packages.
The Ubuntu list of Ruby packages illustrates this:
http://packages.ubuntu.com/search?keywords=ruby  There are separate 
Ruby1.8
and Ruby1.9 packages.

Note that the newer Debian systems map Ruby1.8 to Ruby 1.8.7  they also 
seem
to use patchlevel and other information to generate their own fourth 
level
version numbers

Macports only seems to have s single Ruby which is currently at 1.8.7
 >port list ruby
ruby                           @1.8.7-p72      lang/ruby

Considering how much trouble there's been reconciling the issues around
rubygems and debian, I'm not very confident that package maintainers 
will
treat 1.8.6.x and 1.8.7 as different upstream versions.

But I 'll reiterate that I think that the idea of maintaining 1.8.6 with
fixed semantics is a good idea.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Thu, Feb 12, 2009 at 11:35 AM, Rick DeNatale 
<rick.denatale@gmail.com> wrote:
> As long as the downstream packagers pick up on it, but without additional
> help, I think that most systems would treat 1.8.7 as compatible with, and
> 'better' than 1.8.6.x.
>
[elided]
>
> But I 'll reiterate that I think that the idea of maintaining 1.8.6 with
> fixed semantics is a good idea.

Good points.  I wonder what matz is willing to turn over.  If it's the 
1.8 line,
then the next release should probably be 1.8.8 and represent a
continuation of the 1.8.6 line.  If he wants to maintain a 1.8.X and 
1.9.X
line, then I think we need to think about either a 1.8.6.X or a 
RubyClassic
1.0 (or something like it)

Hi,

At Fri, 13 Feb 2009 02:36:06 +0900,
Rick DeNatale wrote in [ruby-talk:327919]:
> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.

1.8.6-p###.

2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>>         Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6.
>> (...)
>
> This would give those of us who need a stable legacy 1.8 to follow a
> place to look for bug fixes and stablizations.

Gregory, there is no Ruby 1.8 and has never been. There have been
1.8.0, 1.8.1, up to 1.8.7, each one differing from the others. I'm
sure that for each new version you can find new methods introduced
and/or behaviour of existing methods changed. This was the point I
never understood: what's so special about the transition to 1.8.7?

I think what most of you really want is to keep 1.8.6, not some
ominous "Ruby 1.8", what ever this should be. Ezra has put this right:
"maintainer of 1.8.6".

So, you keep your 1.8.6, and others can go on to 1.8.7 and beyond. I
think this would be a perfect solution.

Regards,
Pit

On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> 
wrote:
> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others. I'm
> sure that for each new version you can find new methods introduced
> and/or behaviour of existing methods changed. This was the point I
> never understood: what's so special about the transition to 1.8.7?

You keep saying this but frankly, it's ridiculous.  Yes, you can find
changes.  In Ruby 1.8.7, you get clubbed over the head with them.

> I think what most of you really want is to keep 1.8.6, not some
> ominous "Ruby 1.8", what ever this should be. Ezra has put this right:
> "maintainer of 1.8.6".
>
> So, you keep your 1.8.6, and others can go on to 1.8.7 and beyond. I
> think this would be a perfect solution.

We're not in disagreement here.  It's just been my experience that I
can write code on 1.8.6 without thinking about back-wards
compatibility with earlier versions, for the most part.  We all know
that things have changed, but not in so radical a fashion.

What I was supporting was a stable 'flavor' of Ruby 1.8, in the form
of a EY supported 1.8.6.

And I agree completely that this solves the issue without forcing
people in one direction or the other.  If ruby-core wishes to support
1.8.7 and beyond, those who like the idea will not be left
disappointed.

-greg

2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
>> Gregory, there is no Ruby 1.8 and has never been. There have been
>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>
> You keep saying this but frankly, it's ridiculous.  Yes, you can find
> changes.  In Ruby 1.8.7, you get clubbed over the head with them.

So we agree to disagree. Though I'd be interested in what you'd define
as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
will be 1.8.6, so why not name it as such? Why interpret more into it
as it really is?

> We're not in disagreement here.  It's just been my experience that I
> can write code on 1.8.6 without thinking about back-wards
> compatibility with earlier versions, for the most part.  We all know
> that things have changed, but not in so radical a fashion.

Hmm, let's see how radical a change 1.8.7 has been until now:
Hash#hash has been changed (or should I say: fixed), it's not allowed
to allocate new objects during garbage collection anymore (the SWIG
problem), plus (admittedly a large number of) new features have been
added. I wouldn't call this radical, but, again, we just disagree
here, so I'll shut up now.

Regards,
Pit

On Feb 12, 2009, at 1:47 PM, Nobuyoshi Nakada wrote:

> Hi,
>
> At Fri, 13 Feb 2009 02:36:06 +0900,
> Rick DeNatale wrote in [ruby-talk:327919]:
>> Although, I'm at a loss as to what you'd use for the version number  
>> on the
>> first maintenance release.
>
> 1.8.6-p###.

+1 on that.  I never even consider downloading 1.8.7 or later for a
customer... I just grab the most recent 1.8.6-pxxx release.  If p288
came out and didn't break anything, I'd start using that...

Yours,

tom

On Thu, Feb 12, 2009 at 2:33 PM, Pit Capitain <pit.capitain@gmail.com> 
wrote:
> a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
> will be 1.8.6, so why not name it as such? Why interpret more into it
> as it really is?

I understand what you mean here, and actually, you're right in saying
that the term "Ruby 1.8" is completely amorphous.

But I suppose what I'm saying is that from 1.8.2 up until 1.8.6, I did
not once say "Wow! now I can do all this new cool stuff!".   I also
didn't worry too much about whether code I wrote on my latest Ruby 1.8
version would work in various out of date production environments.  I
did not worry about patches from contributors having the same problem
in my open source projects.

The situation also might be different for me if 1.9 didn't exist.  But
I'm not sure you'll agree with my reasoning on that, and it's not
terribly important anyway, so I won't elaborate further.

> here, so I'll shut up now.
I think you're looking at this from the perspective of standalone Ruby
code, and I can see a bit of what you're saying from that perspective.
 But I'm speaking based on my experience of having to deploy code to
older versions of Ruby in a commercial setting, as well as running
several mainstream open source projects that have an active
contributor base.   It is possible that we're 'both right' in our own
situations, and that this solution of having EY run 1.8.6 might give
us the best of both worlds.

I apologize for using vague terminology about '1.8', it's probably the
main source of dispute here.

-greg

Stefan Lang wrote:

> internal AST is  not part of its public API, much
> less part of Ruby 1.8, the language.

So if Ruby 1.8.7 had broken RubyInline, that would be okay?

Pit Capitain wrote:
> will be 1.8.6, so why not name it as such? Why interpret more into it
> as it really is?

"Ruby 1.8" is that which installs libraries into
$PREFIX_DIR/lib/ruby/1.8 .

2009/2/12 Phlip <phlip2005@gmail.com>:
>>  internal NODE structure."
>>
>> It's cool that such libraries exist, but AFAIK MRI's
>> internal AST is  not part of its public API, much
>> less part of Ruby 1.8, the language.
>
> So if Ruby 1.8.7 had broken RubyInline, that would be okay?

If it relies on MRI internals there would definitely be
no fault on the 1.8 maintainers side.

This is common sense. If you rely on internals and monkey
patching, your code can break when you update a dependency.

Stefan

On Thu, Feb 12, 2009 at 11:07 AM, Gregory Brown
<gregory.t.brown@gmail.com> wrote:
> 1.8.7 and beyond, those who like the idea will not be left
> disappointed.

But that still leaves a communication gap between two groups of
implementers -- Engine Yard and "Ruby-Core" -- and the Linux distros
that are probably only going to package *one* Ruby and are expecting
*their* user base to have working Ruby and Rails and gems! Right now,
I'm running openSUSE 11.1, which ships 1.8.7. IIRC RHEL 5 / CentOS 5
are still shipping 1.8.5, and I have no idea what's in the two most
recent versions of Ubuntu, or what's going to be in Debian Lenny when
it releases in  the near future. In short, the distro Ruby herds need
to be in the loop, or the Ruby community will have a bunch of
implementations to choose from.
>
> -greg
>
> --
> Technical Blaag at: http://blog.majesticseacreature.com
>  Non-tech stuff at: http://metametta.blogspot.com
> "Ruby Best Practices"  Book now in O'Reilly Roughcuts:
> http://rubybestpractices.com
>
>



--
M. Edward (Ed) Borasky

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

2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
> But I suppose what I'm saying is that from 1.8.2 up until 1.8.6, I did
> not once say "Wow! now I can do all this new cool stuff!".   I also
> didn't worry too much about whether code I wrote on my latest Ruby 1.8
> version would work in various out of date production environments.  I
> did not worry about patches from contributors having the same problem
> in my open source projects.

Yeah, I think I understand you, too. Of course you could develop right
away in 1.8.7 without using the new features. This code should still
work with 1.8.6. But it would require you to always think about this
necessity, and you would have no immediate feedback when you
accidentally used one of the new features.

> I apologize for using vague terminology about '1.8', it's probably the
> main source of dispute here.

There's absolutely no reason to apologize, Greg. To me the main source
of dispute was that so many people were telling "1.8.7 breaks
compatibility with 1.8.6" but almost no none could prove this.

Just one more remark to Joel's post, and then I'll definitely shut up.

2009/2/12 Joel VanderWerf <vjoel@path.berkeley.edu>:
> "Ruby 1.8" is that which installs libraries into
> $PREFIX_DIR/lib/ruby/1.8 .

Hmm, currently this includes every release from 1.8.0 to 1.8.7, right?

Regards,
Pit

On Feb 12, 4:13 pm, "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
> > of ruby1.8.6 and we would like to step up to the plate for the whole ruby
> > community. Please respond here if you think Engine yard would make good
> > maintainers of the ruby1.8.6 lineage
>

I'll like to jump late on this thread, but just not trying to add more
noise...

> Thanks!! Yes, I think you'd be ideal for this. I do have some questions, though:
>
> 1. Would there be a chance of merging the efficiencies of Ruby
> Enterprise Edition, especially copy-on-write friendliness, into the
> "Engine Yard 1.8.6 stack?"
>

CoW will not be cross-platform compatible (at least not for Windows).
The amount of changes needed by CoW are so big because the C code of
Ruby sometimes can be complicated.

> 2. Will this impact Rubinius?

I hope not, and I think it wouldn't.

> 3. Will there be a contribution to the Windows One-Click Installer
> project as part of this?

I wish they do, or at least merge contributions back :-)

Regards,

On Thu, Feb 12, 2009 at 10:19 PM, Pit Capitain <pit.capitain@gmail.com> 
wrote:

> There's absolutely no reason to apologize, Greg. To me the main source
> of dispute was that so many people were telling "1.8.7 breaks
> compatibility with 1.8.6" but almost no none could prove this.
That is a very good point. My issues however are much more of a
practical or psychological reason
The pure fact that incompatibilities exist, however small, will
certainly not assure me about BW (8.7 -> 8.6 )compatibility for future
releases and neither for FW(8.6->8.7+).
That's why I voted on this thread and not the other one.

I felt that Greg somehow was very much anticipating trouble rather
than seeing it around already. I was quite impressed by that vision,
but that of course does not mean that he/we is/are correct :).

Cheers
Robert

Yossef Mendelssohn wrote:
> Or maybe you meant the bug was that people were comparing strings at
> all, which is understandable (though a strange word choice).

Yes, that's what I meant.

- Charlie

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, 
respond"
    on Fri, 13 Feb 2009 02:10:41 +0900, Stefan Lang 
<perfectly.normal.hacker@gmail.com> writes:

|What do you mean with "Hash ordering"?
|An order for Hash instances? Hash doesn't define a <=> method.
|Or iteration order of Hash elements? That wasn't defined
|in 1.8.6 (I don't know if it is in 1.8.7).

I think he relied on the version/implementation specific behavior, so
1.8.7 HELPED to find a bug in HIS code, unless I am wrong in any ways.
Any other example of 1.8.7 incompatibility?

I am not happy with FUD-like attitude against 1.8.7.  From my point of
view, 1.8.7 is a good release with unfortunate beginning.  There are
slight incompatibility, but every past releases also had some sort of
incompatibilities as well.  I'd like to use 1.8.7 to write new 1.8
code.

It might be true that number of "enterprisey" Ruby users have grown
beyond our expectation, and we might need to keep "maintained stable
snapshot of the past version", which happen to be 1.8.6, for existing
code base, that's OK.  We ARE keeping.  If we want to keep it after
1.8.8 is out (in whatever state), we will need a volunteer to replace
Shyouhei.

EngineYard raised their hands for 1.8.6 maintainer.  It's OK.  I am
not sure when we pass the role, now or future.  In any case, we have
to discuss 1.8.6 maintenance policy.  Let's move to ruby-core.

              matz.

2009/2/12 David A. Black <dblack@rubypal.com>

>>> in 1.8.6 (I don't know if it is in 1.8.7).
>
> Hashes aren't ordered at all in 1.8, as far as I know.



I realise that there is no explicit iteration order specified for hashes 
in
1.8. All I know is that this patch fixed by 1.8.7 bugs:

http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849

Basically involves inserting keys in an explicit order rather than using
hash literals. This project uses a bunch of custom collection classes 
but
they're basically wrappers for arrays and hashes that merge array and 
hash
functionality into a single class. The constructors would iterate over 
the
hashes provided and insert values, and this insertion order changed in
1.8.7.

I would concede that this is something of a grey area as it's neither a 
bug
fix or an explicit feature addition, but the question was asked about 
1.8.6
code that broke, and this is an example. I still have a regex-related 
bug in
this project that I've been unable to fix under 1.8.7. In fact, if 
anyone is
able to fix the last remaining test failure I'd be incredibly grateful.

Hi --

On Fri, 13 Feb 2009, James Coglan wrote:

>>>> An order for Hash instances? Hash doesn't define a <=> method.
>>> the patch).
>>>
>>
>> Hashes aren't ordered at all in 1.8, as far as I know.
>
>
>
> I realise that there is no explicit iteration order specified for hashes in
> 1.8. All I know is that this patch fixed by 1.8.7 bugs:

Sorry, I misunderstood what you were getting at.

> fix or an explicit feature addition, but the question was asked about 1.8.6
> code that broke, and this is an example. I still have a regex-related bug in
> this project that I've been unable to fix under 1.8.7. In fact, if anyone is
> able to fix the last remaining test failure I'd be incredibly grateful.

I can't get any of your tests to fail under 1.8.7, at least the one
I've got installed on the machine where I tried it (pl0).


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!

On 2009-02-12, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>
>    Engine Yard is willing to  step up as the official maintainer
> of ruby1.8.6. We can provide  the right amount of human resources as
> well  as server  and  QA  resources with  automated  CI running  the
> rubyspecs.

This is excellent!

Jeremy Henty

The entire 1.8.x series should be backward compatible to 1.8.6 NOT 
forward compatible to 1.9.x.

Gregory Brown wrote:
> 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+
> 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'.  If you disagree, please find the
> other thread titled 'If you are happy with the direction of Ruby
> 1.8.7, respond'.  If you are in the middle, I don't know what you
> should do... write two posts?
> 
> My goal is to survey ruby-talk so that the core Ruby team has a chance
> to see what people really want.  I'm curious to see if this is as
> one-sided as I think it is.
> 
> -greg

It is absolutely wrong to change major API and syntax within a major 
release series.

1.8.8 should definitely go back to 100% syntactical and regression test 
compatability with 1.8.6

Wayne

Stefan Lang wrote:

> > This is trivial to prove.  This code:
> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.
> 
> That Rails broke was their own fault. They extend core
> classes, so clashes are to be expected. If they had
> tested with an 1.8.7 release candidate, I'm sure they
> could have worked out a solution with the 1.8 maintainers.
> 
> Stefan

+1

Stefan Lang wrote:

> > 
> 
> Your code happened to work by chance.
> 
> > To work with 1.8.7, you need to create an empty hash
> > and add keys one by one rather than putting them all in a hash
> > literal (see the patch).
> 
> Do I understand that the code relies on insertion order now?
> Then it's still working by chance in case it works at all.
> 
> Stefan

+1

Mr. Coglan seems not to understand how a hash-table is implemented.
One cannot predict the iteration order because he cannot know in which
bucket each element has been stored.  Furthermore, it makes no sense
at all to be concerned about iteration-order for a hash-table.

If one is concerned about iteration-order, he should use an
association-list.

An element is fetched a hash-table by key, not by position,
which is undefined.

Hi,

At Fri, 13 Feb 2009 09:16:39 +0900,
James Coglan wrote in [ruby-talk:327995]:
> 1.8.7.
Hash in 1.8 doesn't define any kind of "order".  It's
definitely a bug in your code as you use the word "order".

> I would concede that this is something of a grey area as it's neither a bug
> fix or an explicit feature addition, but the question was asked about 1.8.6
> code that broke, and this is an example. I still have a regex-related bug in
> this project that I've been unable to fix under 1.8.7. In fact, if anyone is
> able to fix the last remaining test failure I'd be incredibly grateful.

Could you post it in another thread?

pat eyler wrote:

> > confusing as to which Ruby I should be using. I understand that
> > 1.8.6 via Pickaxe is a standard and so is 1.9.1 via David Black's
> > upcoming book.
> > 

Have you at work been using practices as egregiously substandard
as top-posting?

David A. Black wrote:

> matter of degree, not kind. In other words, no one is saying that
> Enumerable: 22
> Array: 83
> Hash: 47
> Range: 15
> Enumerable: 43
> 
> (Gotta love Range :-)

No, I don't.  I enjoy having new methods, so long as the behavior of
the old methods is "exempt from mutation".

Alex Fenton wrote:
>> We know the Rails issue (and solved), but could you elaborate on
>> issues with wxRuby and SWIG?
> 
> http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645

This is not our fault.  Please hold on and think yourself.  GC is 
running means
  ruby interpreter is running out of memory.  It is as clear as day that 
object
allocation during GC is not doable, because we do not have any memory 
space.

So SWIG had a bug. 1.8.7 helped to find it out.

On 12/02/2009, M. Edward (Ed) Borasky <zznmeb@gmail.com> wrote:
> > What I was supporting was a stable 'flavor' of Ruby 1.8, in the form
>  *their* user base to have working Ruby and Rails and gems! Right now,
>  I'm running openSUSE 11.1, which ships 1.8.7. IIRC RHEL 5 / CentOS 5
>  are still shipping 1.8.5, and I have no idea what's in the two most
>  recent versions of Ubuntu, or what's going to be in Debian Lenny when

1.8.7, obviously. It's there for ages already, and lenny is frozen
since some time like end of year.

>  it releases in  the near future. In short, the distro Ruby herds need
>  to be in the loop, or the Ruby community will have a bunch of
>  implementations to choose from.

Or rather to not choose from unless you are willing to build your own.

Thanks

Michal

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, 
respond"
    on Fri, 13 Feb 2009 03:13:05 +0900, "M. Edward (Ed) Borasky" 
<zznmeb@gmail.com> writes:

|1. Would there be a chance of merging the efficiencies of Ruby
|Enterprise Edition, especially copy-on-write friendliness, into the
|"Engine Yard 1.8.6 stack?"

No please.  Any new technology for 1.8 should merged in HEAD first,
then merged back into 1.8.6 if appropriate.  I am not going to allow
EngineYard to fork off 1.8.6.  If people from EngineYard want to
improve 1.8, it's OK.  We are open.  I will give them commit privilege
even.  But no fork.

              matz.

Urabe Shyouhei wrote:
> Alex Fenton wrote:
>>> We know the Rails issue (and solved), but could you elaborate on
>>> issues with wxRuby and SWIG?
>> http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645
> 
> This is not our fault.  Please hold on and think yourself.  GC is running means
>   ruby interpreter is running out of memory.  It is as clear as day that object
> allocation during GC is not doable, because we do not have any memory space.
> 
> So SWIG had a bug. 1.8.7 helped to find it out.

Thanks. I perfectly understand the reason for the change, although the
old behaviour worked fine in practice and libraries (not just SWIG ones)
relied on it. It can be seen "fixing broken behaviour" though IMHO
changing expectations of how GC works would better have been left for
1.8->1.9 transition.

My concern about 1.8.7 has always been more that code written for 1.8.7
is not necessarily compatible with 1.8.6, not the other way around - and
to a much greater degree than previous .x releases. The problem is with
expected and actual meaning of version numbers, not the code itself.

Anyway, I'm not going to stop using ruby just because it has an
idiosyncratic versioning scheme. Thanks to all for a useful and mostly
temperate discussion.

alex

On 13/02/2009, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>  I think he relied on the version/implementation specific behavior, so
>  1.8.7 HELPED to find a bug in HIS code, unless I am wrong in any ways.
>  Any other example of 1.8.7 incompatibility?
>
>  I am not happy with FUD-like attitude against 1.8.7.  From my point of
>  view, 1.8.7 is a good release with unfortunate beginning.  There are
>  slight incompatibility, but every past releases also had some sort of
>  incompatibilities as well.  I'd like to use 1.8.7 to write new 1.8
>  code.

I'm sorry if I personally added to this kind of view. Unlike earlier
releases I had some minor problem with code not running after upgrade
to 1.8.7, and it seemed many other people have similar experience.
While acceptable for your own code it is not good for code you
distribute to somebody else.

Back then nobody stepped up and said that if code working on 1.8.6
broke it is a bug so I just left it at that - the compatibility seemed
to be not so great. I have not experienced the same with earlier
versions. There was some issue in the past when a bug in the
interpreter was fixed and it broke a C extension that relied on the
bug and was widely used but it was a single, well understood issue.

The real indisputable failing of 1.8.7 is the introduction of many new
convenience methods into the core classes. If these were separated
into an extension (perhaps one which could be built for 1.8.6 as well)
which was not automatically loaded it would be fine and useful to have
them. As things are now the new methods are often convenient and
somebody coding on 1.8.7 would likely use the new methods making the
code unusable on 1.8.6 and earlier. Been there, done that - as many
people did.

Thanks

Michal

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, 
respond"
    on Fri, 13 Feb 2009 16:41:25 +0900, Michal Suchanek 
<hramrach@centrum.cz> writes:

|I'm sorry if I personally added to this kind of view. Unlike earlier
|releases I had some minor problem with code not running after upgrade
|to 1.8.7, and it seemed many other people have similar experience.
|While acceptable for your own code it is not good for code you
|distribute to somebody else.
|
I expect you to be more concrete and specific about minor problems.
As far as I know:

  * Rails had problem from method name conflict.  This was
    unfortunate, caused by Rails' fragile monkey patching and our bad
    for lack of thorough Rails test before 1.8.7.  It is fixed now.

  * erb also had a bug in 1.8.7 initial release.  It is fixed now.

  * two other problems are reported (SWIG and hash order), and as far
    as I understand, they both contain bugs that haven't disclosed for
    1.8.6 by accident.

I consider them minor and not being worse than previous releases.
Most of them are addressed already.  Am I missing something?

|Back then nobody stepped up and said that if code working on 1.8.6
|broke it is a bug so I just left it at that - the compatibility seemed
|to be not so great. 

If compatibility of 1.8.7 is really "not so great":

  * if it is fixable, we can fix.

  * if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
    as we did in the past.

  * if upgrading is not affordable for enterprisey people (yes, I
    understand them; upgrading is costly even when incompatibility is
    minor), they can keep using 1.8.6, which is maintained right now.
    As EngineYard raised their hands, the maintenance of 1.8.6 will be
    kept, even after 1.8.8.

If more evidence of great incompatibility is not shown, I will
consider it FUD, or FUD-like at most, even though I see no bad
intention from anyone.

              matz.

>
> Your code happened to work by chance.


Granted. As I've said elsewhere, this is just my example of a 
significant
change in 1.8.7. I accept that no iteration order was ever explicitly 
stated
for 1.8, and a change like this is something of a grey area in terms of
whether it would be considered a backward incompatibility.



> > To work with 1.8.7, you need to create an empty hash
> > and add keys one by one rather than putting them all in a hash literal
> (see
> > the patch).
>
> Do I understand that the code relies on insertion order now?
> Then it's still working by chance in case it works at all.



I may have misstated this: it does rely on insertion order, but I 
maintain
that explicitly in my code now -- I'm not relying on Ruby to do it for 
me.

On 13/02/2009, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>  |distribute to somebody else.
>  |
>
> I expect you to be more concrete and specific about minor problems.

Yes, I would like to be more concrete. Unfortunately, it's some time
since 1.8.7 was released and I do not have any of the code at hand.

>  As far as I know:
>
>   * Rails had problem from method name conflict.  This was
>     unfortunate, caused by Rails' fragile monkey patching and our bad
>     for lack of thorough Rails test before 1.8.7.  It is fixed now.

This was well understood from the start, and easy enough to fix.

Again, if the many methods added were optional such situations could be 
avoided.

>
>   * erb also had a bug in 1.8.7 initial release.  It is fixed now.
>
>   * two other problems are reported (SWIG and hash order), and as far
>     as I understand, they both contain bugs that haven't disclosed for
>     1.8.6 by accident.

The SWIG problem was until recently described as something like "many
C extensions fail". I personally don't care as I don't use them but I
would not upgrade to 1.8.7 a package in a system distriution be cause
of this.

 It's obviously a change of expectations on which many C extensions
rely. While this might be a step towards making the GC "more correct"
the old behaviour was "safe enough" and the fix is not localized into
replacing a single bit - many C extensions will have to change so this
might not be considered minor.

> If compatibility of 1.8.7 is really "not so great":
>
>   * if it is fixable, we can fix.

I guess saying this is exactly what the 1.8.7 release was missing at the 
start.

There were people saying it breaks things, and no obvious progress
towards fixing the issues. When I got 1.8.7 in an overall system
upgrade I also had to modify code which I believed to work on 1.8.6.

>  If more evidence of great incompatibility is not shown, I will
>  consider it FUD, or FUD-like at most, even though I see no bad
>  intention from anyone.
>

Yes, the attitude towards 1.8.7 evolved in an unfortunate way.

And I think some of the uncertainty resulted from lack of
communication on part of the core team.

Thanks

Michal

2009/2/13 James Coglan <jcoglan@googlemail.com>:
> I would concede that this is something of a grey area as it's neither a bug
> fix or an explicit feature addition, but the question was asked about 1.8.6
> code that broke, and this is an example.

James, maybe you missed ruby-talk:327937
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/327937).
Your code isn't working reliably even on 1.8.6. Look at this IRB
session I've just run on my ruby 1.8.6 (2007-03-13 patchlevel 0)
[i386-mswin32]:

  irb(main):001:0> {2 => 0, 1 => 0}
  => {1=>0, 2=>0}
  irb(main):002:0> {:a => 0, :z => 0}
  => {:a=>0, :z=>0}
  irb(main):003:0>

As you can see, in one case the hash is iterated over in insertion
order, in the other case not. It depends on the hash keys and maybe
other factors. If your code was working for you you've just been
lucky, but you can't claim that this is an example for code that was
working on 1.8.6. The code was broken in 1.8.6 and still is broken in
1.8.7, and 1.8.7 even helped you find the bug in your code, as someone
else had said already.

Regards,
Pit

2009/2/13 William James <w_a_x_man@yahoo.com>

> > Your code happened to work by chance.
> +1
>
> Mr. Coglan seems not to understand how a hash-table is implemented.
> One cannot predict the iteration order because he cannot know in which
> bucket each element has been stored.  Furthermore, it makes no sense
> at all to be concerned about iteration-order for a hash-table.
>
> If one is concerned about iteration-order, he should use an
> association-list.



I do know how hash tables work, I was responding to the question of 
whether
any code was broken by 1.8.7. I've conceded elsewhere in this thread 
that no
iteration order was ever guaranteed for 1.8, and that the question of
whether this counts as a true backward incompatibility is a grey area at
best.

I am using an ordered hash implementation, but was initialising it using
hash literals, which obviously does not work if iteration order is 
different
from source order. I've since fixed the bug by adding keys explicitly 
one by
one.

This begs the question of whether 1.9 should guarantee insertion order 
for
hashes. Since hashes are not inherently ordered beings, wouldn't it make
more sense to provide an OrderedHash subclass that explicitly provides 
that
behaviour? At least then it would be clearer if you were using a 1.9 
feature
that won't work on 1.8.

James Coglan wrote:

> > 
> > Your code happened to work by chance.
> 
> 
> Granted. As I've said elsewhere, this is just my example of a
> significant change in 1.8.7. I accept that no iteration order was
> ever explicitly stated for 1.8, and a change like this is something
> of a grey area in terms of whether it would be considered a backward
> incompatibility.

No, it's not a gray area.  Anyone who has a basic understanding of
hash-tables doesn't even think about the iteration order.

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, 
respond"
    on Fri, 13 Feb 2009 17:50:02 +0900, Michal Suchanek 
<hramrach@centrum.cz> writes:

|Yes, the attitude towards 1.8.7 evolved in an unfortunate way.

Indeed, and I want to fix it.

|And I think some of the uncertainty resulted from lack of
|communication on part of the core team.

Communication has both side.  Of course, core team can/should improve
their attitude.  But users might be able to improve how they report to
the team.  Some of the team claimed they didn't get the concrete
report more than complaining in some cases.  And we now have Redmine
to improve the communication.

              matz.

2009/2/13 William James <w_a_x_man@yahoo.com>

> > incompatibility.
>
> No, it's not a gray area.  Anyone who has a basic understanding of
> hash-tables doesn't even think about the iteration order.


Not true. Some languages (Ruby 1.9, most JavaScript implementations) 
iterate
over hashtables in insertion order. This is often done (as it is in 
Ruby) by
storing the table entries as a linked list so that every entry has 
pointers
to its neighbours. Though a basic hashtable implementation will not
guarantee iteration order, there is potential confusion if an 
implementation
*appears* to guarantee it. I referred to this is a grey area because 1.8
never made any such promises, it just *looked* like it did in some use 
cases
until 1.8.7.

Anyway, this has gone a little off-topic. As previously stated, I would
point out that http://github.com/jcoglan/packr/tree/3.1 still has a
regex-related bug under 1.8.7 that I've not found a fix for and that 
does
not appear in any other 1.8 or 1.9 release. If anyone has had regex 
issues
on 1.8.7 I'd really love some help fixing my bug!

Hi,

At Fri, 13 Feb 2009 16:33:38 +0900,
Alex Fenton wrote in [ruby-talk:328029]:
> Thanks. I perfectly understand the reason for the change, although the 
> old behaviour worked fine in practice and libraries (not just SWIG ones) 
> relied on it. It can be seen "fixing broken behaviour" though IMHO 
> changing expectations of how GC works would better have been left for 
> 1.8->1.9 transition.

And the workaround has been introduced into 1.8.7 already, so
those extensions would work without changing.

Ezra Zygmuntowicz wrote:
> the whole ruby community. Please respond here if you think Engine yard 
> would make good maintainers of the ruby1.8.6 lineage
>
> Thanks 
Yes... (and thanks!)

On Fri, Feb 13, 2009 at 12:15 AM, Nobuyoshi Nakada 
<nobu@ruby-lang.org>wrote:

> >
> definitely a bug in your code as you use the word "order".
>
>
Yes, and this particular kind of change, making something which was
previously undefined now be defined, seems to be a benign change, since 
the
defined behavior is within the 'definition' of the previous behavior.

It's the changing of defined behavior while implying compatibility which
causes problems, particulary when the change is significant enough, or 
there
are enough such changes.  And when this threshold is crossed is, 
admittedly,
subjective.
--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

James Gray wrote:

> I have no problems with the 1.9 release.  I feel like the reasoning has
> been well explained and I understand it.
> 
> Essentially, a lot was promised for 2.0.  About half of it has been
> built.  We could have kept waiting for the other half, or release what
> was done.  It's not all of 2.0 though, so it's instead called 1.9.

I suppose once all the smoke clears on the current discussion, dare I
ask about the road map for the 1.9.x --> 2.0 transition, and perhaps
even more important, the *process* for it?

<ducking>
--
M. Edward (Ed) Borasky

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

On Fri, Feb 13, 2009 at 4:53 AM, William James <w_a_x_man@yahoo.com> 
wrote:

> > incompatibility.
>
> No, it's not a gray area.  Anyone who has a basic understanding of
> hash-tables doesn't even think about the iteration order.


Let me try to calm the waters on this particular part of the 
conversation.

A couple of years ago, there was a long discussion here, when some, led 
by
Hal Fulton IIRC,  advocated defining the order for enumerating Ruby 
hashes.

At that time, I argued vehemently to your point that hash tables are
inherently unordered, and therefore it was inconceivable to order them.

I was wrong.

First, although Ruby Hash is implemented using a hash table, they aren't
hash tables, they are Ruby objects which for better or worse are named
simply Hash.  Perhaps if they had been named something like Dictionary, 
or
Map, a name which doesn't betray the implementation, this all would have
been less controversial.

Sometime after that discussion, Matz, who I know has much more than a 
basic
understanding of hash-tables, decided that, yes,
defining the iteration order of Ruby hashes to  be by insertion order, 
and
that this was easily done with minimal impact to performance/space
requirements by linking buckets in the internal hash table used to 
IMPLEMENT
Hash, and made this change in Ruby 1.9, which has been backported to 
Ruby
1.8.7.

And as for whether or not changing something which was previously 
undefined
to something which is defined introduces a backwards compatibility 
issue, I
think it's pretty clear that it does not.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

Ola Bini wrote:
>>> lineage
>>>     
>> +1
>>
>> Although, I'm at a loss as to what you'd use for the version number on
>> the
>> first maintenance release.
>>
>>
>>   
> What about 1.8.6.1?
> 
Someone suggested having 1.8.8 being 1.8.6 syntax and semantics with
only bug fixes, security fixes and efficiency enhancements. That appeals
to me ... that way, "1.8.7" is a development release and "1.8.8" is
stable. But I would think EngineYard would want to "brand" their ruby
1.8.6 implementation in a manner similar to Ruby Enterprise Edition.

BTW, Perl had no trouble going from 5.8.x to 5.10.x, and I understand
there is a 5.12.x coming. So I don't see a problem with Ruby doing
similar things in the third digit. 1.8.10 works for me, as does 1.9.10. 
:)

--
M. Edward (Ed) Borasky

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

On Fri, Feb 13, 2009 at 4:50 AM, James Coglan 
<jcoglan@googlemail.com>wrote:

>
> This begs the question of whether 1.9 should guarantee insertion order for
> hashes. Since hashes are not inherently ordered beings, wouldn't it make
> more sense to provide an OrderedHash subclass that explicitly provides that
> behaviour? At least then it would be clearer if you were using a 1.9
> feature
> that won't work on 1.8.


For Ruby 1.9, the issue is settled.  Ruby 1.9 is a new and different 
Ruby
than Ruby 1.8.6.

To make an analogy from ancient history, there is a Rubicon between Ruby
1.8.6 and Ruby 1.9.  Because of the consequences of crossing the 
Rubicon,
one should make a conscious decision to do so.

Ruby 1.8.7 represents the middle of the river.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

Hi --

On Sat, 14 Feb 2009, Rick DeNatale wrote:

> Sometime after that discussion, Matz, who I know has much more than a basic
> understanding of hash-tables, decided that, yes,
> defining the iteration order of Ruby hashes to  be by insertion order, and
> that this was easily done with minimal impact to performance/space
> requirements by linking buckets in the internal hash table used to IMPLEMENT
> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
> 1.8.7.

Hashes aren't ordered in 1.8.7, though.


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!

2009/2/13 David A. Black <dblack@rubypal.com>

>> IMPLEMENT
>> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
>> 1.8.7.
>>
>
> Hashes aren't ordered in 1.8.7, though.


Seconded -- 1.8.7 is precisely where my code that was relying on 
insertion
order *does not work*. Actually let me be more specific. My code was 
relying
on keys being inserted in the order they appear in a hash literal, and 
on
subsequent iteration occuring in the same order. My own code was 
maintaining
key order explicitly using an array of keys (
http://github.com/jcoglan/packr/blob/3.1/lib/packr/collection.rb), but 
when
using a hash literal to initialize an instance, the keys are not 
inserted in
literal appearance order in 1.8.7.

So it may be that 1.8.7 does use insertion order for iteration, but does 
not
use literal appearance order when creating a new hash.

On Thu, Feb 12, 2009 at 10:24 PM, Urabe Shyouhei 
<shyouhei@ruby-lang.org> wrote:
> Alex Fenton wrote:
>>> We know the Rails issue (and solved), but could you elaborate on
>>> issues with wxRuby and SWIG?
>>
>> http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645
>
> This is not our fault.  Please hold on and think yourself.  GC is running means
>  ruby interpreter is running out of memory.  It is as clear as day that object
> allocation during GC is not doable, because we do not have any memory space.

GC is running may mean the interpreter is running out of memory, it
may mean some code just called GC.start for some other reason.

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

>>> that this was easily done with minimal impact to performance/space
> order *does not work*. Actually let me be more specific. My code was relying
> on keys being inserted in the order they appear in a hash literal, and on
> subsequent iteration occuring in the same order.

That doesn't happen in any 1.8 version, though. (Sorry; I feel like
something's going right past me, and I'll stop after this iteration
:-)


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!

> something's going right past me, and I'll stop after this iteration
> :-)



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.

In article 
<b913ba1b0902130743j17a62d1ck9e8150912bfc8002@mail.gmail.com>,
  James Coglan <jcoglan@googlemail.com> writes:

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

Would you show us an example which the insertion order is
preserved on 1.8.6 and not preserved on 1.8.7?

I tested as follows.  The order is changed since 1.9.
1.8.7 is same as 1.8.6 and older.

% all-ruby -e 'h = {2=>"b", 1=>"a"}; p h'
ruby-1.4.6(2000-08-16)         {1=>"a", 2=>"b"}
ruby-1.6.0(2000-09-19)         {1=>"a", 2=>"b"}
ruby-1.6.1(2000-09-27)         {1=>"a", 2=>"b"}
ruby-1.6.2(2000-12-25)         {1=>"a", 2=>"b"}
ruby-1.6.3(2001-03-19)         {1=>"a", 2=>"b"}
ruby-1.6.4(2001-06-04)         {1=>"a", 2=>"b"}
ruby-1.6.5(2001-09-19)         {1=>"a", 2=>"b"}
ruby-1.6.6(2001-12-26)         {1=>"a", 2=>"b"}
ruby-1.6.7(2002-03-01)         {1=>"a", 2=>"b"}
ruby-1.6.8(2002-12-24)         {1=>"a", 2=>"b"}
ruby-1.8.0(2003-08-04)         {1=>"a", 2=>"b"}
ruby-1.8.1(2003-12-25)         {1=>"a", 2=>"b"}
ruby-1.8.2(2004-12-25)         {1=>"a", 2=>"b"}
ruby-1.8.3(2005-09-21)         {1=>"a", 2=>"b"}
ruby-1.8.4(2005-12-24)         {1=>"a", 2=>"b"}
ruby-1.8.5(2006-08-25)         {1=>"a", 2=>"b"}
ruby-1.8.5p52(2007-06-07)      {1=>"a", 2=>"b"}
ruby-1.8.5p113(2007-09-23)     {1=>"a", 2=>"b"}
ruby-1.8.5p115(2008-03-03)     {1=>"a", 2=>"b"}
ruby-1.8.5p231(2008-06-20)     {1=>"a", 2=>"b"}
ruby-1.8.5head(2008-06-20p231) {1=>"a", 2=>"b"}
ruby-1.8.6p0(2007-03-13)       {1=>"a", 2=>"b"}
ruby-1.8.6p36(2007-06-07)      {1=>"a", 2=>"b"}
ruby-1.8.6p110(2007-09-23)     {1=>"a", 2=>"b"}
ruby-1.8.6p111(2007-09-24)     {1=>"a", 2=>"b"}
ruby-1.8.6p114(2008-03-03)     {1=>"a", 2=>"b"}
ruby-1.8.6p230(2008-06-20)     {1=>"a", 2=>"b"}
ruby-1.8.6p287(2008-08-11)     {1=>"a", 2=>"b"}
ruby-1.8.6head(2009-02-13p330) {1=>"a", 2=>"b"}
ruby-1.8.7p0(2008-05-31)       {1=>"a", 2=>"b"}
ruby-1.8.7p17(2008-06-09)      {1=>"a", 2=>"b"}
ruby-1.8.7p22(2008-06-20)      {1=>"a", 2=>"b"}
ruby-1.8.7p72(2008-08-11)      {1=>"a", 2=>"b"}
ruby-1.8.7head(2009-02-13p116) {1=>"a", 2=>"b"}
ruby-1.8(2009-02-05r22080)     {1=>"a", 2=>"b"}
ruby-1.9.1p0(2009-01-30r21907) {2=>"b", 1=>"a"}
ruby-1.9(2009-02-11r22240)     {2=>"b", 1=>"a"}

2009/2/13 James Coglan <jcoglan@googlemail.com>:
>> something's going right past me, and I'll stop after this iteration
>> :-)
>
>
>
> Regardless of whether they're *supposed* to, the Rubies I've used before
> 1.8.7 actually do iterate in insertion order.

NO THEY DO NOT. It is the nature of a regular hashtable that
the order of entries in its internal data structures depends
only on the hash function and its inputs. It doesn't know
anything about the order of entries in your hash literal.

I've shown you examples using Ruby *1.8.6* that clearly
demonstrate that it gives a **** about order of appearance
in a literal, or insertion order.

Stefan

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

>> something's going right past me, and I'll stop after this iteration
>> :-)
>
>
>
> 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.

I think it probably is machine-dependent, or something like that. I've
never heard of hash order being anything but "not guaranteed" before
1.9 -- except that if you iterate twice, I believe it definitely
happens in the same order both times (though I'm not 100% sure that
that's actually specified or guaranteed either).


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!

Hi Matz, I'm glad to see that you've entered this fray.

I trust that you know me well enough to know, that while I have strong
opinions, I have no ill-will, particularly to you or your language.

On Fri, Feb 13, 2009 at 3:10 AM, Yukihiro Matsumoto 
<matz@ruby-lang.org>wrote:

>    as I understand, they both contain bugs that haven't disclosed for
>    1.8.6 by accident.
>
> I consider them minor and not being worse than previous releases.
> Most of them are addressed already.  Am I missing something?


First, the next  comment is directed to a subset of the Ruby community,
which doesn't  include you Matz,

I know that Rails isn't liked by everyone in the Ruby community, but for
better or worse, it's an important factor to the health of a significant
portion of 'our' community.  Those who don't use Rails or other large 
Ruby
frameworks over time haven't experienced how we got to the point where 
these
problems have been addressed.

At this point, it's a little hard to recover the history, but, although
Rails 2.2 is now compatible with Ruby 1.8.7 it has taken work, and new
releases, from both the Ruby team and the Rails team.

Rails users faced with upgrades, need to deal with the evolution of both
Ruby and Rails.  To a large extent Rails over the last year to 18 months 
has
been even more volatile than Ruby. Porting a Rails app from Rails 1.2.x 
to
Rails 2.0 (There was no Rails 1.3) was, as the change in major version
number indicates a fairly significant jump.  And Rails made changes in 
Rails
2.2 which, for applications doing certain complex things with 
ActiveRecord,
VERY difficult to port.  That's not Ruby's fault, it's just a fact of 
life.

So there are quite a few Rails Apps, which need to stay on a version of
Rails which is compatible with Ruby 1.8.6, but won't work with Ruby 
1.8.7.

|Back then nobody stepped up and said that if code working on 1.8.6
> |broke it is a bug so I just left it at that - the compatibility seemed
> |to be not so great.
>

Of course, none of us is perfect, particularly without the benefit of
hindsight.

As a practitioner and advocate of agile techniques, I like to have a
comprehensive test suite to expose compatibility issues when changes are
made.

Unfortunately in the case of a language like Ruby, it's impossible to 
have
such a test suite, It would need to draw from a significant portion of 
the
applications implemented in Ruby, and applications implemented on 
frameworks
like Rails which are implemented on Ruby, etc. etc.  Not really 
practical.

If compatibility of 1.8.7 is really "not so great":
>
>  * if it is fixable, we can fix.
>
>  * if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
>    as we did in the past.
>
>  * if upgrading is not affordable for enterprisey people (yes, I
>    understand them; upgrading is costly even when incompatibility is
>    minor),



I'm not sure who you are calling enterprisey people here.  I know that 
you
have no intent to disparage, but that term does carry a certain meaning 
of
"the other guys" with some of the Rubyists, (and others) I run into.

To me "enterprisey" means  someone working in a large corporate 
enterprise,
who is following strategies, architectures and standards, promulgated by
enterprise vendors, like Microsoft, and IBM (to the extent IBM still has 
the
influence to do this), probably because of edicts handed down from on 
high
from the executives who play golf with sales reps from those vendors.

I'm pretty sure that such "enterprisey" types make up a very small 
subset of
the Ruby/Rails community.  We don't have many sales reps who play golf 
with
corporate executives.

The vast majority of those using Rails are fairly small companies trying 
to
leverage the almost unique advantages of Ruby and Rails to be able to
quickly deploy into production, and incrementally improve core business
applications.  And the vast majority of Rails developers are either 
working
for those small companies, or for a small Rails consultancy, or as
independent freelance contractors.


> they can keep using 1.8.6, which is maintained right now.
>
>
Very true, I've got no argument with that, but it's important to 
understand
that those who are using packaged distributions of Ruby from debian
(including Ubuntu), RedHat, macports etc. have more trouble keeping 
1.8.6
because normal system administration has a nasty tendency to replace 
1.8.6
with 1.8.x where x > 6 because they don't differentiate versions with
differences in teeny version numbers as backwards incompatible.  While 
1.8.7
is backwards compatible with 1.8.6 in theory. Whether or not it really 
is,
depends on whether or not all of the ancillary ruby code on the 
particular
system, like Rails, Gems, and local applications have been kept, or 
brought
up to date.

Savvy developers get around this by eschewing packaged versions and
installing the components of the Rails stack, including Ruby, from 
source.
But there are a lot of developers who trust the package maintainers, and 
run
into these issues, and end up blaming Ruby.  We could say "well that's 
their
problem," if we don't care about the impact on the overall perception of
Ruby.  Perhaps that's the right attitude, but I'm not so sure.

Would it have been better for those with these problems had Ruby 1.8.7 
not
included the changes from 1.9 which broke apps and frameworks?  I think 
that
the answer is clearly yes.

But, for better or worse, it did, and we have to live with the 
consequences,
that doesn't mean we need to be happy about it.

   As EngineYard raised their hands, the maintenance of 1.8.6 will be
>    kept, even after 1.8.8.

If more evidence of great incompatibility is not shown, I will
> consider it FUD, or FUD-like at most, even though I see no bad
> intention from anyone.
>

I hope that this doesn't come across as FUD, or even FUD-like, I'm just
trying to put a bit more context on why compatibility isn't a black or 
white
thing, and the sources of real FUD.

The real FUD doesn't come from discussions like this, it comes from 
those
who either have run into these problems and blame Ruby.  We have no 
control
over what they say, we can only try to consider the effects of decisions 
on
the broader community, within the bounds of our human lack of complete
knowledge.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Fri, Feb 13, 2009 at 10:14 AM, David A. Black <dblack@rubypal.com> 
wrote:

>> IMPLEMENT
>> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
>> 1.8.7.
>>
>
> Hashes aren't ordered in 1.8.7, though.
>

Which makes this part of the thread rather moot, doesn't it?!

Thanks for pointing that out.
--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Fri, Feb 13, 2009 at 10:06 AM, M. Edward (Ed) Borasky
<zznmeb@gmail.com>wrote:

>
> Someone suggested having 1.8.8 being 1.8.6 syntax and semantics with
> only bug fixes, security fixes and efficiency enhancements. That appeals
> to me ... that way, "1.8.7" is a development release and "1.8.8" is
> stable.


Bad idea, IMHO.

This would mean that  Ruby 1.8.8, would be backwards compatible with 
Ruby
1.8.6, but NOT with Ruby 1.8.7, which might be good for needing to say 
with
the  Ruby 1.8.6 definition, but not those who are already using Ruby 
1.8.7.


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

> demonstrate that it gives a **** about order of appearance
> in a literal, or insertion order.



I'm really not up for a slanging match so let me just say that, in code 
I've
written, Ruby < 1.8.7 has demonstrated the behaviour I described. This 
may
be a fluke or a bug, in which case I will investigate further and file 
bugs
if necessary. What I do know is that I've had code in a library released
over 2 years ago and used by a fair number of people relying on this
behaviour and heard no complaints until 1.8.7 arrived. I realise that
hashtables are not ordered in 1.8 and have since made my code more 
robust.
I'm not questioning your examples -- you can but experiment to see what
works -- and I will try to extract the code from my project that
demonstrates my point when I have some time.

I'm not the least bit interested in who's right or wrong or in berating 
the
Ruby code devs or indeed anyone else, and was hoping for a productive
discussion, not people repeatedly asserting that I don't know how a hash
table works and trying to shut me up. When I've time I'll see if what I 
have
is a Ruby bug or something else. Until then I'm canning this 
conversation.

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

> I'm really not up for a slanging match so let me just say that, in code I've
> written, Ruby < 1.8.7 has demonstrated the behaviour I described. This may
> be a fluke or a bug, in which case I will investigate further and file bugs
> if necessary.

It's not a bug; there was never any defined order behavior, so no
behavior is either right or wrong.


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!

+1 for the main question,
 but...


On Feb 11, 9:15 pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> I still feel like Ruby 1.9 should have been 2.0.
> Then 1.8.7 could have been 1.9, 1.8.8 could be 1.10,
> and so on, ...

I also agree about this. Perhaps it isn't too late
to rename "1.9.1.0.0.1" to "2.0.0.0.1" ??

Also is it possible to make some "ruby20.rb" package
wich emulate some features of 1.9 present in 1.8.7?

Then in ruby-1.8.8 which would be 1.8.6 like
but would allow us to write:

   require 'ruby20'

Then all sugar features that are present in ruby 1.8.7
would be enable!
Perhaps this package could even be required from a 1.8.6
ruby version??

-- Maurice

P.S.
+1 for the original question ;-)

On Fri, Feb 13, 2009 at 11:07 AM, David A. Black <dblack@rubypal.com> 
wrote:

>> if necessary.
>>
>
> I think it probably is machine-dependent, or something like that. I've
> never heard of hash order being anything but "not guaranteed" before
> 1.9 -- except that if you iterate twice, I believe it definitely
> happens in the same order both times (though I'm not 100% sure that
> that's actually specified or guaranteed either).
>

No, it's in the absence of key collisions, it's really determined by the
hash values of the keys,  The iteration is over the hash buckets and 
hash
buckets marked as empty are skipped.

Consider your examples which I've excerpted:

% all-ruby -e 'h = {2=>"b", 1=>"a"}; p h'
...
ruby-1.8.6head(2009-02-13p330) {1=>"a", 2=>"b"}
...
ruby-1.8.7head(2009-02-13p116) {1=>"a", 2=>"b"}
...
ruby-1.9.1p0(2009-01-30r21907) {2=>"b", 1=>"a"}

Note that for Ruby 1.8.6 and 1.8.7, the iteration order is by the sort 
order
of the keys.  But that's just a side-effect of the hash of a fixnum 
being
just the internal immediate representation which happens to be n*2 + 1 
for a
Fixnum n:

irb(main):001:0> 1.hash
=> 3
irb(main):002:0> 2.hash
=> 5

Had you used what is arguably the more natural order in the literal, 
i.e. {1
=> "a", 2 => "b"} it would appear as if iteration was by insertion 
order,
but that's just an accidental artifact.

I suspect that those who observed that Ruby 1.8.7 'preserves' insertion
order are looking at specific artificial cases like this.
--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Feb 13, 2009, at 3:53 AM, William James wrote:

>> incompatibility.
>
> No, it's not a gray area.  Anyone who has a basic understanding of
> hash-tables doesn't even think about the iteration order.

I guess you haven't used Ruby 1.9.  :)

James Edward Gray II

On Feb 13, 2009, at 9:06 AM, M. Edward (Ed) Borasky wrote:

> BTW, Perl had no trouble going from 5.8.x to 5.10.x, and I understand
> there is a 5.12.x coming. So I don't see a problem with Ruby doing
> similar things in the third digit. 1.8.10 works for me, as does  
> 1.9.10. :)

 >> "1.8.9" < "1.8.10"
=> false

James Edward Gray II

Hi --

On Sat, 14 Feb 2009, Rick DeNatale wrote:

>>> supposed to now be defined behaviour I'll investigate further and file a
>
> ruby-1.8.7head(2009-02-13p116) {1=>"a", 2=>"b"}
> irb(main):002:0> 2.hash
> => 5
>
> Had you used what is arguably the more natural order in the literal, i.e. {1
> => "a", 2 => "b"} it would appear as if iteration was by insertion order,
> but that's just an accidental artifact.

That's why I didn't :-)


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!

2009/2/13 James Coglan <jcoglan@googlemail.com>:
>> demonstrate that it gives a **** about order of appearance
>> in a literal, or insertion order.
>
>
>
> I'm really not up for a slanging match so let me just say that, in code I've
> written, Ruby < 1.8.7 has demonstrated the behaviour I described. This may
> be a fluke or a bug, in which case I will investigate further and file bugs
> if necessary.

I can tell you how such a bug report would look like:

    Bug: In Ruby 1.8.x Hash iteration order .....

    Rejected: Hash iteration order in 1.8 is undefined.

> What I do know is that I've had code in a library released
> over 2 years ago and used by a fair number of people relying on this
> behaviour and heard no complaints until 1.8.7 arrived.

A hidden bug in your code because of an incorrect assumption.

> I realise that
> hashtables are not ordered in 1.8 and have since made my code more robust.
> I'm not questioning your examples -- ...

You seem to be ignoring them.

> ... you can but experiment to see what
> works -- and I will try to extract the code from my project that
> demonstrates my point when I have some time.
>
> I'm not the least bit interested in who's right or wrong or in berating the
> Ruby code devs or indeed anyone else, and was hoping for a productive
> discussion, not people repeatedly asserting that I don't know how a hash
> table works and trying to shut me up. When I've time I'll see if what I have
> is a Ruby bug or something else. Until then I'm canning this conversation.

I and others here took the trouble finding out and explaining
why your code failed. That's a productive discussion. You'd just
have to accept that it's your code that was buggy. There's
nothing bad about that. Everybody writes buggy code sometimes.

Instead you keep looking for a bug in Ruby that doesn't exist,
as has been clearly proven.

Stefan

On Fri, Feb 13, 2009 at 8:11 AM, Rick DeNatale <rick.denatale@gmail.com> 
wrote:
> I'm pretty sure that such "enterprisey" types make up a very small subset of
> the Ruby/Rails community.  We don't have many sales reps who play golf with
> corporate executives.

I saw a (fairly boring) panel discussion on "The Future of Enterprise
Software" by some of these "enterprisey" folks last night, including
the President of Oracle, who gave the keynote address. Yes, there is a
*big* difference between the 5-million ton gorilla Oracle (did you
know there are five million Oracle developers, all connected by Oracle
software?) and a typical Rails development team.

> Very true, I've got no argument with that, but it's important to understand
> that those who are using packaged distributions of Ruby from debian
> (including Ubuntu), RedHat, macports etc. have more trouble keeping 1.8.6
> because normal system administration has a nasty tendency to replace 1.8.6
> with 1.8.x where x > 6 because they don't differentiate versions with
> differences in teeny version numbers as backwards incompatible.  While 1.8.7
> is backwards compatible with 1.8.6 in theory. Whether or not it really is,
> depends on whether or not all of the ancillary ruby code on the particular
> system, like Rails, Gems, and local applications have been kept, or brought
> up to date.

It's not just the users ... the *packagers* need to be in the loop
too. There are two main package formats -- Debian/Ubuntu and RPM (Red
Hat / SuSE / Mandriva). And there are three major "community" Linux
distros as well as a few "Corporate" Linux entities. Sure, there are
differences in the details of how a Linux distro is packaged and
administered, but the tasks, issues and use cases are the same: first
of all it has to *work*, security holes need to be fixed ASAP,
preferably *before* exploits appear in the wild, and capacity planning
tools need to exist so that a supplier can be sure his service level
agreements are being met. The distinction here is not one of scale --
Oracle vs. a "typical Rails app". The distinction is between a
production, deployed IT environment and a chaotic, risky experimental
venture.

I think we have to start thinking in terms of weeding out some of the
chaos. For example, I would expect openSUSE, Fedora and Ubuntu to be
all shipping a Ruby with *identical* syntax and semantics. I would
expect them all to be shipping a Rails with *identical* behavior. I
would expect to be able to walk up to a Ubuntu, openSUSE or Fedora
server console and type a *distro* install command to bring in any
Gem, *not* "sudo gem install <gem-name>" because *some* gems are in
the package repository but others aren't. In short, I would expect
that there would be *one* Ruby and *one* Rails, differing only in
whether I said "sudo apt-get install rails", "sudo zypper install
rails", or "sudo yum install rails". It should *just work*.

This requires communication. This requires "marketing". This requires
the kind of discussion we are having in this thread within the Ruby
community, but it also requires communication between the Ruby / Rails
communities and the distros. I haven't done much in terms of syncing
up with the openSUSE community on Ruby, but I did get a sense of the
frustration with Ruby in the Gentoo community when I was a Gentoo
user.
--
M. Edward (Ed) Borasky

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

> No, it's not a gray area.  Anyone who has a basic understanding of
> hash-tables doesn't even think about the iteration order.

There's a big difference between abstract computer science theory and 
pragmatic
technology.

Ruby uses option-hashes as an emergent "named parameters" system. We 
have
hundreds of DSLs written with them.

After these DSLs can see the order that the user-programmer wrote the
parameters, they are free to use this order to grow more powerful.

On Feb 13, 11:11 am, Rick DeNatale <rick.denat...@gmail.com> wrote:
> >    unfortunate, caused by Rails' fragile monkey patching and our bad
>
> Rails 2.2 is now compatible with Ruby 1.8.7 it has taken work, and new
> releases, from both the Ruby team and the Rails team.

Well, it's frustrating for me. My ISP just sent word:

  We will be upgrading your server to the following versions of Ruby
and Rails on Wednesday, February 18, 2009.

  Ruby 1.8.7
  Rails 2.2.2

  This upgrade is needed to bring Ruby and Rails to the current stable
releases.

I'm wondering what it's going to take to get to 1.9. That's were I
want to go. But now I have to horse around in 1.8 and 1.8.7 for who
knows how long.

The switch from 1.6 to 1.8 went much more smoothly. If Rails were
around back then, I wonder if we would still be deal with 1.6.9 today?

I think 1.8.7 was a mistake. It has taken us too long to get to 1.9
and now we are being forced to deal with a unwanted stop-gap measure,
holding it all up yet again.

T.

Pit Capitain wrote:
> 2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
>> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
>>> Gregory, there is no Ruby 1.8 and has never been. There have been
>>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>>
>> You keep saying this but frankly, it's ridiculous.  Yes, you can find
>> changes.  In Ruby 1.8.7, you get clubbed over the head with them.
> 
> So we agree to disagree. Though I'd be interested in what you'd define
> as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
> a "Ruby 1.8", despite the differences to 1.8.6?

Until now, it didn't matter. Most code written under 1.8.6 ran quite 
happily under 1.8.5 or 1.8.2, unless it exercised a few specific bugs or 
a few edge cases of feature enhancements.

Example: TCPSocket.new now accepts up to 4 arguments instead of just 2. 
However few people use the functionality (for binding to an explicit 
local IP and/or port). Those who do will need to run the later version 
of Ruby.

IMO, the biggest problem with 1.8.7 is that people are getting it 
installed by default (e.g. in newer Debian/Ubuntu systems). They are 
starting to write code using a whole heap of new features in 1.8.6, 
sometimes by accident. This code will not run on production 1.8.6 
platforms. Once library writers start doing this, it messes up the whole 
library ecosystem.

On Fri, Feb 13, 2009 at 8:41 PM, Trans <transfire@gmail.com> wrote:

> I think 1.8.7 was a mistake. It has taken us too long to get to 1.9
> and now we are being forced to deal with a unwanted stop-gap measure,
> holding it all up yet again.

It indeed was, though technically fine! It seems that it killed its 
sibling. :(
R.

Ola Bini wrote:
> What about 1.8.6.1?

As much as I dislike the patchlevel concept, it would be very cumbersome
to change it now and have a fourth digit. Rubyspec would have to change,
other implementations would have to change...consider the patchlevel
number as the fourth digit and just continue to increment it.

- Charlie

Nobuyoshi Nakada wrote:
> Hi,
> 
> At Fri, 13 Feb 2009 02:36:06 +0900,
> Rick DeNatale wrote in [ruby-talk:327919]:
>> Although, I'm at a loss as to what you'd use for the version number on the
>> first maintenance release.
> 
> 1.8.6-p###.

Agreed, just to make more noise about this. The p-numbers aren't great
(they could have just been a fourth digit) but moving to a fourth digit
now would cause mass confusion.

Which do I install, 1.8.6-p287 or 1.8.6.1?

- Charlie

M. Edward (Ed) Borasky wrote:
> Someone suggested having 1.8.8 being 1.8.6 syntax and semantics with
> only bug fixes, security fixes and efficiency enhancements. That appeals
> to me ... that way, "1.8.7" is a development release and "1.8.8" is
> stable. But I would think EngineYard would want to "brand" their ruby
> 1.8.6 implementation in a manner similar to Ruby Enterprise Edition.

IMHO, Engine Yard should not take over Ruby 1.8.6 to take it in new
directions, they are just becoming 1.8.6 *maintainers*. I agree with
Matz that any large-scale changes like REE or other stuff should still
filter down the 1.8 mainline chain.

And look at it this way...the non-Japanese community has perhaps not had
enough say in the direction of 1.8...we don't want to turn around and do
the same thing. If EY becomes 1.8.6 maintainers, they should not repeat
mistakes and make sure the rest of ruby-core and the Japanese Ruby
community are on board with *all* 1.8.6 revisions.

- Charlie

Yukihiro Matsumoto wrote:
> then merged back into 1.8.6 if appropriate.  I am not going to allow
> EngineYard to fork off 1.8.6.  If people from EngineYard want to
> improve 1.8, it's OK.  We are open.  I will give them commit privilege
> even.  But no fork.

Agreed here...1.8.6 should become more stable, and all changes should
filter down throught the 1_8 branch on ruby-lang. 1.8.6 should *not*
start to incorporate fixes/enhancements that are not in the other 1_8
versions.

- Charlie

2009/2/13 James Coglan <jcoglan@googlemail.com>:
> I'm really not up for a slanging match so let me just say that, in code I've
> written, Ruby < 1.8.7 has demonstrated the behaviour I described.

This is just not true. Period. And I can prove it.

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

You say that in 1.8.6 the iteration order of the resulting hash has
been the same as the order in the hash literal, but look at the
following output:

  puts DICTIONARY
  => 
(COMMENT1)|(COMMENT2)|(STRING1)|(STRING2)|(CONDITIONAL)|(OPERATOR)|(REGEXP)

As you can see, the iteration order is completely different from the
order in the hash literal. I really don't know what made you think
that 1.8.6 was using insertion order.

> What I do know is that I've had code in a library released
> over 2 years ago and used by a fair number of people relying on this
> behaviour and heard no complaints until 1.8.7 arrived.

Your code was working by accident. Read along:

> I realise that
> hashtables are not ordered in 1.8 and have since made my code more robust.

You noticed that the iteration order had changed in 1.8.7, so you
changed your code to:

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

I don't know whether this change made a difference on 1.8.7. It
definitely had no effect on the iteration order, neither in 1.8.7 nor
in 1.8.6:

  puts DICTIONARY
  => 
(COMMENT1)|(COMMENT2)|(STRING1)|(STRING2)|(CONDITIONAL)|(OPERATOR)|(REGEXP)

Now you might say that on your machine and with your version of Ruby
the iteration order had been different and that in your environment
the iteration order still had been the same as the literal order. But
that is not true. Read on:

> I will try to extract the code from my project that
> demonstrates my point when I have some time.

No need to do that. I fixed some bugs in your code so that the
iteration order is really the same as the literal order:

  puts DICTIONARY
  => 
(OPERATOR)|(CONDITIONAL)|(COMMENT1)|(COMMENT2)|(REGEXP)|(STRING1)|(STRING2)

And guess what? Your code stopped working! Your code only works with
the iteration order of 1.8.6. The iteration order must be different
from insertion order, or else your code doesn't work.

Now please stop talking about 1.8.6 having some well defined property
that has been changed in 1.8.7. This simply is not true.

> I'm not the least bit interested in who's right or wrong or in berating the
> Ruby code devs or indeed anyone else, and was hoping for a productive
> discussion (...)

OK. You said in a previous post that you still had one problem with
regular expressions in 1.8.7. In reality, the bug had nothing to do
with regular expressions, but with ... guess what? ... the iteration
order of hashes. If you carefully build all the hashes in the same
order as those you got with Ruby 1.8.6, then all your tests are
working on both 1.8.6 and 1.8.7.

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.

Regards,
Pit

+1

In article 
<a245658d0902131727k241af80ai195a5fe0b534a060@mail.gmail.com>,
  Pit Capitain <pit.capitain@gmail.com> writes:

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

On 2/13/09 1:00 AM, "ruby-talk-admin@ruby-lang.org"
<ruby-talk-admin@ruby-lang.org> wrote:

> From: Yossef Mendelssohn <ymendel@pobox.com>
[...]
> find it dismaying that anyone would seriously say that this isn't
> desired string comparison behavior. I mean, these are *strings*, not
> anything special. They just happen to contain a certain pattern of
> characters.
> 

Well, I am seriously suggesting just that.

And I am not alone. The Mac Finder will "alphabetically" list files 
named
1.8.8, 1.8.9 and 1.8.10 in that order.

Moreover, in MacRuby, I can do:

>> framework 'Cocoa'
=> true
>> a="1.8.8"
=> "1.8.8"
>> b="1.8.9"
=> "1.8.9"
>> c="1.8.10"
=> "1.8.10"
>> a.compare b, options:NSNumericSearch
=> -1
>> b.compare c, options:NSNumericSearch
=> -1

Before you point it out, yes, the NSNumericSearch constant option must 
be
passed to compare for that to work that way. Without it, compare returns 
the
result you expect.

My point is that we programmers have grown to expect string comparison 
to
work in the incorrect way, to the point that you now claim that the
*desired* behaviour is the wrong one. My claim is that the *desired*
behaviour is for "1.8.10" to sort after "1.8.9". My mother and my
grandfather agree.

And no, I don't suggest we redefine string comparison in Ruby at this 
point
in time.

As for the issue at hand, a good solution was proposed.

On Feb 13, 7:11 am, Jean-Denis Muys

> My point is that we programmers have grown to expect string comparison to
> work in the incorrect way, to the point that you now claim that the
> *desired* behaviour is the wrong one. My claim is that the *desired*
> behaviour is for "1.8.10" to sort after "1.8.9".

Absolutely not.
That would be desired only when 10 and 9 are numbers,
not strings.

[ "1.8.10", "1.8.9" ].sort_by{|s| s.split(".").map{|x| x.to_i}}
    ==>["1.8.9", "1.8.10"]

>       My mother and my
> grandfather agree.

I'll wager they are piss-poor programmers.

>
> And no, I don't suggest we redefine string comparison in Ruby at this point
> in time.

Later, you mean?

William James wrote:

> Normal hash-tables are ordered nowhere, no-how, and no-way.

> A 9-year-old boy wanted to keep track of the color of his
> toys.  He wrote "car: red" on a piece of paper which he then
> put in a bag.  Then he did the same with "airplane: silver"
> and "ball: blue".  Days later, he decided to review the data.
> He reached into the bag and pulled out a slip.  It didn't
> say "car"!  It was the slip with the color of the ball!
> The slips were coming out in the wrong order!

There's a big difference between abstract computer science theory and 
pragmatic
technology.

Ruby uses option-hashes as an emergent "named parameters" system. We 
have
hundreds of DSLs written with them.

After these DSLs can see the order that the user-programmer wrote the
parameters, they are free to use this order to grow more powerful.

Just because one (technological) implementation of hash tables throws
information away, that does not mean it was _required_ to throw that 
info away.

How about we give you your own special version, 
HashWithIndifferentOrder, that
guarantees it randomizes key order?

And along the way, we can give you := for assignment, and = to test 
equality,
because - you know - the = operator has always meant equality, not 
assignment.

William James wrote:
>>> only on the hash function and its inputs. It doesn't know
>> case I will investigate further and file bugs if necessary.
> Normal hash-tables are ordered nowhere, no-how, and no-way.
>> asserting that I don't know how a hash table works
> say "car"!  It was the slip with the color of the ball!
> The slips were coming out in the wrong order!
> Devestated, he began crying and ran to his mommy.

Um, how is bag["car"] implemented? How is this analogous with a hash? Do
*you* understand how a hash-table works? (Yes, I know you do.)

>
> 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
jcoglan@googlemail.com, 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?

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

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

Phlip wrote:
> Ruby uses option-hashes as an emergent "named parameters" system. We 
> have hundreds of DSLs written with them.

Granted.

> After these DSLs can see the order that the user-programmer wrote the 
> parameters, they are free to use this order to grow more powerful.

How so?

I honestly can't think of a case where I'd want to do that. If I wanted
positional arguments, I'd use them. If I want named arguments, why do I
care about their position?

> Just because one (technological) implementation of hash tables throws 
> information away, that does not mean it was _required_ to throw that 
> info away.

No, but it's very likely more efficient to do so, and the vast majority
of hashes simply do not need that information.

> How about we give you your own special version, 
> HashWithIndifferentOrder, that guarantees it randomizes key order?

Because most hashes don't need them?

There are several OrderedHash implementations, some of them quite old,
if you really want to depend on hash ordering.

> And along the way, we can give you := for assignment, and = to test 
> equality, because - you know - the = operator has always meant 
> equality, not assignment.

Ew. I see your point, but I find I do a lot more assignments than tests
for equality, so I prefer less typing for that.

Also not sure what this has to do with the other discussion...

On Feb 11, 12:10 pm, Gregory Brown <gregory.t.br...@gmail.com> wrote:
> 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.

On Sat, Feb 14, 2009 at 10:03 AM, aks <alan.stebbens@gmail.com> 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:

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.

--
M. Edward (Ed) Borasky

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

James Coglan 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

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?

Christopher Dicely wrote:
> may mean some code just called GC.start for some other reason.
True, but that doesn't change the conclusion.

2009/2/15 Nobuyoshi Nakada <nobu@ruby-lang.org>:
> 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

Hi --

On Sun, 15 Feb 2009, Pit Capitain 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 (http://manning.com/black2)

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

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.

2009/2/15 David A. Black <dblack@rubypal.com>:
> 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

Hi --

On Sun, 15 Feb 2009, Pit Capitain wrote:

> 2009/2/15 David A. Black <dblack@rubypal.com>:
>> 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.

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!