My talk was titled Tirando Ruby por la Ventana, which translates to Throwing Ruby through the Window

The talk was aimed at highlight a few issues with Ruby on Windows, ranging from the community to the implementation.

Here are the slides:

While the slides are in spanish, you might get the idea from the profiling to all the other charts

But ranting without something to back you up is silly, so I’ve tried to proof that platform is not the issue.

On my slides I showed Fenix a proof-of-concept of harness the power of Windows API just re-implementing File.expand_path function, which was considered one of the culprits of performance issues on Windows.

Fenix as an experiment is a nice sandbox to play with Ruby without the lengthy compilation times on building Ruby from scratch on Windows.

It also helped to have a side-by-side comparison of Ruby own implementation.

But, most important, it served the purpose of document File.expand_path behavior through specs.

Ruby itself has no code to ensure that File.expand_path behave consistently across versions.

The goals were simple:

• * Figure out what Ruby it is supposed to do and document it (specs)
• * Implement the minimum code that make those specs pass
• * Harness the power of newer Windows API
• * Benchmark and compare always

So I have only done the minimum set of requirement to make Rails run, and run faster. There are plenty of corner cases that I didn’t cover and some that I’ve acknowledge in the specs but require its implementation.

The end result is use Fenix as playground to start working on better internals for Ruby itself, but without the tedious build process.

Also, all the work is aiming at Ruby 2.0, since the inner changes on Ruby to accommodate something similar are too big to be included back in 1.9.3

How I’m supposed to test this out?

So I guess you don’t believe in my slides… neither other developer’s conclusions

You can take a look to TheCodeShop builds that already include Fenix and test for your self.

Want to join us make Ruby better?

Please, try out and send us your feedback at TheCodeShop group.

A faster Ruby is possible, we just need to get rid of the legacy stuff and build for the future.

I must say that I’m happy to inform that not only was a blast, but RubyInstaller received some financial backing!

Yes, along with Phusion Passenger, RubyInstaller project received donations from the amazing Brazilian Community that attended to Ruby Masters Conf.

Thanks goes to e-Genial too, the company behind the conference.

This contribution is well received, specially in the light of upcoming changes to the project that will be soon announced.

As lead developer of RubyInstaller, to all Brazilians who participated: Muito obrigado!

And yes, the conference will be online with an excellent line up of speakers

Video, chat, slides and interaction with the speakers all using e-Genial online platform, kinda cool, isn’t?

Is cheap! R$ 35 (Brazil reais) is around 21 USD. You gain access to all the talks and if you couldn’t watch them live, you can see the videos 15 days later.

And the awesome part? Their objective is collect money for open source projects, like Phusion Passenger and, wait for it… RubyInstaller !!!

What are you waiting for?

All of the above results were obtained using rake-compiler 0.7.5.

Compilers

All the tests of compilation where performed against the following compilers:

While there are other cross compilers available out there, I haven’t done any testing against them, so can’t verify it’s correctness in the above results.

I would personally recommend the usage of mingw-w64 compilers since are fresh and updated quite often.

Recommendations

If you’re creating extensions, it is recommend you use both 1.8.7 and 1.9.2 as test-beds for your extensions. That will ensure maximum compatibility with future versions of Ruby.

Next version of rake-compiler will bump the default version to 1.8.7, so is better you start preparing now.

¹ 1.8.6 compilation fails when used with mingw-w64 compiler (i686-w64-mingw32 host)

² You can download mingw-w64 compiler from SourceForge Automated Builds

Is quite common use coloring in the output of your tools to indicate an error
or a success, or some sort of information.

To make things easy, there is something called ANSI escape sequences which has great support on Unix systems, but not Windows.

Back in DOS days, there was something called ANSI.SYS which allowed certain ANSI codes to work.

But DOS has been dead for quite some time, and Windows (32 and 64 bits) had no more this nice ANSI support.

