Dev (old posts, page 8)

Handling connection reset issues with bitchx

, | Tweet this

I'm testing out bitchx at work on my other latop which I ignore in the back of my monstrously large cube. The problem is that I'll ignore it for an hour and then go back to discover that I've had my connection reset like 60 times and I can't see any of the conversation at all.

I think the problem is that the router between me and the Internet drops sessions that aren't passing data. Telnet has an AYT kind of thing to deal with this. So I started looking for similar things in IRC land (to which I'm pretty new) and discover nothing. The problem is that I don't know what they would call it and when I do a Google search for the error message, I get everyone's IRC logs.

bitchx has a timer, though. So I tossed an event in the timer to whois thepresident (who doesn't exist) every 2 minutes. That seems to have solved the problem.

The better solution would be for there to be more people hanging out on #pyblosxom thus creating more data going back and forth.

gnome-blog

, | Tweet this

I'm testing out gnome-blog.... Not entirely sure what all these things do....

I'll post this entry and see if it does what I'm hoping it'll do.

Update: it sort of did what I expected. Gnome-blog seems to wrap everything in <p> stuff. It seems it handles the html for you which is nice, I guess. I had to go in manually and edit the resulting blog entry, though.

Programming as if performance mattered

, | Tweet this

I thought this article was pretty interesting.

It's very often that I'll be working on a project and focusing on behavior issues when someone will come along and tell me it's not optimized fully. They're right in a sense, but I don't really care generally and certainly don't care while I'm trying to get the behavior right. It's not as if the code I'm writing is wildly unoptimized... it's just a bit unoptimized.

Time to step down

, | Tweet this

I've passed off Lyntin maintainership to Eugene a few days ago but made the official announcement today on both the mailing list and the web-site. It's sort of bitter-sweet for me. Sweet in that I needed to drop a project or two because I've got too many. Bitter in that I've spent a lot of time working on Lyntin and I'm leaving with a few things I had wanted to do, but never got around to doing. Even so, it was time to hand it off. So ends a chapter of my development life.

More more static rendering....

, | Tweet this

I checked in some fixes to the static rendering code and it's working nicely. I fixed my flavour files, made some adjustments to my plugins and then re-rendered everything. My statically rendered site is at http://bluesock.org/~willg/test/.

Things the static renderer is not good at:

  1. figuring out if an entry has moved from one category to another (you'll probably end up with two versions)
  2. comments (if someone adds a comment, that doesn't adjust the mtime on the entry file, so we won't re-render)
  3. figuring out if material has changed on other pages (if you add an entry to april on the 4th, the other april pages won't reflect this in the calendar--they would need to be re-rendered but pyblosxom can't figure that out nicely in a general fashion)

Those are somewhat complex problems. One way to fix them is to store a record of which pages belong to which categories and dates. So then if an entry is updated in April, we'd figure out that we really need to update all April entries. That fixes the immediate problem of pycalendar, but doesn't provide a generic fix and I'd prefer not to have to store records of things if I don't have to.

Robert suggested I add a callback for plugins to tell me what urls need to be rendered. If you extrapolate on that, the plugins could also take a look at what's changed since the last time we rendered and figure out the related pages that also need to be re-rendered. For example, pycalendar could implement the callback, get a list of entries that are going to be re-rendered, notice that one of them is in april, and then tell Pyblosxom all the April entries need to be re-rendered as well as the entries in May (because of the "next month" link) and March (because of the "previous month" link). Not sure that's a really wildly good idea. And the effort involved is pretty high. I think it'd be easier on everyone if the suggested fix is to build a cron script that does this:

   #!/bin/bash
   cd /home/willkg/public_html/cgi-bin/
   ./pyblosxom.cgi --static
   find /home/willkg/public_html/test -mmin +30 -exec 'rm' '{}' ';'

That'll run the static renderer and then remove any file that was modified over 30 minutes ago (i.e. it didn't get touched by the static renderer).

Fewer plugins

, | Tweet this

I've decided I don't really need to be running all the plugins I had running. So I've removed a bunch. The good news is that removing a plugin requires the following extremely difficult steps:

  1. remove the plugin from load_plugins in my config.py file

If I want to completely eradicate the plugin:

  1. delete the plugin file from the file system
  2. delete all entries in config.py that have to do with the plugin
  3. delete any data files the plugin used from the file system

Anyhow, I'm probably going to install comments, pingbacks, trackbacks, quarter-backs, double-decaf-half-backs, atom, madam, and all the other possible ways for blogs to intertwine with one-another over the next week so that I will finally have an inkling of what all the hubbub is about. [1]

[1] I also want to fix the comments documentation, test all the code, and get everything ready for a 1.0 release some time in my lifetime.

Solving circular import problems with Python code

, | Tweet this

I keep bumping into circular import problems. While some say it's a symptom of bad design, I'm not wholly sure I agree. Some systems are just really complex. Not everything can be refactored into a pretty little UML diagram.

Anyhow, there's a link on daily python url to Victor Ng's blog entry on his experience with circular import problems with Python. The comments of that blog entry are wonderfully enlightening.

Testing static rendering....

, | Tweet this

I'm going to write this entry, see if it gets picked up by the static renderer, then I'm going to edit it and see if it gets picked up again.

Ok... editing it.

Neato--works super.