John B. wrote:
The real problem is with the inability to tell if a tool will work in a
given environment. I looked on RubyForge for lint and found two
programs, only one that appeared to be functional. After using gem
install to load the gem and all the dependencies I found out that my
current level of Ruby was insufficient to run the program. So I updated
Ruby to the latest version without knowing that other tools needed by
the first wouldn’t work with the latest and greatest. Its very
frustrating to try and do something and spend so much time trying to
navigate the maze of dependencies while blindfolded.
Paul S. wrote:
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?
Michael W. Ryder wrote:
Paul S. wrote:
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?
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 G.