After a recent Ruby upgrade from 2.6 to 2.7, I no longer get colorized Minitest output as I used to in Windows 10. I can still get colorized output with minitest-reporters or minitest-color, but these do not apply by default—they need a require or a command-line argument. It would be nice to have colors by default.
I'm fairly certain this feature came from a gem that I had installed, but due to my careless upgrade I seem to have lost it, and I've had no success finding it again even after hours of searching.
I have installed win32console, but that didn't make any difference. I also tried using Ruby 2.6 again, to no avail.
Related
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.
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.
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.