I would like to summarize in this blog post what has been going on with RubyInstaller project and what is coming up.

On a previous post I mentioned we reached RubyInstaller goal of provide a stable installer and a series of tools to ease the life of Ruby developers using Windows.

Of course, perfection is a myth, and is good to know that you can always improve what you did before.

But, where to start?

Development Kit as installer

We start looking to what users said on Twitter, our group and of course the bug tracker. We noticed one of the big problems: the Development Kit and complicated instructions.

As you might know already, Windows do not come with development tools out of the box. Even more, if you opt for Microsoft ones (Visual Studio) you might end having issues with GNU tools or projects that do not support MSVC very good.

We took the approach of using Free Software, and base our work on GCC and MinGW project which made more easy for us redistribute things ready for you to use.

A proper DevKit installer is under works, at this time a 7z and self extracting packages can be generated, but the installer will do more stuff, which you find more about it in our group.

Upgrading to GCC 4.5.0

One of the reasons we moved from Visual C 6.0 to GCC was that the compiler was no longer available (and also cost money). Now, it is time to move to a newer version of GCC, to take advantage of specific optimization flags and improved debugger (GDB).

All the components which lack GCC binaries for Windows are built from source for RubyInstaller project.

You can checkout use-devkit branch at GitHub
use-devkit branch has been merged into master.

This proved two important things: our DevKit is able to compile out of the box some projects without tweaks, and two, we are eating our own food.

Getting ready for Ruby 1.9.2

Yes, Ruby 1.9.2 final is coming out soon, and we can say RubyInstaller provided a rc2 for experimentation 2 months ago, and we are building newer packages for further testing.

We hope be able to deliver RubyInstaller 1.9.2 binaries as soon 1.9.2 gets out.

We still need you, and your feedback

Please keep in mind all the contributors are doing all this work in their free time.

Help is always welcome and appreciated. There is not a specific set of skills required, just the willingness to help.

Feedback is important too, and will love hear from your experiences using RubyInstaller, no matter how weird or Rails-related is the thing you’re working on.

That’s all, as I said, exciting stuff coming soon.

RubyInstaller packages released.

Last details of RubyInstaller installers itself was sorted out a month ago, but was holding the release because wanted to be 100% sure nothing else breaks. I should have known better, you can never be 100% sure, so decided to stop stalling and release the final versions.

You can find the installers or 7-zip packages at our website in the download section:

http://rubyinstaller.org/

Which BTW, sports the new design from the pledgie, do you like it? (Sure I do)

What to expect?

RubyInstaller team worked providing installers that works seamlessly across different versions of Windows, environments and a bunch of wacky requirements.

A few points:

• Releases for newer version of Ruby will be delivered more often, really.
• You can install RubyInstaller as normal user without requiring administrative rights (good for lock-down computers).
• Installer do not mess with your system or other Ruby installations
• You can safely uninstall it and your gems or customizations will be kept
• It is extremely fast to install
• It is easy to embed in other installers (silent installation mode).

But that’s not all!

Indeed, more stuff is published to RubyForge now: Experimental

Experimental will be the section dedicated to preview or beta version of Ruby. Right now you can find newer 1.9.2-preview3 version, just released a few weeks ago. Ideally, once it hits final, we will provide installers.

In the mean time, you can experiment with it and help Ruby community improve it’s support for Windows.

Please report any Ruby bug from it to Ruby Redmine bug tracker.

What is next?

We haven’t defined a Roadmap for the installers yet. The next target in the queue is 1.9.3, which is been worked in a separate branch since it requires newer libraries been build.

You can checkout this at our repository

Thank you!

Last but not least I personally want to thank all the developers and users that provided feedback about the installer, the building recipes and helped out with support details at the group.

Without them nothing could have been possible!

Feedback or questions?

Just join us at RubyInstaller group and we will happily answer them

What’s new?

Only two new things: STDERR is now redirected (wasn’t before) and the addition of ECHO on/off functionality thanks to Justin Love

How to install?

You can read previous post with installation instructions, since it is a prerelease, please test it and report me any new issue here

Known Issues

AutoSpec is known to have problems, but is not an issue of win32console, as you can read in GH-3

Cheers!

