I'm in some kind of Lyntin development kick again. I implemented all the changes I talked about in yesterday's email:

• removed #import and added #load and #unload
• fixed addCommand so that it removes a command first (and its help file)
• changed the order of how modules get imported

Then on top of that, I wrote a testing module and started building tests for various functionality. It's not a great module, but it definitely gives me the ability to programmatically regression test large portions of Lyntin's functionality. The issue now is that I have a lot of tests to write, run, and then verify. It's somewhat time consuming. I don't plan on releasing 3.2 until I get a significant number of tests done and verified.

Additionally, I worked out how I want to handle the config stuff. I still have to write it out and fill in the details. I want to release 3.2 and get some other things cleaned up before I start on the config stuff.

So while the lyntin-devl list is deathly quiet, there's definitely stuff happening.

Last week I took a break from Lyntin development and I'm probably not going to do much this coming week either. Having said that, I made some minor changes last week including:

• moved the databuffer to the session class, ditched datagrep and datagreplines commands, and added a grep command (with context flag)
• removed the threadmanager
• gave some good thought to the config system

Then Josh implemented his default argument code for the argparser which is extremely cool though I'm not entirely sure we should be storing those kinds of things in the variable manager.

Read more about it here.

I've been using PyBlosxom for 3 months now and it just keeps getting better. On top of that, the development and user communities have grown significantly in the last month--definitely a testament to the project and its maintainer.

I spent a few hours working through a second tutorial for Lyntin module development. The first one covers the basics of developing modules in Lyntin and also walks through the basics of creating Lyntin commands. This one walks through the basics of hook usage.

I don't have any ideas for writing a third tutorial, so I'll wait until I'm inspired.

Josh discovered a page on the Python wiki that talks about Large Python Projects. Turns out that Lyntin is one of three listed. There are probably a lot of other large Python projects out there so that doesn't really mean quite what we think it means. Anyhow, they list us as having 11,856 lines of code back in July of 2002.

Josh and I then used their pycount.py script to figure out how many lines we have now and discovered we have 14,024 total lines (listing here) of which 6,157 lines are actual code, 4,649 are doc-strings and 1,171 are comments. That means that 41.5% of our code-base is documentation. That's pretty cool. How many projects can say that about themselves?

So, I was looking around in the wide wide world of blogging and saw a bunch of sites that list the categories they have on the side along with their archives and calendars and all kinds of fancy things... And I wanted one too!

I took a gander at the pyarchives.py plugin and then cannabalized it into pycategories.py which returns that fancy list of category links you see on the far right under the calendar.

Then like a good boy, I added it to the CVS repository figuring it's probably going to be a must-have feature rather than an eclectic feature that only a few of us real blogging odd-balls would want.

Yesterday I slam-dunked some code to form some infrastructure for plugin modules--I figured I've done this for Lyntin and Stringbean, might as well go for the hat trick! The code allows us to build a set of callback chains and such to let people extend the functionality of pyblosxom without having to re-write pyblosxom internals. Blah blah standard plugin stuff.

At some point, I'll write a tutorial to use it beyond the brief documentation I left in the api module. Until then, I leave the following excerpt for how it all ties together using the pycalendar module as an example.

01: """
02: This is my fancy pyfortune module.  Basically what it's going to do
03: is call /usr/local/bin/fortune and populate the fortune variable
04: with the resulting string.
05: """
06: import commands
07: from libs import api, tools
08: 
09: class PyFortune:
10:   def __init__(self):
11:     self._fortune = None
12: 
13:   def getFortune(self, args):
14:     entry_dict = args[0]
15:     text_string = args[1]
16:     if self._fortune == None:
17:       self._fortune = commands.getoutput("/usr/games/fortune")
18: 
19:     return (entry_dict, tools.parse({"fortune": self._fortune}, text_string))
20: 
21: def initialize():
22:   api.parseitem.register(PyFortune().getFortune)

Figure 1: libs/plugins/pyfortune.py

Mmm... It occurs to me that this doesn't use the api module at all. On the other hand, it's pretty neat looking, so I'll leave it for now. At some point someone is going to have to remind me to write an api usage example.

Have a dynamically generated fortune:

...

This fortune has been removed because it turns out that dynamically generated text causes RSS feeds to think this is a new entry every time. Thus, no fortune for you!

I broke out my Programming Python (2nd Edition) book and doubled my Tk knowledge in the space of an hour or two. I went through the tkui and fixed up a lot of issues involving thread contention. The tkui should be more stable now, titlebar manipulation works again (through the settitle(...) method), NamedWindows work, I fixed the Autotyper, and I went through and cleaned up the code while I was at it. All in a good night's work.

This was the last big issue I needed to solve before releasing 3.1 which has some sweeping fixes in it.

I finally finished the complete overhaul of the Stringbean driver. It's now separated into a driver and a mudlib. I have everything implemented as a series of hooks and managers. Some portions are a bit awkward, though and could probably be re-written. Some components are implemented simplistically for now until I (or someone else) design and implement a more sophisticated version. All in good time, though.

Currently implemented: commands, emotes, heartbeats, lookables, exits, simple NPCs, connect, disconnect, and some other stuff.

So for some reason (and I haven't done enough research to even describe the problem adequately) Tk in Python 2.2.2 will hang (the entire Python process) when you go futzing around with the members of whatever you get back from Tkinter.Tk(). It only seems to have this problem on Windows 2000 and Windows XP. No one has mentioned issues on other platforms.

Anyhow, so I was going to do a version release this last weekend (that would be January 5th), except now I have to go puzzle through why Tk is being so twitchy.