Phusion Corporate Blog

Creating our very first Mac application with Ruby, how exciting!

Jean Pierre Hernandez — Fri, 12 Mar 2010 13:09:00 +0000

People always ask me why I never find a programming language for the Mac and settle down down down. C’est absolument incroyable indeed as the answer should be pretty straight forward to those who have already written an application for the Mac using Objective-C.

As a matter of fact, in France, raising such a question is like asking whether or not Camembert goes well with French fries or not. The answer to this question is obvious as it’s a known fact that Camembert goes well with everything. Seeing as not everyone is blessed with a taste for fine French cuisine and/or is from French héritage however, I’ll try to give an approximation in this blog.

For this, we need to emphasize the differences of developing Mac applications with and without MacRuby.

After setting up MacRuby as described in our previous blog post and having set up Xcode, it is now time to create our very first Mac application in Ruby. In this series of articles, we assume that you have the latest version of OS X installed on your Mac. By the time of this writing, that is Snow Leopard and it is important to emphasize this seeing as some Cocoa API methods have been deprecated or added since its last iteration. Without further ado, allons-y!

Creating a new project

After starting up Xcode:

Select File
Select New Project

A dialog window as shown below should appear.

From this window

Select MacRuby application
Click on Choose…

A file save dialog should now appear as displayed below.

In this window:

Type in BornToBeAlive as our project name.
Click on Save.

A new window should now appear representing the newly created project in the Xcode environment.

By the time of this writing our environment is setup to target OS X 10.5 (Leopard). As mentioned before, we’re going to target OS X 10.6 (Snow Leopard) seeing as we want to utilize the most mature Cocoa API and platform. As such we need to set this target environment to OS X 10.6 in the overview popup menu.

Now that that’s been dealt with, we can finally really start working on our application.

Designing our Interface

Before we’re going to write even a single line of code, let’s first start off by designing the user interface to our application. To do this, we first need to discuss how our programming environment deals with this kind of information.

Certain information about our interfaces, in particular the one’s we’ve created using Interface Builder (the UI design application of Xcode) are usually stored in bundles called NIB files.

As of Xcode 3, these are actually stored in files with the xib file extension as opposed to the nib file extension. Worry not however, as they are just different formats for storing the same information: where xib files appear to be represented as XML text files, a nib file is an archive. More importantly however, the difference between xib and nib files are that the former will be compiled within the executable and will not appear in the final .app bundle.

In general, Xcode will ultimately know what to do with these files and how to treat them. It is for this reason that we’ll refer to both formats as nib files and basically assume no distinction between them.

In the Groups & Files panel, expand the NIB Files group.

In this panel

Double click on MainMenu.xib

This action should result in Interface Builder firing up for this MainMenu.xib file. Various windows of Interface Builder should now be visible to you.

In the MainMenu.xib window:

You see a collection of objects and proxy objects that are necessary for describing our user interface. The objects displayed in this window are objects that describe our application’s user interface and are stored in a freeze dried manner, i.e. serialized. Upon loading the NIB file, they get thawed and instantiated again.

In light of this, it is considered good practice to store only one window object per nib file. This way, we only load in the windows when we really need them (thus conserving memory) and will keep our design more maintainable too as each window and its components will be contained by its own NIB file. The latter will allow us to possibly recycle NIB files too in other projects.

Strictly speaking, we also shouldn’t store a window in our MainMenu.xib as is now the case, but in order to load this in, we require a notion of delegates. The latter is something we’ll discuss in a later article so for now, we’ll keep the window object in MainMenu.xib.

For now:

Double click on Window

This should put the focus on our initial window and via the inspector, we can edit some of its properties, such as the title of the window instance.

While having selected the Window in the MainMenu.xib window, in the inspector window:

Select the first tab, so that the inspector window is displaying the Window Attributes.
Edit the Title field to Born to be Alive

Hit the enter key

Your window should now bare the title Born to be Alive. How exciting!

Let’s add a Label to this window proclaim this message of life even bigger. To add cocoa components to our window, we need to drag and drop them from our Library panel to the window we want to add them to.

In the Library panel:

Set the focus on the search field at the bottom of the Library panel.

Type in Label. Notice that as we type character per character, the components get filtered based on our query.

