ActiveState Code is a site for sharing code recipes. It is the replacement for the popular ASPN Cookbooks (especially the Python Cookbook, which was a collaboration with O’Reilly and Associates that resulted in two print cookbooks using recipes from the site). The new site adds things like tagging, the ability to add recipes in a number of other languages, and a fresher and hopefully more usable site.

Migration should be easy. All recipes from the Python, Tcl and PHP Cookbooks have been carried over. Redirects maintain all old aspn.activestate.com/ASPN/Cookbooks links. Recipe id and author ids have been maintained. The ASPN Cookbook categories have been translated into tags in the new system — full details here.

I welcome any feedback on the site.

I’ve had lots of good feedback from the Python community (Apologies if I haven’t gotten back to you yet. I will.) and have made a number of changes based on that feedback. I’ll post more details once the site has been switched over.

We get requests for localizations of Komodo every so often, but lack the resources to do this ourselves. Given a number of good translations here, I can start providing language pack extensions to Komodo’s add-ons site.

This is a trial balloon that I really hope turns out well. I remember having a great chat with Michal Berman about Mozilla’s l10n infrastructure at FSSOS 2007 waaay back in October last year. I dropped that ball following up after that discussion. I’d also like to take a look at Launchpad Translations to see if that would work well.

If you are interested in helping out with translating Komodo to your language, please take a look at this forum thread and/or let me know (trentm at activestate dot com).

What this site offers over the ASPN Cookbooks:

• a complete visual refresh (long overdue)
• full tagging support of recipes
• support for many many more languages (the ASPN Cookbooks were restricted to Python, PHP, Tcl and XSLT recipes)

In addition, the new site provides a sound foundation for other improvements — so tell us what you think!. What is missing? What doesn’t work? What would make the site more useful for you? for your community?

While the site is in beta, new recipes, comments and votes are not saved — instead the site’s data will be sync’d from the ASPN Cookbooks most nights. The plan is to fully move to this new site in two weeks, shutting down the old ASPN Cookbooks (redirects will preserve all old links).

After a hiatus while I worked hard on the Komodo 4.3 release with the Komodo crew here, I’ve finally had the chance to update ActivePython 2.5 and 2.4 to the latest.

Full details in the ActivePython release notes. These releases update the core to Python 2.5.2 and 2.4.5.

Enjoy.

Last Friday gives me good reason to post about it: We now have a “nightly” channel for Komodo Edit!

Komodo Auto-update channels

There are three Komodo auto-update “channels”:

1. “release”: This is the typical (and default) channel for installations of a final release of Komodo (e.g. 4.2.0, 4.2.1, 4.3.0). On this channel, Komodo will only update itself to the latest final Komodo release.

2. “beta”: This is the typical (and default) channel for Komodo alpha/beta builds. On this channel, Komodo will update itself to the final or pre-release (i.e. alphas and betas).

3. “nightly”: This is a channel that I finally got working on the server-side on Friday. Since the announcement of OpenKomodo and open sourcing of Komodo Edit we’ve been doing “nightly” builds of Komodo Edit (built on most nights :). These are publicly available here: http://downloads.openkomodo.com/komodoedit/nightly/

As of last Friday, if you are on the nightly update channel Komodo Edit will update to the latest nightly build. These are quite a bit more burning-edge that the “beta” channel. Often the only criteria for putting up a nightly is that the build worked for all platforms. So, occasionally some features are broken — though I think we do pretty well.

This channel is quite new for us though, so there may be some growing pains in the first couple of weeks. Please let me know if you have any problems with it. I think it will be pretty cool to easily always be running the very latest Komodo Edit.

At this time we aren’t yet doing public nightlies of Komodo IDE.

Setting the update channel for your Komodo installation

Currently there isn’t a prefs panel in Komodo to tweak auto-update settings — such as the channel you are one. There should be. I hope to get one in sometime after 4.3.0.

To set your Komodo channel edit “channel-prefs.js” in your Komodo installation as appropriate. On Windows and Linux this file is here:

INSTALLDIR/lib/mozilla/defaults/pref/channel-prefs.js

and on Mac OS X here:

INSTALLDIR/Contents/MacOS/defaults/pref/channel-prefs.js

It is a very simple file that looks like this:

// Valid values are "release", "beta" and "nightly" (internal-only).
pref("app.update.channel", "beta");

Happily that “internal-only” is no longer correct for Komodo Edit.

Other Komodo AUS Stuff

