Present Perfect

I've been hacking on Paisley again recently since I found it I am not the only current maintainer. There is a branch on github from which a 0.3 release was recently made.

That's good news, because I didn't really need a new project to maintain. But I still have code I want to see land there, so I'm working on merging branches between launchpad, github, and some of my experimental svn branches here and there.

I had just implemented a cache for the object view mapping using couchdb-python's mapping.py and it turns out someone else was interested in adding memcache support to cache document lookups.

Some discussion started on a possible API, and I took a stab at a first draft over the past week.

Separately from that, I also took a CouchDB training course for work (together with Marek, one of our developers) ran by the Couchbase (company merger of CouchOne, formerly CouchIO (?) and Membase) people. That was a good training - but I digress.

At night Marek told me that they have some 300 lines of code that sadly reuses some classes from the current work codebase to set up and tear down test cases that work against an actual couchdb instance. He didn't feel like rewriting all that code to not use some of work's code just so that it could be contributed to Paisley for example. I felt I could do it in less than 100 lines, but he didn't seem to believe me.

So here I am after a magnificent Jose Gonzalez concert at the Palau de la Musica which is right around the corner from me, trying to write the caching code, and realizing I can't properly test it together with the change notification listener I wrote.

So while I was watching an episode of Breaking Bad, I wrote the setUp and tearDown code to do just that - start a couchdb instance on a random port, get the port, and connect to it.

It's probably not perfect yet (I do a busy loop for the creation and filling of the log file to read the port), but it worked for my simple test case. And it's 74 lines of code, including docstrings (which Marek for some reason does not believe in) and comments (which Marek also not believes in).

It's being worked on in this branch and I hope to land that in the paisley tree soon.

I've been hacking on Paisley again recently since I found it I am not the only current maintainer. There is a branch on github from which a 0.3 release was...

The first PyChecker release done by yours truly is out the door. You can download the source or install the Fedora 12/13/14 package from my package repository. I hope to push it in Fedora as soon as possible.

This release collects two years of bug fixes, and adds support for Python 2.7, which is now the default in Fedora 14.

I already have a few additional local patches that bring out a bunch of new (and correct) warnings in Flumotion, so I'll probably not wait another two years for the next release. My goal is to work towards a clean check of Flumotion.

The first PyChecker release done by yours truly is out the door. You can download the source or install the Fedora 12/13/14 package from my package repository. I hope to...

After more than two years, it's high time another PyChecker release is made. The previous stable release, 0.8.18, does not work at all with Python 2.7. I also implemented a slew of opcodes, and I fixed one particular bug a long time ago where modules with the same name (in different packages) where hiding each other's errors. Especially in Flumotion where most components have an admin_gtk.py, this was very common.

This is going to be my first PyChecker release, so I would appreciate it if you could give this prerelease a whirl and see how it works for you. I'm especially interested in hearing from projects that used to use pychecker but have stopped using it because it hasn't seen releases the past years.

Download the pre-release. The same directory has a src.rpm and a noarch.rpm for Fedora 14.

I plan to release this Saturday.

After more than two years, it's high time another PyChecker release is made. The previous stable release, 0.8.18, does not work at all with Python 2.7. I also implemented a...

... went a little something like this.

• home desktop upgraded to F14, still a bunch of packages missing.
• Want to do a release of moap because it's been too long, but can't because make check fails because pychecker fails because F14 is the first one with Python 2.7
• Look into pychecker failures. Figure out that there are new opcodes. Worse - for the first time I can tell opcode numbers have been shifted around. Find this bug where renumbering started; commented to ask if this was expected. Apparently it is, although no good reason for doing so has been offered. Shrug, not my fight, although it's going to make for ugly if's in Pychecker code.
• Realize I don't actually have Python 2.7 on the Pychecker buildbot page. Remember I have a script to build Python versions from source which now builds 2.3-2.7 and 3.0 (just check out and run make, then py-x.y to start a shell with that version of python).
• Add it to buildbot master config, restart, see buildbot fail spectacularly. Apparently buildbot was upgraded since I last started it, and code has been shuffled around. Spend a few hours figuring out how to upgrade buildbot and my code with custom steps without losing the history. Now have a buildbot 0.7.12 building on 2.7 as well.
• Add some ugly if's for python versions to handle opcode reshuffling. Brings down the test failures. Add some handlers for new things like POP_JUMP_IF_TRUE/FALSE and JUMP_IF_TRUE/FALSE_OR_POP. End up with only one test failure difference with 2.6
• Look into the remaining failure, realize that it is checking for constness of return results, and JUMP_IF_TRUE/POP_TOP pairs are now POP_JUMP_IF_TRUE, so peeking ahead to see LOAD_CONST should move by one opcode.

So, yay! That means CVS (yes...) HEAD of pychecker now works just as good for 2.7 as 2.6 and it's time to start releasing somewhere this week. And maybe I should push on and fix some of the older failures, or shelve them for now, while I'm at it, and have nicely green builds!

... went a little something like this. home desktop upgraded to F14, still a bunch of packages missing. Want to do a release of moap because it's been too long,...

I've been working on Paisley some more recently, finishing a first stab
at a document mapping API.

As discussed with Christopher Lenz a long time, I basically took his
mapping code and applied it to Paisley.

In my personal project I also added a caching version of the CouchDB
object, but I'm not yet convinced it is the right approach, so it's not
in Paisley yet. One of the things I think I will need to do to make
that useful is to have it listen to change notifications, so it can
change cached objects when they change in couchdb, and implement
notifications for these changes so that a program can be informed of
them too and react accordingly.

In any case, I'd like to work towards a release, so feel free to take a
look at
the branch I've made to implement this on, give any feedback or
do any code review, and let me know.

I've been working on Paisley some more recently, finishing a first stab at a document mapping API. As discussed with Christopher Lenz a long time, I basically took his mapping...