Your Library panel should now display a few options for labels and should look something like the following:

Note that my Library panel will most likely display more options here in terms of labels as I’ve also installed the BWToolkit palette too. We won’t be using any of those components for our MacRuby applications though, so it’s safe for you to ignore them for now.

Now it’s time to actually add the Label component to our window. As mentioned earlier on, we do this by simply dragging and dropping the Label icon from our Library panel to the window we want to add it to. Doing so should result in something similar to the following:

Great! Let’s rename the newly added Label to something more fitting. In the window displayed above:

Double click on the newly added Label. This should now open up the ability to edit value of this Label.

Type in Born

Hit the enter key.

Your window should now look something like this:

Wouldn’t it be fun if we would have a button that we could press to unveil the full message of life? Let’s do just that by adding a button to the window we’re designing.

In the Library panel:

Type Button in the search box at the bottom of the Library panel. In a similar fashion as the label, it should filter away the components that do not match the Button search description.

Whoah, so many buttons! Let’s just stick with the first shiny one for now.

Drag and drop the first button that appears in the filtered selection to our window. Depending on where you dragged and dropped the button to, your window should now look something like this:

Double click on the newly added button to be able to edit its title.

Type in Unveil full message

Hit the enter key.

Your window should now be shaping up pretty nicely and look something like:

We can actually build this project at this stage and see what we’ve just designed in the form of a real application! Indeed, the standard MacRuby cocoa template has set up most of the boilerplate to get us started. At a later stage, we’ll dive into the details of the bootstrapping process, but for now let’s just assume that it set it up all correctly and save our changes by selecting File->Save from the Interface Builder main menu.

Compiling is not the task of Interface Builder, but the task of Xcode so let’s switch back to Xcode. In the project window, click on the Build and Run button in its toolbar.

After compiling for a few seconds and linking all the dependencies, your new application should launch in your OS X dock, and in particular, the window you just designed should show up.

Clicking on the Unveil full message button doesn’t do a lot though, but that should come as no surprise seeing as we’ve only been designing the interface up to this point. We haven’t yet specified what should happen if one presses the Unveil full message button button.

In terms of Model-View-Controller (MVC) (a separation of concerns design pattern Cocoa relies heavily on), we need a controller to handle this kind of user input.

Writing our very first controller in MacRuby

As mentioned in the previous section, Cocoa was designed with the MVC paradigm in mind. Within this paradigm, we need some kind of controller layer to process the input provided by the user. This input ranges from keyboard events to mouse events. For our intents and purposes, we’re interested in handling mouse events on our Unveil full message button. In order to be able to do that, we need to create a controller that will be able to deal with that.

Also, we may want to process events employed by the user onto the window itself. This would normally require a NSWindowController instance. Taking in mind we want to process events from components within the window as well, we could choose to create a separate controller for these components as well, but that would likely make things overly granular, especially for the simple scenario we’re currently dealing with.

So in place of the latter, we can also just choose to consolidate the ability to process the events of a window and its components all together into a subclass of NSWindowController. This allows us to handle the general case of controlling an NSWindow as well as specify our own actions for handling the components contained by our NSWindow.

To do this, in the Groups & Files panel, expand the BornToBeAlive project as displayed below by clicking on the triangle next to it.

In this expanded project outline view:

Right click (or ctrl+click) on Classes

Select Add->New File

A new window should now appear giving you the options of what kind of new file you would like to add.

From the Ruby user templates, select Ruby File.

Click on Next

This will open up a Save File dialog.

Type in MyWindowController.rb as the name for the new Ruby file.

Click on Finish.

Your window should now look something like this:

As decided upon earlier, we now need to implement our MyWindowController class in a consolidated way such that it can control both the window and the elements contained by that window. We will achieve this by implementing MyWindowController as being a subclass of NSWindowController, and in doing so, specialize the NSWindowController class for our window.

In the code editor, type in:

class MyWindowController < NSWindowController end

Tres bien! But how do we access the label to modify its value after a user has clicked on the Unveil full message button?

Well, according to the Apple cocoa documentation on NSWindowController, it is capable hold a reference to the window it controls/manages. Instinctively, we assume that through this reference, we could access the elements of the window.

