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?
Alex F. wrote:
We know the Rails issue (and solved), but could you elaborate on
issues with wxRuby and SWIG?http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645
This is not our fault. Please hold on and think yourself. GC is
running means
ruby interpreter is running out of memory. It is as clear as day that
object
allocation during GC is not doable, because we do not have any memory
space.
So SWIG had a bug. 1.8.7 helped to find it out.
On 12/02/2009, M. Edward (Ed) Borasky [email protected] 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
Urabe S. wrote:
Alex F. wrote:
We know the Rails issue (and solved), but could you elaborate on
issues with wxRuby and SWIG?
http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645This 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
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”
[email protected] writes:
|1. Would there be a chance of merging the efficiencies of Ruby
|Enterprise Edition, especially copy-on-write friendliness, into the
|“Engine Y. 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.
On 13/02/2009, Yukihiro M. [email protected] wrote:
I think he relied on the version/implementation specific behavior, so
1.8.7 HELPED to find a bug in HIS code, unless I am wrong in any ways.
Any other example of 1.8.7 incompatibility?I am not happy with FUD-like attitude against 1.8.7. From my point of
view, 1.8.7 is a good release with unfortunate beginning. There are
slight incompatibility, but every past releases also had some sort of
incompatibilities as well. I’d like to use 1.8.7 to write new 1.8
code.
I’m sorry if I personally added to this kind of view. Unlike earlier
releases I had some minor problem with code not running after upgrade
to 1.8.7, and it seemed many other people have similar experience.
While acceptable for your own code it is not good for code you
distribute to somebody else.
Back then nobody stepped up and said that if code working on 1.8.6
broke it is a bug so I just left it at that - the compatibility seemed
to be not so great. I have not experienced the same with earlier
versions. There was some issue in the past when a bug in the
interpreter was fixed and it broke a C extension that relied on the
bug and was widely used but it was a single, well understood issue.
The real indisputable failing of 1.8.7 is the introduction of many new
convenience methods into the core classes. If these were separated
into an extension (perhaps one which could be built for 1.8.6 as well)
which was not automatically loaded it would be fine and useful to have
them. As things are now the new methods are often convenient and
somebody coding on 1.8.7 would likely use the new methods making the
code unusable on 1.8.6 and earlier. Been there, done that - as many
people did.
Thanks
Michal
Hi,
In message “Re: If you are unhappy with the direction of Ruby 1.8.7+,
respond”
on Fri, 13 Feb 2009 16:41:25 +0900, Michal S.
[email protected] 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.
On 13/02/2009, Yukihiro M. [email protected] 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
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.
2009/2/13 William J. [email protected]
Your code happened to work by chance.
+1Mr. 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.
2009/2/13 James C. [email protected]:
I would concede that this is something of a grey area as it’s neither a bug
fix or an explicit feature addition, but the question was asked about 1.8.6
code that broke, and this is an example.
James, maybe you missed ruby-talk:327937
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/327937).
Your code isn’t working reliably even on 1.8.6. Look at this IRB
session I’ve just run on my ruby 1.8.6 (2007-03-13 patchlevel 0)
[i386-mswin32]:
irb(main):001:0> {2 => 0, 1 => 0}
=> {1=>0, 2=>0}
irb(main):002:0> {:a => 0, :z => 0}
=> {:a=>0, :z=>0}
irb(main):003:0>
As you can see, in one case the hash is iterated over in insertion
order, in the other case not. It depends on the hash keys and maybe
other factors. If your code was working for you you’ve just been
lucky, but you can’t claim that this is an example for code that was
working on 1.8.6. The code was broken in 1.8.6 and still is broken in
1.8.7, and 1.8.7 even helped you find the bug in your code, as someone
else had said already.
Regards,
Pit
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 S.
[email protected] writes:
|Yes, the attitude towards 1.8.7 evolved in an unfortunate way.
Indeed, and I want to fix it.
|And I think some of the uncertainty resulted from lack of
|communication on part of the core team.
Communication has both side. Of course, core team can/should improve
their attitude. But users might be able to improve how they report to
the team. Some of the team claimed they didn’t get the concrete
report more than complaining in some cases. And we now have Redmine
to improve the communication.
matz.
2009/2/13 William J. [email protected]
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 GitHub - jcoglan/packr at 3.1 still has a
regex-related bug under 1.8.7 that I’ve not found a fix for and that
does
not appear in any other 1.8 or 1.9 release. If anyone has had regex
issues
on 1.8.7 I’d really love some help fixing my bug!
Hi,
At Fri, 13 Feb 2009 16:33:38 +0900,
Alex F. wrote in [ruby-talk:328029]:
Thanks. I perfectly understand the reason for the change, although the
old behaviour worked fine in practice and libraries (not just SWIG ones)
relied on it. It can be seen “fixing broken behaviour” though IMHO
changing expectations of how GC works would better have been left for
1.8->1.9 transition.
And the workaround has been introduced into 1.8.7 already, so
those extensions would work without changing.
Ezra Z. wrote:
the whole ruby community. Please respond here if you think Engine yard
would make good maintainers of the ruby1.8.6 lineageThanks
Yes… (and thanks!)
James C. 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.
James G. 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?
M. Edward (Ed) Borasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
On Fri, Feb 13, 2009 at 12:15 AM, Nobuyoshi N.
[email protected]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
Ola B. wrote:
lineage
+1
Although, I’m at a loss as to what you’d use for the version number on
the
first maintenance release.What about 1.8.6.1?
Someone suggested having 1.8.8 being 1.8.6 syntax and semantics with
only bug fixes, security fixes and efficiency enhancements. That appeals
to me … that way, “1.8.7” is a development release and “1.8.8” is
stable. But I would think EngineYard would want to “brand” their ruby
1.8.6 implementation in a manner similar to Ruby Enterprise Edition.
BTW, Perl had no trouble going from 5.8.x to 5.10.x, and I understand
there is a 5.12.x coming. So I don’t see a problem with Ruby doing
similar things in the third digit. 1.8.10 works for me, as does 1.9.10.
–
M. Edward (Ed) Borasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
On Fri, Feb 13, 2009 at 4:50 AM, James C.
[email protected]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