*scottstuff*

We made a lot of progress this weekend on Typo. We’re down to 9 open tickets, and several of those aren’t really code issues–things like “set up a Typo blog on http://typosphere.org” (which is mostly done, actually). There are a few bugs left, and one or two minor development points, but at this point the thing we really need most is some testing. If you use Typo, then I’d love it if you could either test the latest trunk or the latest .gem release (sudo gem install typo; typo install /some/path) and file bugs.

I think I just killed The Great Typo Memory Leak of 2006 (not to be confused with last year’s great memory leak).

I think this was the leak that has been causing so many problems for Typo users on shared hosting systems lately. I’d been putting off debugging it, because there really aren’t any good tools for Ruby memory leak tracing, and there’s enough magic in Rails that makes it hard to even fully understand the control flow in your rails app, much less when memory is being allocated and freed.

Since Typo 4.0 is nearly ready for release, I was running out of time to fix it. Fortunately, during some benchmarking this morning I discovered something useful:

1. With the cache disabled, my Typo processes stay around 30 MB.
2. With the cache enabled, my Typo processes grew to 70 MB within a couple hundred hits to the same URL.

Since the cache-hit path is about 1/100th as long as the cache-miss path, it’s a lot easier to debug. And since we’re using our own reimplementation of Rails’s Action Cache, I have a decent understanding of the caching code. As it turns out, though, I think the normal action cache would have had the same problem.

The problem was that we have multiple before and after filters, and at least one of them saves state in the before filter and expects the after filter to free it. But suppose our filter order looks like this:

  stateful_before_filter
    action_cache_before_filter
      render a page
    action_cache_after_filter
  stateful_after_filter

The problem is that the action cache’s before filter will cancel the rest of the render chain if it gets a cache hit. So stateful_after_filter will never be called. So, whatever stateful_before_filter saved (by shoving it into a class variable, for instance) is now with us forever.

In general, you should be able to fix this by adjusting the order that you apply your filters. The first call to around_filter goes on the outside and all further calls are nested inside it. However, Typo currently applies a couple filters in a superclass controller, so there’s no easy way to move the caches_action call into the superclass. So, as a workaround, I changed the call to around_filter in caches_action_with_params to be prepend_around_filter instead of around_filter. Now my Typo processes stay around 32 MB even after thousands of cached hits.

Longer-term, I want to clean up our controller hierarchy, because I don’t fully understand why we need multiple layers of stacked controller classes when 95% of Typo is in one controller. But for now the memory leak is fixed and we’re back on track for Typo 4.0 in the next week or so.

There’s a lesson here to other Rails users–be careful nesting filters when you’re using the action cache (or any filter that can terminate the request), because you can’t depend on the after_filter being called. If you save things in the before_filter, expect leaks unless you’re very careful with your filter nesting order.

I did a bunch of Typo bug triage this morning, and road to Typo 4.0 finally looks clear. We currently have 8 open Typo 4.0 tickets, and none of them look very difficult. I’m still waiting for more feedback on the Typo Installer, and that’s really the biggest issue keeping Typo 4.0 from being released now. I expect that it’ll take a week or so before I’m comfortable enough with the installer to release it to the general public.

If there’s something that you really want to see in Typo 4.0 that isn’t already in the tree, then this is probably your last chance to speak up.

Hot on the heels of this morning’s Typo 3.99.0 release comes Typo 3.99.1. Somehow, 3.99.0 worked much better on my laptop then it’d work anywhere else in the world. Oops. Give the new version a try if you want to test out the new installer.

I just uploaded a gem for Typo 3.99.0 to Rubyforge. Once it propagates, people should be able to test the new Typo installer by running two simple commands:

    $ gem install typo
    $ typo install /tmp/typo

This is a test release; please don’t overwrite your existing, working Typo build with the new Typo installer.

I’d love to get some feedback from people about the installer, though. If you have a chance, give it a shot and let me know if it works. It should pull in Rails 1.1.4 and Mongrel all on its own, and then freeze the Rails gems into vendor/. I had to write my own Rails freeze code, because rake rails:freeze:gems won’t let you specify which Rails release you’re freezing, and I’d like to allow people to continue to install Typo even on systems that have Rails 1.2.x installed. I could have just bundled all of Rails into the Typo gem, but that’d be an abuse of the packaging system. As it is, it should all ‘just work’.

