What exactly is ruby-build-github, and why should I use it instead of the normal ruby builds?
I came across it while looking into installing Jekyll and using Github Pages.
It makes it easy to install github's fork of ruby (either with rbenv or on its own).
Github's ruby doesn't vary dramatically from "normal" MRI - it's largely backports of things that will be released as part of normal ruby later on.
Github seem to roll out new versions of ruby quite aggressively (according to this [gist]https://gist.github.com/tmm1/8393897) they were running 2.1.0 in production only a fortnight or so after it was released and had run into some of the sharp edges you might expect to encounter.
In general you would have to take a view as to whether you were interested in any of the patches they had applied to mainline ruby, which will of course vary over time
Related
I used Ruby many years ago and am back hopefully to stay. I recall from several years ago reading that odd-numbered releases of Ruby (eg. 1.9.1, 1.9.3, 1.9.5) are meant for development and that even releases (eg. 1.9.2, 1.9.4) are meant to be production stable. Is this (still) the case or is the latest "stable" as per the Ruby website the way to go?
I've never developed a project as grand as Ruby so I don't know if there are rules for releases that should be followed. Any enlightenment on this topic would be appreciated.
Thank you.
Yes, it is in fact true that odd-numbered releases were unstable in the past. (However, note that "odd-numbered" refers to the minor number, not the tiny number, i.e. 1.1.x, 1.3.x, 1.5.x and 1.7.x were unstable development releases.)
This was changed with Ruby 1.9 for a very simple (and very embarassing) reason: there are tons of Ruby scripts as well as shell scripts (including the scripts that the Ruby maintainers themselves use to automate the development, testing and releasing of Ruby) out there, which simply assume that the major version is a single digit. They would simply break otherwise, mostly because they did things like
if RUBY_VERSION > '1.6.3'
which fails for '1.10.0', because the string '1.10.0' is lexicograhically smaller than the string '1.6.3'.
As a result, it was decided to give up the distinction between odd-numbered and even-numbered releases, and make the next stable release 1.9, because that was easier than convincing everybody that their scripts are broken.
So, the 1.9.0-x series of releases corresponds to 1.9.x under the old numbering scheme (i.e. a series of development releases in preparation of the next release) and the 1.9.(x > 0) series of releases corresponds to 1.10.(x-1), i.e. 1.9.2 is really 1.10.1. (Well, except that 1.9.1 was a botched release, so it is more like a 1.10.0-pre and 1.9.2 is 1.10.0 and 1.9.3 is 1.10.1.)
Also, Ruby 2.0 is intended to be fully backwards-compatible, which means that it's really 1.12 ... does that clear up any confusion? :-)
So, in summary: Yes, it used to be true (but in a different way than you thought), but it is no longer true, and hasn't been true since the 1.7 series which ended with the release of Ruby 1.8.0 in August of 2003, over eight years ago.
Nope, that's not the case. I don't think it was ever the case with ruby. 1.8.6 and 1.8.7 were considered stable, as are 1.9.2 and 1.9.3.
You might be thinking of Linux kernels, that's how they do it there.
How good is the new Ruby Installer for Windows?
I asked before about why Ruby was so slow on windows and now I've seen some impressive benchmarks showing marked speed improvements with the minGW compilation used in the new installers and am curious how it has worked for people who have tried it?
How many gems are broken for this version? Any big ones you have been bit by not on this list?
I've played with it a fair bit. It's definitely faster, both because of the new YARV VM in 1.9.1, and the use of a C compiler created sometime this century.
Pure Ruby gems are pretty reliable, obviously. Getting mswin32 binaries to work is a hit/miss situation (mostly miss IMHO), and native mingw32 binaries are still the exception, not the rule.
I wanted FXRuby on Windows, and went through the following to get it: Getting FXRuby Going with Ruby 1.9.1 and the new RubyInstaller
So it depends what gems you care about and how handy you are with build scripts and such. Despite the heroic efforts of Louis Lavena and the Ruby Installer contributors, Ruby on Windows remains a second-class citizen.
As you've already noticed, the RubyInstaller guys maintain a list of gems known to work, or not, but this is pretty fluid. The mailing list is usually pretty responsive to questions as well.
It's quite a bit faster, the exact experience varying according to your application. For low-volume Rails stuff, for example, I think you would probably not notice much: database access doesn't really change, for example.
Easiest thing is to try it. If you save your ruby\bin and ruby\lib directories first, you can install over your existing Ruby and be able to switch between the two. I think only those two directories are affected - it seems to work for me at least.
Once you have an installed mingw32 instance, start with the gem installs. The ones that have compiled components will hopefully already have mingw32 versions. Failing that, you could try modifying with the mswin32 versions from your "old" lib - I haven't done this myself and have only the vaguest memory of reading something that suggested it may work...
At the bare minimum, the mingw32 binaries run fine. If you start installing some esoteric gems, you might get some install failures. I highly recommend using Ruby on Linux or Mac, everything works better on those platforms. You will actually be spending time writing Ruby code instead of yak shaving your way to get gems to configure and build properly. I am writing this based on installing Ruby 1.9.1 mingw bins. The 1.8 version might be more stable. The msvc Ruby 1.9.1 binaries have their own separate set of issues, mostly run time ones.
I know there is ongoing work for in this regards but what is the exact status of JRUby 1.3 compatibility with Ruby 1.9.1 ? I am slightly confused if I can dwnload jruby 1.3 and start working with my ruby 1.9 installation.
The JRuby homepage says :
* Ruby 1.8.6 compatible now
* Ruby 1.9 compatible soon
Wikipedia says the following:
Release history
This table present only releases that present significant steps in JRuby history, aside from versions that mainly fixed bugs and improved performance.
Release Release Date Highlights
0.9 2006-08-01 Rails support[11]
1.1 2008-03-28 Performs better than Ruby MRI 1.8.7[6]
AOT mode and JIT mode[21]
1.1.4 2008-08-28 Refactored Java integration layer
Beginning of Ruby 1.9 support
FFI subsystem for calling C libraries[22]
1.2.0 2009-03-16 Ruby 1.9 support almost complete (including JIT compiler)
Preliminary Android support
A detailed overview of what is done and what is missing can be found on their wiki. From that page:
These are entire areas that need to be worked on.
Encoding::Converter
Yielder/Generator
key Marshal changes
cli options
some RubyBignum changes
possible other changes in Numerics
changes in Dir/IO/File (some obvious things are done, like enumeratorize)
some changes in Math
encoding information in exception messages (now passed via java String)
BigDecimal changes ?
In general, though, I think you'll be fine if you use JRuby for Ruby 1.9 code. Any errors that you may have will be few and far between, and easily fixable (for the most part). I recommend you try your code with the latest JRuby, and if it doesn't work, then you know not to use it yet.
Update to 1.6.4 and you'll get JRuby 1.9 with the --1.9 flag, or with the JRUBY_OPTS environment variable set to --1.9.
Here's an update from the 11/2/2009 release notes for Jruby 1.40:
We have also gotten more serious about
out 1.9 support (–1.9). The bigger
applications mostly just work at this
point, but we still have a ways to go
on 1.9 support. Please try your 1.9
code in JRuby and help us firm things
up.
Having struggled with Rails when it almost worked under JRuby, I'd advise sticking with 1.8x for now if you're doing production work. The JRuby guys are great, and I'm sure they'll nail 1.9, but in the meantime, living on the edge is painful when you're trying to get things done.
I've wanted to learn Ruby for some time and even started to learn a little bit. I then got distracted and for some reason went with Python. I have now however decided that even though my current project is in Python, I will also be learning Ruby and Ruby on Rails.
If somebody were to ask me what version of Python to start with I'd suggest 2.6 because 3 breaks compatibility with all the tutorials they would google. Knowing so little about Ruby, what version should I install on my computer? Is there a major difference between any two versions etc etc?
The version you learn is not that important.
While there will eventually be a shift from the more stable 1.8.x series, 1.9 isn't game breaking in a way where you will be disadvantaged.
Rails recommends version 1.8.7, so if you're going to be learning rails, I'd stick with that. This book is pretty good.
I don't think Ruby has had that many breaking changes - except 1.9 onwards. So any version in the 1.8.x should be fine.. pick the latest stable version.
Rails on the other hand has changed dramatically in Rails 2.
If you're going to be working in Windows, go with the current most stable one-click installer. At time of writing, that would still probably be the 1.8.6-26, although 1.8.6-27 is imminent. 1.8.7 is a small increment and I'm very uncertain about the status of 1.9.1 on the platform.
On OSX or other *nix varieties I'd be prepared to be somewhat more adventurous: the current production Rails release (2.3.2) is supposed to be 1.9.1-compatible (although that may not be the case with all third-party libraries for some time) and learning might be more entertaining with the latest version. It should run a good but faster, too.
Ruby 1.9 makes a few breaking changes, but not like Python 3. Any old Ruby tutorials should work just fine for 1.9. There's nothing like, for example, Python changing print and merging range() with xrange().
It really doesn't make that much difference. The core language hasn't changed a lot — 1.9 is just a lot faster and has gained some new features.
There are some changes that broke some libraries, but those have more to do with the finer implementation details rather than what you learn in basic tutorials, so it shouldn't hurt you. If you want to go with 1.8 for the better library support, that's fine. If you want to go with 1.9 for the better core features, that's fine as well. It doesn't make that much of a difference when you're just starting off.
If you're planning on building stuff that you don't release to the public, that makes use of lots of libraries, 1.8.7 or 1.8.6. If you're writing libraries that will be released to the public, please, please, please make sure they work in Ruby 1.9. Ruby 1.9 is a superior interpreter, but we're stuck with 1.8.x because so many libraries are incompatible with it right now.
http://isitruby19.com/
Learn the latest version. Current latest version is 2.4., but when higher versions are out, go for them immediately. Ruby team pays attention to only release finished work, you don't need to be afraid to install the newest one.
There are multiple Ruby implementations in the works right now. Which are you looking forward to and why? Do you actively use a non-MRI implementation in production?
Some of the options include:
Ruby MRI (original 1.8 branch)
YARV (official 1.9)
JRuby
Rubinius
IronRuby - Ironruby.net
MagLev (Thanks Julian) Github link
MacRuby (Thanks Damien Pollet)
Maglev. It will have the speed benefit of all the optimization that has gone into a major Smalltalk VM over many, many year. Plus it will automatically persist all your data pretty much automatically so there is no more need to monkey around with Object-Relational mapping layers and so on.
Ruby 1.9 (YARV) gives us a good idea as to where ruby is headed, but I wouldn't recommend using it for production use. While it's certainly much faster than 1.8, even some parts of the syntax keep changing, so I don't think you could call it stable. It does have some interesting new features and syntax which will surely find their way into all the other implementations over time.
JRuby and IronRuby are useful in that they give ruby access to a whole range of new libraries and environments where ruby couldn't be used otherwise. I've not found much use for them myself yet, but think it's great that they exist. They may allow ruby to infiltrate corporate environments where it wouldn't otherwise be permitted. That can only be a good thing.
Rubinius and Maglev are probably the most interesting projects, but also those where their benefit to the community is likely to be furthest into the future. Rubinius may well develop into a cutting edge 'pure' VM for the ruby language, allowing ruby code to run much faster than it can now. Maglev too seems extremely promising, backed as it is by 20+ years of VM experience. It will also provide features over and beyond a standard VM, but of course these will come at the cost of code portability.
Overall though, what I'm most excited about is the competition between these implementations. Having competing projects all working to make ruby better can only make the ruby ecosystem stronger. From what I've seen too, while the competition exists it is friendly; each project giving and taking ideas from each other. The work done by the JRuby and Rubinius teams in creating a ruby spec is probably the most important outcome so far, as it will help ensure that all implementations remain compatible.
jRuby is stable and reliable today. Maglev is very promising.
No one mentioned MacRuby yet? I guess it's a bit Mac-specific now, but it could probably be made to compile to the GNU or Étoilé objective-c runtimes too.
Also, I'm waiting for Maglev :)
What about Enterprise Ruby? This has been out there for a while.
https://www.phusionpassenger.com/enterprise