Even though this is kind of true, the NSWindow class was designed for general cases as well and not just our specific window. This means that its design is well composed and that it will be rather tedious to acquire a reference to the element of the window we’re interested in manipulating. Most likely, it will involve a lot of chaining query calls which violates the principle of least knowledge.

To drive the point home, accessing an element in such a fashion in general will look something like: window.view.subviews[0]

A non-food solution to this would be to subclass our NSWindow to hold a direct reference to the elements we’re interested in manipulating, but that would require an assumption in terms of type seeing as our NSWindowController only deals with NSWindow and not OurSpecificWindow.

Taking all this into account, it’s probably just better to give our MyWindowController a direct reference to the element of the window we’re interested in manipulating.

In our particular case, we’d like to change the label’s string value after the user has clicked on the Unveil full message button to show the true message of life. This means we need a reference to the label within our MyWindowController and as such our code listing of MyWindowController now is:

class MyWindowController < NSWindowController attr_accessor :my_label end

In Cocoa, such a reference is usually referred to as an outlet, in our case, representing the metaphor of “being able to plug a label object into the outlet”. C’est bon indeed!

We now need to define the action to be taken when a user has clicked on our Unveil full message button. You might be wondering right now whether or not we also need a reference to the button from within MyWindowController as was the case for the label. This however, is not necessarily the case for us seeing as the button — an instance of NSButton — is an action emitter. More specifically, an NSButton inherits from NSControl and NSResponder allowing it to receive user input (e.g. mouse events) and convert these to action events and dispatch the latter to our code. We may touch base on this subject in more detail in a later article, but for now, suffice it to say that we don’t need such a property reference.

When the button receives a mouse event from the user that is of our interest, i.e. a click event, it will convert this event into a click action and try to dispatch the action message to our code. To that end, the button expects us to provide an object with an action handler method to handle the action on delivery. In Cocoa terminology, this object containing the action handler method is referred to as the target of the button.

An action handler method in MacRuby has a distinct method signature: it is a method with one parameter named sender. It is important to adhere to this rule for action handler methods as Xcode and Interface Builder will only then recognize them as being actions.

Let’s open up our code editor in Xcode for MyWindowController.rb and change the listing to:

class MyWindowController < NSWindowController attr_accessor :my_label def unveil_full_message_clicked(sender) @my_label.stringValue = "42" end end

Here, we’ve added the unveil_full_message_clicked action, which will change the stringValue property of our label to the true message of life. Excellent! We’ve now set up all our code, and what remains now is to tell our button to who it should dispatch its action to.

We can setup this target-action for our button programmatic, but Interface Builder provides us with a visual solution for setting these up as well. For the sake of clarity and convenience, the visual solution that we’ll go over with in a few moments enjoys our preference for now.

Hooking our MyWindowController up to our window

In the previous sections we’ve gone from designing our window to providing an implementation for our MyWindowController class. They still need to be hooked up to one another however as they are now still disjoint entities that don’t know of eachothers existence. In this section, we’ll describe how we’ll be able to hook these things up visually using Interface Builder.

In Xcode:

Double click on MainMenu.xib to open up Interface Builder for this nib file.

As we’ve discussed earlier, objects are stored in a freeze dried manner in our NIB file that get “thawed for use” when the NIB file is loaded again. In this case, we need an instance of MyWindowController to hook it up to our freeze dried window instance.

In Interface Builder in the Library Panel:

Type in NSObject in the search field.

Drag and drop the Object from the panel to the MainMenu.xib window of Interface Builder. This will create a new freeze dried object in the NIB file that will be instantiated when the NIB file gets loaded in.

Select the object.

In the Inspector panel:

Click on the Object Identity tab.

As we can see, the object is of class type NSObject. We need to change this to be MyWindowController to let this object be an instance of that type.

In the class identity field, type in MyWindowController.

Our object is now of type MyWindowController. Tres bien!

Now that we’ve created a freeze dried MyWindowController object, it’s time to hook it up to our window instance.

Recall from the code listing on MyWindowController that we have defined an accessor — i.e. outlet — for our label, but have not yet set this property. In particular, we need to set the my_label property of our MyWindowController instance to point to the label of our window. In Cocoa jargon, we need to “plug our window’s label into our MyWindowController’s my_label outlet”.

