[ruby-core:21946] New hash : syntax for the 1.8 series?
Brent Roman
I always liked the new hash symbol key colon syntax introduced in 1.9
h = {dog: "bark", cat: "meow", horse: "neigh", programmer: "z z z"}
It's especially nice in method invocations:
animal.noises dog: "bark", cat: "meow", horse: "neigh"
Is anyone working working on porting this back to 1.8?
Anyone else interested in this?
- brent
--
View this message in context: http://www.nabble.com/New-hash-%3A-syntax-for-the-1.8-series--tp21928963p21928963.html
Sent from the ruby-core mailing list archive at Nabble.com.
Eero Saynatkari
>
> I always liked the new hash symbol key colon syntax introduced in 1.9
>
> h = {dog: "bark", cat: "meow", horse: "neigh", programmer: "z z z"}
>
> It's especially nice in method invocations:
>
> animal.noises dog: "bark", cat: "meow", horse: "neigh"
>
> Is anyone working working on porting this back to 1.8?
> Anyone else interested in this?
I know the version boundary is not absolute, but I would very much
like to try to keep as much of significant language- and syntax
changes as possible in 1.9.
But, more importantly, why not just use 1.9? The faster everyone
migrates, the better. If there are any deficiencies in 1.9, your
(and others') energies would be better spent there than trying
to backport changes into 1.8.
Eero
--
Magic is insufficiently advanced technology.
Urabe Shyouhei
> Is anyone working working on porting this back to 1.8?
Not sure if it should go to 1.8, but porting itself is as easy as this:
Index: parse.y
===================================================================
--- parse.y (revision 22198)
+++ parse.y (working copy)
@@ -267,7 +267,7 @@
k__LINE__
k__FILE__
-%token <id> tIDENTIFIER tFID tGVAR tIVAR tCONSTANT tCVAR
+%token <id> tIDENTIFIER tFID tGVAR tIVAR tCONSTANT tCVAR tLABEL
%token <node> tINTEGER tFLOAT tSTRING_CONTENT
%token <node> tNTH_REF tBACK_REF
%token <num> tREGEXP_END
@@ -2504,6 +2504,10 @@
{
$$ = list_append(NEW_LIST($1), $3);
}
+ | tLABEL arg_value
+ {
+ $$ = list_append(NEW_LIST(NEW_LIT(ID2SYM($1))), $2);
+ }
;
operation : tIDENTIFIER
@@ -4526,6 +4530,17 @@
}
}
+ if ((lex_state == EXPR_BEG && !cmd_state) ||
+ lex_state == EXPR_ARG ||
+ lex_state == EXPR_CMDARG) {
+ if (peek(':') && !(lex_p + 1 < lex_pend && lex_p[1] == ':')) {
+ lex_state = EXPR_BEG;
+ nextc();
+ yylval.id = rb_intern(tok());
+ return tLABEL;
+ }
+ }
+
if (lex_state != EXPR_DOT) {
const struct kwtable *kw;
Akinori MUSHA
Brent Roman wrote:
> I always liked the new hash symbol key colon syntax introduced in 1.9
>
> h = {dog: "bark", cat: "meow", horse: "neigh", programmer: "z z z"}
>
> It's especially nice in method invocations:
>
> animal.noises dog: "bark", cat: "meow", horse: "neigh"
>
> Is anyone working working on porting this back to 1.8?
> Anyone else interested in this?
Yes. Backporting syntactic changes is a big part of the plan for ruby
1.8.8, although some features in 1.9 can never be integrated into 1.8
because of compatibility constraints or implementation limitations.
Considering those unfortunate cases, I am thinking of making the 1.8
interpreter at least capable in parsing 1.9 specific constructs
without error, although it may not be able to actually run it.
That way, one would be able to write a script that supports both 1.8
and 1.9 without avoiding 1.9 specific features.
# Note that the version comparison is considered as the last
# resort and for example, object respond_to? test is far more
# preferable and appropriate whenever applicable.
if RUBY_VERSION >= "1.9.1"
# fansastic code for 1.9 making full use of shiny new features
else # This part will be removed when you drop 1.8 support.
# legacy code that works for 1.8
end
Honestly, I don't want ruby developers to hesitate to adopt 1.9
features just because of the market/customer needs for supporting ruby
1.8, nor do like the situation where every developer is forced to make
the ultimate choice among "go for 1.9, drop 1.8", "stay at 1.8, use
1.9 only as a faster 1.8", and "maintain two sets of codebase".
Improving compatibility with 1.9 will help those who are attracted to
1.9 features but still have to work with 1.8, and ease the pain of
supporting multiple versions of ruby.
This has been and is still going to be a tough challenge, but I
believe ruby 1.8 has to move forward (keeping compatibility!) with 1.9
to achieve gradual migration.
P.S.
I will take a close look at Shyouhei's patch when I have the time.
I'm busy right now because I'm moving this weekend.
Regards,
--
Akinori MUSHA / http://akinori.org/
Kornelius Kalnbach
> Yes. Backporting syntactic changes is a big part of the plan for
> ruby 1.8.8
crazy. I generally don't support the idea of backporting features. but I
assume the choice has already been made *sighs*
on the topic: colon hash notation is a great thing, backporting it in
1.8.8 seems to be logical considering the complete change of meaning of
the teeny version since 1.8.7. approaching complete syntactic
compatibility with 1.9 would be nice. but, with most of the new core
methods already backported, 1.8.8 starts to feel like another 1.9.1 to
me - just without YARV, Oniguruma, and memory diet.
by the way, you mention the "plan for Ruby 1.8.8" - can it be seen anywhere?
[murphy]
Eero Saynatkari
> At Tue, 10 Feb 2009 16:30:55 +0900,
> Brent Roman wrote:
> > I always liked the new hash symbol key colon syntax introduced in 1.9
> >
> > h = {dog: "bark", cat: "meow", horse: "neigh", programmer: "z z z"}
> >
> > It's especially nice in method invocations:
> >
> > animal.noises dog: "bark", cat: "meow", horse: "neigh"
> >
> > Is anyone working working on porting this back to 1.8?
> > Anyone else interested in this?
>
> Yes. Backporting syntactic changes is a big part of the plan for ruby
> 1.8.8, although some features in 1.9 can never be integrated into 1.8
> because of compatibility constraints or implementation limitations.
> Considering those unfortunate cases, I am thinking of making the 1.8
> interpreter at least capable in parsing 1.9 specific constructs
> without error, although it may not be able to actually run it.
I personally feel this is not the best course of action. I see no
reason for anyone to stay with the 1.8 line unless it is due to
some company policy/security/risk concern, and in those cases the
only changes should be security and bugfixes that do not change
the language.
That is, I do not understand the case for essentially two parallel
lines of implementation of new features. So far as I understand,
there is nothing in 1.9 that would disqualify it from use if one
accepts the changes anyway. Migration is certainly always something
that takes a certain amount of time, but 1.8 -> 1.9 is not too bad
just to get working--after which one can start using new features.
My feeling is that this migration is best get over with as soon
as possible.
I am also not entirely convinced about the "not maintaining two
versions of the library" argument, in that if the 1.8 line is
essentially hard frozen for new features, then there is no need
to do *anything* to create an 1.8 branch but to keep what one
has right now (and any updates to 1.8.8 will not break it, just
fix bugs etc.) On the other hand, it would seem to me that if
1.8.8 is unlike 1.8.{6,7} but also not quite like 1.9, there
would be a need to actually manage the two library branches
because there is variance in both.
As usual, I am keenly aware that I may be overlooking something
crucial, and would be happy to hear where my thinking has gone
wrong.
Also, thanks for both maintainers' hard work.. it is often
thankless enough without people like me complaining on top
of that.
David A. Black
The problem is, though, that if a customer says, "We will only run
1.8", it usually either means 1.8.6, or else it means "We don't trust
1.9". I can't help thinking that the big thing is to get people to
trust 1.9, and to smooth out any remaining problems with 1.9. Right
now, it may be that the 1.8 "brand" has more trust, but that's just a
coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
2.0, there would not be the same branding effect. (I know that's just
speculation, but I do think that 1.8.x is having to play an awfully
large number of roles.)
I admit I've always been skeptical of the gradual migration approach.
I don't see how it plays out with actual code, and I've never talked
to anyone who actually does it or wants to do it. I know a few people
who have run 1.8.7 (I installed it to learn about it but don't use
it), but by far the majority of opinions I've heard amount to: use
1.8.6, or make the move to 1.9.
Can you put lots of warnings in 1.8.8, so people will see that it's a
bridge version? :-)
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!
Akinori MUSHA
Kornelius Kalnbach wrote:
> on the topic: colon hash notation is a great thing, backporting it in
> 1.8.8 seems to be logical considering the complete change of meaning of
> the teeny version since 1.8.7. approaching complete syntactic
I may have redefined the meaning of teeny, but I think that the
major.minor.teeny labels are confusing in the first place. It sounds
weird that 1.9 is incompatible with 1.8 when they have the same
"major" version number. I would rather label them epoch.major.minor.
Putting it aside, sharing a major version number generally means
backward compatibility, and it certainly is the case for the 1.8
series. There is no discrepancy/violation here even if the second
number were labeled "major" as I said above.
> compatibility with 1.9 would be nice. but, with most of the new core
> methods already backported, 1.8.8 starts to feel like another 1.9.1 to
> me - just without YARV, Oniguruma, and memory diet.
M17N is another main feature that will never get backported. 1.8 only
provides awkward ways to handle multiple string encodings.
> by the way, you mention the "plan for Ruby 1.8.8" - can it be seen anywhere?
I'm sorry but no at the moment. Individual tasks will be added to
Redmine as they come up:
http://redmine.ruby-lang.org/projects/ruby-18/issues
Of course anyone can add a feature request via the tracker.
While backport as well as fixing bugs and misfeatures goes on, I
always consider the backward compatibility very important. So, there
is no question that the branch policy remains in effect:
http://redmine.ruby-lang.org/wiki/ruby-18/BranchPolicy
I know there was unfortunate method name clash with ActiveSupport in
1.8.7, and I had learned from that. I wasn't using Rails or popular
gems so much at the time, but now I do, so you can expect that I will
coordinate with the developers of those major products through the
release engineering process.
Berger, Daniel
> From: Brent Roman [mailto:br...@mbari.org]
> Sent: Tuesday, February 10, 2009 12:31 AM
> To: ruby...@ruby-lang.org
> Subject: [ruby-core:21946] New hash : syntax for the 1.8 series?
>
>
> I always liked the new hash symbol key colon syntax introduced in 1.9
>
> h = {dog: "bark", cat: "meow", horse: "neigh", programmer: "z z z"}
>
> It's especially nice in method invocations:
>
> animal.noises dog: "bark", cat: "meow", horse: "neigh"
>
> Is anyone working working on porting this back to 1.8?
> Anyone else interested in this?
No. I used to be, but then decided it looked ugly with symbols:
h = {dog: :bark}
Will these parse?
h = {object::bark}
h = {dog: object::bark}
h = {dog: ::Array.new::bark}
Regards,
Dan
Akinori MUSHA
Eero Saynatkari wrote:
> I personally feel this is not the best course of action. I see no
> reason for anyone to stay with the 1.8 line unless it is due to
> some company policy/security/risk concern, and in those cases the
> only changes should be security and bugfixes that do not change
> the language.
We provide ruby_1_8_6 and ruby_1_8_7 branches (patch releases) for
that very purpose.
What I feel was unfortunate with hindsight is that the development of
1.9 lacked speed and main features until YARV and M17N actually worked
hard on and finally took place. When many core developers started to
expect a 1.9 release, the 1.8 series had already reached 1.8.5 without
getting much backport because nothing in 1.9 had been (at least
seemed) fixed and promised. The early 1.8 series also had problems
with backward compatibility. Partly because it had many bugs and
misfeatures gradually found and exposed, and mostly because there were
no development policy, incompatible changes had often been made. So I
took over the maintainership, worked out a policy, and released 1.8.6.
I had to start backporting after that. The backports made in 1.8.7
might surprise many people, but from my point of view they should have
been done long time ago.
> That is, I do not understand the case for essentially two parallel
> lines of implementation of new features. So far as I understand,
> there is nothing in 1.9 that would disqualify it from use if one
> accepts the changes anyway. Migration is certainly always something
> that takes a certain amount of time, but 1.8 -> 1.9 is not too bad
> just to get working--after which one can start using new features.
> My feeling is that this migration is best get over with as soon
> as possible.
There are many kinds of users and many situations. Some people agrees
with me that consciously or unconsciously, you tend to avoid using new
features if you still have some install base of old versions of ruby.
The funny thing is, that's still the case even for a new feature you
proposed or implemented. One day, after you migrated to a new version
of ruby, you find yourself thinking of proposing a new feature
completely forgetting that you once proposed something similar, which
has been adopted in the new version. How did we get used to that? My
answer is lack of timely backports.
Let's think about minor new features. Imagine you had code for 1.8,
and you knew you could slightly improve the code by using some minor
new features in 1.9. Would you take a risk and rewrite the code? I
think small enhancements should be introduced bit by bit in a daily
manner and not a bunch at once in every three year, considering that a
new feature in Ruby often introduces user to a good, beautiful style
of coding. Ruby developers deserve a mickle of fun and convenience
made by every a little new feature introduced everyday.
> I am also not entirely convinced about the "not maintaining two
> versions of the library" argument, in that if the 1.8 line is
> essentially hard frozen for new features, then there is no need
> to do *anything* to create an 1.8 branch but to keep what one
> has right now (and any updates to 1.8.8 will not break it, just
> fix bugs etc.) On the other hand, it would seem to me that if
> 1.8.8 is unlike 1.8.{6,7} but also not quite like 1.9, there
> would be a need to actually manage the two library branches
> because there is variance in both.
Given the following points, it seems to me that you can drop support
for old "teeny" releases of ruby in a new version of your library
after a certain period of time.
- 1.8.8 will be upper (mostly) compatible with 1.8.{6,7}.
- One who needs to stay at 1.8.{6,7} would not want a new version of
your library with new features either.
Of course every developer has their own maintenance policy that should
be respected, but I would suggest the way of thinking as the ruby 1.8
maintainer.
> As usual, I am keenly aware that I may be overlooking something
> crucial, and would be happy to hear where my thinking has gone
> wrong.
The most crucial point I must not overlook is that the cost of every
step upgrade from 1.8.x to 1.8.(x+1) must be minimized. I will keep
that ceintainly in mind.
> Also, thanks for both maintainers' hard work.. it is often
> thankless enough without people like me complaining on top
> of that.
Never mind. Thank you for your feedback!
David A. Black
On Wed, 11 Feb 2009, Akinori MUSHA wrote:
> The most crucial point I must not overlook is that the cost of every
> step upgrade from 1.8.x to 1.8.(x+1) must be minimized. I will keep
> that ceintainly in mind.
Could we call 1.8.8 "1.9.-1"? :-) I think a lot of people are getting
the message that there's something so scary about 1.9 that anything is
preferable, as long as it isn't actually 1.9. I know that's not at all
what you intend, but I see signs of it.
Urabe Shyouhei
> The problem is, though, that if a customer says, "We will only run
> 1.8", it usually either means 1.8.6, or else it means "We don't trust
> 1.9". I can't help thinking that the big thing is to get people to
> trust 1.9, and to smooth out any remaining problems with 1.9. Right
> now, it may be that the 1.8 "brand" has more trust, but that's just a
> coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
> 2.0, there would not be the same branding effect. (I know that's just
> speculation, but I do think that 1.8.x is having to play an awfully
> large number of roles.)
>
> I admit I've always been skeptical of the gradual migration approach.
> I don't see how it plays out with actual code, and I've never talked
> to anyone who actually does it or wants to do it. I know a few people
> who have run 1.8.7 (I installed it to learn about it but don't use
> it), but by far the majority of opinions I've heard amount to: use
> 1.8.6, or make the move to 1.9.
>
> Can you put lots of warnings in 1.8.8, so people will see that it's a
> bridge version? :-)
Every single ruby release was a bridge version for ruby 2.0 anyway; take a look
at those "parenthesize argument(s) for future version" warnings :p
Whether 1.8.8 should follow 1.9 fashion is beyond me, but I like 1.8.7 for
being the most powerful 1.8 version I've ever seen.
Also note that I cannot maintain 1.8.6 forever. I think it wiser for you not
to stay 1.8.6 once it reaches its end, like when I finished 1.8.5. That day
comes sooner or later.
Akinori MUSHA
David A. Black wrote:
> The problem is, though, that if a customer says, "We will only run
> 1.8", it usually either means 1.8.6, or else it means "We don't trust
> 1.9". I can't help thinking that the big thing is to get people to
> trust 1.9, and to smooth out any remaining problems with 1.9. Right
> now, it may be that the 1.8 "brand" has more trust, but that's just a
> coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
> 2.0, there would not be the same branding effect. (I know that's just
> speculation, but I do think that 1.8.x is having to play an awfully
> large number of roles.)
Agreed. Maybe it's time to (re)define the versioning scheme. As I
said in another mail, I always feel twisted when the second version
number is called "minor". What is more, even sharing the first two
numbers did not always mean API compatible before 1.8.6.
> I admit I've always been skeptical of the gradual migration approach.
> I don't see how it plays out with actual code, and I've never talked
> to anyone who actually does it or wants to do it. I know a few people
In my view, every new piece of code you write or add is part of
migration, like avoiding upgrade-unsafe method, using a new method
that performs well, etc. .
> who have run 1.8.7 (I installed it to learn about it but don't use
> it), but by far the majority of opinions I've heard amount to: use
> 1.8.6, or make the move to 1.9.
That's not a surprise for me considering that 1.8.6 was the first
version that had decent continuous support by a decent maintainer
under a decent policy. I'm proud of that, and proud of Shyouhei.
However, there are still bugs found in the 1.8 series and some of them
are difficult to fix in 1.8.6 due to its strict backward compatibility
policy or implementation defects.
I would suggest frameworks and libraries move at least to 1.8.7 soon.
Incompatible changes from 1.8.6 are minimal, and all user visible
changes are documented. If any of you have any problem in upgrading,
please let me know. Maybe I can give some clues.
Adopting 1.9 now for production is a brave move, but frameworks and
popular libraries should prepare for that as soon as possible. While
at fixing version dependent parts, make good use of backports in 1.8.7
wherever appropriate to reduce code.
> Can you put lots of warnings in 1.8.8, so people will see that it's a
> bridge version? :-)
I have already added warnings to most of the methods that will
disappear or change in 1.9. There is also a plan to introduce a
compatility warning framework. I'm not sure as to how or when,
though.
Charles Oliver Nutter
> Every single ruby release was a bridge version for ruby 2.0 anyway; take a look
> at those "parenthesize argument(s) for future version" warnings :p
>
> Whether 1.8.8 should follow 1.9 fashion is beyond me, but I like 1.8.7 for
> being the most powerful 1.8 version I've ever seen.
>
> Also note that I cannot maintain 1.8.6 forever. I think it wiser for you not
> to stay 1.8.6 once it reaches its end, like when I finished 1.8.5. That day
> comes sooner or later.
I hope there's some consideration for alternative implementations as
well. If you were us, what would you do? Support only 1.9.1 features?
Move to 1.8.7? Support 1.8.6, 1.8.7, and 1.9.1? And then add 1.8.8 on
top of that?
It's to be expected alternative impls will always be chasing the
"current" Ruby, but releases like 1.8.7 make even harder to find a
slow-moving target to build toward. We do not want to abandon 1.8.6
users, but with an even smaller dev team than core Ruby, we can't afford
to maintain N branches for N production versions of Ruby. So for the
moment, we only have resources to do 1.8.6 and 1.9.1, with a huge
emphasis on 1.8.6.
And then this also affects adoption of the other releases. We've heard
from many people that have not moved to 1.8.7 or 1.9.1 because the
alternative impls have only been 1.8.6 compatible. We've heard from
others that they might consider moving to 1.9.1 once JRuby has support.
And at the same time we hear from users who see our continuing work on
making JRuby's 1.8.6 mode more and more solid and want us to stay there
forever. It's a balancing act complicated by having many drastically
different production branches of the C impl.
A lot of this would also be helped by getting the implementer meetings
going again. We could talk through these concerns. I'm convinced most of
the confusion around 1.8.7 could have been avoided with more communication.
- Charlie
Urabe Shyouhei
> I hope there's some consideration for alternative implementations as
> well. If you were us, what would you do? Support only 1.9.1 features?
> Move to 1.8.7? Support 1.8.6, 1.8.7, and 1.9.1? And then add 1.8.8 on
> top of that?
I, as one of a mentor of "alternative implementations" than matz's 1.9, know so
well how painful it is to chase moving targets. We really need a steady point
of implementation to refer. To be honest I personally wish 1.8 should have
been more solid, conservative in changes than it is now.
But that was not what we chose. When I asked whether to "freeze" 1.8 last
time, this list's answer was "no".
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/9493
So I know how you feel Charlie. I once was at your point. What I learned was
that core people are geeks; they are destined to write new codes. We have to
interact with them.
> It's to be expected alternative impls will always be chasing the
> "current" Ruby, but releases like 1.8.7 make even harder to find a
> slow-moving target to build toward. We do not want to abandon 1.8.6
> users, but with an even smaller dev team than core Ruby, we can't afford
> to maintain N branches for N production versions of Ruby. So for the
> moment, we only have resources to do 1.8.6 and 1.9.1, with a huge
> emphasis on 1.8.6.
Talking about human resources, there are total of 1.0 people to maintain both
1.8.6 and 1.8.7 branches, that is, myself. (plus another 1.0 people for 1.9.1,
who is yugui.) This is why we cannot last 1.8.6 forever; MRI also lacks
developers to do that. When we release 1.8.8, whatever that may be, I cannot
handle 3 branches at one time.
# A few more hands of people change this picture.
> And then this also affects adoption of the other releases. We've heard
> from many people that have not moved to 1.8.7 or 1.9.1 because the
> alternative impls have only been 1.8.6 compatible. We've heard from
> others that they might consider moving to 1.9.1 once JRuby has support.
> And at the same time we hear from users who see our continuing work on
> making JRuby's 1.8.6 mode more and more solid and want us to stay there
> forever. It's a balancing act complicated by having many drastically
> different production branches of the C impl.
There is another balancing act MRI faces. MRI was born to be a geek toy.
People have won its control little by little and geek sandboxes are now very
limited. But once people completely take that away from geeks, what happens --
a plateau. Their new ideas to be used by all Rubyists is the biggest source of
their motivation. Ruby cannot work without that.
Now I think difference in MRI branches are some kind of necessary evil, costs
that Ruby users should pay. JRuby people are paying that cost too much and
there must be a better meeting point, but it is not realistic to completely
abandon new features and stick developers to 1.8.6.
> A lot of this would also be helped by getting the implementer meetings
> going again. We could talk through these concerns. I'm convinced most of
> the confusion around 1.8.7 could have been avoided with more communication.
Agreed. A concensus is essential to an activity like Ruby releasing.
Evan Phoenix
On Feb 10, 2009, at 11:44 AM, Akinori MUSHA wrote:
> At Tue, 10 Feb 2009 22:32:19 +0900,
> David A. Black wrote:
>> The problem is, though, that if a customer says, "We will only run
>> 1.8", it usually either means 1.8.6, or else it means "We don't trust
>> 1.9". I can't help thinking that the big thing is to get people to
>> trust 1.9, and to smooth out any remaining problems with 1.9. Right
>> now, it may be that the 1.8 "brand" has more trust, but that's just a
>> coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
>> 2.0, there would not be the same branding effect. (I know that's just
>> speculation, but I do think that 1.8.x is having to play an awfully
>> large number of roles.)
>
> Agreed. Maybe it's time to (re)define the versioning scheme. As I
> said in another mail, I always feel twisted when the second version
> number is called "minor". What is more, even sharing the first two
> numbers did not always mean API compatible before 1.8.6.
I would hope that some consideration is given to how people expect
version numbers to work. As you stated before, you've been thinking
about ruby's versions like epoch.major.minor, but I'd expect that no
one else has been.
This causes massive confusion and doubt about ruby. When a user
upgrades to 1.8.7 and a significant amount of code begins to fail,
they worry. When the upgrade to 1.8.8 and discover they've been using
new syntax that their coworkers don't have, they get worried.
They get worried because when they see a change in the 3rd number,
they don't expect "this release breaks backward compatibility in major
ways."
We can do little to change their expectations of this fact sadly,
because this is the way almost all open source software uses version
numbers.
In my opinion, we're doing everyone a dis-service by calling YARV and
the trunk 1.9. It's such a huge rewrite, it clearly should be at the
very least 2.0. If we did that, people would
1) Be quite happy there was a new ruby major release, as there as
never been one.
2) Be very aware that it changes a lot, and it's not a simple thing
to upgrade
The problems with the current situation are compounded by the fact
that trunk is currently called 1.9.1, which indicates it's a minor
change from 1.9, which is completely false.
As 1.9 stabilized, it should have been upgraded to 2.0 and begun life
as a normal, new major release.
We can not continue to consider using the first number if the version
a forbidden thing. It is holding back ruby in the eyes of the
programming community, and it's making us all fight amongst ourselves.
>
>
>> I admit I've always been skeptical of the gradual migration approach.
>> I don't see how it plays out with actual code, and I've never talked
>> to anyone who actually does it or wants to do it. I know a few people
>
> In my view, every new piece of code you write or add is part of
> migration, like avoiding upgrade-unsafe method, using a new method
> that performs well, etc. .
>
>> who have run 1.8.7 (I installed it to learn about it but don't use
>> it), but by far the majority of opinions I've heard amount to: use
>> 1.8.6, or make the move to 1.9.
>
> That's not a surprise for me considering that 1.8.6 was the first
> version that had decent continuous support by a decent maintainer
> under a decent policy. I'm proud of that, and proud of Shyouhei.
>
> However, there are still bugs found in the 1.8 series and some of them
> are difficult to fix in 1.8.6 due to its strict backward compatibility
> policy or implementation defects.
>
> I would suggest frameworks and libraries move at least to 1.8.7 soon.
> Incompatible changes from 1.8.6 are minimal, and all user visible
> changes are documented. If any of you have any problem in upgrading,
> please let me know. Maybe I can give some clues.
>
> Adopting 1.9 now for production is a brave move, but frameworks and
> popular libraries should prepare for that as soon as possible. While
> at fixing version dependent parts, make good use of backports in 1.8.7
> wherever appropriate to reduce code.
This is absolutely true, but by creating more confusing in the 1.8
release process, everyone suffers. The company that is considering
using ruby for the first time can easily say "They're not stable
across releases."
The question should be asked, what is the point of 1.8.8? Is it to aid
in migrating people to 1.9? If so, do not release it as 1.8, as it is
not a maintance release for 1.8! As David Black mentioned, call it
something like 1.8x9 or something.
Something that says "this is a release for people transitioning to 1.9"
If thats not said, people won't know why 1.8.8 is put out. They'll
assume it's because there are bug fixes, when thats not at all why it
was put out.
I pled with you to reconsider making drastic changes to 1.8. It will
only create confusion, uncertainty, and doubt about ruby and the ruby
community.
- Evan Phoenix
M. Edward (Ed) Borasky
<charles...@sun.com> wrote:
> I hope there's some consideration for alternative implementations as well.
> If you were us, what would you do? Support only 1.9.1 features? Move to
> 1.8.7? Support 1.8.6, 1.8.7, and 1.9.1? And then add 1.8.8 on top of that?
>
> It's to be expected alternative impls will always be chasing the "current"
> Ruby, but releases like 1.8.7 make even harder to find a slow-moving target
> to build toward. We do not want to abandon 1.8.6 users, but with an even
> smaller dev team than core Ruby, we can't afford to maintain N branches for
> N production versions of Ruby. So for the moment, we only have resources to
> do 1.8.6 and 1.9.1, with a huge emphasis on 1.8.6.
Most of the people that I know running production Ruby environments
are still on some dialect of 1.8.6, either JRuby, MRI 1.8.6 or Ruby
Enterprise Edition. However, I now run openSUSE 11.1 on my main
workstation and it defaults to 1.8.7. If I want 1.8.6, I have to
install it myself. As soon as I can figure out the dependencies, I'm
probably going to put Ruby Enterprise Edition up and use that as my
Ruby 1.8.6 interpreter.
> And then this also affects adoption of the other releases. We've heard from
> many people that have not moved to 1.8.7 or 1.9.1 because the alternative
> impls have only been 1.8.6 compatible. We've heard from others that they
> might consider moving to 1.9.1 once JRuby has support. And at the same time
> we hear from users who see our continuing work on making JRuby's 1.8.6 mode
> more and more solid and want us to stay there forever. It's a balancing act
> complicated by having many drastically different production branches of the
> C impl.
Since I'm currently not working with any production servers, I'm
planning to go full steam ahead with 1.9.1. The new version of the
Pickaxe is nearly finalized, and David A. Black's 1.9.1 book is close
to being printed or already printed. I see absolutely no reason to use
1.8.7 or 1.8.8 for anything new, nor any reason to take a production
system running happily on 1.8.6 and upgrade it in any direction. I
think you've made the right choice -- focus on 1.8.6 and 1.9.1,
although I think I'd like to see more activity on 1.9.1 now that the
syntax and semantics are pretty solid.
>
> A lot of this would also be helped by getting the implementer meetings going
> again. We could talk through these concerns. I'm convinced most of the
> confusion around 1.8.7 could have been avoided with more communication.
Yes. And I'd go one step further. IIRC there was a move for ISO
standardization of the language. Given the amount of time it takes to
form a committee, get representative stakeholders together and such,
I'd expect it to take about a year for some kind of momentum to build.
But I think it's worth the effort. All the languages I know of that
have committee-driven standards -- Forth, FORTRAN, C/C++, Scheme, for
example -- have proven successful in their niches, and in the case of
C/C++, as general-purpose languages.
--
M. Edward (Ed) Borasky
I've never met a happy clam. In fact, most of them were pretty steamed.
M. Edward (Ed) Borasky
[snip]
> This is absolutely true, but by creating more confusing in the 1.8 release
> process, everyone suffers. The company that is considering using ruby for
> the first time can easily say "They're not stable across releases."
>
> The question should be asked, what is the point of 1.8.8? Is it to aid in
> migrating people to 1.9? If so, do not release it as 1.8, as it is not a
> maintance release for 1.8! As David Black mentioned, call it something like
> 1.8x9 or something.
>
> Something that says "this is a release for people transitioning to 1.9"
>
> If thats not said, people won't know why 1.8.8 is put out. They'll assume
> it's because there are bug fixes, when thats not at all why it was put out.
>
> I pled with you to reconsider making drastic changes to 1.8. It will only
> create confusion, uncertainty, and doubt about ruby and the ruby community.
I am much less concerned about the numbers than I am about the
proliferation of versions with little usage in the community. I don't
really care if the current YARV is called 1.9.1 or 2.0, but I *do*
care that there seem to be mostly unused 1.8.7 and 1.8.8, "unstable"
1.9.0, heavily-used 1.8.6 and one "stable" YARV, 1.9.1. As I noted
above, I'm moving my development efforts to 1.9.1 because
a. The documentation is there now, and
b. I want the YARV engine!
Yukihiro Matsumoto
In message "Re: [ruby-core:21977] Re: New hash : syntax for the 1.8 series?"
on Wed, 11 Feb 2009 10:33:56 +0900, Evan Phoenix <ev...@fallingsnow.net> writes:
|This causes massive confusion and doubt about ruby. When a user
|upgrades to 1.8.7 and a significant amount of code begins to fail,
|they worry. When the upgrade to 1.8.8 and discover they've been using
|new syntax that their coworkers don't have, they get worried.
As for 1.8.7, it was unfortunate to break Rails at the beginning, but
"significant amount" is overrated, as far as I understand. The
problems were Rails design was bit weak for name conflict, and more
importantly, NO ONE ever had tried to check Rails on 1.8.7 RC during
the release candidate time. I had talked with DHH and people behind
REE after that, to ask for help when 1.8.8 will out. We will see less
problems, I hope.
matz.
Akinori MUSHA
On Wed, Feb 11, 2009 at 10:33 AM, Evan Phoenix <ev...@fallingsnow.net> wrote:
>
> On Feb 10, 2009, at 11:44 AM, Akinori MUSHA wrote:
>
>> At Tue, 10 Feb 2009 22:32:19 +0900,
>> David A. Black wrote:
>>>
>>> The problem is, though, that if a customer says, "We will only run
>>> 1.8", it usually either means 1.8.6, or else it means "We don't trust
>>> 1.9". I can't help thinking that the big thing is to get people to
>>> trust 1.9, and to smooth out any remaining problems with 1.9. Right
>>> now, it may be that the 1.8 "brand" has more trust, but that's just a
>>> coincidence of the numbering. If 1.8.7 had been 1.9.0, and 1.9.1 were
>>> 2.0, there would not be the same branding effect. (I know that's just
>>> speculation, but I do think that 1.8.x is having to play an awfully
>>> large number of roles.)
>>
>> Agreed. Maybe it's time to (re)define the versioning scheme. As I
>> said in another mail, I always feel twisted when the second version
>> number is called "minor". What is more, even sharing the first two
>> numbers did not always mean API compatible before 1.8.6.
>
> I would hope that some consideration is given to how people expect version
> numbers to work. As you stated before, you've been thinking about ruby's
> versions like epoch.major.minor, but I'd expect that no one else has been.
OK, you are talking about the teeny part under some impression I'm yet
to follow.
In my point of view:
MAJOR(1) - means not much. It is bumped when Matz really feels like it.
MINOR(8) - means backward compatibility. It is bumped when backward
incompatiblity of a significant kind is introduced.
TEENY(7) - means a release sequence in a MINOR version series.
> This causes massive confusion and doubt about ruby. When a user upgrades to
> 1.8.7 and a significant amount of code begins to fail, they worry. When the
A significant amount? I would really like to know more about it.
What we have done through the 1.8.7 development was essentially just
backports from 1.9 that don't change existing behaviors.
There are some cases where a library treads on an incompatibility land
mine, but they are mostly corner cases. For instance, Rails 1.2 began
to fail after 1.8.7, but such libraries as ActiveSupport's core
extensions naturally need an update after a new version of Ruby is
released, because they tweak the builtin features (the language core)
deep inside. No criticism or blame intended, but I simply wonder why
a simple fix for that problem was not shared soon.
The famous method clash with String#chars could have been easily coped
with in the Rails/ActiveSupport world just by adding "class String;
remove_method :chars; end" to disable the newly backported method.
(Technically, ActiveSupport's core extensions add methods not by
directly defining them in a class but by including a module -- that's
why the builtin method is called when ActiveSupport has one with the
same name)
Actually I received a mail regarding the problem from the author who
implemented the conflicting method/library, I replied with some
suggestions to solve the problem but got no reply, so I just gave up.
Next time I will proactively proceed with that.
> upgrade to 1.8.8 and discover they've been using new syntax that their
> coworkers don't have, they get worried.
True, only if backward incompatilitity that a step upgrade brings is
on an untolerable level for business use. (I hope not)
> They get worried because when they see a change in the 3rd number, they
> don't expect "this release breaks backward compatibility in major ways."
As I keep saying, I don't think there was that major incompatibility
introduced in 1.8.7 that affect ordinary people.
> In my opinion, we're doing everyone a dis-service by calling YARV and the
> trunk 1.9. It's such a huge rewrite, it clearly should be at the very least
> 2.0. If we did that, people would
> 1) Be quite happy there was a new ruby major release, as there as never
> been one.
> 2) Be very aware that it changes a lot, and it's not a simple thing to
> upgrade
It would be quite nice if requiring a huge rewrite is what everyone
welcome, but I'm not sure with that thinking of myself and people
around.
> The problems with the current situation are compounded by the fact that
> trunk is currently called 1.9.1, which indicates it's a minor change from
> 1.9, which is completely false.
People should learn that a .0 release is normally considered as a
developer preview, especially when so officially announced. As for
Ruby, a new series has never stabilized with both feature and runtime
stabilities until a .3 release rolls out.
Brent Roman
Urabe,
This patch almost works. However, it fails on this:
ruby -ve "p false ? nil: 'food'"
ruby 1.8.7 (2009-2-10 MBARI 7/0x8770 on patchlevel 72) [i686-linux]
-e:1: syntax error, unexpected tLABEL
p false ? nil: 'food'
^
I've attached a (much bigger :-) patch to 1.8.7-p72 that also backports the
new
lexer states from 1.9 necessary to handle the above syntax.
Thank you *very much* for your quick response.
Without it, I would not have known where to begin.
I've also backported this to the heavily patched version of Ruby 1.6.8
that MBARI uses for embedded systems and robotics.
See photos and videos at:
http://www.mbari.org/ESP
In this application, molecular biologists write high-level Ruby scripts to
perform
chemical assays. A slightly modified version of irb serves as
the user interface. In this environment, Ruby syntax changes
necessarily impact end users. I choose Ruby over Python six
years ago largely because of its free form syntax. The fact that
newer versions require more parentheses and leading zeros for
all floating point literals may make Ruby a more rigorous
programming language, but they also make it less comfortable
for use on an interactive command line.
I've gradually come to view my patched 1.6.8 Ruby as part of
our application. At some point, after I've bent it to my needs,
I expect to switch to a version based on the 1.8 series.
I think that the feature set of 1.8.7 was a good tradeoff. The fact is that
internationalization in 1.9 and YARV add considerable complexity,
resulting in a ruby core binary twice as large as 1.8.7 and three times
the size of 1.6.8.
I hope the MRI team will continue to incrementally improve the 1.8 series.
I'll continue to help in any small way I can.
- brent
Urabe Shyouhei-4 wrote:
>
> Brent Roman wrote:
>> Is anyone working working on porting this back to 1.8?
>
> Not sure if it should go to 1.8, but porting itself is as easy as this:
> ...snip...
>
http://www.nabble.com/file/p21950857/parse.y parse.y
--
View this message in context: http://www.nabble.com/New-hash-%3A-syntax-for-the-1.8-series--tp21928963p21950857.html
Brent Roman
Attached the complete parse.y by accident.
Here's a link to the tested patch against parse.y in 1.8.7-p72:
http://www.nabble.com/file/p21950939/parse.y.patch parse.y.patch
--
View this message in context: http://www.nabble.com/New-hash-%3A-syntax-for-the-1.8-series--tp21928963p21950939.html
Radosław Bułat
But it's only one side of the problem. The other is that with new
syntax changes (possibilities to parse 1.9 syntax correctly as
mentioned Akinori MUSHA) there possibility to write program in 1.8.8
which won't run either in 1.8.7 and 1.8.6 which is very bad thing.
Considering example from Akinori:
if RUBY_VERSION >= "1.9.1"
# fansastic code for 1.9 making full use of shiny new features
else # This part will be removed when you drop 1.8 support.
# legacy code that works for 1.8
end
This program completely fail (it won't even parse) in 1.8.6 and 1.8.7.
From my experience I know that many (if not most) people didn't update
1.8.6 to 1.8.7.
If I must be honest I'm very worried and confused with Ruby versioning
policy. I can't even imagine what is that "fansastic code for 1.9
making full use of shiny new features" which I *must* use and it
should work with 1.8.8 and 1.9.1. Doing so people will migrate to
1.9.1 even slowly because they get message "we backported so many
thing from 1.9.1 s you don't have to migrate to 1.9.1 yet". From user
perspective I expect that so tiny change in version number gives me
almost 100% backwards compatibility and again with Ruby policy it's
wrong.
And what about other Ruby implementations? I know that it's not
problem of Ruby core-team but they should be aware that probably other
implementators target 1.8.6 and 1.9.* branches and won't make 1.8.7
and 1.8.8 versions (of course I'm guessing at this point but I can
image what amount of work it costs). I could lead to partitioning of
community (because people may want to be compatible with other
interpreters like JRuby, Rubinius, MacRuby and in nearly future with
IronRuby, MagLev).
--
Pozdrawiam
Radosław Bułat
http://radarek.jogger.pl - mój blog
Pit Capitain
> From my experience I know that many (if not most) people didn't update
> 1.8.6 to 1.8.7.
I've been one of them until today. Having to stay at home a couple of
days, I decided to try to run all my Ruby programs with 1.8.7. I'm
impressed that *all* but one of them work the same with 1.8.7 as they
did with 1.8.6, and I'm using many evil tricks like modifying Ruby's
AST and fiddling with Ruby's internal memory structures. So, as
Akinory-san said, I see no reason not to update to 1.8.7, besides that
I'm on Windows and there's no One-Click-Installer yet. (BTW many
thanks to Luis for his continuing work on that!) If the transition to
1.8.8 will be as smooth as it seems to be to 1.8.7, I see absolutely
no problems with the plan to provide a 1.8 Ruby which will be able to
parse 1.9 syntax.
Regards,
Pit
M. Edward (Ed) Borasky
Programming is as much, if not more, about communications within a team
of programmers as it is about communication between programmers and
computers. This lesson is drilled into us at early stages in our careers
-- at least it was in mine.
For example, FORTRAN (I) was first created in 1957, and by 1966 there
was a committee-defined language standard, FORTRAN 66. Roughly every 11
years thereafter a new standard appeared, although the growth of C in
the application domain that used to be FORTRAN's exclusive niche has
slowed the standardization process. FORTRAN 1995 seems to be about it.
Ruby is older now than FORTRAN was when it was first standardized, and
yet we don't have a formalized structure of users and implementers in
place to *define* the language. We have the tools and test suites, we
have the community, and we have, I think, enough "industrial support" to
make an ISO standard possible now. I think it's time we got together and
did this.
We have two "de facto" standards now -- Ruby 1.8.6 as defined by the
second edition of the Pickaxe, and Ruby 1.9.1 as released and documented
in "Programming Ruby 1.9" and "The Well-Grounded Rubyist" and "The Ruby
Programming Language". I don't have a huge installed base of Ruby code,
so I am moving to 1.9.1 to take advantage of the YARV engine. I do not
see the point in testing 1.8.7 or 1.8.8 when 1.8.6 works in the MRI
implementation, JRuby, Ruby Enterprise Edition and perhaps others.
James Gray
> If I must be honest I'm very worried and confused with Ruby versioning
> policy.
I agree.
I'm also pretty sure we have a lot more voices in this thread saying
"this is scary" than we do "this is smart." I've seen multiple
recommendations in the wild to avoid 1.8.7 altogether.
I really think we need to take a step back and think about how we got
here and if we are getting the right reactions. In other words, is
this healthy for Ruby that so many disapprove of the 1.8.7 and 1.8.8
releases?
James Edward Gray II
Gregory Brown
> On Feb 11, 2009, at 3:58 AM, Radosław Bułat wrote:
>
>> If I must be honest I'm very worried and confused with Ruby versioning
>> policy.
>
> I agree.
>
> I'm also pretty sure we have a lot more voices in this thread saying "this
> is scary" than we do "this is smart." I've seen multiple recommendations in
> the wild to avoid 1.8.7 altogether.
I'll be blunt. I think it is extremely irresponsible of ruby-core to
stick by what has been such a wildly unpopular decision.
I am all for Ruby 1.9.1 adoption (my book "Ruby Best Practices" is 1.9
only), but Ruby 1.8.7+ creates such a problem for me as a package
maintainer, author, and community member that I am really starting to
get frustrated with the way this is being handled.
Please, please consider moving this experiment to a branch and making
1.8.6 the new 1.8 head. I've seen countless prominent voices in the
community ask for this, and it remains unanswered.
-greg
Radosław Bułat
Good for you :). But I repeat it again: it's only one side of the
problem. Even if 1.8.8 will be compatible with 1.8.7 or 1.8.6 (it
can't be compatible with both of them because 1.8.7 isn't compatible
with 1.8.6 - for example AFAIR the way Hash compute hash for it's keys
has been changed) what is the reason to give user possibility to write
program that won't be compatible with 1.8.6 and 1.8.7? (because user
could use new backported features).
Paul Brannan
> It's such a huge rewrite, it clearly should be at the very least 2.0.
Why not Ruby 2000? :)
Paul
Pit Capitain
> Even if 1.8.8 will be compatible with 1.8.7 or 1.8.6 (it
> can't be compatible with both of them because 1.8.7 isn't compatible
> with 1.8.6
Many people have claimed this, but no one has shown examples for this yet.
> - for example AFAIR the way Hash compute hash for it's keys
> has been changed)
Why would this break code compatibility?
> what is the reason to give user possibility to write
> program that won't be compatible with 1.8.6 and 1.8.7? (because user
> could use new backported features).
This has been the same in most previous releases of Ruby I can
remember. Most of the times there have been new features introduced
with newer versions.
Regards,
Pit
Berger, Daniel
> -----Original Message-----
> From: Pit Capitain [mailto:pit.ca...@gmail.com]
> Sent: Wednesday, February 11, 2009 2:49 PM
> To: ruby...@ruby-lang.org
> Subject: [ruby-core:22009] Re: New hash : syntax for the 1.8 series?
>
> 2009/2/11 Radosław Bułat <radek...@gmail.com>:
> > Even if 1.8.8 will be compatible with 1.8.7 or 1.8.6 (it can't be
> > compatible with both of them because 1.8.7 isn't compatible
> with 1.8.6
>
> Many people have claimed this, but no one has shown examples
> for this yet.
I'd show you, but I can't build 1.8.7-p72:
C:\\ruby-1.8.7-p72>win32\configure
find: =: No such file or directory
Creating Makefile
Creating Makefile(6) : fatal error C1085: Cannot write compiler generated file: '': Invalid argument
NMAKE : fatal error U1077: 'cl' : return code '0x1'
Stop.
Regards,
Dan
Urabe Shyouhei
> This patch almost works. However, it fails on this:
>
> ruby -ve "p false ? nil: 'food'"
> ruby 1.8.7 (2009-2-10 MBARI 7/0x8770 on patchlevel 72) [i686-linux]
> -e:1: syntax error, unexpected tLABEL
> p false ? nil: 'food'
> ^
Oops, I was not aware of this error. Thank you pointing it out.
daz
Builds OK for me using VC++2008 Express ("free") download:
http://www.microsoft.com/express/vc/
Need to ensure that the VC environment is set correctly with:
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat
That takes care of requirement (3) in Ruby's "win32\README.win32":
(3) Please set environment variable (({INCLUDE})), (({LIB})), (({PATH}))
to run required commands properly from the command line.
It looks like you have "nmake" and "cl" in your path but LIB, INCLUDE unset?
Daz
Nobuyoshi Nakada
At Thu, 12 Feb 2009 07:11:49 +0900,
Berger, Daniel wrote in [ruby-core:22011]:
> C:\\ruby-1.8.7-p72>win32\configure
> find: =: No such file or directory
Use Windows bundled find.exe, not of msys or cygwin.
--
Nobu Nakada
Akinori MUSHA
<charles...@sun.com> wrote:
> I hope there's some consideration for alternative implementations as well.
> If you were us, what would you do? Support only 1.9.1 features? Move to
> 1.8.7? Support 1.8.6, 1.8.7, and 1.9.1? And then add 1.8.8 on top of that?
>
> It's to be expected alternative impls will always be chasing the "current"
> Ruby, but releases like 1.8.7 make even harder to find a slow-moving target
> to build toward. We do not want to abandon 1.8.6 users, but with an even
> smaller dev team than core Ruby, we can't afford to maintain N branches for
> N production versions of Ruby. So for the moment, we only have resources to
> do 1.8.6 and 1.9.1, with a huge emphasis on 1.8.6.
Maybe it was my understanding that was wrong, but what I thought was as follows:
=begin
Following 1.8.7 is sort of part of following 1.9.1 for alternative
implementations. Sooner or later they will start supporting 1.9
anyway, and 1.8.7 is just on the way.
Most of them are written in a high level language with advanced
designs, and merging changes for 1.9 into 1.8 is mostly as easy as
semi-automatically applying patches, while in MRI you can't even merge
a single patch because of the K&R vs. ANSI style change and the
internal (private/static) API changes in 1.9. If I, a part-time
hacker, can do all these backports in 1.8.7 MRI, there is no reason to
think they can't.
=end
From what you said there are probably not a few wrong assumptions
here, but I really thought so at the time.
> And then this also affects adoption of the other releases. We've heard from
> many people that have not moved to 1.8.7 or 1.9.1 because the alternative
> impls have only been 1.8.6 compatible. We've heard from others that they
> might consider moving to 1.9.1 once JRuby has support. And at the same time
> we hear from users who see our continuing work on making JRuby's 1.8.6 mode
> more and more solid and want us to stay there forever. It's a balancing act
> complicated by having many drastically different production branches of the
> C impl.
I don't really understand that. If you are a developer and your
product targets all versions ruby including JRuby or the users
strongly want that, you support them including 1.8.6 and older anyway
because that's that the market demands. If you are the user and want
a product to support 1.8.6, then ask the vendor or the author. If
they think if that's reasonable/affordable/profitable, they will do
that. Why ruby 1.8.7 should be the one to be blamed?
Ruby 1.8.7 is targeted at existing <=1.8.6 users and the users who
simply want to use the new features or move to 1.9 but want to leave
some room for 1.8 users to use their products, and I'm pretty sure
there are a plenty of those kinds of users, although nagative opinions
always tend to sound loud.
> A lot of this would also be helped by getting the implementer meetings going
> again. We could talk through these concerns. I'm convinced most of the
> confusion around 1.8.7 could have been avoided with more communication.
Yes, I stand corrected about my lack of understanding, and am
absolutely willing to join. Those kind words at the end healed me a
bit on this thorny dock..
Akinori MUSHA
Brent Roman wrote:
> Attached the complete parse.y by accident.
> Here's a link to the tested patch against parse.y in 1.8.7-p72:
>
> http://www.nabble.com/file/p21950939/parse.y.patch parse.y.patch
Thanks, I've done almost the same on ruby_1_8 and found a problem.
Please continue on the issue #1183.
http://redmine.ruby-lang.org/issues/show/1183