Instead, Microsoft created a lot of functions that make it more easy to use screen buffers, flip between them to avoid flickering and other stuff, but we (developers) loose the ability to use colors across platforms transparently from the code perspective.

Because of that, and because we are eager to use colors (remember, we all love colors), developers created libraries on every language that mimic ANSI sequences on Windows using the Win32 console functions.

Java, Perl and others all have their implementation.

In the case Ruby, it does too, as port from Perl’s Win32::Console module by Gonzalo Garramuno which then was packaged as gem by Justin Bailey and is currently maintained by me.

With the move of Ruby to version 1.9.x, certain changes were required and still suffer from some compatibility issues, speed been one.

Thanks to the Internet, we found a little gem hidden on the tubes called “ANSICON” created by Jason Hood, which provides — in C — ANSI escaping codes completely independent of your language of choice.

ANSICON works hooking your console process and any program, extracting any ANSI sequence automatically and translating to the proper Win32 console API.

It works under 32 and 64 bits systems.

What all that means to me?

I proposed the deprecation of win32console and replace it with ANSICON, but what are the benefits of it?

• Proven to work under several scenarios
• Its written in C, not Ruby, which make it available to any other language
• Its faster than win32console
• One less gems for me to maintain

Now, how to use this?

Well, projects like RSpec and Cucumber haven’t still been adapted to use ANSICON yet, but developers are working to provide the changes.

First, you will need to visit ANSICON website and download the binaries:

http://adoxa.110mb.com/ansicon/index.html

Grab the latest package (1.31) and extract its contents somewhere.

Depending on your system architecture, copy the contents of x86 (32bits) or x64 (64bits) to a folder that you have in your PATH. On previous post I’ve recommended have a Tools\bin folder inside your HOME. See my binfiles README for suggestions

Now that ansicon.exe and it’s support libraries are placed there, you can start it manually:

ansicon

That will simply create a new cmd.exe with ANSICON hooks enabled. At any time you can type exit and return to your previous cmd.exe process that is clean of ansicon.

I will recommend you read the README file that comes with ANSICON to know about permanently install ANSICON in your system.

Now, let’s get back to an example:

puts "\e[34mHello \e[31mWorld\e[0m"

In this case, I entered manually the escape codes. If you’re serious for colors, take a look to term-ansicolor

Anyhow, now let’s execute our program:

ruby hello.rb

On a normal prompt, we got something like this:

But, powered by ansicon, we get this lovely result:

Now, extra to that, ANSICON advertise certain information into the ANSICON environment variable

C:\Users\Luis>ECHO %ANSICON%
100x3000 (100x28)

In that variable, we have 4 values. The first two are buffer dimensions and the ones between parenthesis are the size of my visible console.

For example, you can use the visible size information to truncate rows of information.

So what, why care?

Unless you suffer from color blind-ness, colors are useful. Tools like RSpec communicate visually errors from other states using colors.

ANSICON offers a less intrusive approach than previous solutions for coloring, less work for me and more fun for you!

Start using it today!

Over the past month some of these changes materialize and others are still in progress. Consider the following post an status update of the project.

RubyInstaller is been promoted in Ruby-Lang website.

Yes! finally RubyInstaller downloads are displayed first in Ruby’s download page

This marks an important step for the project and it’s goals of make it more easy to try out Ruby on Windows. One less pebble on our path.

Ruby 1.9.2-p0 release and GCC 4.5.0 been used

So 1.9.2-p0 went out, so was RubyInstaller package of it. It felt great release the newer packages just 2 days after the official source code release.

I must admit that it was only possible thanks to the hard work of all the contributors and the ones that prefer to remain anonymous.

Lots of buzz

Since I declared One-Click Installer dead and put the initial bricks for RubyInstaller back in 2007, lot of things happened.

Over the past years thanks to many developers, the project has gained visibility and with it, a bigger user base.