In the MainMenu.xib window of Interface Builder:

Hold down the right button (or hold ctrl+click) on the MyWindowController object and drag your mouse to the label in the designer.

Release the right mouse button above the label. A popup menu as displayed below should now appear showing you the outlets to which you can hook the label up to.

Click on my_label in the Outlet popup menu to hook the label in the window up to our MyWindowController’s my_label property.

Our MyWindowController now knows what object it should refer to when we use @my_label in MyWindowController. What remains is to set up the target-action for our button to our controller’s action handler method. We’re almost there indeed!

To set the target-action for our button:

Hold down the right mouse button (or ctrl+click) on the button in our window and drag to our My Window Controller object in the MainMenu.xib window as illustrated below.

Release the right mouse button. A popup menu should now appear displaying the controller’s action handler methods we can dispatch the button’s (click) action to.

Click on unveil_full_message_clicked: to allow the button to dispatch the click action event to this method of our MyWindowController instance.

Hit cmd+s to save our changes in Interface Builder.

Return to Xcode. Make sure we’ve saved all the changes we’ve made to the files here too via cmd+s.

Hit the Build & Run button in the toolbar as we’ve done before.

Congratulations, your very first MacRuby application should now be in working order! Go ahead, click on the button to unveil the full message of life!

Epilogue

For the sake of brevity — something I know is hard to believe looking at the volume of this first tutorial — we’ve omitted a few steps you’d normally like to take into consideration.

For instance, we’ve not connected the window outlet of MyWindowController (an outlet it inherited from NSWindowController) to our window instance to allow it to manage the window. Connecting this outlet occurs in a similar fashion as was the case with connecting the label outlet by holding down the right mouse button on the MyWindowController instance and dragging it to the window instance.

Releasing the right mouse button will display a popup menu outlining the outlets we can connect the window to. Clearly we should select the window outlet here.

We’ve also not yet discussed how we can adhere to the one window per nib file, moving the window object from our MainMenu.xib to its own nib file and load it in programmatically. As mentioned before, this will require knowledge of a programming concept called delegates which we’ll discuss in our next tutorial. This will also allow us to explain the concept of File’s Owner and so on, which will require us to refine some of the techniques we’ve explained up to this point.

For now, go out and celebrate your victory of writing your very first MacRuby application.

Homework Assignment

Port the following Born to be Alive application by Johannes Fahrenkrug to MacRuby! Post your GitHub links in the comments for extra street credit Having a hard time being able to do so? Stay tuned for our next installment in the MacRuby series with moi as we’ll dive into objective-c for rubyists!

A gentle introduction to MacRuby

Jean Pierre Hernandez — Fri, 12 Mar 2010 13:08:41 +0000

Bonjour les amis! My name is Jean Pierre Hernandez, I work at Phusion and indeed, am a direct relative of legendary super star disco god Patrick Hernandez.

Where Patrick was born to do disco, I was born to dabble in code, in particular with Cocoa. My brother would often use a cane to emphasize his graceful dance moves, and following suit, we’ll use Ruby to emphasize our élégance and love for fine Mac application development.

It brings me enormous joy to have you here on my blog, most likely resulting from a latent hate [[[towards] angular] brackets]. That’s okay, we’ve all been there, the important thing is we’ve found out that this torture is absolutement not necessary and that verbosity and masochism are still choices when it comes to developing delicious Mac applications. Not here however, as we’ll settle with no less than élégance and beauty! Painlessly incroyable indeed!

Before we’re able to start cooking on our first of many delicious Mac applications, we first need to set up the environment where all the magic happens.

As elegant and beautiful as MacRuby may appear to the developer, make no mistake, it’s also a beast when it comes to performance. Via techniques such as Just-in-Time (JIT) and ahead-of-time compilation, MacRuby applications can achieve performance comparable to native applications. Ahead-of-time compilation in particular is useful if you would like to keep your delicious mac recipes private to a larger extend.

In order to achieve all this goodness, MacRuby employs one of the most sophisticated compiler infrastructures at this moment in the form of LLVM. Depending on your needs and intentions with MacRuby you may want to choose to compile all these components from source by grabbing it from SVN or Git. Keep in mind that in the case of the latter, LLVM is still a moving target in terms of releases and is subjected to rapid API and feature changes. It is for this reason that MacRuby is forced to use specific builds as specified in the README.

