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.
Related
I wrote a bunch of Ruby scripts that integrate different tools to create a "workflow for academics". A number of my friends have been very interested in trying this out, however they are held back by how hard it is to install or replicate my environment.
Although Ruby comes built-in with Mac OSX (the applications I integrate are all Mac applications, so unfortunately the solution can only work on Mac), I use a few binary gems, including Appscript (bridge to AppleScript). The problem is that this requires XCode, which my non-programmer friends do not have installed (and it seems a bit demanding to ask them to install 3GB of software to run a few kbs of code).
I tried freezing the gems by installing them with gem -i, into a subdirectory of the source (on github), and tried removing my entire central gems directory on my local computer - it worked fine, the scripts still ran, etc. However, when my friends tried running the scripts, they got error messages about missing library files etc.
So my two questions are:
* how specific are compiled binary gems? will they work on other Mac OSX versions? with other versions of Ruby? etc
* how can I find out exactly which binary files (located in central locations) a Ruby gem depends on, and package this with the source (and how do I tell the gem where to find these files in non-standard locations)
I know this might not be "standard procedure", and I should just package it as a gem and let my friends deal with the problems etc - but I'd really like to solve this, and I am sure there must be some way of doing this?
Thanks a lot
In my experience, compiled gems are not portable. They're dependent on the exact version of ruby and whatever other libraries they use. A better solution would be to have your friends install the "Command Line Tools" version of Xcode -- it's only 100-150 MB and includes everything you need to build gems (and other software). You'll need a (free) Apple Developer ID to download it though.
https://developer.apple.com/downloads?q=Command%20Line%20Tools
well guess that many of you have great expertise on Linux. I currently have some issues with creating a linux-live-medium.
i have a box with OpenSuse-Linux Version 11.3 with all nice things. Several languages run very well: Perl, Python, PHP! All is very well! BTW - i am very glad that Perl runs very nice.
But I am not able to install Ruby 1.9. Everytime i want to do that i end up with Ruby 1.8.7. I want to testrun some ruby-code. Therefore i need Ruby with the following gems
mechanize
nokogiri
utf8_utils
I heard of a Linux-Live-medium that is able to run with all the wanted things including Ruby 1.9.
Therefore the Live-medium is installed on a USB-Stick with R/W partitions. Is this possible.
I am not a linux-expert - but with all the expertise here i think it is possible to create such a USB-Stick. (...with Ruby 1.9 and all with all that extensions)
I love to hear from you!
best regards
zero
Debian/Ubuntu includes both Ruby 1.8.x and 1.9.x - and essentially duplicates most packages in 2 flavors: for 1.8 and 1.9. That might be enough for your purposes - although YMMV, of course.
Yet another solution is RVM that karudzo already mentioned.
Yet another solution is virtualization: simplest form of it would be just chrooting. Most modern Linux systems have an ability to install itself based from some root directory (SuSE has install into given directory functionality, Debian/Ubuntu have debootstrap - and then just running chroot /path/to/that/directory - you'd end up in essentially another system installed cleanly in separate directory.
This will actually be a better solution for you- use RVM:
https://rvm.io/
Then you can easily switch back and forth from 1.8 to 1.9 as desired and make 1.9.2 your default. Just read their docs carefully, it really makes gem management a lot easier.
got a new mac, need to have it setup ready for development. I heard great things about macports, should i use it? Is it really easier than manually download and compile? anyone has any problems using it?
It is for typical ruby web development stuff.
thanks
Try homebrew. It's really good because it's highly optimized, and has no redundant packages.
It's also built in Ruby, which seems particularly relevant to you.
It really is easier than doing it manually. For example:
sudo port install gimp
will download, build, and install Gimp, plus all its dependencies. There are a lot of dependencies.
If you're doing "typical" stuff, the versions of stuff in MacPorts will be sufficient. Only if you need to be on the bleeding edge will you need to bypass MacPorts and download and install manually.
While macports can make installation easier, it's the difference between 4 commands (wget/tar/configure/make) and 1 command. Where macports really shines is in package management. If you're primarily interested in Ruby development, RubyGems might be all you need. If you're doing Ruby on Rails, macports will be quite helpful with all the non-ruby software you'll need. If you want to go completely GUI, you can use Porticus as a macports frontend.
I have had the occasional problem during the build phase, but that's under Tiger, which is behind the times.
I prefer macports, but some people like doing it themselves. Macports tends to be behind releases, but it's still good for me
The strongest problem with macports is that it's not cross platform, and it's hard to specify a well defined development scenario (e.g. you use Foo version 1.2.3, Bar version 0.5.6 etc.). It makes your life easier, but as of today, I still haven't found a decent solution to the definition and building of a development runtime environment which is efficient, easy and cross platform. See also this question.
So my suggestion is: go with macports, unless you want very strict control of your development environment.
You should use a package manager unless you have a well defined, specific reason not to.
'Course, I prefer fink.
It seems to be very counter productive in that so many gems will break on windows. I have been dealing with so many mysql and ruby-mysql gem problems (seg faults occuring in the gem itself, a class called UnixSocket apparently doesn't work well on windows machines, etc etc).
I'm I just wasting my time here? Should I move onto a different scripting language?
I have very little experience with Ruby on Windows but when I was starting with Ruby I was on Windows and I got the general impression that it wasn't a Windows-native system.
So after many years of using primarily Windows, getting into Ruby prompted me to switch back to my original system, Unix, this time to Linux. Ruby did run with less hassle and running bash in its native environment was better than the just-mostly-OK Cygwin. I was happy.
Then my new employer had me switch to the Mac. Now I'm really spoiled, but really happy.
I realize this is subjective but ISTM that Linux was a lot better than windows and the Mac is a lot better than Linux. I could still run Windows in VMWare Fusion if I wanted to, but I don't. I do have some Linux VM's.
I think what I'm really trying to say is that there is a reason Ruby isn't best deployed on Windows. The kind of people who run Ruby are .. I'm trying to think of a non-pejorative word here .. not likely to be found on Windows.
So this is a turning point for you. Yes, .net is a sophisticated and well-documented environment, yes, windows has been reliable for several years now, and yes, it's a respectable system at this point. Yes, it runs Stack Overflow and some of the gurus are Windows guys. But it's just kind of a litmus test for .. darn, missing that word again ..
A lot of people run Windows because they just don't know what else to run. Linux is a good alternative if you have to buy the system yourself. And if you or your employer can afford it, the (Unix-underneath) Mac gives you everything Linux does plus the Mac-specific world.
It's time to choose... :-)
I've been developing with Ruby on Windows for several years, including building and deploying "enterprise" intranet Rails apps running against Oracle, MySQL and SQLServer on both Windows and Solaris servers.
Agreed, there are a few gems that have compiled components whose authors have not built Windows versions - that's OK, it's an open-source platform and they don't have to if they don't want to. Similarly, you're perfectly entitled to (a) ignore libraries that don't have mswin32 or mingw32 versions or (b) give something back by compiling them yourself!
As for the MySQL gem, IIRC on Windows you need the "pure Ruby" adaptor, which does not use the MySQL C API: http://github.com/tmtm/ruby-mysql or gem install ruby-mysql
I don't think you're wasting your time. I've worked with two guys who've done extensive projects on Ruby on Rails apps using Windows XP, like major, long-term projects. They seem to not mind it at all. They both worked on it using the NetBeans IDE. (It has a Ruby-specific version.)
I tried it myself when I first got started with Ruby and didn't run into a lot of errors or problems with gems, though there were some things that worked awkwardly. Usually there was a workaround.
I decided that I greatly preferred using OS X or CentOS Linux for Ruby development. But I know for a fact that working on Windows is possible.
One thing to look out for is that 90% of the Ruby community is on OS X and deploys to Linux, so you'll get more help if you're on one of those OSs.
Another thing to look out for is that the whole Ruby universe and culture is very oriented towards the Unix command line using the bash shell. All your tutorials and stuff are going to kind of assume that. They're going to have instructions like "Go to the shell and run # rake db:migrate and it will be a lot easier to follow those instructions if you have a full-featured shell with command completion, command history, etc. So if you want to work on Windows you might look into installing something like MinGW.
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.