iCoreTech Research Labs Just a placeholder

Cappuccino: the jake branch

Those steps assumes you have already setup your Cappuccino source similarly to my environment.

If not, please read previous articles.

Keep in mind that the "jake" branch will be merged into master at some point, and the switch should happen sometime in the upcoming weeks; at least I've been told this way so take this information with a grain of salt.
Therefore: those instructions can turn obsolete at any time and probably are.

If you read my previous article you already know that I'm running Snow Leopard.
At any point do not close the Terminal window until you did every step.

Download Narwhal from GitHub.

cd ~/src/
git clone git://github.com/tlrobinson/narwhal.git

Activate paths and use tusk to install required packages.

source ~/src/narwhal/bin/activate
tusk install jake browserjs narwhal-jsc jack

Build Narwhal JSC:

cd ~/src/narwhal/packages/narwhal-jsc
make webkit
export NARWHAL_ENGINE=jsc

Build Cappuccino:

# if you don't already have a cappuccino source remember to have a CAPP_BUILD defined and
# git clone git://github.com/280north/cappuccino.git ~/src/cappuccino_source
cd ~/src/cappuccino_source
git checkout -b jake origin/jake
rm -rf $CAPP_BUILD
jake
jake debug # if you want also the Debug build
jake docs # if you want up to date local xml/html documentation, requires doxygen

Building Cappuccino with jake instead of rake will take some minutes to compile.

I read about some people reporting that the process gets stuck, this didn't happened to me (well it did, but because I was compiling against master by mistake); the jake building process took about 4 minutes to complete on a 2,53 GHz Unibody Intel Core 2 Duo Macbook Pro.

We are going to tweak our $PATH in order to find the new Cappuccino Tools and Narwhal binaries like jake.
Keep in mind that you probably already have them in /usr/local/bin so we must adjust our PATH with some precedence.
Old utilities in /usr/local/bin aren't modified by this procedure, since the jake task that should install them is currently commented.

Here is my .bash_profile related code:

# CAPP_BUILD, directory for built Cappuccino framework.
export CAPP_BUILD="$HOME/src/cappuccino_framework"
 
# Cappuccino jake branch.
PATH="$CAPP_BUILD/Release/CommonJS/objective-j/bin:$PATH"
PATH="$HOME/src/narwhal/bin:$PATH"
 
# Finalize PATH
export PATH=$PATH

This will make capp, nib2cib and press available on command line.

Reopen Terminal and test:

03:52 ~ $ which capp
/Users/kain/src/cappuccino_framework/Release/CommonJS/objective-j/bin/capp
22:42 ~ $ cd Sites/
22:42 ~/Sites $ capp gen MySecondApp -t NibApplication
/Users/kain/src/cappuccino_framework/Release/CommonJS/objective-j/lib/capp/Resources/Templates/NibApplication -> MySecondApp
# ...

Have fun!

On Cappuccino spriting and why it matters, part 1

The first working builds of sprited Cappuccino were released around 14th October.

If you're familiar with Cappuccino this means frameworks that include images/themes and also entire applications can be sprited.
This will be the default behaviour for Cappuccino applications, we'll talk about advantages in a bit, first, a word about spriting if you're wondering what is it.

Developed around mid-1970, spriting is a technique still used today; if you're into CSS you might have used it.
If you're old enough and curious you may have also dug into a videogame's resource files and you may have seen images composed of multiple little images in a grid.

In fact spriting mostly consists in placing images into a larger image grid, and display the image we are requesting by supplying its correct position in the grid.

What that means in Cappuccino?

Simply put, by using spriting, Cappuccino can squeeze all your project's images in a single file, thus reducing the number of requested/served files.

This is a big gainer, since Cappuccino also makes intensive use of themes; Aristo, the now default theme, counts around 111 files.
They will be only 2 after spriting kicks in for all users in master branch.

The wonderful thing is that it's built-in, you are not required to do this kind of stuff. Couple that with the fact that will be using Narwhal-JSC soon, Cappuccino will be *really* fast.

I will discuss with Francisco Tolmasky (tolmasky) of 280 North about how spriting works in Cappuccino and as usual will report my findings here, in a second part of the article.

Foundation.j and AppKit.j 404

During some Rails integration with Cappuccino I noticed that my Rails' logs were filling fast with 404s.

At first I thought I did something wrong in including my Frameworks, however it turns out that's a normal behaviour by design.

I won't go into the details here on why it's happening, but here's a solution:

Ruby on Rails

To avoid the stack trace generation overhead in Rails simply put down those routes:

  map.connect '/Frameworks/Foundation/Foundation.j',
    :controller => 'application',
    :action     => 'handle_cappuccino_404',
    :conditions => { :method => :get }
  map.connect '/Frameworks/AppKit/AppKit.j',
    :controller => 'application',
    :action     => 'handle_cappuccino_404',
    :conditions => { :method => :get }

Then in your handle_cappuccino_404 method you can simply render :nothing => true:

class ApplicationController < ActionController::Base
  def handle_cappuccino_404
    render :nothing => true
  end
end

I think we can't rescue_from ActionController::RoutingError at this point.
Please also read another solution involving Rails Metal below.

Rails Metal

I was thinking about using Rails Metal to avoid even the extra bits:

script/generate metal cappuccino

Then in app/metal/cappuccino.rb:

require(File.dirname(__FILE__) + "/../../config/environment") unless defined?(Rails)
 
class Cappuccino
  def self.call(env)
    if env["PATH_INFO"] =~ /^\/Frameworks\/Foundation|AppKit\/Foundation|AppKit.j/
      [200, {"Content-Type" => "text/html"}, []]
    else
      [404, {"Content-Type" => "text/html"}, ["Not Found"]]
    end
  end
end

No need for the method described above: you can safely remove routes and the 404 handling method from your controller.

Sinatra

To avoid it in Sinatra:

# from http://github.com/mchung/cappuccino_sandbox
get "/Frameworks/AppKit/AppKit.j" do
  [404, {}, "Look elsewhere"]
end
get "/Frameworks/AppKit/Foundation.j" do
  [404, {}, "Look elsewhere"]
end