Compiling LLVM and MacRuby from source can be quite time consuming and tedious. In particular, LLVM will take about 1 hour to compile utilizing both CPU cores on a unibody MacBook Pro. Luckily, our community is blessed with nice people who made sure we could also utilize already-compiled binaries and nightlies, the latter containing nightly edge builds of MacRuby. For the sake of stability, we’d recommend you to use the former instead.

Once you’ve installed these components, we can start cooking up our first cocoa application for the mac using Ruby, which is exciting indeed!

Phusion Passenger 2.2.11 released

Hongli Lai — Fri, 05 Mar 2010 10:24:12 +0000

This release fixes a regression that appeared in 2.2.10 which only affects Apache. When under high load, Apache might freeze and stop responding to requests. The regression was caused by an attempt in 2.2.10 to fix various file descriptor passing problems. The fix introduced a race condition in one of the Phusion Passenger components, and since the problem only occurs under certain high-concurrency workloads it escaped our last release testing.

This problem does not affect Nginx; you only have to upgrade if you’re using Apache.

More information about the problem can be found at the following discussion thread: http://groups.google.com/group/phusion-passenger/t/d5bb2f17c8446ea0

How do I upgrade to 2.2.11?

Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Or, if you’re an Nginx user:

passenger-install-nginx-module

Please don’t forget to copy & paste the Apache/Nginx config snippet that the installer gives you.

Via a native Linux package

John Leach from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update’).

Once you’ve done this then you can install Phusion Passenger by running:

sudo apt-get install libapache2-mod-passenger

-or-

sudo apt-get install nginx-brightbox

(Note that John is currently packaging 2.2.11, so it might take a while before this release shows up in the apt repository.)

Final

Phusion Passenger is provided to the community for free. If you like Phusion Passenger, please consider sending us a donation. Thank you!

Phusion Passenger 2.2.10 released

Hongli Lai — Mon, 22 Feb 2010 12:53:20 +0000

Phusion Passenger is an Apache and Nginx module for deploying Ruby on Rails web applications, and is mainly focused on ease of use and stability.

Recent changes

Phusion Passenger is under constant maintenance and development. We are pleased to announce Phusion Passenger version 2.2.10. This is a bug fix release.

Fixed some Bundler compatibility problems.

Fixed some file descriptor passing problems, which previously could lead to mysterious crashes.

Fixed some compilation problems on newer GCC versions. Issue #430.

Support #size method in rack.input.

How do I upgrade to 2.2.10?

Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Or, if you’re an Nginx user:

passenger-install-nginx-module

Please don’t forget to copy & paste the Apache/Nginx config snippet that the installer gives you.

Via a native Linux package

John Leach from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update’).

Once you’ve done this then you can install Phusion Passenger by running:

sudo apt-get install libapache2-mod-passenger

-or-

sudo apt-get install nginx-brightbox

(Note that John is currently packaging 2.2.10, so it might take a while before this release shows up in the apt repository.)

Final

Phusion Passenger is provided to the community for free. If you like Phusion Passenger, please consider sending us a donation. Thank you!

Ruby Enterprise Edition 1.8.7-2010.01 released

Hongli Lai — Wed, 20 Jan 2010 22:05:30 +0000

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements, such as:

A “copy-on-write friendly” garbage collector, capable of reducing Ruby on Rails applications’ memory usage by 33% on average.

The tcmalloc memory allocator, which lowers overall memory usage and boosts memory allocation speed.

The ability to performance tune the garbage collector.

The MBARI patch set, for improved garbage collection efficiency.

The zero-copy context switching patch, included as an experimental feature.

Various analysis and debugging features.

REE can be easily installed in parallel to your existing Ruby interpreter, allowing you switch to REE with minimal hassle or risk. REE has been out for about a year now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
– Tobias Lütke (Shopify)

Ruby Enterprise Edition is 100% open source.

Changes

Upgraded to Ruby 1.8.7-p248

The previous REE release was based on 1.8.7-p174.

Improved compiler optimization options