I found that with the diversity of the growing user base, it also increased and exposed issues in the way we work with the project and deal with either bugs, feature requests or even support.

It is hard to keep everybody pleased and is hard to teach people coming to Ruby for the first time how to deal with things they never needed in their dotNET or Java jobs.

It is even harder when the first thing they hear are negativity to their environment (yes, Windows ala windoze, windblows, etc)

So we decided to put all the collective knowledge in our Wiki, specially the Tutorials page. It is interesting to see how that particular page grew over the past 6 months.

Even more interesting and satisfying is see that not only individuals are paying attention to the project but even groups like Pragmatic Studio and their Ruby on Rails training program acknowledge Windows users and provide instructions for getting them started.

Still lot to do

Work on the DevKit installer still goes as we adjust minor details to improve the first time experience and the support for both RubyInstaller and possibly JRuby.

People has been asking to get the DevKit included in the same Ruby package because that will reduce the errors users get. Not everybody needs to compile things all the time.

I personally don’t believe that will fix the education and lack of documentation problem, it will just make the installers 12MB bigger.

We need your help

The project needs more people involved. There is not a huge technical barrier to get started, just the willingness to get things done.

Either you want to document things (tutorials and such) or help out others with issues. Anything you want to do will be appreciated.

More to come

I’m trying to improve the cross-compilation support of Ruby so Linux/OSX developers can provide compatible code for other Windows users. Lot to be done there.

Other exciting things are coming and will post in follow ups. Enough for today!

Nick commented out here that Ryan Tomayko post is correct.

Well, kind of, sorta… not entirely correct.

Mandatory warning

Take the following statements with a grain of objectivity without pondering how much bits and bytes a packaging solution like RubyGems adds to your scenario.

Now, let me present this with a story (I love stories)

Creating my application or library

I had an excellent idea for a new library we needed here at the office. This library will provide a client-side OOP access to a remote webservice we use daily.

After investigation of my remote webservice API and structure and exploration of existing HTTP/REST like interfaces, I decided that would be best to invest my time in leverage the low-level HTTP complexity to an existing library published by another developer.

Filling the gaps and start working

Started creating my library (called Foo) and based the internals calls on what was published for Bar at that time (let’s say was version 1)

So far, everything is great. Everything works great on my computer.

Time to share

It has been 2 weeks since I created this library and we internally wanted to use in another project.

This time, my colleague check out my library repository and try to use the library.

He realizes that Bar is required and is not present in his environment, which leads him to start a gem installation process.

He succeed installing Bar version 2, as is the latest available version by the developer of it, but my library no longer works with it, since there are several API changes.

Spotting that issue can be simple, but now think the following: I’ve used Rip instead of Rubygems, and Rip uses repositories directly, not packaged versions.

So now, Foo is not only version specific, but commit specific since the developer of Bar could have changed API between commits to finalize or stabilize it.

Even worse could be that I used setup.rb that was part of Bar and installed inside my Ruby installation, which then will make complicated to figure out which version I used to implement Foo

But what if…

• Usage of Git submodules for my dependencies… if I’m using Git at all.
• Gemify my library, which then will lead to negative comments from others about me imposing a packaging system on them.
• Do not release or share my library at all. Problem solved.

Add to that, that even if I released my library as a gem or not, there is no way to determine the usage of my Foo from Joe’s Foo variation. Something I raised about GitHub gem forks and commented out here

So, try all the approaches, get your own conclusions, but don’t say that the way I implement something is flawed. That is plain subjective.

Yeah, Windows doesn’t do ANSI coloring like any POSIX terminal, and it has it’s own API with extended control of the console functionality.

UPDATE: Please see this post for the beta1 release of new win32console.

So, I took over the project long ago, since required a couple of fixed. You could find the code here at GitHub

I must say that my backyard and house is getting crowded. Lot of small Open Source projects that require attention and some of those that require some special care, like this case.

What do I mean by this?