I still have a few things that I need to do before the installer is complete:

1. Actually write the Apache HTTP proxy instructions (for 1.3 and 2.x)
2. Add lighttpd proxy directions.
3. Figure out how to best have Typo restart on reboot.
4. Handle the ”missing swig” problem better.
5. Figure out of the installer will work on Windows.

We also have a couple issues remaining before Typo itself is ready to be called 4.0.0, but we’re getting pretty close. If a few people could test this pre-release for us, then we should be able to get 4.0 out within a week or two.

Update: Expect 3.99.1 in a few hours. There are a couple substantial installer bugs when running from the .gem file. They aren’t dangerous, but they’ll keep it from working in many situations.

If I’ve learned anything from Typo, it’s that Rails apps are a serious pain for first-time users to install. Here’s what it takes to get Typo (or any open-source Rails app) up and running on a random Unix box today:

• You need a working database, like MySQL or PostgreSQL.
• You need to know how to create at least two databases for Typo.
• You need Ruby 1.8.4
• You need rubygems installed.
• You need Rails 1.1.x
• You need Ruby drivers for your DB.
• You need Ruby FCGI drivers installed
• You need a web server with FCGI installed
• You need to download Typo and figure out how to install it without a useful README.
• You need to configure your web server to run Typo’s FCGI dispatcher.
• You need to get all of the permissions right, especially if your web server runs under a different user ID then you normally use.

Sometimes I’m amazed that Typo has as many users as it does. I’ve been promising to do something about this for months, and it’s finally getting close to working. Here’s what you’ll need to do to get Typo running once I’ve released the installer:

  $ gem install typo
  (installs Typo, Rails, mongrel, sqlite3-ruby, and whatever else we need, as defined by the Gem spec)
  $ typo install /var/www/my_typo_site
  Typo Installer
   Checking for existing Typo install in /var/www/my_typo_site
   Reading files from /usr/lib/ruby/gems/1.8/gems/typo-4.0.0
   Copying 755 new files into /var/www/my_typo_site
    copying /CHANGELOG
    copying /MAINTAINERS
    copying /MIT-LICENSE
    ...
  Creating default database configuration file
  Creating initial Typo SQLite database
  Migrating Typo's database to newest release
  Running tests.  This may take a minute or two
  All tests pass.  Congratulations.
  Starting Typo on port 4936

  Typo is now running on http://scott17.local:4936
  Use 'typo start /var/www/my_typo_site' to restart Typo after boot.
  Look in /var/www/my_typo_site/installer/apache.conf.example to see how to integrate Typo with Apache.

The installer sets up a complete Typo installation from a Ruby Gem in a directory of your choice, and then take care of creating a SQLite database for you. Instead of FastCGI, it uses Mongrel, because it’s easier to do HTTP proxying then FastCGI 95% of the time. The same installer knows how to upgrade an existing Typo install–just run typo install on the same directory again, and it’ll shut down mongrel, back up your database, upgrade all of the files that need changed, run migrations, retest the installation, and then restart Mongrel.

This isn’t the ideal install for everyone, but it should be good enough for most people, and there’s really nothing preventing people from hand-installing Typo. There’s certainly nothing preventing people from using Capistrano or any other heavier-weight management system, but that’s overkill for most personal blogs.

Right now, the installer works for me, but it’s not quite ready for wider use. I still need to add Rails freezing support, as well as a bit of subversion support, and I need to clean up the code a bit more. Once that’s done, I’ll check it all into the Typo trunk and then I’ll start building Typo 3.99.x GEMs for people to test. Once we’re reasonably confident that the installer and the current trunk work for people, I’ll go ahead and release Typo 4.0.0.

Once Typo 4.0 is out, I’ll see what I can to do extract the Typo installer into a generic installer for lightweight Rails apps. I doubt that Typo is the only project that could use something like this.

I just released version 1.0.3 of the Rails Schema Generator. This is a minor release; I added a db/schema_version file. This is needed for the Typo installer, which should appear reasonably shortly.

I’ve been trying to get Typo working with SQLite 3 on my Mac off and on for MONTHS with no success. The root problem was simple:

  a = Article.new
  a.title = 'Testing'

  a.save => true
  a.id => 0