The previous REE release was compiled with -Os -fno-strict-aliasing.

-fno-strict-aliasing was used to avoid improper code generation by GCC 4.4. This was actually caused by some aliasing bugs in Ruby’s util.c source file. The problems have been fixed in 1.8.7-p174 so we’ve now removed this compilation flag, allowing for better compiler optimizations.

It turned out that -O2 yields better performance than -Os in many production environments, though some microbenchmarks might indicate otherwise. Therefore we’ve now replaced -Os with -O2.

Fixed OpenSSL extension compilation problems on systems with OpenSSL 1.0

At this time, upstream Ruby cannot be compiled on systems with OpenSSL 1.0 because of compatibility problems in the Ruby OpenSSL extension. Fedora 12 includes OpenSSL 1.0. We’ve applied a patch by the Fedora guys and added some minor changes to fix some compilation warnings. These patches have been send upstream. Ruby issue #2022.

Backported an IO#write exception bug fix

Upstream Ruby 1.8.7-p248 has a bug in its IO#write method: it always raises Errno::EINVAL even when a different error occured. We found this problem while testing Phusion Passenger on this Ruby release.

We’ve submitted a patch upstream. This patch is also applied in this REE release.

Thread timer fix now merged upstream

Previous REE releases included Joe Damato’s and Aman Gupta’s thread timer fix. This fix has now found its way back upstream and is included by default in 1.8.7-p248, so we’ve removed the patch from our source tree.

Fix a crash bug in the zero-copy context switching patch set

This crash can be reproduced by running “god”, which will eventually cause a crash. Aman Gupta has fixed this problem.

Please note that the zero-copy context switching patch set is disabled by default, and must be explicitly enabled by passing –fast-threading to the installer. It is currently still marked as experimental because there are some known issues with the Kernel::fork method. Issue #9.

Ubuntu package now contains debugging symbols

Previous REE Ubuntu packages that we release had binaries with debugging symbols stripped, in order to minimize the package sizes. We no longer strip the debugging symbols now because Joe and Aman’s Memprof depends on the presence of debugging symbols. Memprof should work out-of-the-box with this release of REE.

Please note that although the binaries are larger, this does not affect performance in any way. The debugging symbols are only used for debugging and introspection purposes and do not affect the runtime behavior of Ruby at all.

Developer documentation is now installed by default

RDoc and RI documentation are now installed by default. You can avoid this by passing --no-dev-docs to the installer.

The Ubuntu packages include developer documentation.

Installer now checks for the existence of the ‘patch’ utility

This fixes bug #10.

Some documentation updates

Parts are contributed by Trevor Turk.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

Phusion Passenger 2.2.9 released

Hongli Lai — Fri, 08 Jan 2010 10:53:56 +0000

Phusion Passenger is an Apache and Nginx module for deploying Ruby on Rails web applications, and is mainly focused on ease of use and stability.

Recent changes

Phusion Passenger is under constant maintenance and development. We are pleased to announce Phusion Passenger version 2.2.9. This is a bug fix release.

Fixed compatibility with Rails 3.

Actually, previous Phusion Passenger releases were already compatible with Rails 3, depending on the spawn method that would be invoked. Here’s the story:

Since Phusion Passenger 2.2.8, when the file config.ru exists, Phusion Passenger will treat the app as a Rack app, not as a Rails app. This is in contrast to earlier versions which gave Rails detection more priority than Rack detection. Phusion Passenger loads Rack apps and Rails apps in different ways. The Rails loader was not compatible with Rails 3, which is what we’ve fixed in this release.

That said, a Rails 3 app would have worked out-of-the-box on Phusion Passenger 2.2.8 as well because Rails 3 apps include a config.ru file by default, causing Phusion Passenger 2.2.8 to use the Rack loader. Earlier versions of Phusion Passenger would just completely bail out because they’d use the Rails loader.

With 2.2.9 there are still some caveats:

Smart spawning (the mechanism with which REE’s 33% memory reduction is implemented) is *not* supported for Rack apps. This means that if you want to utilize smart spawning with Rails 3, then you should remove your config.ru file.

Rails 3 depends on Rack 1.1.0. You must have Rack 1.1.0 installed as a gem, even if you’ve bundled it with the gem bundler. This is because Phusion Passenger itself depends on Rack.

