Oakwinter.com :: Code

So, there was originally supposed to be a Perl version of svnmock included in this release. I spent a day or two working on it before remembering how much I hate Perl. svk rm branches/perl felt somehow purifying.

On the upside, recoding the package from scratch gave me some good ideas about how to improve some things in the Python version. The main change in the 0.3 release is that you no longer have to explicity declare and directly manipulate a MockSession object; svnmock.mock takes care of creating the inital MockSession for you, then provides convenience add_command, add_error, etc, module-level functions to manipulate it. This turns out to be a big win in practice.

In other good news, svnmock’s internals will be serving as the model for the rewrite of DBD::Mock that I’m working on. DBD::Mock’s guts are currently…well…not something you’d bring home for dinner at your parents’. Again, this will be a big win, both in terms of code maintainability and in functionality.

All of my Python packages make use of setuptools, an extension to Python’s built-in distutils package that’s supposed to make life easier for everyone. After a recent mucking-about with my Python install, I got to see what happens if you try to use a setuptools-dependent package without having setuptools.

Now, you’d think the answer would be, “It doesn’t work. Duh,” but one of the package’s “features” is that

Your users don’t need to install or even know about setuptools in order to use them, and you don’t have to include the entire setuptools package in your distributions. By including just a single bootstrap module (an 8K .py file), your package will automatically download and install setuptools if the user is building your package from source and doesn’t have a suitable version already installed.

It’s that last bit that kills me. It’s just assumed that you have an always-on Internet connection, and God help the poor bastard who doesn’t.

Now, the logical thing to do would have been to have the bootstrap module attempt to download setuptools, but with a time out on the connection. If the module was unable to contact les Internets, it would attempt to fall back to the shipped-with-Python distutils. If the package-to-be-installed’s setup script used some setuptools-only feature, then it should inform the user that she’ll need to download setuptools manually.

My solution was to rip the bootstrap module out of my packages, then tweak setup.py like so: instead of

from setuptools import setup

I do this

try:
    from setuptools import setup
except:
    from distutils.core import setup

That way, if the user has setuptools installed, great, we’ll use that. If not, we fall back to distutils. This plan works, but it’s not foolproof; distutils still raises some harmless warnings about certain arguments to setup that it doesn’t recognise, but beyond that, this solution gets me where I want to go.

It’s a pretty frequent event that while reading, say Audrey Tang’s blog or the Haskell mailing lists, I someone mentions some journal article that catches my eye.
It’s also a pretty frequent event that after I download the PS or PDF of the paper, it sits untouched on my harddrive for months before I remember that, Oh yeah, I meant to read such-and-such last year.

In an effort to hold myself a little more accountable on this front (i.e., make sure these papers actually get read), I’m going to keep a list here and check off articles as I finish them.
The current reading list:

Compilers

• Cheap Deforestation for Non-Strict Functional Languages (Gill, 1996)
• Haskell on a Shared-Memory Multiprocessor (Harris, Marlow & Peyton Jones, 2005)
• Making a Fast Curry: Push-Enter vs Eval-Apply for Higher-Order Languages (Marlow & Peyton Jones, 2004)
• Playing by the Rules: Rewriting as a Practical Optimisation Technique in GHC (Peyton Jones, Tolmach & Hoare, 2001)

Functional Programming

• Object-Oriented Style Overloading for Haskell (Shields & Peyton Jones, 2001)
• Scrap More Boilerplate: Reflection, Zips and Generalised Casts (Laemmel & Peyton Jones, 2004)
• Scrap Your Boilerplate With Class: Extensible Generic Functions (Laemmel & Peyton Jones, 2005)
• Scrap Your Boilerplate: a Practical Design Pattern for Generic Programming (Laemmel & Peyton Jones, 2003)

Garbage Collection

• A Real-Time Garbage Collector Based on the Lifetimes of Objects (Lieberman & Hewitt, 1983)
• Connectivity-Based Garbage Collection (Hirzel, 2004)
• Garbage Collection in Java (Martin, 1997)
• Quantifying the Performance of Garbage Collection vs Explicit Memory Management (Hertz & Berger, 2005)

Miscellaneous

• Interpreting the Data: Parallel Analysis with Sawzall (Pike, Dorward, Griesemer & Quinlan, 2006)
• The Google File System (Ghemawat, Gobioff & Leung, 2003)

Type Theory

• Once Upon a Polymorphic Type (Wansborough & Peyton Jones, 1999)
• Simple Usage Polymorphism (Wansborough & Peyton Jones, 2000)
• Type Theory and Functional Programming (Thompson, 1999)

For the curious, I’ve made the papers available on my server.

Also, I’m looking for a file manager that uses tags (like Google Mail) instead of directories. Anyone have one of those lying around?

The functional project has seen a lot of work since its inception (which predates its announcement). Version 0.1 was released on 19 January, and now less than two weeks later, version 0.5 is making its way to PyPI.

This latest release sees the project split into two branches. One is written, as before, in pure Python, targeting readability and portability. The second is coded in C, aiming for raw performance. Both support the same functionality and pass the same test suite.

Speaking of functionality…I was digging around the itertools module the other day and what should I discover but pre-existing implementations of most of functional’s members. All the duplicates have been stripped out for the 0.5 release. I’m hoping to add more useful higher-order tools to replace them.

Well, released a few days ago, but still.

The big news for 0.2 is the addition of tracing support and a rearrangement of the internals to support it. svnmock.trace allows you to keep a running log of which API functions have been called, with what arguments and what it returned (it logs raised exceptions, too!). You can then pretty-print the log and examine it to make sure things are going as planned.

Why would you want to do this? It’s great for quick debugging work when you don’t want to spend quality time with svnmock.mock, scripting up an entire session. That session may involve thousands of API calls, whereas svnmock.trace can skip directly to the area you’re concerned about.

On the horizon for 0.3:

• A tool to turn the output captured by svnmock.trace into a MockSession object.

• A perl port. svnmock -> SVN::Mock.