Somehow, the ID wasn’t being updated whenever new ActiveRecord objects were created. They’d end up in the DB just fine, but the new ID wasn’t visible from Ruby. Since this is a really basic feature of any ORM, I was really amazed that it didn’t work. A bit of research shows that SQLite and Rails work fine for most users, but I’m not alone with this problem–there are a few reports of similar problems on the Rails wiki.

For the fun of it, I installed SQLite on one of my Linux boxes, and everything worked fine there. So I tried installing a newer SQLite via DarwinPorts, with no improvement. I spent a couple hours uninstalling and reinstalling things, and nothing changed anything. Digging deeper, the bug was clearly deep inside of sqlite3-ruby–it was telling Rails that the ID number for the latest insert was 0.

I finally figured out the problem here at Gnomedex today while watching to the Gillmor Gang record their latest podcast. It’s simple:

The SQLite bindings for Ruby require SWIG. If SWIG isn’t installed, then they’ll still work, sort of, but they fail to fetch the ID from SQLite.

So, to fix the problem, I just ran port install swig, then gem uninstall sqlite3-ruby and gem install sqlite3-ruby.

There’s probably a endian problem in the non-SWIG SQLite Ruby code, but it’s easier (and probably faster) to just install SWIG.

Don’t get your hopes up too high, but I’ve finally had a bit of time to work on Typo again. Hopefully this will continue, and I’ll be able to fix the current round of bugs and finish the Typo installer that I’ve been promising for months. Once that’s done we’ll finally release 4.0.

I’m a little uncertain how involved I’ll be with Typo after 4.0 ships. On one hand, I have a few things I’d love to add. On the other hand, I’m really a terrible maintainer–I’m much better at adding new features then applying waves of bugfixes week in and week out.

So we’ll see how it goes. There’s a lot of admin work that I’d really like to do, and spam blocking is getting more and more important. And there are some microformat things that I’ve been itching to do for months.

We’ve been talking about releasing a new stable version of Typo since October, with no real success. Frankly, I’ve only spent a few hours per month on Typo since I started working for Google in late November, and that’s not enough to get a major release out. Fortunately, most of the weirdness in my personal schedule seems to be over, now that I’m done commuting back and forth between Seattle and Silicon Valley once or twice per month. I still don’t have as much free time as I used to (Google keeps me busy), but I’m not spending every minute preparing to travel and dealing with the consequences of life on the road.

So, now that I’m back on a normal schedule, it’s time to get serious about releasing a stable version of the current Typo trunk. I’d like to release Typo 4.0.0 before April 1st. Frankly, 95% of the features that we want for Typo 4.0 are already in the tree, so mostly we just need bug fixing and testing. There are a few features that need some finishing work, and one feature that still needs to be implemented, but late March should be workable, if people can pitch in and help a bit.

As I see it, here are the areas that we really need to work on:

• Trackbacks (they’re still utterly broken)
• Podcasting (cleanup and testing)
• Notifications
• Threaded comment support (optional)
• Migration cleanups
• Merge one or two theme contest themes.
• Bugs, bugs, bugs

I should probably explain the “threaded comments” bit–months and months ago, I wrote some threaded comment code for Typo. Tobi didn’t want it in Typo, so he (correctly) refused to merge it. I’m still using my threaded comment code here, maintaining it in parallel with the Typo trunk. The problem is that there’s no easy way to merge the old threaded comment code with Piers’s big STI patchset, so I’m stuck running an older version of Typo here. I can’t upgrade without either losing all of the threading information that I’ve accumulated or spending some time adding minimal threaded comment support to Typo. I’ve discussed my Big Plan for comments in Typo, but I don’t think I’ll have time to implement everything in the next month; instead I want to concentrate on getting something released, and then we’ll spend some more time enhancing comments for Typo 4.1.

There’s one big thing that I need from people if we’re going to be able to make this schedule: help getting back on top of all of the bugs in Typo’s Trac. We were trying to keep the number of open tickets below 50 for most of last year, but now we’re up to 165, and that’s too many for me to easily manage. So, I need to start applying patches and closing them. If there’s a patch that’s ready to apply, or a simple ticket that doesn’t need more then 5 minutes worth of work, can you please leave a comment here? Thanks.

Finally, to answer the inevitable question: where is Typo 3.0, you ask? Months ago, we decided to skip version 3.0, to avoid confusion with Typo3. So we’re going from Typo 2.x to Typo 4.x. That’s it.