Both of these caveats are temporary. We have plans to solve both of these properly in the future.

What’s up with the Gem Bundler?

There has been some reports that Phusion Passenger is not compatible with Yehuda Katz’s gem bundler. This might have been true for an earlier version of the gem bundler, but the latest version seems to work fine. Please note that you need to insert the following snippet in config/preinitializer.rb, as instructed by the gem bundler’s README:

require "#{RAILS_ROOT}/vendor/gems/environment"

The Rails::Boot monkey patching code as posted here does not seem to be required anymore.

Fixed support for ActiveRecord subclasses that connect to another database.

ActiveRecord subclasses that connect to a database other than the default one did not have their connection correctly cleared after forking. This can result in weird errors along the lines of "Lost connection to MySQL server during query". Issue #429.

[Nginx] Fixed PCRE URL.

passenger-install-nginx-module downloads PCRE 7.8 if PCRE is not already installed. However PCRE 7.8 has been removed from their FTP server, so we’ve updated the URL to point to the latest version, 8.0.

How do I upgrade to 2.2.9?

Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Or, if you’re an Nginx user:

passenger-install-nginx-module

Please don’t forget to copy & paste the Apache/Nginx config snippet that the installer gives you.

Via a native Linux package

John Leach from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update’).

Once you’ve done this then you can install Phusion Passenger by running:

sudo apt-get install libapache2-mod-passenger

-or-

sudo apt-get install nginx-brightbox

(Note that John is currently packaging 2.2.9, so it might take a while before this release shows up in the apt repository.)

Final

Phusion Passenger is provided to the community for free. If you like Phusion Passenger, please consider sending us a donation. Thank you!

Phusion Passenger 2.2.8 released

Hongli Lai — Wed, 16 Dec 2009 07:39:11 +0000

Phusion Passenger is an Apache and Nginx module for deploying Ruby on Rails web applications, and is mainly focused on ease of use and stability.

Recent changes

Phusion Passenger is under constant maintenance and development. We are pleased to announce Phusion Passenger version 2.2.8. This is a bug fix release.

[Nginx] Fixed some signal handling problems.

Restarting Nginx on OS X with SIGHUP can sometimes take a long time or even fail completely. This is because of some signal handling problems, which have now been fixed.

[Nginx] Added OpenSSL as dependency.

OpenSSL is required in order to install Nginx, but this was not checked by passenger-install-nginx-module. As a result, passenger-install-nginx-module fails on e.g. out-of-the-box Ubuntu installations until the user manually installs OpenSSL. Issue #422.

[Nginx] Fixed support for internal redirects and subrequests.

It is now possible to, for example, point X-Accel-Redirects to Phusion Passenger-served URLs. Patch contributed by W. Andrew Loe III: issue #433.

[Apache] Fixed a GnuTLS compatibility issue

mod_gnutls can cause Phusion Passenger to crash because of an unchecked NULL pointer. This problem has now been fixed: issue #391.

Fixed thread creation issue on Intel Itanium platforms.

This fixes issue #427.

Fixed compilation problems on Linux running on the Renesas SH4 CPU.

Patch contributed by iwamatsu: issue #428.

The Rack library has been unvendored.

The original reason for vendoring was to work around broken Rails applications that explicitly specify Rack as a gem dependency. We’ve found a better workaround that does not require vendoring Rack. This also fixes a compatibility problem with Rails 3, because Rails 3 depends on a newer Rack version than the one we had vendored. Issue #432.

Fixed compatibility with Ruby 1.9.1 patchlevel >= 152

Ruby 1.9.1 patchlevel >= 152 has a bug in its tempfile library. If you’ve seen an error message along the lines of

*** Exception IOError in Passenger RequestHandler (closed stream)

then this is a Ruby bug at work. This bug has been fixed in Ruby 1.9.2, but Ruby 1.9.1 still contains this bug. We’ve added a workaround so that the bug is not triggered with this Ruby version. Issue #432.

How do I upgrade to 2.2.8?

Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Or, if you’re an Nginx user:

passenger-install-nginx-module

Please don’t forget to copy & paste the Apache/Nginx config snippet that the installer gives you.

