How do I use nitpick

[Paul Smith]

After using gem install to load

the gem and all the dependencies I found out that my current level of Rub= y
was insufficient to run the program. =A0So I updated Ruby to the latest
version

No, you didn't. You update an older stable version of Ruby for a
cutting edge development release. I don't think through this whole
thread that you've understood that point.

Ruby 1.8.7 is the most up to date stable version.

Ruby 1.9 is a development version, a technology preview, a cutting
edge look at the future of Ruby. It's not the same as Ruby 1.8, and
it won't be.

--=20
Paul Smith
http://www.nomadicfun.co.uk

(e-mail address removed)

 

[Michael W. Ryder]

No, you didn't. You update an older stable version of Ruby for a
cutting edge development release. I don't think through this whole
thread that you've understood that point.

Ruby 1.8.7 is the most up to date stable version.

Quoting from www.ruby-lang.org/en/downloads: Ruby 1.9.1-p243 (md5:
515bfd965814e718c0943abf3dde5494) Stable Version (recommended). This is
the entry for Source code.
Quoting from the same source: Ruby 1.9.1-p129 Binary (md5:
d9a014199d5d52e9fd170704d2c318e6) Stable version (recommended). This is
for the Ruby on Windows downloads.
Where on this page does it say that not to use the 1.9.1 version? Where
does it say that using the latest version will break a lot of older code?
When I download a program I try to get the latest version and patches
unless there is a warning that it is only for certain environments.
Having been programming for over 35 years this is the first time that I
have had a new version of a language break a lot of existing code.
If the RubyForge site specified which versions of Ruby a gem will work
with it may have prevented me from "downgrading" to the latest version.

Ruby 1.9 is a development version, a technology preview, a cutting
edge look at the future of Ruby. It's not the same as Ruby 1.8, and
it won't be.

Again, where does it say this in ruby-lang.org?

 

[Florian Gilcher]

Quoting from www.ruby-lang.org/en/downloads: Ruby 1.9.1-p243 (md5:
515bfd965814e718c0943abf3dde5494) Stable Version (recommended). This is
the entry for Source code.
Quoting from the same source: Ruby 1.9.1-p129 Binary (md5:
d9a014199d5d52e9fd170704d2c318e6) Stable version (recommended). This is
for the Ruby on Windows downloads.
Where on this page does it say that not to use the 1.9.1 version? Where
does it say that using the latest version will break a lot of older
code?
When I download a program I try to get the latest version and patches
unless there is a warning that it is only for certain environments.
Having been programming for over 35 years this is the first time that I
have had a new version of a language break a lot of existing code.
If the RubyForge site specified which versions of Ruby a gem will work
with it may have prevented me from "downgrading" to the latest version.


Again, where does it say this in ruby-lang.org?

Sorry for bumping this, but I didn't have internet access for the last
few days and wanted to loose a few words about this.

Ruby 1.9.1 is not a development version. It's the most recent production
version. Usually, porting projects from 1.8 to 1.9 is not that much of
an issue and using it in a production environment is totally fine. In my
experience, most projects that have maintainer are 1.9-compatible. My
complete toolchain is on 1.9 and in the seldom cases that I something
didn't work, it was long time to switch for a newer alternative anyways.

Projects using parse_tree however, are not. The reason is simple:
parse_tree relies on a non-guaranteed implementation detail of the Ruby
1.8 interpreter, which happens to store the AST of the interpreted
program in memory and then interprets it. parse_tree accesses this data
structure.
The problem is that Ruby 1.9 is not compiled to an AST anymore but to
bytecode for the YARV virtual machine. So the structure of a running MRI
program have fundamentally changed. For any sane program, this change is
transparent. For parse_tree, it is not. So the problem is parse_tree
being a far too popular and dangerous hack of the runtime, not the Ruby
interpreter being fundamentally incompatible.
It is however possible to get similar results with other libraries.

Regards,
Florian Gilcher