Komodo’s auto-update system, on the client side (i.e. the app), pretty much just uses the excellent Mozilla auto-update system. On the server-side we have our own (very simple) Django-based update server. On the build-side, we have our own Python scripts (mozupdate.py et al) for building all relevant partial and complete update packages as part of full builds.

I hope to post more about our AUS server and about our build tools. I think I could fairly easily package up our tools to provide a possible answer to Mozilla Bug 415181 (Package the MAR generation tools for easy external usage).

There used to be an open bug (found it: Mozilla Bug 375752) to convert some of the Bash shell scripts for Mozilla update package building to Python scripts. I see (by way of Mozilla Bug 410806) that that has at least partially happened with make_incremental_updates.py.

Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

No release package yet (setup.py, setuptools, easyinstall, ezsetup? — my head is spinning), but you can get the file directly from SVN: markdown2.py.

This is the first project for which I am really using Google Code project hosting. I’m really digging it. Nice bug tracker, nice enough wiki (all wikis should use a source control system as their backend), svn. Goodbye sourceforge.

• source: http://svn.openkomodo.com/openkomodo/browse/openkomodo/trunk
• grok (an alternative to lxr): http://grok.openkomodo.com/source/search?q=koDirs
• wiki: http://wiki.openkomodo.com/index.php/Main_Page
• mailing lists: http://lists.openkomodo.com/mailman/listinfo
• irc: irc.mozilla.org #komodo

Check it out.

Quick build notes:

# Get the source
svn co http://svn.openkomodo.com/repos/openkomodo/trunk openkomodo
# Build Mozilla
cd openkomodo/mozilla
python build.py configure -k 1.0 --moz-src=cvs:1.8 --release \
    --no-strip --shared --tools
python build.py distclean all
cd ..
# Build Komodo
export PATH=`pwd`/util/black:$PATH   # Komodo's "bk" build tool
bk configure
bk build
# Run Komodo
bk run

If you have the build prerequisites setup, you should be able to cut ‘n paste the above. (Windows users, use the Windows-specific quick build steps in the README.txt.)

I have some (longer term) plans to reduce those build steps to:

./configure.py
mk

I’m hoping to meet a few of the Mozilla folks that will be there: Benjamin to ask about breakpad (I want to get breakpad running for Open Komodo and Komodo builds), looking forward to Mike Beltzner’s talk on UE design at Mozilla, Eric Shephed to ask about how mozilla handles localization of their docs.

As well, if any of the mozilla folks involved in the AUS will be there, I’d love to talk with you to compare notes with Komodo’s auto-update system.

Originally my interest in it was with the discussion surrounding santization, and I expect to use it for that later, but today I’ve been playing with some general parse/filter/serialize code to support some preprocessing of HTML documentation for Open Komodo.

My code looks like this:

import sys
from html5lib import treebuilders, treewalkers
from html5lib.serializer.xhtmlserializer import XHTMLSerializer

def filter_play(path):
    p = html5lib.XHTMLParser(tree=treebuilders.getTreeBuilder("simpletree"))
    f = open(path)
    dom = p.parse(f)

    walker = treewalkers.getTreeWalker("simpletree")
    stream = walker(dom)
    #stream = MyPreprocessingFilter()

    s = XHTMLSerializer()
    outputter = s.serialize(stream)

    for item in outputter:
        sys.stdout.write(item)

filter_play(sys.argv[1])

One thing that bugged me a little with the output generated with this is that attributes on HTML elements get sorted, i.e. their order is not preserved. While totally cool for correctness, this reduces the utility of using diff or similar for comparing input with output. As well, I work on the Komodo IDE/editor and would like to consider using html5lib for an HTML reflow/beautifier feature at some point. Preserving attribute order for this will be important.

To that end, here is a small patch that adds the ability to preserve attribute order in serialized output. To use it:

1. You need odict.py.

2. You need to change the above code to:

   ...
   s = XHTMLSerializer(preserve_attr_order=True)
   ...
   

Obviously this isn’t something that would be ready to check-in to html5lib. Reasons why:

• It only works for the “simpletree” treebuilder/treewalker. I’m not sure if it is feasible/practical to get it to work with some of the others (e.g. dom).
• It unconditionally requires an external non-standard module (odict.py).
• It should be optional on the parser because (a) using OrderedDict instead of dict would presumably have an undesired perf impact and (b) the attribute order normalization could be desirable for many users.

Maybe a better solution would be a custom “roundtriptree” tree type? Anyway, just throwing this up here to perhaps come back to later. I have to dig into the html5lib discussion list to see if this has come up before.