First of all i just want to install ruby to use sass.
My os is Windows 7 64-bit.
Like recommended on the Sass website:
The fastest way to get Ruby on your Windows computer is to use Ruby
Installer
but here it is not clear which version to use. Quote from the Ruby website:
If you don’t know what version to install and you’re getting started
with Ruby, we recommend you use Ruby 2.1.X installers.
[...]
The 64-bit versions of Ruby are relatively new on the Windows
area and not all the packages have been updated to be compatible with
it. To use this version you will require some knowledge about
compilers and solving dependency issues, which might be too
complicated if you just want to play with the language."
So normally I would install version Ruby 2.2.3 (x64) (which is the newest by now) but after reading the website I tend to Ruby 2.1.7 (not even Ruby 2.1.7 (x64))
I really searched a lot on this topic with google but was not able to get any profound information.
First question: x86_64 or 32 bits
In my experience you should focus on the gem you want to use. Maybe some gems with C code are not ready to be used/compiled on x86_64 OS.
the sass is written in ruby and it depends on yard and maruku (source : https://github.com/sass/sass/blob/stable/sass.gemspec)
maruku doesn't seem to have any dependencies (https://github.com/bhollis/maruku/blob/master/maruku.gemspec) and is written in ruby.
I have looked for yard and it seems that it is a full ruby gem without any dependencies.
That means that the ruby version OS you use shouldn't be a problem (there is no compilation of C code to be done ...).
The other question is the ruby version.
The problem could come from the Ruby 2.2.3 version (32 bits or 64 bits)
This version is relatively new with some changes that needed some adjustments for some gems.
So use 32 bits you can use all the gems you want, and don't try to use the last version of ruby unless you want to try the latest functionalities that have been implemented.
TL;DR: use the Ruby 2.1X installers as they say.
Related
I have installed watir-webdriver via macgem in root and in user, I have required rubygems and included /Library/Frameworks recursively in my framework search path in build settings for this project.
require 'rubygems' runs without a problem
require 'watir-webdriver' returns the error :
Assertion failed: (method_getImplementation(m) == imp), function add_method, file vm.cpp, line 1019.
(lldb)
Im really new to using ruby in xcode can someone explain this?
Thanks
I think I recall hearing something about the version of ruby that ships with the mac OS being um well a kind word would be ancient (1.8 started in 2003.. 1.8.7 in 2008, and while it has been patched more recently than that, it's still kinda old.)
Not sure what Apple's reason for not going to a 1.9 version was, but for some reason they seem to like the older stuff.
Most folks I know working on Watir use some flavor of Ruby 1.9 typically 1.9.3 or 1.9.3. Increasingly people are shifting to 2.0, which came out in Feb.
The first thing I would try is getting a more current version or Ruby and see if that eliminates that error. Instructions are found here I'm pretty sure I used RVM when I installed on my 'work' system (a macbook pro). RVM can be pretty handy (such as if you want to experiment with 2.0) so I'd usually recommend using it for folks on a Mac
I migrated an old script to a new CentOS box and got the following message when running the script:
Faraday: you may want to install system_timer for reliable timeouts
Is it a warning and what is system_timer? A gem?
It is a gem.
You should not need it any more, though, as it only supports Ruby 1.8 and older (and Ruby 1.8 is officially deprecated).
From http://ph7spot.com/musings/system-timer:
Update: system_timer is only relevant if you are running Ruby 1.8. You do not need it if you are running Ruby 1.9, JRuby, Rubinius or MacRuby. Actually using system_timer with one of these Ruby interpreters would not even make any sense since, as explained in this article, system_timer is designed to workaround a fundamental limitation of the threading implementation in Ruby M.R.I. 1.8 (green threads). All other Ruby interpreters use native threads and timeout.rb should work as expected as long as the global interpreter lock is released.
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.
What steps should I follow to upgrade a Ruby project from 1.8.6 to 1.8.7?
It should be mostly seamless, since it was mostly compatible changes to the api.
Still, check out the list of incompatibilities
If you start using the new methods offered by 1.8.7 (or newer!) but would like to remain compatible with 1.8.6, checkout my backports gem.
There are just method add in ruby 1.8.7 in compare to ruby 1.8.6. So if it's works with 1.8.6 it's works in ruby 1.8.7 too.
But if you are a great test suite, launch it and see if all works.
It's a point release. You shouldn't have to do anything.
hey, read this http://casperfabricius.com/site/2010/01/24/multiple-ruby-versions-with-rvm/
it takes you through the installation and setup of Ruby Version Manager - which makes it really easy to switch between different versions of ruby in linux (and mac I think) - if you are on windows, then use this, it's called pik http://github.com/vertiginous/pik/
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.