On Wed, Feb 11, 2009 at 12:53 PM, [email protected] 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.
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.
Charles Oliver N. wrote:
And note also that Ruby core has only a few resources to maintain Ruby
versions…which means the existence of 1.8.7 and plans for 1.8.8 will
eventually force 1.8.6 to be abandoned like 1.8.5 and 1.8.4. How would
you feel about 1.8.6 being EOLed because of 1.8.7 and 1.8.8 taking up
resources?
This can of course be avoided if someone else follows me to continue
supporting
1.8.6. Merging back upper stream changes into 1.8.6 is actually easy;
it is an
automated process and you do not have to write C until “svn merge”
conflicts
something. The harder part is to decide which one to merge.
On Wed, Feb 11, 2009 at 3:03 PM, Trans [email protected] wrote:
+1 if 1.8.7 can’t run 1.8.6 code. I don’t so much care if they add
abilities to bridge to 1.9.
That said, I have a simple solution. Move to 1.9.1 as fast as your
fingers will allow. Do not pass go. Do not collect $200. Get’r done.
T.
That’s exactly my plan, but I don’t have legacy Rails apps or large
RSpec test suites to maintain.
–
M. Edward (Ed) Borasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
Hi Greg et al,
I’d really love to have only 1.8.6 (or compatible) then 1.9.x.
Having more seems like a waste of efforts and will (I’m afraid) make
it more difficult to ensure various plugins/gems do work properly. As
a consequence the ruby/rails/merb etc applications maintainers will
meet more trouble.
+1 for 1.8.x staying compatible with 1.8.6, absolutely.
– Thibaut
On 11/02/2009, Charles Oliver N. [email protected] wrote:
In general, I don’t have any doubt that 1.8.7 and 1.8.8 would be fine
standalone releases, but making them be minor version number changes
essentially forces everyone to upgrade eventually, whether they want to or
not, since Ruby distributors generally don’t expect a 0.0.x release to be
filled with incompatible changes or additions. Ubuntu, for example, now
installs 1.8.7 by default, so Ubuntu users are now much more likely to write
code that doesn’t work on 1.8.6.
+1
On 11/02/2009, Urabe S. [email protected] wrote:
a bright new idea. No one wants to nurse a dead-ended product.
That’s completely fine but then mark the bright new idea as such, not
as a version of a dead-end product. It will do good service to both
the bright new idea and the dead-end product if they are labeled
correctly.
Thanks
Michal
Pit C. wrote:
AFAIK 1.8.7 introduced a method that Rails was using. This could have
happened in previous Ruby upgrades as well. I don’t see why this is
something special with 1.8.7.
That’s the point: library authors should be able to write against a
‘stable’ version of the language, without fearing that a Ruby branch
maintainer is going to happen to fancy to add a clashing method.
As a library author, it’s fair to ask me to track pre-release versions
of 1.9, if I want to ensure timely compatibility with that. But it’s not
reasonable to ask me to track changes on a ‘stable’ branch.
As for the C extensions: do you have more information about what was
changed in the Ruby internals that lead to those problems?
http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645
But this misses the main point - that there is no assurance that code
developed using 1.8.7 (or 1.8.8) will run on 1.8.6.
Again, this is nothing special with the 1.8.7 release. It has been
like this since I’m using Ruby, which is since 2000. The important
point is that (most) 1.8.6 code still runs on 1.8.7.
A folly repeated is not a folly reduced. I’ve suffered from this before
1.8.5 → 1.8.6, and been critical of it before.
I guess that 1.8.7 has just happened to make the silliness of adding a
random pot-pourri of features more apparent to more people.
alex
Yukihiro M. 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 F. [email protected] writes:
|> compatibility of 1.8.7 seems to be pretty good.
|
|Well, Rails. And many SWIG-based C-extensions - eg wxRuby.
We know the Rails issue (and solved), but could you elaborate on
issues with wxRuby and SWIG?
http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645
a
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 F.
[email protected] 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.
Urabe S. 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
On Wed, Feb 11, 2009 at 5:03 PM, Michal S. [email protected]
wrote:
On 11/02/2009, Charles Oliver N. [email protected] 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.
From: “Rick DeNatale” [email protected]
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
Bill K. wrote:
“1.8.9” > “1.8.8”
=> true
“1.8.10” > “1.8.9”
=> false
I remember that… did anyone ever suggest other number bases?
irb(main):001:0> “1.8.9” > “1.8.8”
=> true
irb(main):002:0> “1.8.A” > “1.8.8”
=> true
Nah, too weird!
Alex F. 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.
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
Urabe S. 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.
Gregory B. wrote:
I am setting up two threads
…
This one is for those who wish that Ruby 1.8 would go back to being
1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your
thoughts or at least a simple ‘+1’.
I think it’s too late to go back now, but +1 to wishing 1.8.7 had never
existed. It causes all sorts of confusion even on this mailing list as
to what features do or do not exist in ruby 1.8, and gives admins an
unnecessary dilemma: upgrade all production boxes to new and relatively
untested code which may break existing applications? Or suffer the
complaints from new applications which start to rely on the new
features?
This was all handled much better in the 1.6 -> 1.8 transition.
- 1.6 was stable
- 1.7 was developmental, and added a bunch of features
- finally it was released as 1.8
- there was no meddling with 1.6
- A separate “shim” library was released which included a number of
useful new features from 1.8 (e.g. StringIO), which allowed some code
written using 1.8 features to run under 1.6, thus extending the lifetime
of 1.6
Under this model: 1.9 would have been experimental, it would have been
released eventually as 1.10 (or as 2.0, I don’t care). 1.8 would have
been a stable production branch, and for those people who wanted
1.10/2.0 features, there would be an optional compatibility library.
As for numbering, it’s not so important, but the current scheme is silly
and appears to be based on an irrational fear of exceeding 1.9. AFAICT,
this is either because the string “1.10” doesn’t sort after “1.9”, or
because 2.0 would somehow imply the language is especially “blessed” or
“finalised”.
On that basis, 2.0 will never be released. IMO, YARV was a big enough
change to warrant a new major number. If you want to see numbering done
properly, look at FreeBSD’s release process.
Anyway, I look forward to running ruby version 1.9.9.9 in future years
Bill K. 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.
In article
[email protected],
Rick DeNatale [email protected] 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.