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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-11 18:12
(Received via mailing list)
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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-11 18:29
(Received via mailing list)
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
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-11 18:36
(Received via mailing list)
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.
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2009-02-11 18:40
(Received via mailing list)
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
54185df1d348bbd34587fcd4f8e4779b?d=identicon&s=25 Louis-Philippe (Guest)
on 2009-02-11 18:43
(Received via mailing list)
+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>
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-11 18:56
(Received via mailing list)
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.
Aaca034456897ccbc8bb14953c4a41c1?d=identicon&s=25 Radosław Bułat (radarek)
on 2009-02-11 19:27
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-11 19:41
(Received via mailing list)
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.
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-11 19:43
(Received via mailing list)
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.
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-11 19:44
(Received via mailing list)
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.
6c6088d4a7d9d07e28a13d9c2677d5a6?d=identicon&s=25 Daniel Dettlaff (dmilith)
on 2009-02-11 19:49
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!  ;}
3b1756d05466b4a78afd9aea7bb845c2?d=identicon&s=25 Aaron Turner (Guest)
on 2009-02-11 19:55
(Received via mailing list)
+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
C482081f2c6c893c26f72f6e31999bcb?d=identicon&s=25 Zachary Brown (Guest)
on 2009-02-11 20:02
(Received via mailing list)
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
Fb1fc6f2eccd067a19b298d89235bfe0?d=identicon&s=25 Rupert Voelcker (rupert)
on 2009-02-11 20:05
(Received via mailing list)
+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
Bb6ecee0238ef2461bef3416722b35c5?d=identicon&s=25 pat eyler (Guest)
on 2009-02-11 20:11
(Received via mailing list)
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.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-11 20:40
(Received via mailing list)
> 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??
0c00d644de3b8bb2f655908c79af25a5?d=identicon&s=25 Matt Lawrence (Guest)
on 2009-02-11 20:49
(Received via mailing list)
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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-11 20:57
(Received via mailing list)
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
0babf177db6fc39a4460aea7b2901d08?d=identicon&s=25 Sam (Guest)
on 2009-02-11 21:06
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-11 21:07
(Received via mailing list)
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.
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-02-11 21:13
(Received via mailing list)
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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-11 21:17
(Received via mailing list)
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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-11 21:18
(Received via mailing list)
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
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 unknown (Guest)
on 2009-02-11 21:55
(Received via mailing list)
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.)
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-11 22:03
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-11 22:16
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-11 22:16
(Received via mailing list)
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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-11 22:46
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-11 22:54
(Received via mailing list)
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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-11 22:56
(Received via mailing list)
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
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2009-02-11 22:57
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-11 23:10
(Received via mailing list)
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
B57c5af36f5c1f33243dd8b2dd9043b1?d=identicon&s=25 F. Senault (Guest)
on 2009-02-11 23:17
(Received via mailing list)
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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-11 23:19
(Received via mailing list)
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
7b8e1744137ecbad51b24ab2d169779b?d=identicon&s=25 Serabe (Guest)
on 2009-02-11 23:34
(Received via mailing list)
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
9d2f78236e45a335301ba1195026105d?d=identicon&s=25 Urabe Shyouhei (Guest)
on 2009-02-12 00:00
(Received via mailing list)
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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-12 00:07
(Received via mailing list)
+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.
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-12 00:25
(Received via mailing list)
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.
A246f7c0ce5f2909483d358bd9e83e4e?d=identicon&s=25 Mike Gold (mikegold)
on 2009-02-12 00:46
[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.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-12 00:50
(Received via mailing list)
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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 00:56
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-12 01:08
(Received via mailing list)
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.
9d2f78236e45a335301ba1195026105d?d=identicon&s=25 Urabe Shyouhei (Guest)
on 2009-02-12 01:15
(Received via mailing list)
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.
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-12 01:18
(Received via mailing list)
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.
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2009-02-12 01:32
(Received via mailing list)
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
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-12 02:05
(Received via mailing list)
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
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-12 02:16
(Received via mailing list)
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
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2009-02-12 02:31
(Received via mailing list)
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=2...

>> 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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-02-12 02:39
(Received via mailing list)
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.
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2009-02-12 02:45
(Received via mailing list)
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=2...

a
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2009-02-12 03:11
(Received via mailing list)
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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2009-02-12 03:27
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-12 03:47
(Received via mailing list)
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.
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-02-12 06:30
(Received via mailing list)
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!
9d2f78236e45a335301ba1195026105d?d=identicon&s=25 Urabe Shyouhei (Guest)
on 2009-02-12 06:34
(Received via mailing list)
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.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-12 06:55
(Received via mailing list)
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.
6e366eb5a71be2bad7f383d42aeb4788?d=identicon&s=25 Justin Collins (Guest)
on 2009-02-12 09:56
(Received via mailing list)
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
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-02-12 10:04
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
:-)
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-12 11:23
(Received via mailing list)
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
C215c6ac79d6bc891dd6a2f4f74aff71?d=identicon&s=25 Ollivier Robert (Guest)
on 2009-02-12 11:31
(Received via mailing list)
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.
C215c6ac79d6bc891dd6a2f4f74aff71?d=identicon&s=25 Ollivier Robert (Guest)
on 2009-02-12 11:40
(Received via mailing list)
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.
B1b1d33e0655e841d4fd8467359c58d0?d=identicon&s=25 Yossef Mendelssohn (Guest)
on 2009-02-12 15:26
(Received via mailing list)
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.00...
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-12 15:30
(Received via mailing list)
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!
B57c5af36f5c1f33243dd8b2dd9043b1?d=identicon&s=25 F. Senault (Guest)
on 2009-02-12 16:01
(Received via mailing list)
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
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-12 16:23
(Received via mailing list)
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
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-12 16:30
(Received via mailing list)
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'
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-12 16:56
(Received via mailing list)
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
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-12 16:57
(Received via mailing list)
>
>
> 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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-12 16:58
(Received via mailing list)
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!
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-12 17:14
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-12 17:28
(Received via mailing list)
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!
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-12 17:45
(Received via mailing list)
> > 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/9ece59428bb...
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-12 18:14
(Received via mailing list)
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/9ece59428bb...
>

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
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2009-02-12 18:30
(Received via mailing list)
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
A5b01739148d8795e99582444361a1bc?d=identicon&s=25 Ola Bini (Guest)
on 2009-02-12 18:34
(Received via mailing list)
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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 18:36
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-12 18:38
(Received via mailing list)
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
8853f712852b03ba6646b59b1723f44d?d=identicon&s=25 Flower Born (flowerborn)
on 2009-02-12 18:38
(Received via mailing list)
* 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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 18:42
(Received via mailing list)
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
Bb6ecee0238ef2461bef3416722b35c5?d=identicon&s=25 pat eyler (Guest)
on 2009-02-12 18:45
(Received via mailing list)
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.
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-12 18:46
(Received via mailing list)
>
>
>
> 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).
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-12 18:52
(Received via mailing list)
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
A5b01739148d8795e99582444361a1bc?d=identicon&s=25 Ola Bini (Guest)
on 2009-02-12 18:56
(Received via mailing list)
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.
Bb6ecee0238ef2461bef3416722b35c5?d=identicon&s=25 pat eyler (Guest)
on 2009-02-12 18:58
(Received via mailing list)
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
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-12 19:05
(Received via mailing list)
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.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-12 19:07
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-12 19:11
(Received via mailing list)
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!
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-12 19:13
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-12 19:15
(Received via mailing list)
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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 19:16
(Received via mailing list)
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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-12 19:20
(Received via mailing list)
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
F2c730957ef0aec5616091b30fe88075?d=identicon&s=25 Ruben Medellin (chubas)
on 2009-02-12 19:26
(Received via mailing list)
+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.
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-02-12 19:28
(Received via mailing list)
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).
Fb1fc6f2eccd067a19b298d89235bfe0?d=identicon&s=25 Rupert Voelcker (rupert)
on 2009-02-12 19:31
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-12 19:38
(Received via mailing list)
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
Bb6ecee0238ef2461bef3416722b35c5?d=identicon&s=25 pat eyler (Guest)
on 2009-02-12 19:49
(Received via mailing list)
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)
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2009-02-12 19:52
(Received via mailing list)
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###.
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-12 20:01
(Received via mailing list)
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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 20:10
(Received via mailing list)
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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-12 20:35
(Received via mailing list)
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
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2009-02-12 20:35
(Received via mailing list)
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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 20:47
(Received via mailing list)
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
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-12 21:06
(Received via mailing list)
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?
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-02-12 21:11
(Received via mailing list)
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 .
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-12 21:33
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-12 21:55
(Received via mailing list)
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.
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-12 22:24
(Received via mailing list)
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
E7cff3cfd41c495e1012227d7dc24202?d=identicon&s=25 Luis Lavena (luislavena)
on 2009-02-12 22:55
(Received via mailing list)
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,
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-12 23:10
(Received via mailing list)
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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-13 00:02
(Received via mailing list)
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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-02-13 00:39
(Received via mailing list)
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.
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 01:18
(Received via mailing list)
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/9ece59428bb...

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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-13 02:13
(Received via mailing list)
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!
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-02-13 02:25
(Received via mailing list)
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
238d827434032df031fc2822afc33b6c?d=identicon&s=25 Gnu Zoo (gnuzoo)
on 2009-02-13 04:51
The entire 1.8.x series should be backward compatible to 1.8.6 NOT
forward compatible to 1.9.x.
0a9c5aca43de64491c28adcca5b04169?d=identicon&s=25 Wayne Walker (wwalker)
on 2009-02-13 04:58
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
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-13 06:06
(Received via mailing list)
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
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-13 06:17
(Received via mailing list)
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.
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2009-02-13 06:18
(Received via mailing list)
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?
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-13 06:25
(Received via mailing list)
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?
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-13 07:00
(Received via mailing list)
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".
9d2f78236e45a335301ba1195026105d?d=identicon&s=25 Urabe Shyouhei (Guest)
on 2009-02-13 07:26
(Received via mailing list)
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=2...

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.
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-13 08:19
(Received via mailing list)
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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-02-13 08:23
(Received via mailing list)
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.
669b7046f02e5dfc4bda4421f1069731?d=identicon&s=25 Alex Fenton (Guest)
on 2009-02-13 08:35
(Received via mailing list)
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=2...
>
> 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
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-13 08:43
(Received via mailing list)
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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-02-13 09:12
(Received via mailing list)
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.
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 09:43
(Received via mailing list)
>
> 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.
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-13 09:52
(Received via mailing list)
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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-13 10:13
(Received via mailing list)
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/...).
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
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 10:56
(Received via mailing list)
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.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-13 10:56
(Received via mailing list)
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.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-02-13 11:03
(Received via mailing list)
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.
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 11:11
(Received via mailing list)
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!
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2009-02-13 12:27
(Received via mailing list)
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.
34a7615f38496a5dafbb3e6b721c435e?d=identicon&s=25 Mohit Sindhwani (Guest)
on 2009-02-13 13:14
(Received via mailing list)
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!)
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 15:38
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-13 16:01
(Received via mailing list)
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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 16:03
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-13 16:08
(Received via mailing list)
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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 16:09
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-13 16:16
(Received via mailing list)
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!
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 16:30
(Received via mailing list)
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...), 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.
D7463bd611f227cfb2ef4da4a978a203?d=identicon&s=25 Christopher Dicely (Guest)
on 2009-02-13 16:31
(Received via mailing list)
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=2...
>
> 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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-13 16:35
(Received via mailing list)
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!
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 16:43
(Received via mailing list)
> 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.
B11f10c4cd9d53970e7be20caa43f940?d=identicon&s=25 Tanaka Akira (Guest)
on 2009-02-13 16:52
(Received via mailing list)
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"}
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-13 17:01
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-13 17:09
(Received via mailing list)
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!
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 17:19
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 17:22
(Received via mailing list)
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 17:27
(Received via mailing list)
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
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-13 17:28
(Received via mailing list)
> 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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-13 17:32
(Received via mailing list)
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!
7ece60b3b5bb235d1b6df89727ca6cf7?d=identicon&s=25 mdiam (Guest)
on 2009-02-13 17:51
(Received via mailing list)
+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 ;-)
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-13 17:54
(Received via mailing list)
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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-13 17:55
(Received via mailing list)
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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-13 17:59
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-13 18:16
(Received via mailing list)
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!
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2009-02-13 18:17
(Received via mailing list)
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-13 18:23
(Received via mailing list)
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.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-13 19:18
(Received via mailing list)
> 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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-13 20:43
(Received via mailing list)
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.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-02-13 21:24
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.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-13 22:09
(Received via mailing list)
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.
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-13 23:58
(Received via mailing list)
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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-14 00:16
(Received via mailing list)
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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-14 00:22
(Received via mailing list)
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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-14 01:24
(Received via mailing list)
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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-14 02:27
(Received via mailing list)
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
4bfcb18ca5298df54d8eb410244d004f?d=identicon&s=25 Uwe Kubosch (donv)
on 2009-02-14 02:43
(Received via mailing list)
+1
B11f10c4cd9d53970e7be20caa43f940?d=identicon&s=25 Tanaka Akira (Guest)
on 2009-02-14 04:42
(Received via mailing list)
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.
Da40adcc3ce9d842f4ea6e2c5ebc3636?d=identicon&s=25 Jean-Denis Muys (Guest)
on 2009-02-14 07:16
(Received via mailing list)
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.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 unknown (Guest)
on 2009-02-14 10:16
(Received via mailing list)
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?
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-14 13:48
(Received via mailing list)
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.
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-02-14 13:48
(Received via mailing list)
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.)
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-14 14:12
(Received via mailing list)
>
> 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?
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-14 14:21
(Received via mailing list)
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!
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-14 14:36
(Received via mailing list)
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...
40ab8a6e1c1a71d3ecbcfea4c54b89ed?d=identicon&s=25 aks (Guest)
on 2009-02-14 19:06
(Received via mailing list)
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.
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-14 20:23
(Received via mailing list)
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.
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-14 23:09
(Received via mailing list)
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
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2009-02-15 06:22
(Received via mailing list)
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?
9d2f78236e45a335301ba1195026105d?d=identicon&s=25 Urabe Shyouhei (Guest)
on 2009-02-15 06:57
(Received via mailing list)
Christopher Dicely wrote:
> may mean some code just called GC.start for some other reason.
True, but that doesn't change the conclusion.
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-15 13:47
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-15 13:58
(Received via mailing list)
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!
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2009-02-15 14:20
(Received via mailing list)
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.
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-15 14:51
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-15 14:56
(Received via mailing list)
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!
This topic is locked and can not be replied to.