Via a native Linux package

John Leach from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update’).

Once you’ve done this then you can install Phusion Passenger by running:

sudo apt-get install libapache2-mod-passenger

-or-

sudo apt-get install nginx-brightbox

(Note that John is currently packaging 2.2.8, so it might take a while before this release shows up in the apt repository.)

Final

Phusion Passenger is provided to the community for free. If you like Phusion Passenger, please consider sending us a donation. Thank you!

Google Tech Talk on Ruby Enterprise Edition

Hongli Lai — Wed, 16 Dec 2009 00:53:40 +0000

Last Friday we visited the awesome Googleplex and gave a tech talk there about Ruby Enterprise Edition. This talk elaborates a bit on how REE works under the hood. Many thanks to John Woodell for making this possible!

Phusion Passenger 2.2.7 released

Hongli Lai — Wed, 18 Nov 2009 17:33:35 +0000

Sorry, I made a mistake while releasing 2.2.6. In the past few days we’ve closed about 30 issues in our issue tracker, but in the mids of it I forgot to remove a single line of debugging code in passenger-install-apache2-module, causing it not to compile the Apache module. I’ve just released 2.2.7 which fixes this problem, and it should be indexed by RubyForge any time now. Our apologies again for the inconvenience.

Phusion Passenger 2.2.6 released

Hongli Lai — Wed, 18 Nov 2009 14:41:59 +0000

Phusion Passenger is an Apache and Nginx module for deploying Ruby on Rails web applications, and is mainly focused on ease of use and stability. It is under constant maintenance and development. We are pleased to announce Phusion Passenger version 2.2.6. This is a bug fix release.

This will be one of the last 2.2.x releases. Next in the pipeline is 3.0. We believe that all the upcoming changes will be well worth the version number bump. But more about this in a later blog post.

Anyway, the following things have changed since 2.2.5:

Fixed compatibility with /tmp cleaners such as tmpwatch

Some /tmp cleaner programs such as tmpwatch try to remove subdirectories in /tmp/passenger.xxx after a while because they think those subdirectories are unused. This could cause Phusion Passenger to malfunction, requiring a web server restart. Measures have now been taken to prevent those tmp cleaner programs from removing anything in /tmp/passenger.xxx. Issue #365.

Autodetection now gives more priority to Rack than to Rails

When autodetecting the application type, Rack is now given more priority than Rails. This allows one to drop a config.ru file in a Rails directory and have it detected as a Rack application instead of a Rails application. Patch contributed by Sam Pohlenz: issue #338.

Increased default socket backlog

The default socket backlog has been increased from ‘SOMAXCONN’ (which is 128 on most platforms) to 1024. This should fix most ‘helper_server.sock failed: Resource temporarily unavailable’ errors.

Apache fixes

The location of the ‘apxs’ and ‘apr-config’ commands can now also be passed to the installer through the –apxs-path and –apr-config-path parameters, in addition to the $APXS2 and $APR_CONFIG environment variables. Issue #3.

Nginx fixes and changes

Various problems that only occur on 64-bit platforms (such as Snow Leopard) have been fixed.

The installer now installs Nginx 0.7.64 by default.

Various other fixes

Fixed compilation problems on Solaris. Issue #369 and issue #379.

Fixed crashes on PowerPC.

Some Ruby 1.9 compatibility fixes. Issue #398.

The installer now displays correct dependency installation instructions for Mandriva Linux.

How do I upgrade to 2.2.6?

Via a gem

Please install it with the following command:

gem install passenger

Next, run:

passenger-install-apache2-module

Or, if you’re an Nginx user:

passenger-install-nginx-module

Please don’t forget to copy & paste the Apache/Nginx config snippet that the installer gives you.

Via a native Linux package

John Leach from Brightbox has kindly provided an Ubuntu 8.04 package for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update’).

Once you’ve done this then you can install Phusion Passenger by running:

sudo apt-get install libapache2-mod-passenger

-or-

sudo apt-get install nginx-brightbox

(Note that John is currently packaging 2.2.6, so it might take a while before this release shows up in the apt repository.)

Final

Phusion Passenger is provided to the community for free. If you like Phusion Passenger, please consider sending us a donation. Thank you!