I’ve pushed to RubyGems a version 0.4.beta3, you can access it from here

What’s new?

Bugsfixes, thanks to sinclair that fixed a couple of regressions due the refactoring and removal of win32-service dependency.

Please read the previous post about install and usage instructions. Thank you.

I just pushed to official gem repositories (Gemcutter) the newer version of mongrel_service

What’s new?

A few outstanding bugs has been fixed. A few patches from Daniel Gies and papillon and other stuff:

Removed win32-service dependency

Since win32-service used SEH, something only present in Visual C, newer builds of Ruby made with GCC cannot use it.

This change will make possible to depend on even less external stuff.

Remember: you still need administrative privileges to install or remove Windows Services.

Mongrel log files are written to the path specified by –log option

Yes, log files used to be written all in Ruby bin folder, this has now changed, thanks to Daniel Gies contribution.

This will happen automatically with the upgraded exectuable.

Workaround Windows 2008 process detection

It is now possible execute the service on any account besides LocalSystem. Contribution by Daniel Gies and papillon.

Wait longer for child process terminate properly

There are times some pending database connections are slow. With this change these will terminate smoothly now.

Nitty gritty

I took the time to cleanup the repository, folder structure and build process to make it more easy update this project in the future. Thanks Hoe and my own experience working with Rake.

How to install it?

Since this is a prerelease gem, you need to indicate the option during gem installation:

gem install mongrel_service --prerelease

Once installed, you can now install new services.

If you already have a service installed for your application, you will need to remove it and install it again for it to update the executable and adjust the service registry information.

The expected commands are mongrel_rails service::remove --name MyService and after issue mongrel_rails service::install --name MyService ...

Report bugs

If you find any problem with this newer build, please use GitHub issues since current Mongrel tracker is full of spam.

Please include servicefb.log, mongrel_service.log and mongrel.log generated when attempts to start or stop the service failed.

When to expect a final release

If no serious bug appears, expect a final 0.4 release next weekend.

Thanks all for the contributions and happy new year!

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.

So, just pushed to Gemcutter the prerelease version (_beta1_) so you guys can test with your current Cucumber/RSpec scenarios.

How to install prerelease versions?

All the RubyGems 1.3.x series sport the feature to prerelease gem installations. I recommend update to RubyGems 1.3.5 first in case you haven’t already, and proceed to install the gem:

gem install win32console --prerelease

The process will install version 1.3.0.beta1, which will be automatically available to any require done by Cucumber or RSpec.

What changed on this release?

As I mentioned before, there are a couple of changes required to support 1.9. On this release, I got rid of hardcoded translation tables used to convert codepages from input/output consoles.

How this affects me?

It will only affect you if you use accented characters in the output. If you do, then you should verify that your console codepage supports them. There is more information in the Cucumber wiki troubleshooting page

Now that text is sent transparently to the output, you have the control to feed the stream with different encodings and ensuring the output matches the console codepage.

A working example of this is located here

Please test it out so a formal 1.3.0 release can be done the upcoming days.

Cheers!

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

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.

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

Update 2: 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.

JRuby

This new version includes an amazing contribution by Alex Coles that allow compilation and packaging of JRuby extensions and gems!

Yes, it is now possible, under JRuby, to compile JRuby gems that bundle jar files with the extensions.

Even more, with proper tools and a valid JRuby installation, you can even compile extensions from your current 1.8 or 1.9 MRI installation!

Please take a look in the README.rdoc file for more details

Rubinius?

I couldn’t test it myself, but seems that rake-compiler got bundled in latest RC1 of Rubinius. See it for yourself here

Thanks to Rubinius support for Ruby C API and huge reverse engineered mkmf, rake-compiler should work for most of the extensions. Will check that statement later.

So, resistance is futile… the next implementations to be assimilated are MacRuby and MagLev, wanna help me out on that?

What’s next?

At the time I started with rake-compiler, none of the cool tools like Pik or rvm existed.

Because of that, the only way possible to generate fat binaries (mentioned before here) was cross-compiling.

Now that is easy to switch Ruby versions and implementations, it will be possible to implement changes to generate native fat-binaries on any platform.

This functionality is planned, but not ETA yet. Want to help? Fork the project on GitHub and start right now!