win32console do more than just fancy colors, it also translates the current console page back and forth using some clever but not portable character extrapolation…

Now, Ruby 1.9 doesn’t like you do that, not at all.

So wonder, what if I just get rid of that? How much of win32console features are being used beyond the ANSI coloring?

I just verified that tweak work with cucumber in 1.8 and 1.9, but dunno other user cases.

Want to know all that, since I’m creating a much simpler solution that uses FFI and will provide colors for both MRI and JRuby, no extension compilation and will deprecate the need of win32console.

What do you think? Please let me know your thoughts in the comments.

Thank you

Update: See the new list of supported versions here

Update 2: Added 1.8.7-p299 to the list of no compatible

Update 3: Added 1.8.6-p398 to the list of compatibles and 1.8.7 still is not cross-compilable, sorry. 1.9.1-p378 is not cross-compilable either.

To give some background, for the fresh ones just arriving to the blog. rake-compiler provides, besides C/Java extension standardization structure, the ability to cross-compile versions of Ruby to allow developers on Linux/OSX build and release gems for users running Windows.

Seems that latest patchlevels of Ruby 1.8.7 (172) and 1.9.1 (376) cannot be cross compiled.

I’ve reported that to Ruby’s bug tracker under issues #2464 and #2484

From what you can read there, there is a clear change in the rules about what is the minimum Ruby version that can be used to cross compile (known as BASERUBY)

Now, being pointed to the Developer’s Howto page, and checking the history and time, it is clear the note about the limitation is really fresh

The funny thing is that I still can cross compile 1.9.2dev using 1.8.6! Which is contrary to what the recently edited howto states!

Don’t get me wrong, I have no personal issue besides being annoyed, and that will require put some lock in cross-ruby compilation to avoid bug reports about something that is beyond my control.

So, with the goal of making this public and have a link to include in my canned response to people reporting bugs about it, the following is the list of versions and patchlevels of Ruby that I know works and aim to support in relation to bug fixes of rake-compiler itself:

Tricky list, even switching the version of Ruby to match the one desired to be installed, it doesn’t work (reported as #2485, I’m very persistent).

So, apologies to anyone having issues with this: I’m having the same ones here.

I have so cool news to everybody:

MySQL/Ruby support

As I announced 2 months ago, new releases of MySQL gem are going to be build from my repository at GitHub

Please note: only report bugs related to the gem itself, more likely the binary issues. Other type of bugs will be rejected, since this gem is a wrapper around MySQL/Ruby code from Tomita Mashahiro (tmtm)

SQLite3/Ruby bindings

I took the role of maintainer of SQLite3/Ruby project, but I really lack the skills to dig into all the inner details of it.

So, I’m opening the door to anyone with new features, enhancements or bug fixes to fork my clone of the project (here), do your changes and send a pull request.

Both RubyForge Tracker and GitHub pull requests will be honored.

Pure-Ruby Readline (rb-readline)

Released version 0.2.0 a couple of weeks ago, but still is far from perfect.

We are still missing IO redirect and be able to run test_readline.rb test directly.

Roger Pack worked on that, but he also needs some help

Please, fork the project, do your changes and send your pull requests!

Windows Console (win32console) new release soon.

A few patches to improve 1.9 compatibility are under way.

rake-compiler get more audience!

That’s right folks!, rake-compiler now is being used to drive the compile and release process of native gems for DataMapper, FFI and even Thin !

Not too bad for 10 months old tool, ah?

Thanks to all the developers involved in these projects for caring about their products and adding the compatibility for Windows.

More projects listed here … Keep them coming!

Ruby Installer for Windows

Preview and DevKit releases has been moved to RubyForge

While our preview concept is quite stable, we are working on getting it better

Got my certificates to deliver signed installers, how cool is that?

Still alive an kicking

If you think I’m quiet, please join us at RubyInstaller Google Group, will find out that I talk more there than here