From: Florian Gilcher Date: 2009-10-05T06:35:11+09:00 Subject: Re: How do I use nitpick Michael W. Ryder wrote: > Paul Smith 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 Gilcher -- Posted via http://www.ruby-forum.com/.